Just to be clear, using import/export is a different scenario. We're not talking about having classes in the nested jars being made available in the domain which is what export does, they're for use by other things _within_ the outer contribution. So say your SCA service implementation is using some classes in some 3rd party jar thats not an SCA contribution jar so import/export wont help and anyway its a implementation detail so you don't really want to expose the 3rd party classes in the domain.
...ant On Fri, Jan 23, 2009 at 6:16 PM, Luciano Resende <[email protected]>wrote: > I think we should be consistent and don't over engineer things here. > The way this has worked in the past is that we would try each jar as a > different contribution and would use import/export to make the > resources from one contribution available to others. > > On Fri, Jan 23, 2009 at 9:52 AM, ant elder <[email protected]> wrote: > > > > > > On Fri, Jan 23, 2009 at 5:08 PM, Simon Laws <[email protected]> > > wrote: > >> > >> > >> On Fri, Jan 23, 2009 at 4:54 PM, ant elder <[email protected]> wrote: > >>> > >>> Ok, but this is not inventing a new packaging scheme as the Assembly > spec > >>> defines this zip contribution format. If a zip contribution is really > just a > >>> identical to a jar contribution why have them both? > >>> > >>> Quoting from the spec about the contents of a zip contribution: > >>> > >>> "The most obvious examples of such non-XML artifacts are Java, C++ and > >>> other programming language files necessary for component > implementations." > >>> > >>> A jar is a Java file necessary for component implementations, so that > >>> seems to apply perfectly. > >>> > >>> ...ant > >>> > >>> On Fri, Jan 23, 2009 at 4:39 PM, Raymond Feng <[email protected]> > >>> wrote: > >>>> > >>>> Hi, > >>>> > >>>> Let's be careful here. > >>>> > >>>> First, there are two options to deal with the nested jars: > >>>> 1) Treat it as an artifact > >>>> 2) Treat it as a container with child artifacts > >>>> > >>>> Second, we should not try to invent new packaging schemes. We should > >>>> support archives per existing technologies such as JAR, ZIP, WAR, and > EAR. > >>>> WAR and EAR support one level of jar nesting. OSGi bundles can also > have > >>>> nested jars on the Bundle-ClassPath. How to construct the classpath > for a > >>>> given contribution should be conforming to the standard. > >>>> > >>>> Thanks, > >>>> Raymond > >>>> From: ant elder > >>>> Sent: Friday, January 23, 2009 1:44 AM > >>>> To: [email protected] > >>>> Subject: Folder and ZIP format contributions containing nested > >>>> application JARs > >>>> Section 12.2 in the SCA Assembly spec describes contribution formats > and > >>>> makes it sounds like you should be able to have things like folder or > zip > >>>> format contributions which contain application artifacts like jar > files > >>>> which should be made available. The spec doesn't specifically mention > >>>> contributions containing nested jar files, but from my read of the > spec that > >>>> does seem to be the intention.I've added an itest > "contribution-folder" > >>>> which shows what I think should work but doesn't with the current > tuscany > >>>> code. As an example, the folder contribution at [1] the two jars > don't get > >>>> added to the classpath. I wondered what others thought, should this be > >>>> something thats supported? > >>>> > >>>> ...ant > >>>> > >>>> [1] > >>>> > https://svn.apache.org/repos/asf/tuscany/branches/sca-java-1.x/itest/contribution-folder/src/test/resources/repository2/folderWithJars/ > >>> > >> > >> Looking at the bottom of section 12.2 of the latest assembly spec from > >> OASIS (line 3285 on) they talk about what happens when jar files are > found > >> within jar file contributions. They conclude by suggesting that it is up > to > >> the implementation to decide whether the internal jar is treated as a > single > >> contribution artifact or whether the nested jars contents should be > looked > >> at individually. > >> > >> Is it safe to assume that this sentiment applies to Zip/Folder > >> contributions and hence discuss how we wish to treat jar files found > >> therein? > >> > > > > Thats a good indication that this type of function is useful, i don't > think > > its exactly the same situation though. Nesting jars within jars is > "unusual" > > and it does seem to change the commonly expected behaviour of how a jar > > works so i wouldn't be much concerned if jars with jar contributions > didn't > > work. The zip contribution on the other hand seems different to me and a > > much more intuitive way to behave. Now that its come up and the spec says > > what it does I think it seems like a really useful thing to support. > > > > ...ant > > > > > > > > -- > Luciano Resende > Apache Tuscany, Apache PhotArk > http://people.apache.org/~lresende <http://people.apache.org/%7Elresende> > http://lresende.blogspot.com/ >
