You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2009/01/23 17:39:39 UTC
Re: Folder and ZIP format contributions containing nested application JARs
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: dev@tuscany.apache.org
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/
Re: Folder and ZIP format contributions containing nested application
JARs
Posted by ant elder <an...@apache.org>.
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 <lu...@gmail.com>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 <an...@apache.org> wrote:
> >
> >
> > On Fri, Jan 23, 2009 at 5:08 PM, Simon Laws <si...@googlemail.com>
> > wrote:
> >>
> >>
> >> On Fri, Jan 23, 2009 at 4:54 PM, ant elder <an...@gmail.com> 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 <en...@gmail.com>
> >>> 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: dev@tuscany.apache.org
> >>>> 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/
>
Re: Folder and ZIP format contributions containing nested application
JARs
Posted by Luciano Resende <lu...@gmail.com>.
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 <an...@apache.org> wrote:
>
>
> On Fri, Jan 23, 2009 at 5:08 PM, Simon Laws <si...@googlemail.com>
> wrote:
>>
>>
>> On Fri, Jan 23, 2009 at 4:54 PM, ant elder <an...@gmail.com> 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 <en...@gmail.com>
>>> 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: dev@tuscany.apache.org
>>>> 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/
Re: Folder and ZIP format contributions containing nested application
JARs
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Apr 17, 2009 at 4:50 PM, ant elder <an...@apache.org> wrote:
> On Fri, Apr 17, 2009 at 4:42 PM, Simon Laws <si...@googlemail.com> wrote:
>> On Fri, Apr 3, 2009 at 6:02 PM, ant elder <an...@apache.org> wrote:
>>> On Fri, Apr 3, 2009 at 5:50 PM, Raymond Feng <en...@gmail.com> wrote:
>>>> --------------------------------------------------
>>>> From: "ant elder" <an...@apache.org>
>>>> Sent: Friday, April 03, 2009 9:16 AM
>>>> To: <de...@tuscany.apache.org>
>>>> Subject: Re: Folder and ZIP format contributions containing nested
>>>> application JARs
>>>>
>>>> [[snip]]
>>>>>
>>>>> I'm not sure if you're objecting to supporting zip contributions with
>>>>> nested jars or that currently the change to do that doesn't
>>>>> discriminated between zip and jar contributions so its possible to
>>>>> nest jars in jars?
>>>>
>>>> I'm against adding nested jars to jar contributions. Zip contributions can
>>>> have its own classloading scheme.
>>>>
>>>
>>> Cool, me too. Like i said earlier this is work in progress and thats
>>> just a whole that needs to be plugged, i'll go prevent that from being
>>> possible.
>>>
>>> ...ant
>>>
>>
>> Sorry, I overlooked this thread as I was out at the time. In summary
>> then are you saying your preference is the following....
>>
>> OK
>> -----
>>
>> mycontrib.ear
>> myutil.jar
>>
>> mycontrib/
>> myutil.jar
>>
>> Not OK
>> -----------
>>
>> mycontrib.jar
>> myutil.jar
>>
>> Simon
>>
>
> Assuming you mean zip ("mycontrib.zip" not "mycontrib.ear") then yes,
> and thats what the code 1.x and 2.x support now.
>
> ...ant
>
oops, ears on the brain. Yes I had intended "mycontrib.zip" not
"mycontrib.ear". Although mycontrib.ear as a contribution is also a
valid scenario so
OK
-----
mycontrib.ear
myutil.jar
mycontrib.zip
myutil.jar
mycontrib/
myutil.jar
Not OK
-----------
mycontrib.jar
myutil.jar
Seems ok to me.
Simon
Re: Folder and ZIP format contributions containing nested application
JARs
Posted by ant elder <an...@apache.org>.
On Fri, Apr 17, 2009 at 4:42 PM, Simon Laws <si...@googlemail.com> wrote:
> On Fri, Apr 3, 2009 at 6:02 PM, ant elder <an...@apache.org> wrote:
>> On Fri, Apr 3, 2009 at 5:50 PM, Raymond Feng <en...@gmail.com> wrote:
>>> --------------------------------------------------
>>> From: "ant elder" <an...@apache.org>
>>> Sent: Friday, April 03, 2009 9:16 AM
>>> To: <de...@tuscany.apache.org>
>>> Subject: Re: Folder and ZIP format contributions containing nested
>>> application JARs
>>>
>>> [[snip]]
>>>>
>>>> I'm not sure if you're objecting to supporting zip contributions with
>>>> nested jars or that currently the change to do that doesn't
>>>> discriminated between zip and jar contributions so its possible to
>>>> nest jars in jars?
>>>
>>> I'm against adding nested jars to jar contributions. Zip contributions can
>>> have its own classloading scheme.
>>>
>>
>> Cool, me too. Like i said earlier this is work in progress and thats
>> just a whole that needs to be plugged, i'll go prevent that from being
>> possible.
>>
>> ...ant
>>
>
> Sorry, I overlooked this thread as I was out at the time. In summary
> then are you saying your preference is the following....
>
> OK
> -----
>
> mycontrib.ear
> myutil.jar
>
> mycontrib/
> myutil.jar
>
> Not OK
> -----------
>
> mycontrib.jar
> myutil.jar
>
> Simon
>
Assuming you mean zip ("mycontrib.zip" not "mycontrib.ear") then yes,
and thats what the code 1.x and 2.x support now.
...ant
Re: Folder and ZIP format contributions containing nested application
JARs
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Apr 3, 2009 at 6:02 PM, ant elder <an...@apache.org> wrote:
> On Fri, Apr 3, 2009 at 5:50 PM, Raymond Feng <en...@gmail.com> wrote:
>> --------------------------------------------------
>> From: "ant elder" <an...@apache.org>
>> Sent: Friday, April 03, 2009 9:16 AM
>> To: <de...@tuscany.apache.org>
>> Subject: Re: Folder and ZIP format contributions containing nested
>> application JARs
>>
>> [[snip]]
>>>
>>> I'm not sure if you're objecting to supporting zip contributions with
>>> nested jars or that currently the change to do that doesn't
>>> discriminated between zip and jar contributions so its possible to
>>> nest jars in jars?
>>
>> I'm against adding nested jars to jar contributions. Zip contributions can
>> have its own classloading scheme.
>>
>
> Cool, me too. Like i said earlier this is work in progress and thats
> just a whole that needs to be plugged, i'll go prevent that from being
> possible.
>
> ...ant
>
Sorry, I overlooked this thread as I was out at the time. In summary
then are you saying your preference is the following....
OK
-----
mycontrib.ear
myutil.jar
mycontrib/
myutil.jar
Not OK
-----------
mycontrib.jar
myutil.jar
Simon
Re: Folder and ZIP format contributions containing nested application
JARs
Posted by ant elder <an...@apache.org>.
On Fri, Apr 3, 2009 at 5:50 PM, Raymond Feng <en...@gmail.com> wrote:
> --------------------------------------------------
> From: "ant elder" <an...@apache.org>
> Sent: Friday, April 03, 2009 9:16 AM
> To: <de...@tuscany.apache.org>
> Subject: Re: Folder and ZIP format contributions containing nested
> application JARs
>
> [[snip]]
>>
>> I'm not sure if you're objecting to supporting zip contributions with
>> nested jars or that currently the change to do that doesn't
>> discriminated between zip and jar contributions so its possible to
>> nest jars in jars?
>
> I'm against adding nested jars to jar contributions. Zip contributions can
> have its own classloading scheme.
>
Cool, me too. Like i said earlier this is work in progress and thats
just a whole that needs to be plugged, i'll go prevent that from being
possible.
...ant
Re: Folder and ZIP format contributions containing nested application JARs
Posted by Raymond Feng <en...@gmail.com>.
--------------------------------------------------
From: "ant elder" <an...@apache.org>
Sent: Friday, April 03, 2009 9:16 AM
To: <de...@tuscany.apache.org>
Subject: Re: Folder and ZIP format contributions containing nested
application JARs
[[snip]]
> I'm not sure if you're objecting to supporting zip contributions with
> nested jars or that currently the change to do that doesn't
> discriminated between zip and jar contributions so its possible to
> nest jars in jars?
I'm against adding nested jars to jar contributions. Zip contributions can
have its own classloading scheme.
>
> I don't think we should require a manifest in a zip contribution as
> the spec doesn't say thats required, i guess we could support an
> optional manifest to enable defining only a subset of the nested jars
> get used though it doesn't seem like a high priority to me.
We might need to bring this up to the SCA spec to get clarifications on how
Zip should be handled.
>
> ...ant
Re: Folder and ZIP format contributions containing nested application
JARs
Posted by ant elder <an...@apache.org>.
On Fri, Apr 3, 2009 at 5:02 PM, Raymond Feng <en...@gmail.com> wrote:
> I have some concerns over the changes [1][2] to add nested jars onto the
> classpath of a jar contribution without consulting the manifest.
>
> Jar is a standard packaging scheme [3] in java, we shouldn't try to invent a
> new classloading behavior. For jar, the Class-Path header in
> META-INF/MANIFEST.MF is used to extend the classpath.
>
> Other standard archives such as JEE EAR/WAR or OSGi bundle
> (Bundle-ClassPath) defines how the nested jars are honored using additional
> manifest files or deployment descriptors. We should respect them.
>
> There is no standard way to deal with zip in Java classloading. I'm fine
> with the default behavior to include all nested jars on the classpath. Maybe
> we should also require a manifest file in the zip to provide the inner jars
> to the classpath.
>
I'm not sure if you're objecting to supporting zip contributions with
nested jars or that currently the change to do that doesn't
discriminated between zip and jar contributions so its possible to
nest jars in jars?
I don't think we should require a manifest in a zip contribution as
the spec doesn't say thats required, i guess we could support an
optional manifest to enable defining only a subset of the nested jars
get used though it doesn't seem like a high priority to me.
...ant
Re: Folder and ZIP format contributions containing nested application JARs
Posted by Raymond Feng <en...@gmail.com>.
I have some concerns over the changes [1][2] to add nested jars onto the
classpath of a jar contribution without consulting the manifest.
Jar is a standard packaging scheme [3] in java, we shouldn't try to invent a
new classloading behavior. For jar, the Class-Path header in
META-INF/MANIFEST.MF is used to extend the classpath.
Other standard archives such as JEE EAR/WAR or OSGi bundle
(Bundle-ClassPath) defines how the nested jars are honored using additional
manifest files or deployment descriptors. We should respect them.
There is no standard way to deal with zip in Java classloading. I'm fine
with the default behavior to include all nested jars on the classpath. Maybe
we should also require a manifest file in the zip to provide the inner jars
to the classpath.
[1] http://svn.apache.org/viewvc?rev=761236&view=rev
[2] http://svn.apache.org/viewvc?rev=761611&view=rev
[3] http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@gmail.com>
Sent: Thursday, April 02, 2009 6:06 AM
To: <de...@tuscany.apache.org>
Subject: Re: Folder and ZIP format contributions containing nested
application JARs
> On Thu, Apr 2, 2009 at 11:24 AM, ant elder <an...@gmail.com> wrote:
>> On Sat, Jan 24, 2009 at 10:10 AM, ant elder <an...@gmail.com> wrote:
>>> 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
>>
>> I was asked off list by a user about when we'd be supporting this,
>> I've asked them to post to the ML about it but in the meantime i had a
>> quick go at adding support for this in 2.x r761236. Its work in
>> progress and presently jars within zips get copied to temporary files
>> which doesn't seem ideal, but its enough to get the two itests for zip
>> and folder contributions running. Comments on better approaches
>> welcome.
>>
>> ...ant
>>
>
> and if we're going to support zip contributions there are some other
> things that would be nice to do:
>
> - a maven plugin for creating zip contributions. You could do it with
> the maven assembly plugin but it would be nice to simplify that so you
> can do something like just have <packaging>sca-zip</packaging> in the
> pom.xml and perhaps a simple way to include/exclude dependency jars
> that get included in the zip.
>
> - an archetype to create sca zip contribution projects
>
> - update the webapp runtime so it can use jar and zip contributions as
> well as the existing way of having everything in web-inf/classes
>
> ...ant
Re: Folder and ZIP format contributions containing nested application
JARs
Posted by ant elder <an...@gmail.com>.
On Thu, Apr 2, 2009 at 11:24 AM, ant elder <an...@gmail.com> wrote:
> On Sat, Jan 24, 2009 at 10:10 AM, ant elder <an...@gmail.com> wrote:
>> 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
>
> I was asked off list by a user about when we'd be supporting this,
> I've asked them to post to the ML about it but in the meantime i had a
> quick go at adding support for this in 2.x r761236. Its work in
> progress and presently jars within zips get copied to temporary files
> which doesn't seem ideal, but its enough to get the two itests for zip
> and folder contributions running. Comments on better approaches
> welcome.
>
> ...ant
>
and if we're going to support zip contributions there are some other
things that would be nice to do:
- a maven plugin for creating zip contributions. You could do it with
the maven assembly plugin but it would be nice to simplify that so you
can do something like just have <packaging>sca-zip</packaging> in the
pom.xml and perhaps a simple way to include/exclude dependency jars
that get included in the zip.
- an archetype to create sca zip contribution projects
- update the webapp runtime so it can use jar and zip contributions as
well as the existing way of having everything in web-inf/classes
...ant
Re: Folder and ZIP format contributions containing nested application
JARs
Posted by ant elder <an...@gmail.com>.
On Sat, Jan 24, 2009 at 10:10 AM, ant elder <an...@gmail.com> wrote:
> 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
I was asked off list by a user about when we'd be supporting this,
I've asked them to post to the ML about it but in the meantime i had a
quick go at adding support for this in 2.x r761236. Its work in
progress and presently jars within zips get copied to temporary files
which doesn't seem ideal, but its enough to get the two itests for zip
and folder contributions running. Comments on better approaches
welcome.
...ant
Re: Folder and ZIP format contributions containing nested application
JARs
Posted by ant elder <an...@gmail.com>.
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 <en...@gmail.com> 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 <an...@apache.org>
> *Sent:* Friday, January 23, 2009 9:52 AM
> *To:* dev@tuscany.apache.org
> *Subject:* Re: Folder and ZIP format contributions containing nested
> application JARs
>
>
>
> On Fri, Jan 23, 2009 at 5:08 PM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Fri, Jan 23, 2009 at 4:54 PM, ant elder <an...@gmail.com> 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 <en...@gmail.com>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 <an...@gmail.com>
>>>> *Sent:* Friday, January 23, 2009 1:44 AM
>>>> *To:* dev@tuscany.apache.org
>>>> *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
>
>
Re: Folder and ZIP format contributions containing nested application JARs
Posted by Raymond Feng <en...@gmail.com>.
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: dev@tuscany.apache.org
Subject: Re: Folder and ZIP format contributions containing nested application JARs
On Fri, Jan 23, 2009 at 5:08 PM, Simon Laws <si...@googlemail.com> wrote:
On Fri, Jan 23, 2009 at 4:54 PM, ant elder <an...@gmail.com> 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 <en...@gmail.com> 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: dev@tuscany.apache.org
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
Re: Folder and ZIP format contributions containing nested application
JARs
Posted by ant elder <an...@apache.org>.
On Fri, Jan 23, 2009 at 5:08 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Fri, Jan 23, 2009 at 4:54 PM, ant elder <an...@gmail.com> 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 <en...@gmail.com>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 <an...@gmail.com>
>>> *Sent:* Friday, January 23, 2009 1:44 AM
>>> *To:* dev@tuscany.apache.org
>>> *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
Re: Folder and ZIP format contributions containing nested application
JARs
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Jan 23, 2009 at 4:54 PM, ant elder <an...@gmail.com> 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 <en...@gmail.com> 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 <an...@gmail.com>
>> *Sent:* Friday, January 23, 2009 1:44 AM
>> *To:* dev@tuscany.apache.org
>> *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?
Simon
Re: Folder and ZIP format contributions containing nested application
JARs
Posted by ant elder <an...@gmail.com>.
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 <en...@gmail.com> 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 <an...@gmail.com>
> *Sent:* Friday, January 23, 2009 1:44 AM
> *To:* dev@tuscany.apache.org
> *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/
>