This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Need to clean and build Maven stand alone module | ||
---|---|---|---|
Product: | apisupport | Reporter: | javydreamercsw <javydreamercsw> |
Component: | Maven | Assignee: | Milos Kleint <mkleint> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jtulach |
Priority: | P2 | ||
Version: | 7.2 | ||
Hardware: | PC | ||
OS: | Windows 7 | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Attachments: | IDE log |
Description
javydreamercsw
2012-08-15 20:40:06 UTC
Created attachment 123162 [details]
IDE log
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. http://hg.netbeans.org/core-main/rev/32976baed604 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 implemented since: http://hg.netbeans.org/core-main/rev/6fb895c84d27 |