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
