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://lresende.blogspot.com/
