Peter Kriens wrote: > I am not sure I understand the bug (I only understand it is unrelated > to bnd), but it is trivial to save the build jar in a directory > instead of jar file. That is, you do not first have to jar it and then > unjar it. > > I guess this allows the packager to do its work? > > Now, before bnd is called, the plugin assembles the classpath from > the maven information. If we get a good overview from the bugs then it > should not be that hard to rewrite the classpath? > The problem is maven itself not the plugin or bnd. Basically when you use modules and do a full build, then maven uses the local classpath of the existing modules (target/classes folder) instead of the published artifacts. Since the bnd plugin creates only a jar but doesn't unpack any files under target/classes (why should it?), maven adds an empty folder to the classpath which leads to errors when compiling.
If the modules are ran individually then everything is fine. > Kind regards, > > Peter Kriens > > > > CL> Stuart McCulloch wrote: >>> On 01/06/07, Costin Leau <[EMAIL PROTECTED]> wrote: >>>> Hello everybody, >>>> >>>> We are using the maven bnd plugin in a maven project with submodules >>>> and, as reported already, due to the way maven works, the classpath is >>>> assembled incorrectly since the local target/class files is being used >>>> instead of the locally deployed artifact. >>>> >>>> I keep making patches around this problem but I was wondering whether >>>> would you consider adding an option for unpacking the created bundle in >>>> the target folder of the owning project. >>> I use the maven-dependency-plugin to unpack bundles ... adding an >>> option to the bundle-plugin would be neater (less config in the poms) >>> but duplicates functionality from other plugins. > > CL> Right - I've tried it and in a module, 2 levels deep it kicks in before > CL> the bundle is being uploaded and thus has nothing to unpack. > > CL> Not to mention that when using it on over 20 sub-modules (which is the > CL> case with Spring/OSGi) we have a *lot* of duplication to do. You would > CL> not believe how much time was wasted because of this. > CL> I've tried using some sort of 'templating' but the problem is that maven > CL> applies the template on the declaring pom (the modules parent) as well > CL> as the children. > > CL> Moreover, there is a maven bug which doesn't propagate plugin > CL> inheritance more then 1 level deep. > >>>> This way, systems that use modules and the maven plugin do not have to >>>> come with their own, incomplete solution for doing a build. >>>> >>>> What do you think? >>>> >>> no views either way - not much code required, but could be seen as bloat... > > CL> One thing to consider here - I'm suggesting unzipping/unjaring a > CL> particular archive. > CL> The dependency maven plugin is quite generic and has plenty of other > CL> options such as copying, determining the dependencies and so on. > > >>>> Cheers, >>>> -- >>>> Costin >>>> >>> > > > > -- Costin
