Bug 148499 - add compile on save features to maven projects
add compile on save features to maven projects
Status: RESOLVED FIXED
Product: projects
Classification: Unclassified
Component: Maven
6.x
All All
: P2 (vote)
: 6.x
Assigned To: Milos Kleint
issues@platform
:
: 159762 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-26 16:00 UTC by Milos Kleint
Modified: 2009-11-19 11:05 UTC (History)
6 users (show)

See Also:
Issue Type: TASK
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Milos Kleint 2008-09-26 16:00:04 UTC
add compile on save features to maven projects both jar and war/ear/ejb project packagings.
Comment 1 Milos Kleint 2008-10-03 15:53:28 UTC
started to work on the feature at hg.netbeans.org/maven-dev, right now have tests and maven jar packaging projects
working for the simple usecases.

http://deadlock.netbeans.org/hudson/job/maven-dev/
Comment 2 akochnev 2008-10-13 20:51:42 UTC
This would be extremely useful in supporting development in Tapestry 5 which allows for live class reloading. Currently,
when I change a file in the IDE, I have to manually build or run the web app in order for the changes to take effect.
Ideally, when I make a change to the java class, the IDE will compile it and will place the file into the "normal"
target directory, where it would be picked up by the app server (e.g. in an exploded , non-war, deployment). 

Let me know if I can be of any help (e.g. testing it) with the issue. 
Comment 3 Milos Kleint 2008-10-14 08:06:28 UTC
the maven integration will make use of the application server apis, that actually implement the deploy on save. Not sure
how exactly it works (in relation to tapestry)
Comment 4 Quality Engineering 2008-10-17 04:58:05 UTC
Integrated into 'main-golden', will be available in build *200810170201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/db2cc88283eb
User: Milos Kleint <mkleint@netbeans.org>
Log: #148499 CoS for tests started. not complete with all the corner cases though.
Comment 5 Quality Engineering 2008-10-22 15:41:42 UTC
Integrated into 'main-golden', will be available in build *200810221401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/63d969450705
User: Milos Kleint <mkleint@netbeans.org>
Log: #148499 add ui to set compile on save feature. Make the CoS on for tests the default value. The Build/Compile panel in properties dialog was too empty, so I added deprecation and debug info checkboxes as well.
Comment 6 akochnev 2008-10-26 05:41:38 UTC
Thanks for moving this along, I'm really excited about COS in Maven based projects. 

Is this expected to work from the daily builds ? I just downloaded the latest (200810241401) daily build, and I don't
see the COS feature work properly. I definitely see the new COS options in the Build-Compile panel. I switch the
selection in the COS dropdown to "For both application and test execution" or "For application execution only". Then,
modify a source file in a java package and save it, and then check if the class file timestamp is updated . I checked
the class both under target/classes and target/my-app-name/WEB-INF/classes/) and the class doesn't get updated. This is
a web application based on the Tapestry 5 Quickstart archetype. 

Am I missing something ? 

Btw, would the plugin also do a copy-on-save (or deploy-on-save) for resources from the src/main/resources tree ? 
Comment 7 Milos Kleint 2008-10-26 06:54:35 UTC
application handling is not complete. It's partially done for jar packaging. Tests are sort of better off but still work
to do, especially in the area of resources handling. The plan it to fallback to non-CoS execution when you change any
resources as it's the bulletproof way without exactly replicating the maven-resources-plugin.
Comment 8 akochnev 2008-10-27 06:54:30 UTC
I'm not entirely sure what your recorded requirements are for what you plan to accomplish, but here's what would work
great for me (e.g. and anyone using NetBeans to work on Tapestry 5 apps): 
1. When a class is modified, compile and copy the compiled class to the "exploded war" deployment folder.
2. When a resource is modified, copy the modified resource (in the case of T5, the html markup .tml file) into the
"exploded war" deployment folder. 

In both cases, a re-deploy of the application shoudln't be necessary, as T5 can detect changes in both the class and the
resources and re-load just the ones that have changed. 

From this perspective, here are a couple of options that would be nice: 
1. As in my particular case w/ T5 application redeploy is unnecessary and generally wasteful (e.g. takes time for the
app server to reload the app), it would be greate if the COS functionality has a checkbox to select whether to redeploy
the web app to the app server, or just copy over the modified files
2. I'd guess that Maven has a standard place where to put the deployed exploded war, but it would be nice if the COS
functionality supported specifying the root of the directory where the modified classes/resources would be deployed. 

Anyway, if these are not possible (desirable) at this time, my options is to probably write a quick-and-dirty action
that would copy over the new files to a specified dir, or switch back to NetBeans regular web project (which supports
some of this COS stuff). The downside of the first option is that it would be better if supported by the plugin, and the
downside to the second option is that I'll lose all the fancy dep management of Maven. 

