Bug 148499

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/

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. 

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)

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.

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.

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 ? 

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.

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. 

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.

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.

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

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.

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.

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..

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).

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..

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!

*** Issue 159762 has been marked as a duplicate of this issue. ***

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!

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

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. 

"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.

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.

Sounds like switching to GlassFish v3 Prelude or Tomcat should help.

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.

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.

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?

(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)