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.
Created attachment 132635 [details] Maven multimodule project highlighting the issue I have 2 maven modules in my project (attached zip sample) Main class is run from module1 (Module1.java) Module1.java uses Module2.java in the module2 maven module. When I do a change in Module2.java, Netbeans doesn't automatically build Module2.java when running Module1. I have to force in module1 a build with dependencies to make it work. It used to work correctly in some previous version of Netbeans. The behavior previously was that Netbeans had its own building system and was not relying on maven to do it. For example I could do a syntax error in Module2.java and when trying to run Module1 Netbeans would warn me directly that there is a syntax error in Module2.java. With Netbeans 7.1 I can't make it work anymore. I always have to so a build with dependencies. Our project is quite big and it is quite annoying to have to rebuild everything each time a single line of code in one module is changed See attached Maven project to reproduce the problem
compile on save was turned off in 7.3, as in a fair amount of scenarios it fails to work correctly. if it is working for you, just enable it in your projects in project customizer.
Reopening bug, compile on save doesn't solve the issue. Ways to reproduce 1 - unzip the attached file 2 - open the maven project tst in netbeans 3 - build with dependencies module1 3 - add compile on save in both module1 and module2 (I used for both application and test execution 4 - change Module2.java and introduce a syntax error 5 - run Module1 -> it doesn't see that Module2 can't compile
Other test that you can do with the compile on save: change coucou into something else, it is not taken into account Regards Daniel
(In reply to comment #0) > Created attachment 132635 [details] > Maven multimodule project highlighting the issue > > It used to work correctly in some previous version of Netbeans. The behavior > previously was that Netbeans had its own building system and was not relying on > maven to do it. what version did it work exactly.. in 7.3 and before, we still are using the Javarunner API (which more or less resolves to running an ant task). On in dev builds CoS RUN is executed by maven. But we still compile all classes with internal netbeans compiler. The primary issue here is that module2's classes get updated in target/classes but not in the jar file in local repository that is primarily on the ClassPath of module1. I'm almost sure it was always like that, but I wasn't the maintainer of the code in between 6.8 and 7.2. > > For example I could do a syntax error in Module2.java and when trying to run > Module1 Netbeans would warn me directly that there is a syntax error in > Module2.java. But in the IDE everything is correct, right? Changes are linked and the editor error highlights are not shown. > > With Netbeans 7.1 I can't make it work anymore. I always have to so a build > with dependencies. Our project is quite big and it is quite annoying to have to > rebuild everything each time a single line of code in one module is changed > as a long term solution I would recommend integrating jrebel or javeleon if the size of project is the limiting factor. Using either of these tools together with Compile on Save turned on, should eliminate running application restarts in most cases. I have tried in current dev build. I can confirm that with Compile on Save on or off, Maven execution or JavaRunner API, in any combination, the changes in module2 are *not* picked up. I'm however not sure it was ever the case. Unless something changed in the internals of JavaRunner implementation. (jlahoda: true/false??) Because the only solution here on the maven side of things is to keep on updating the jar file in local repository with every compilation update. There could be a way of feeding JavaRunner the right ClassPath with target/classes folders for known dependency project artifacts, but JavaRunner execution has problems of it's own and I'd like to move away from it in the long term. The current dev build is not using it anymore BTW. it's using maven and there's no clear way of feeding maven the tweaked classpath, I will have to think some more about possible ways here..
FYI, it is working with Netbeans 6.7.1 In that version when changing "coucou" in Module2 into somehting else it is directly talen into account. I guess in this version it is just using the .class files and not the jar Regards Daniel
having http://jira.codehaus.org/browse/MEXEC-66 in a released version of exec maven plugin would help in our effort to replace the repository jars with target/classes folders
for dev, https://jira.codehaus.org/browse/SUREFIRE-973 is related on surefire side. We will need to replace parts of the classpath with target/classes folder of their respective projects
the missing linking you are seeing is related to fix for issue 168551
a solution I found to work in general (with maven 3.x), no matter what plugin is to include a WorkspaceReader implementation in core maven and somehow pass along the locations of projects that have CoS enabled. The workspacereader would then redirect the artifact resolution to workspace pom and target/classes. a sample implementation of such workspace reader is at https://github.com/mkleint/ide-workspace-reader, it's based on an environment variable netbeansProjectMappings containing comma separated lists of GAV=<path-to-project> values. The hard part here is making the implementation visible to external maven instances. The official way is to include the jar in $MAVEN_HOME/lib/ext folder and it gets loaded then. We can definitely do that with the maven instance we ship with netbeans. it's less easy with external maven instances. what are our options with external maven: -cp cannot be used -Xbootclasspath/a maybe could work similarly -javaagent:<jarpath> could. ask user to copy the ext jar to the installation or copy the entire installation to a custom location and execute from there.
there appears to be a system property "maven.ext.class.path" that can be passed to maven within MAVEN_OPTS environment variable and that appears to work. More experiments TBD
should be fixed in current trunk for projects with Compile on Save on. CoS Run/Debug builds now executed with maven, providing links to other open projects that are dependencies of the current one. Only works with Maven 3.x. please test when the changeset http://hg.netbeans.org/core-main/rev/127bf80e70b2 appears in the daily builds (should be notified in this issue) for details see http://wiki.netbeans.org/FaqCompileOnSave#Using_Compile_on_Save_in_Maven_Projects I've turned compile on save on by default in dev builds. Let's reevaluate later if we can keep it in release or not..