Yep, and we do already support zip contributions, this applies to folder contributions too. In both of those the code already finds various artifacts within the contribution like wsdl or xsd files, i think its "just" a matter of adding similar support to find the jar files and get them added to the contribution classpath. I've raised TUSCANY-2786 to track this, seems like there is consensus emerging that this would be a useful thing to do.
...ant On Fri, Jan 23, 2009 at 6:39 PM, Raymond Feng <[email protected]> wrote: > 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 <[email protected]> > *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 <[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 > >
