Hi Andrew, Right - it seems like the same situation I was describing. I think you would have a POM that declares the dependencies included in the ZIP, and if you were to produce the ZIP with that it would be a "secondary" type, and you would just depend on the POM to aggregate its deps.
I agree that this should be an aggregating parent instead and use modules instead of dependencies - however, currently this won't work for the case you are describing (there is an open issue to allow it). FWIW, I have been discussing building Eclipse plugins with m2. The discussion was with Jeff McAffer on [EMAIL PROTECTED] I haven't had a chance to investigate it any further at this point due to a lack of time, but it'd be great to compare notes. Are you building your own plugin, or just depending on one? Cheers, Brett On 9/15/05, Andrew Niefer <[EMAIL PROTECTED]> wrote: > > Basically, we are trying to depend upon an Eclipse Plugin. Some plugins > exist as directories instead of as a jar file though they are often zipped > for distribution. For example org.eclipse.tomcat_4.1.30.1 is a directory > containing, among other things, 23 jars. > > Project A provides some interface, so clients only know they want to > depend on A The fact that A provides the implementation as multiple > nested jars is a detail that clients shouldn't know or care about. > > These nested jars could be subprojects (and judging by the replies, should > be). One use case is to take an existing Eclipse plugin and describe it > with a pom so that we can depend on it. > > > -Andrew > > Jesse McConnell <[EMAIL PROTECTED]> wrote on 09/13/2005 > 08:27:05 PM: > > > I am a little confused with what you are trying to do exactly.. > > > > are you basically saying that you want one project to produce multiple > > artifacts that you can use as a dependency seperately within another > > project? > > > > are these projects really subprojects in one project with a shared root > > pom.xml file? > > > > or are they discrete projects,,,? > > > > bit more info would be grand :) > > > > Jesse > > > > On 9/13/05, Andrew Niefer <[EMAIL PROTECTED]> wrote: > > > > > > The resulting artifact of a project A is a directory containing jar > files, > > > binaries and resources and I package this in a jar, or even a zip or > rpm > > > (if I had such a packaging plugin) > > > > > > A jar/zip/rpm > > > - nested1.jar > > > - nested2.jar > > > - resources/binaries > > > - META-INF/manifest.mf > > > > > > manifest.mf is an OSGI manifest that specifies nested1.jar and > nested2.jar > > > using the Bundle-ClassPath. > > > > > > Consider now another project B that has a dependency on A. When > building > > > B, I don't want its classpath to contain A, but instead I want it to > > > contain nested1.jar and nested2.jar. > > > > > > Is it possible to nest jars this way? Or would something like this > require > > > a custom process-resources plugin? > > > > > > -Andrew > > > > > > > > > > > > > > > -- > > jesse mcconnell > >
