There is no question that we need to support the ZIP format for SCA contributions. The tricky thing is that zip is just an archive without well-defined semantics. We need to find a reasonable way to extract resources out of the archive. Java classes or jars can be java resources from zip. The class loading scheme is not defined by any standard AFAIK. We will have to flush it out.
Thanks, Raymond From: ant elder Sent: Friday, January 23, 2009 9:52 AM To: [email protected] Subject: Re: Folder and ZIP format contributions containing nested application JARs 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
