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.
Unlike other APs in the NB source base, @Schema2Beans generates source files, which javac then compiles in a second round. Please check that this works somehow in a Maven NBM project. The generated sources should be placed into some directory under target/ so they can be browsed and the IDE can offer code completion on them.
it seems to work under some conditions and with limitations. 1. the referenced schema files need to be next to the package-info java file, but ideally they should be in the src/main/resources hierarchy. Alternatively one can reach the file in resources with a long double-dotted relative path. cumbersome but doable. 2. the compiled class and the generated source files are both generated into target/classes. So the resulting jar contains the source files and the IDE won't be able to get hold of the generated sources. passing -s <path> for the compiler doesn't solve the problem as the compiler needs that folder to exist up front. I assume http://jira.codehaus.org/browse/MCOMPILER-75 issue will handle that eventually. 3. I've noticed that projects depending on o.o.util failed to compile in 6.9. It seems to be caused by the fact that o.o.util depends on o.o.util.lookup via an implementation dependency and the maven repository generator goal skips all implementation dependencies (on assumption that such dependency is of not to be transitive. The assumption might be wrong and if the impl dependency is on a module with public api then it should generate it as well I suppose.) The annotation processor in o.o.util is using the o.o.util.lookup content however and failed to instantiate. I took the opportunity and removed the implementation dependency. If I recall right these are generally to be avoided anyway.
(In reply to comment #1) > the referenced schema files need to be next to the package-info java file, > but ideally they should be in the src/main/resources hierarchy. This means that Maven is failing to invoke javac with an appropriate -sourcepath argument; it needs to include src/main/resources as well as src/main/java. (Will also affect numerous NB annotation processors: those permitting displayName="#key" verify that the/same/pkg/Bundle.properties exists and has the key.) > the compiled class and the generated source files are both generated into > target/classes. So the resulting jar contains the source files and the IDE > won't be able to get hold of the generated sources. passing -s <path> for the > compiler doesn't solve the problem as the compiler needs that folder to exist > up front. I guess you could work around this by putting some Ant task into the compile goal to create the -s dir first. Ugly. > I've noticed that projects depending on o.o.util failed to compile in 6.9. > It seems to be caused by the fact that o.o.util depends on o.o.util.lookup via > an implementation dependency More likely that they refer to Lookup and now need to declare a dep on it? (The Ant build harness now processes config/ModuleAutoDeps/*.xml at build time, but I expect nbm-maven-plugin does not.) > and the maven repository generator goal skips all > implementation dependencies (on assumption that such dependency is of not to be > transitive. No deps in NB are supposed to be transitive, so I'm not sure what is special about an impl dep. Impl deps are just an alternative form of access control. > I took the opportunity and removed the implementation dependency. Not sure what you mean by this. > If I recall > right [impl deps] are generally to be avoided anyway. Yes, and as of bug #179289 they will be removed from the platform cluster.
(In reply to comment #2) > (In reply to comment #1) > > the referenced schema files need to be next to the package-info java file, > > but ideally they should be in the src/main/resources hierarchy. > > This means that Maven is failing to invoke javac with an appropriate > -sourcepath argument; it needs to include src/main/resources as well as > src/main/java. > > (Will also affect numerous NB annotation processors: those permitting > displayName="#key" verify that the/same/pkg/Bundle.properties exists and has > the key.) well, that's hardly something that will generally accepted as solution. resources can be filtered and can have different file structure anyway (according to Resource's <targetPath> element), only the target/classes folder actually contains the correctly processed resources. So maybe it could be put there, but that sounds ugly as well. > > I've noticed that projects depending on o.o.util failed to compile in 6.9. > > It seems to be caused by the fact that o.o.util depends on o.o.util.lookup via > > an implementation dependency > > More likely that they refer to Lookup and now need to declare a dep on it? (The > Ant build harness now processes config/ModuleAutoDeps/*.xml at build time, but > I expect nbm-maven-plugin does not.) no the URLHandler annotation processor inherits from AbstractAnnProcessor in o.o.util.lookup. > > > and the maven repository generator goal skips all > > implementation dependencies (on assumption that such dependency is of not to be > > transitive. > > No deps in NB are supposed to be transitive, so I'm not sure what is special > about an impl dep. Impl deps are just an alternative form of access control. But unfortunately all maven dependencies are transitive. which means that any api dependency that depends on non-api modules will drag them along into the user's classpath. The heuristics with omitting impl and friend dependencies makes the dependency tree more like you would liek it to have. > > > I took the opportunity and removed the implementation dependency. > > Not sure what you mean by this. > http://hg.netbeans.org/core-main/rev/4a2cfb7f789e
(In reply to comment #3) > resources can be filtered and can have different file structure anyway > (according to Resource's <targetPath> element) Is such filtering or processing an important use case for resources needed by annotation processors? Seems like a P4 to me. > only the target/classes folder > actually contains the correctly processed resources. So maybe it could be put > there Not sure if including classes in -sourcepath could cause issues. Ideally Maven would launch javac directly using JSR 199, in which case it can define a custom JavaFileManager which is able to load true resources from target/classes but exclude *.class. >> More likely that they refer to Lookup and now need to declare a dep on it? (The >> Ant build harness now processes config/ModuleAutoDeps/*.xml at build time, but >> I expect nbm-maven-plugin does not.) > > no the URLHandler annotation processor inherits from AbstractAnnProcessor in > o.o.util.lookup. Oh I think I see the problem you're having. The Ant harness passes -processorpath ${module.run.classpath}, i.e. it includes unfiltered transitive dependencies (nonpublic packages, everything) in what can be loaded by the processor itself. > But unfortunately all maven dependencies are transitive. which means that any > api dependency that depends on non-api modules will drag them along into the > user's classpath. The heuristics with omitting impl and friend dependencies > makes the dependency tree more like you would like it to have. But not the same anyway. Again, friend and impl deps are just access control. NB defines all deps to be nontransitive; access control is irrelevant. If Maven cannot handle this, then it should treat all deps as transitive. > http://hg.netbeans.org/core-main/rev/4a2cfb7f789e I will back this out as it is being done differently.
(In reply to comment #4) > (In reply to comment #3) > > resources can be filtered and can have different file structure anyway > > (according to Resource's <targetPath> element) > > Is such filtering or processing an important use case for resources needed by > annotation processors? Seems like a P4 to me. Well, in my eyes the whole case of Schema2beans annotation is a P4 or P3 at most.. > > > But unfortunately all maven dependencies are transitive. which means that any > > api dependency that depends on non-api modules will drag them along into the > > user's classpath. The heuristics with omitting impl and friend dependencies > > makes the dependency tree more like you would like it to have. > > But not the same anyway. Again, friend and impl deps are just access control. > NB defines all deps to be nontransitive; access control is irrelevant. If Maven > cannot handle this, then it should treat all deps as transitive. > Well, in ideal world I agree with you. However dumping all dependencies on classpath will make the build significantly slower due to the compile vs. runtime CP check we have now. (it checks for classes used in the project and matches them against classes in the dependencies, trying to figure if such setup will work in netbeans runtime). I've already had reports that it can get rather slow with long classpath. Now we would effectively dump the whole platform/IDE on everyone's classpath as long as they would use more than just simple lookup. And there's also the case of backward compatibility and what to do with already generated maven repo content. I've looked at the http://code.google.com/p/maven-annotation-plugin/ plugin you pointed me to. I didn't manage so far to make it run with the schema2beans annotations. I cannot make it find the schema file anywhere. I suppose it's because it doesn't set the source path and/or explicitly just pulls *.java file from the StandardJavaFileManager. I've also filed 2 additional issues there: http://code.google.com/p/maven-annotation-plugin/issues/detail?id=13 http://code.google.com/p/maven-annotation-plugin/issues/detail?id=14 The plugin is only released in it's own repo in svn and contains both releases and snapshots. That's a pity.
Reassigning to default owner.
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