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 <[email protected]> >>> *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
