Stuart: Thanks for the reply. I had pretty much come to the same conclusions after I sent that e-mail yesterday (that it was probably a Maven problem, not a Pax Construct problem), but unfortunately I bouncing around airports for the rest of the day and didn't get a chance to respond with my new insights.
But, your suggestion to have the bundle plugin unpack the Compass bundle seems to have worked. Thanks for the tip. I hate it that I have to do that, though. It just seems to "hacky". But I guess it'll have to do until (and if) Maven decides to behave. Unfortunately, pax-provision still doesn't pick up my web bundle...but I'll look into it a bit more before I bug you with that problem again. Stuart McCulloch wrote: > 2008/10/23 Craig Walls <[EMAIL PROTECTED] <mailto:[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] <mailto:[email protected]> > > http://lists.ops4j.org/mailman/listinfo/general > > > > > _______________________________________________ > general mailing list > [email protected] <mailto:[email protected]> > http://lists.ops4j.org/mailman/listinfo/general > > > > > -- > Cheers, Stuart > ------------------------------------------------------------------------ > > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general > _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
