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: | CoS execution should prepend target/classes/ to ${java.class.path}, but leave target/*.jar | ||
---|---|---|---|
Product: | projects | Reporter: | Jesse Glick <jglick> |
Component: | Maven | Assignee: | Tomas Stupka <tstupka> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | mkleint |
Priority: | P3 | ||
Version: | 8.0 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 153635 |
Description
Jesse Glick
2014-03-13 13:32:41 UTC
The proposed change would probably suffice to make CoS work for “unit” tests in NB module development, where the NB platform expects a META-INF/MANIFEST.MF entry to be available for every module. I suppose this should be reassigned to maven, as the classpath composition for maven based projects is nowadays done on maven level only (and is injected into a cmd line maven. Unless you've suppressed it and are still using the old ant based CoS execution. Yes I am using regular Maven CoS. Thought this was all handled generically. Unfortunately not easily to be done within the current CoS solution. We inject an WorkspaceReader implementation via maven.ext.class.path property, so any 3.x maven will use our implementation in the core. So we effectively modify the internals of maven that way. The advantage here is that it works with most maven plugins that way without a need to modify the plugins in any way. exec-maven-plugin, maven-surefire-plugin etc.. The disadvantage is that the API for workspaceReader allows us just to replace 1 artifact for another one (jar in local repo for target/classes) are any other resources affected by this than MANIFEST.MF? (In reply to Milos Kleint from comment #4) > We inject an WorkspaceReader implementation via maven.ext.class.path I guess this explains why the command line printed in the Output Window is not actually what is happening. Which is a bit frustrating, by the way: if your test fails with a weird error due to a missing JAR manifest, and you then copy the “command line” printed by NetBeans and paste it into a shell, the test runs fine. It would be better I think to not suppress the CLI argument -Dmaven.ext.class.path=… since that can be vital to reproducing the failure from a shell. (You could remove this argument and see the behavior difference, pinpointing the issue as NetBeans-specific.) > The disadvantage is that the API for workspaceReader allows us just to > replace 1 artifact for another one (jar in local repo for target/classes) Hmm. So my alternative suggestion (pulling missing bits out from the JAR and synchronizing them into target/classes/) could still work. (*) (In reply to Milos Kleint from comment #5) > are any other resources affected by this than MANIFEST.MF? Cannot think of anything offhand. For example, in the case of NBM projects, a hand-edited layer.xml would already be synchronized by CoS, and META-INF/generated-layer.xml should be present in target/classes/ if the IDE’s internal compiler is working correctly. Perhaps the specific policy of how to handle CoS should be an SPI so that a particular packaging type module can select a behavior known to work for that module system—whether extracting resources from a JAR previously created by an external build system, or generating temporary copies of such resources adequate for testing based on POM information, etc. (*) I would still feel much more comfortable if the IDE created a separate target/cos/ or whatever, so there is no chance of accidentally contaminating the CLI Maven lifecycle with IDE-generated classes or resources. This would also significantly simplify the code (I think) since you would not need to create a .netbeans_automatic_build marker, or clean up generated classes prior to a full build, etc. 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 |