Comment 9 Milos Kleint 2008-10-27 07:04:30 UTC
Number 2. is generally a problem to achieve. Any maven resources can
a. be at different path in output directory (targetPath element)
b. require filtering of the files.
c. have include/excludes defined.

Especially b. is hard to achieve without the maven-resources-plugin.

Comment 10 Quality Engineering 2008-11-28 17:24:08 UTC
Integrated into 'main-golden', will be available in build *200811281401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/384279af9228
User: Milos Kleint <mkleint@netbeans.org>
Log: #148499 copy resources to the output directory, if any filtering going on, skip CoS.
Comment 11 Quality Engineering 2009-01-20 07:30:28 UTC
Integrated into 'main-golden', will be available in build *200901200201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/ff4dcd4e7cbf
User: Milos Kleint <mkleint@netbeans.org>
Log: #148499 initial  deploy on save added
Comment 12 psartini 2009-01-24 19:38:20 UTC
The features mentioned by akochnev would be very useful to me as well. What's needed for Tapestry 5 developement is the 
possibility to compile the file and copy it over into the exploded WEB-INF/classes/. If it is a normal resource 
(.properties or .tml), just copy it over. No redeploy needed.
Comment 13 tprochazka 2009-01-28 07:25:11 UTC
I tested it with actual dev build of Netbeans 7.
It's almost work good, but after save source file, .class file is moved to:
target\classes\
instead of
target\MyProject-0.2-SNAPSHOT\WEB-INF\classes\

And for example Wicket .html files which are in the same location as .java file is moved to:
target\MyProject-0.2-SNAPSHOT\ (with classpath)
It must be also in target\MyProject-0.2-SNAPSHOT\WEB-INF\classes\

And Netbeans copy also .java file to target\MyProject-0.2-SNAPSHOT\. Why?

I think, that is necessary only fix path and this will be work great.
Comment 14 Milos Kleint 2009-02-11 09:32:33 UTC
while copying classes to WEB-INF/classes might just work for tapestry, I'm not sure that can be generally done as it
could break some other setups.

if there is a tapestry netbeans plugin, such code probably belongs there, rather than the generic j2ee support.

akochnev: "or switch back to NetBeans regular web project (which supports
some of this COS stuff)"
you suggest that it works that way in netbeans ant projects? I don't think so, As far as I can tell, it will perform a
redeploy as well..
Comment 15 psartini 2009-02-12 21:43:50 UTC
mkleint: I am not sure about the redeploy thing. But shouldn't it be possible to just save the file I am working on and 
compile it (CoS)?. After that the class file should end up at the right location.. imho this is WEB-INF/classes for web 
projects.

I see that this may get complicated for netbeans - mainly because it does not have an internal way of building/running 
projects but relies on ant OR maven. There is afaik no way to configure such things without configuring it in the 
build.xml/pom.xml. 

For me, this is a big productivity loss.. sometimes I want to be able to set up more than one way to build/run my 
project. Tapestry is a good example, my "standard" config in the pom is used for the build server and integration 
testing - but for developing I need the fast turn-around and live class reloading.

IMHO an IDE should be able to work around maven or ant... especially for features that are not known by the build tools 
(compile on save is not the responsibility of ant or maven IMHO).
Comment 16 Milos Kleint 2009-02-13 06:09:06 UTC
psartini: well, as the usual classloading works, copying a class to WEB-INF/classes might break the application. Eg.
consider this example:
Class A is using (in some cases) class B. So the first time around just A is loaded by the app server. You change both A
and B classes later, we copy to WEB-INF classes. By using the application, you end up loading class B (now the latest,
changed version) HOWEVER the class A will not be reloaded to new version -> the application eventually break.
That's not connected to ant/maven, that's how classloading works AFAIK. That's the situation what the JVM agents like
javarebel were created for..
Comment 17 psartini 2009-02-13 13:03:35 UTC
Then I wonder what "Compile on Save" feature in netbeans is good for.

The issues you mentioned are partly handled by tapestry-ioc. It reloads all dependent classes as well. But 90% of time 
you just work with one class anyway - and in these 90% of time it is a huge productivity win! If you break something 
because the changes made are more complicated, you have the possibility to redeploy anyway.

This kind of setup is possible with IntelliJ IDEA - and I think with Eclipse as well. It's such a pleasure to develop 
java webapps if you don't need to redeploy... just change your files and reload the browser!
Comment 18 Milos Kleint 2009-03-09 07:43:15 UTC
*** Issue 159762 has been marked as a duplicate of this issue. ***
Comment 19 psartini 2009-03-20 20:34:03 UTC
just curious: in #159762 you said that this feature is done for the most part. Does this mean we will get a working Compile-On-
Save for mvn projects in 6.7? That would be great news!


Comment 20 Milos Kleint 2009-03-27 11:55:28 UTC
I have created a special task for evaluation of special cases like tapestry or javarebel. In these cases we should not
do a redeploy I guess and we should copy the compile classes immediately and not on Run action.
see issue 161337
Comment 21 akochnev 2009-04-02 04:06:37 UTC
I don't think anything special is needed to support Tapestry's COS needs : as long as the class file ends up in the same
directory where the maven build process puts it, it will work just fine. 

This is the use case that works : I build the Tapestry 5 web app, then use Jetty (or something else) to run the web app
(using the jetty:run target). Then, as I make changes to the web app, if I run a build (w/o having to redeploy the app
or restart the erver), T5 successfully reloads the new classes that are placed in the right place
target/[app-name]/WEB-INF/classes. 

In general, it really doesn't matter how long the compile takes : even if this integration just invokes the maven build
target for the file when the file is saved, it'd work just fine (and it seems that by doing that, the plugin doesn't
have to do anything special with putting classes in strange places. 

Similarly, for resources invoking the maven resources goal would also work just fine : with whatever filtering maven
might decide to do with the resources (e.g. pick the up from weird places, filter, etc). 

In the most ideal world, the COS stuff would have an option to configure which java packages to monitor for the COS
stuff (as for example, Tapestry 5 doesn't do live reloading of all packages and classes), and also which resource
directories to monitor for Copy-On-Save. 
Comment 22 Milos Kleint 2009-04-02 10:12:07 UTC
"I don't think anything special is needed to support Tapestry's COS needs : as long as the class file ends up in the same
directory where the maven build process puts it, it will work just fine. "

We that actually means doing something special, the currently implemented Cos for webprojects relies on common codebase
that does both monitoring of changes, copying the compiled classes and redeploying the webapp.
Comment 23 Milos Kleint 2009-05-15 09:23:47 UTC
FYI: the class reloading didn't work, see http://www.netbeans.org/issues/show_bug.cgi?id=165045
Even though it's fixed now, in order to have the class files end up in the expanded web application folder, one need to
deploy on an IDE supported app server (through the IDE), running jetty:run won't cut it, unfortunately.
Comment 24 Petr Jiricka 2009-05-16 10:23:01 UTC
Sounds like switching to GlassFish v3 Prelude or Tomcat should help.
Comment 25 Milos Kleint 2009-06-16 09:44:49 UTC
changes merged by this changeset (http://hg.netbeans.org/main/rev/313ba8e8b334) change CoS in the following ways:

1. Resources (as defined in the pom) are no longer copied before Cos-enabled Run/Debug is performed, but immediately
upon change. They are copied  into the relevant output folder (target/classes for main sources and target/test-clases
for test sources). TargetPath, Includes and Excludes of the resource definition are taken into account. Resources that
shall be filtered are skipped.
2. Previously Compile on Save was only performed after first execution of Run/Debug actions. That placed the
.netbeans_automatic_build stamp file into the relevant output folder to tell the IDE java infrastructure to start
compiling and copying the class files there. Now, the stamp file is created on project open and before executing any
action in the IDE (with exception of Build project and Rebuild project). That should assure that while working with the
project in the IDE, projects that have CoS enabled shall have the classes compiled and resources copied all the time.
That should cover both the javarebel usecase and tapestry usecase when invoked via jetty:run goal invokation.
3. for webapplications, resources are copied from the output folder to the expanded webapp and when using the IDE
supported server deployment, the webapp gets redeployed eventually (based on the rules in the app server support codebase)

I consider the issue fixed/implemented in 6.8 timeframe. Please test extensively in the daily builds and report and
problems, thanks.


Comment 26 mpayne 2009-06-19 15:43:43 UTC
Issue seems fixed in yesterday's build, however its a shame this can't be fixed for the 6.7 release.
Yesterday's daily build has other issues that affect daily usage stability.
Comment 27 mikael 2009-11-19 07:41:21 UTC
Compile on Save does not work for EAR based projects on Dev 200911171401. Eg. changing a jsp in the war project will not be picked up by GF. CoS works fine if I only deploy the war project on itself.

Will this be fixed before NB 6.8 is released or should I go for the an ant based EAR project?
Comment 28 bleathem 2009-11-19 11:05:18 UTC
(In reply to comment #27)
> Compile on Save does not work for EAR based projects on Dev 200911171401.

I created a new bug asking for Compile-on-Save for maven EAR projects:
Bug 177230 (https://netbeans.org/bugzilla/show_bug.cgi?id=177230)


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo