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.
In case there are some process-classes actions in module m1, and module m2 has a dep on m1, including m1/src/main/java as the SFBQ result for m2 may be wrong - the bytecode post-processing might have changed signatures in m1/target/classes. Currently worked around with a system property mevenide.projectLinksDisable, which disables interproject SFBQ, but this is a hack and takes effect globally. Better to automatically enable this mode just when some goals in process-classes are detected. Also better to use Result2 with !preferSources in this case, so we can still jump to sources for reference, but the parser will not consider them authoritative.
do we have examples of maven plugins that do this sort of thing? AOP I guess. quick google search reveals: http://openjpa.apache.org/enhancement-with-maven.html http://mojo.codehaus.org/rmic-maven-plugin/ http://jour.sourceforge.net/jour-maven-plugin/ in general this is very,very rare based on how frequently we get a bug report about it.
(In reply to comment #1) > do we have examples of maven plugins that do this sort of thing? Well "static weaving/bytecode generation" in the original report. The question is whether there is a straightforward way (i.e. without needing to enumerate specific plugins) to determine if the upstream project binds any goals to the process-classes (*) phase - whether explicitly in its POM mentioning that phase, explicitly mentioning a plugin goal which binds by default to that phase, or implicitly due to the default lifecycle mappings for the project's packaging. If so, a ForeignClassBundler impl can say no for preferSources. (*) Or process-test-classes, in the case of a dependency on an artifact with classifier=tests.
https://www.google.com/#q=%22Binds+by+default+to+the+lifecycle+phase%3A+process-classes%22 shows possibly all plugins binding to the process-classes phase. It's not immediately obvious if these should always !preferSources.
It depends on whether the mojo is affecting the public signature of m1 or at least that part m2 is expected to use. If you are just injecting AOP logging or something, then no.
I suppose this issue is sort of duplicate of issue 208411 or at least both boil down to the same solution. What's unclear is just the UI (if any) should be to switch the source preference on and off. The simpler ui would be to add action on the dependency popup. However the discoverability of that would be fairly poor.
An action in the dependency popup also has no obvious UI for reversal if you change your mind.
(In reply to comment #6) > An action in the dependency popup also has no obvious UI for reversal if you > change your mind. yeah, we would have to make the state of link suppression obvious on the dependency's node label and/or icon
we currently link dependencies with classifier ut always with !preferSources
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss