Product Version = NetBeans IDE 7.2 (Build 201207171143)
Operating System = Windows 7 version 6.1 running on x86
Java; VM; Vendor = 1.7.0_05
Runtime = Java HotSpot(TM) Client VM 23.1-b03
When I do changes in the code I need to clean and build to see the changes. I have Compile on Save enabled for both application and test code.
Created attachment 123162 [details]
if you have a nbm maven project and nbm-application project, then compile on save will only work if you use javeleon or jrebel to run the application (i believe, but it's been long I experimented with it). Typically Compile on save will only place the compiled class file int target/classes of the nbm project in question. However the nbm application project uses expanded .nbm files coming from local repository to construct the application binaries.
to make it work we would need a special IDE originating mode of operation when running the application that would use the expanded class structure in target/classes instead of the module jar. Not even sure if that's possible on the side of netbeans bootstrap
according to jtulach, there's a system property used in module system that we could use to redirect the module system on startup to newly compiled classes.
"netbeans.patches." + codenamebase=<path> where <path> would be path to the opened module project's target/classes (with Compile On Save on)
We would have to inject these when running the nbm-application, it needs to be also tested when used together with jrebel..
Even now, on 7.3, I have some problems. I have a couple of wrapper modules. If I clean and build the application it has run time errors complaining about classes not found. Those are on the wrapped modules. I have to compile each wrapper individually, then compile/run the application for it to "see" them.
Not sure if a completely different thing.
now when the module(s) has Compile on Save on, the application project will put their target/classes folders as "patch" directory. That effectively helps with not having to rebuild module before re-running the application.
A few limitations:
1. currently only module's own codebase is "patchable", it would be nice to include also library projects being wrapped by the module
2. space in path will be troubling we have a single maven cmd line property wrapping multiple props to be passed to netbeans
3. adding/removing annotations will not work, at least for those that generate non-classfiles, like most netbeans ones do.. they generate layer files, META-INF/services entries etc. These are not copied by the java infrastructure as part of Compile on Save.
(In reply to comment #5)
> > A few limitations:
> 1. currently only module's own codebase is "patchable", it would be nice to
> include also library projects being wrapped by the module