2008/10/23 Craig Walls <[EMAIL PROTECTED]> > > I think that I'm on to something here...follow along... > > * I did a build in verbose mode (mvn -X)...both for the web bundle > project and for the overall project. > * When I build the web bundle by itself, the Compass dependency is > pulled as a JAR from my local Maven repository. No problems...it > works. > * But when I build the whole project, when it gets to the web > bundle, it uses the target/classes directory from the wrapped > Compass project. But it's just a wrapped JAR, so there are no > classes under target/classes (just META-INF/MANIFEST.MF). > * The chief difference between the web bundle and the other bundles > in my project is that the web bundle uses "war" packaging, but the > others use "bundle". > > So, the question seems to be: How can I have the web bundle pull Compass > from the Maven repository instead of adding it's target/classes to the > build classpath? >
this is a long-running issue in Maven, dating back to at least 2006: http://jira.codehaus.org/browse/MNG-2720 basically, the MavenProject class that's responsible for providing the build classpath has code that explicitly checks to see if a project is in the current "reactor" (ie. same build tree) if it is then Maven adds the outputDirectory (target/classes) to the build classpath instead of the artifact file from the local repo - even when the outputDirectory is missing (as is the case for several packaging types) what's worse is that MavenProject is an internal class hard-wired into the binary build, so there's no easy way to override this "functionality" (believe me, I've tried all sorts of approaches, but it's really tied in...) one workaround is to add the following to your "wrapper" project: <build> <plugins> <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <configuration> <unpackBundle>true</unpackBundle> </configuration> </plugin> </plugins> </build> which will ensure that target/classes ends up with the correct content. Apparently, the "bundle" packaging supported by Pax Construct seems to > have this figured out. Perhaps...and this is just a suggestion...Pax > Construct (or the bundle plugin) should be extended to support another > "web-bundle" packaging (or some such thing) so that it gives the best of > both worlds (WAR and bundle). > I think this is probably because Pax-Construct uses a slightly amended bundle packaging lifecycle that switches in our own mojo for compilation - this was needed to support compilation against embedded jars, as the bundle artifact needs to be unpacked before compilation one side-effect of this was that we were able to revert back some of the changes made to the build classpath... but only for "bundle" packaging, and only during the compilation phase doing this for other packaging types could get messy because we'd need to alter their lifecycles too (not sure if this is possible from a single plugin) and ensure they didn't have <extensions> enabled (more archetype work) actually I wasn't happy doing this for "bundle", but there was no other way without either forcing people to use a customized Maven binary or waiting for MNG-2720 to be fixed :( hmm, perhaps a distinct "web-bundle" packaging may be useful - but can you list the things that it should do over and above "bundle"? or is it just a matter of generating a .war instead of a .jar? Craig Walls wrote: > > New question...and maybe this will help me solve my other problem with > > WAR bundles. > > > > See my http://www.jroller.com/page/habuma for my complaint about > > transitive dependencies on Compass annotations. Now consider this... > > > > * My web bundle depends on my index and domain bundles and the > > domain bundle uses Compass annotations. Consequently, the web > > bundle has an indirect/transitive relationship to Compass (even > > though it doesn't use Compass in any way). > > * If I try to build (mvn compile) either the web bundle or the whole > > project, I get compile errors when it gets to the web bundle that > > complain about missing Compass annotations > > * I have a wrapped (pax-wrap-jar) Compass in my project, as a peer > > to the web project. > > * I can't do a pax-import-bundle for Compass on the web project > > because the web project doesn't directly use Compass (it's a > > transitive dependency). Because it doesn't directly use Compass, > > pax-import-bundle has no effect whatsoever in this case. > > * If I add a Compass <dependency> in the web bundle's pom.xml, I can > > then cleanly compile the web bundle from within the web bundle's > > directory. > > * But I still get compile errors (complaining about missing Compass > > annotations) if I try to compile the whole project. > > * Note that all of this happens at build time, not at runtime. So, > > it's really more of a question of how Pax Construct's pom > > hierarchy is working with Maven than a question of what > > should/shouldn't be in the manifest. > > > > I suspect (but haven't proven) that because I'm unable to build the > > entire project successfully, that it might explain why pax-provision > > isn't picking up the web bundle. > > > > I tried to trace the pom hierarchy to figure out what's causing that to > > happen, but honestly I got a little lost along the way. Can anyone > > suggest the proper way to make my build happy? Ideally, I'd like to > > *not* add Compass as a dependency to the web bundle, but I'll accept any > > solution that enables me to build the entire project cleanly. > > > > > > > > _______________________________________________ > > general mailing list > > [email protected] > > http://lists.ops4j.org/mailman/listinfo/general > > > > > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general > -- Cheers, Stuart
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
