Stuart, thanks for your help. That would have been my last resort, too, yet I was in the hopes of getting around it ...
Cheers, Olaf > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Stuart > McCulloch > Gesendet: Dienstag, 16. Oktober 2007 12:38 > An: [email protected] > Betreff: Re: In reactor mode dependent osgi bundle resolves to > target/classes > > On 16/10/2007, Olaf Bergner <[EMAIL PROTECTED]> wrote: > > > > [Cross-posted from [EMAIL PROTECTED]/no reply to date] > > > > I'm using felix' maven-bundle-plugin to wrap existing libraries - say > > commons-lang - as osgi bundles. The projects that produce these wrapper > > bundles - say commons-lang.osgi - reside in my workspace and are part of > a > > reactor build. Other projects - my own code - declare dependencies on > the > > artifacts - osgi wrapper bundles - produced by my 'wrapper' projects. > > > > Everything works like a charm as long as I build my 'own' projects > > separately. If, however, I do a full-fledged reactor build, as soon as > > maven > > tries to build one of my 'own' projects that declares a dependency on an > > osgi wrapper bundle, compilation fails since maven does not put the > > referenced osgi bundle itself but the target/classes - say > > ../commons-lang.osgi/target/classes - directory from the project that > > produces that bundle on the classpath used to compile my code. > Obviously, > > this cannot work since that directory is empty. After all, we are > dealing > > just with a repackaged jar. > > > > It seems as if in reactor mode maven knows which dependencies originate > > from > > my workspace and tries to use the class files directly. Why ist hat, and > > how > > can I stop maven from doing so? I'm using maven 2.0.6 and > > maven-bundle-plugin 0.8.0-snapshot. > > > this is actually an issue with the internals of Maven (see > MavenProject.java > ) > where it assembles the compilation classpath - if a dependent project is > part > of the reactor then Maven will replace the artifact path with > "target/classes". > > the reason Maven does this is so people can do "mvn compile" from the top > of their multi-module project and not have to deal with missing / > out-of-date > dependency artifacts. > > unfortunately, this doesn't play well with OSGi bundles, where > "target/classes" > may not exist, or be different to the actual packaged contents of the > bundle. > > even more unfortunately, there is no switch/setting in Maven to stop this > from > happening, as this logic is part of the internals rather than the compiler > plugin. > > the simplest workaround is to use the maven-dependency-plugin to unpack > the final bundle under "target/classes" as part of the packaging/install > step :( > > Thanks for any pointers, > > > > Olaf Bergner > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Cheers, Stuart --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
