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
