You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by sebb <se...@gmail.com> on 2008/01/28 15:17:31 UTC
Contents of Tuscany binary archives
Seems to me it would be useful to create a binary archive without any
of the external jars.
This would considerably reduce the size of the archive.
Most of the jars are likely to remain the same between releases anyway.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Contents of Tuscany binary archives
Posted by Jean-Sebastien Delfino <js...@apache.org>.
sebb wrote:
> Seems to me it would be useful to create a binary archive without any
> of the external jars.
>
> This would considerably reduce the size of the archive.
>
> Most of the jars are likely to remain the same between releases anyway.
>
+1
Many projects do that (Spring for example), you can download an archive
with just the project's JARs and another with everything in it.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Contents of Tuscany binary archives
Posted by Simon Laws <si...@googlemail.com>.
snip...
>
> Spring provides another package with the binaries, samples and docs,
> without dependencies [1], but I was not trying to cover samples when I
> pointed to the Spring example and was not suggesting to only have two
Neither was I. just pointing out that Spring takes a slightly different
approach to where it includes the src. I.e. they include it along with
binaries (and dependencies) in one of their zips.
> packages. I'm actually proposing a more modular distro structure in
> another thread [2].
and for each of the proposed zips we will have to consider how to distribute
binary and source versions. While the referenced thread specifically
excluded the issue of release cycles I had assumed that they would be
presented as separately downloadable artifacts. I'm undecided just how
practical this will be but am willing to give it a go as it has the
potential to make the release process more manageable as we will be dealing
with more bite sized chunks. Albeit more of them. Be useful to know if my
assumption is correct?
> [1]
>
> http://sourceforge.net/project/showfiles.php?group_id=73357&package_id=173644&release_id=565295
> [2] http://marc.info/?l=tuscany-dev&m=120102342123577
> --
> SebastiEn :)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Contents of Tuscany binary archives
Posted by Jean-Sebastien Delfino <js...@apache.org>.
sebb wrote:
[snip]
>> Sebastien pointed us toward Spring as another example which, for the
>> framework, has the slightly different pattern
>>
>> ?-binaries
>> ?-binaries+dependencies-src-samples
Spring provides another package with the binaries, samples and docs,
without dependencies [1], but I was not trying to cover samples when I
pointed to the Spring example and was not suggesting to only have two
packages. I'm actually proposing a more modular distro structure in
another thread [2].
>
> I don't like that - seems a waste to have to download the dependencies
> just to get the samples.
I agree with you :) I wouldn't like it either.
>
> SebastiAn ;-)
>
[1]
http://sourceforge.net/project/showfiles.php?group_id=73357&package_id=173644&release_id=565295
[2] http://marc.info/?l=tuscany-dev&m=120102342123577
--
SebastiEn :)
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Contents of Tuscany binary archives
Posted by sebb <se...@gmail.com>.
On 29/01/2008, Simon Laws <si...@googlemail.com> wrote:
> On Jan 29, 2008 9:11 AM, ant elder <an...@gmail.com> wrote:
>
> > On Jan 29, 2008 9:04 AM, Simon Laws <si...@googlemail.com> wrote:
> >
> > > >
> > > >
> > > > Perhaps you could issue the external dependencies in a separate
> > > > archive; that would need the appropriate N &L of course, but would not
> > > > change very often.
> > > >
> > >
> > > Sounds attractive. So we would have
> > >
> > > tuscany-binaries
> > > tuscany-dependencies
> > > tuscany-src
> > >
> > > I think this would be an advantage if we go ahead and split up our
> > > distributions into smaller units as suggested in [1]. At the moment the
> > > distribution contains everything and the chances that a dependency
> > version
> > > will change is high. With smaller, more focused distribution zips, we
> > may
> > > be
> > > able to maintain a set of dependency versions as the Tuscany function
> > > matures.
> > >
> > > Simon
> > >
> > > [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg27305.html
> > >
> >
> >
> > There would still be a download available that includes both Tuscany and
> > the
> > dependency jars though right? This would just add additional downloads
> > separating Tuscany and dependencies?
> >
> > ...ant
> >
> so you mean...
>
> tuscany-binaries
> tuscany-binaries-with-dependencies
> tuscany-src
The advantage of having a separate dependency package is that you only
need to update it when one of the library items changes. The
disadvantage is having to download 2 archives initially. I see that as
very minor.
> Sebastien pointed us toward Spring as another example which, for the
> framework, has the slightly different pattern
>
> ?-binaries
> ?-binaries+dependencies-src-samples
I don't like that - seems a waste to have to download the dependencies
just to get the samples.
>
> Whichever turns out to be the favoured style in the project I'd like to take
> a more static approach to dealing with and packaging binary dependencies and
> their associated licenses.
>
> Simon
>
SebastiAn ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Contents of Tuscany binary archives
Posted by sebb <se...@gmail.com>.
On 29/01/2008, ant elder <an...@gmail.com> wrote:
> On Jan 29, 2008 12:08 PM, sebb <se...@gmail.com> wrote:
>
> > On 29/01/2008, Simon Laws <si...@googlemail.com> wrote:
> > > >
> > > > An alternative to what we do now with all the licenses embedded in the
> > one
> > > > top level LICENSE file is to include the licenses in individual files
> > > > either
> > > > in a separate licenses folder or in the same folder as the dependency
> > so
> > > > its
> > > > real easy to see if any are missing and what they apply to. I thought
> > that
> > > > was discouraged but it seems to be becoming acceptable again and makes
> > > > thing
> > > > clear i think.
> > >
> > >
> > > +1 Having separate license files, one for each dependency where
> > appropriate,
> > > doesn't mean we can't concat them together into a top level if that is
> > > required.
> >
> > I'm not sure that separate LICENSE files are allowed (tried to find
> > that out recently), but even if they are, AFAIK the main LICENSE file
> > would have to have pointers to the additional files, so could not be a
> > vanilla AL 2.0 anyway.
> >
>
> The closest I can find to matching policy says :
>
> "...Otherwise, you should append their license(s) to the LICENSE file at the
> top of the distribution, or at least put a pointer in the LICENSE file to
> the third-party license." - http://www.apache.org/dev/apply-license.html
>
Great!
That's what I was looking for - now to find the thread where the
question was raised ;-)
> So that makes it sound like it would be acceptable to have the top level
> LICENSE just point to a folder containing the other licenses. Several
> poddling releases that do this have been approved by the IPMC in the recent
> past and other non-incubating releases i've seen also do this.
Agreed.
Or perhaps put all the LICENSES in the same directory, but name the
3rd party ones accordingly, e.g. LICENSE_jdom etc
> ...ant
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Contents of Tuscany binary archives
Posted by ant elder <an...@gmail.com>.
On Jan 29, 2008 12:08 PM, sebb <se...@gmail.com> wrote:
> On 29/01/2008, Simon Laws <si...@googlemail.com> wrote:
> > >
> > > An alternative to what we do now with all the licenses embedded in the
> one
> > > top level LICENSE file is to include the licenses in individual files
> > > either
> > > in a separate licenses folder or in the same folder as the dependency
> so
> > > its
> > > real easy to see if any are missing and what they apply to. I thought
> that
> > > was discouraged but it seems to be becoming acceptable again and makes
> > > thing
> > > clear i think.
> >
> >
> > +1 Having separate license files, one for each dependency where
> appropriate,
> > doesn't mean we can't concat them together into a top level if that is
> > required.
>
> I'm not sure that separate LICENSE files are allowed (tried to find
> that out recently), but even if they are, AFAIK the main LICENSE file
> would have to have pointers to the additional files, so could not be a
> vanilla AL 2.0 anyway.
>
The closest I can find to matching policy says :
"...Otherwise, you should append their license(s) to the LICENSE file at the
top of the distribution, or at least put a pointer in the LICENSE file to
the third-party license." - http://www.apache.org/dev/apply-license.html
So that makes it sound like it would be acceptable to have the top level
LICENSE just point to a folder containing the other licenses. Several
poddling releases that do this have been approved by the IPMC in the recent
past and other non-incubating releases i've seen also do this.
...ant
Re: Contents of Tuscany binary archives
Posted by sebb <se...@gmail.com>.
On 29/01/2008, sebb <se...@gmail.com> wrote:
> On 29/01/2008, Simon Laws <si...@googlemail.com> wrote:
> > >
> > > An alternative to what we do now with all the licenses embedded in the one
> > > top level LICENSE file is to include the licenses in individual files
> > > either
> > > in a separate licenses folder or in the same folder as the dependency so
> > > its
> > > real easy to see if any are missing and what they apply to. I thought that
> > > was discouraged but it seems to be becoming acceptable again and makes
> > > thing
> > > clear i think.
> >
> >
> > +1 Having separate license files, one for each dependency where appropriate,
> > doesn't mean we can't concat them together into a top level if that is
> > required.
>
> I'm not sure that separate LICENSE files are allowed (tried to find
> that out recently), but even if they are, AFAIK the main LICENSE file
> would have to have pointers to the additional files, so could not be a
> vanilla AL 2.0 anyway.
>
> > Another thing that would help a lot is to use the Maven plugins to help
> > > generate our legal files instead of creating them by hand.
>
> There have been some discussions about this in Commons which have yet
> to be resolved. I would wait until those are resolved and the
> documentation is updated before going that route.
>
> >
> > Me immediate reaction is that I don't think having more maven plugins is a
> > good thing. A while back I looked at the plugin configuration that CxF use
> > to generate their license information and it seemed effective but ultimately
> > seems like quite a complicated way of reading a configuration file that maps
> > dependencies to licenses. Probably OK if you wrote the plugin but personally
> > I found it quite difficult to follow. Maybe I didn't spend enough time on
> > it. I know more about releases now so I'll take another look and see if it
> > is clearer.
>
> See above.
Just had a look at the CXF NOTICE file, which looks a mess to me. For
example, it includes the line:
"This product includes/uses software(s) developed by 'an unknown
organization' "
which is not exactly helpful or accurate (or grammatical!) ...
The NOTICE should only apply to software that is included in the
distribution, not transitive dependencies - i.e. the "/uses" should be
removed.
Etc. - please don't go there until the requirements are clarified and
the plugin amended to work as per the requirements ...
> > Simon
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Contents of Tuscany binary archives
Posted by sebb <se...@gmail.com>.
On 29/01/2008, Simon Laws <si...@googlemail.com> wrote:
> >
> > An alternative to what we do now with all the licenses embedded in the one
> > top level LICENSE file is to include the licenses in individual files
> > either
> > in a separate licenses folder or in the same folder as the dependency so
> > its
> > real easy to see if any are missing and what they apply to. I thought that
> > was discouraged but it seems to be becoming acceptable again and makes
> > thing
> > clear i think.
>
>
> +1 Having separate license files, one for each dependency where appropriate,
> doesn't mean we can't concat them together into a top level if that is
> required.
I'm not sure that separate LICENSE files are allowed (tried to find
that out recently), but even if they are, AFAIK the main LICENSE file
would have to have pointers to the additional files, so could not be a
vanilla AL 2.0 anyway.
> Another thing that would help a lot is to use the Maven plugins to help
> > generate our legal files instead of creating them by hand.
There have been some discussions about this in Commons which have yet
to be resolved. I would wait until those are resolved and the
documentation is updated before going that route.
>
> Me immediate reaction is that I don't think having more maven plugins is a
> good thing. A while back I looked at the plugin configuration that CxF use
> to generate their license information and it seemed effective but ultimately
> seems like quite a complicated way of reading a configuration file that maps
> dependencies to licenses. Probably OK if you wrote the plugin but personally
> I found it quite difficult to follow. Maybe I didn't spend enough time on
> it. I know more about releases now so I'll take another look and see if it
> is clearer.
See above.
> Simon
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Contents of Tuscany binary archives
Posted by Simon Laws <si...@googlemail.com>.
>
> An alternative to what we do now with all the licenses embedded in the one
> top level LICENSE file is to include the licenses in individual files
> either
> in a separate licenses folder or in the same folder as the dependency so
> its
> real easy to see if any are missing and what they apply to. I thought that
> was discouraged but it seems to be becoming acceptable again and makes
> thing
> clear i think.
+1 Having separate license files, one for each dependency where appropriate,
doesn't mean we can't concat them together into a top level if that is
required.
Another thing that would help a lot is to use the Maven plugins to help
> generate our legal files instead of creating them by hand.
Me immediate reaction is that I don't think having more maven plugins is a
good thing. A while back I looked at the plugin configuration that CxF use
to generate their license information and it seemed effective but ultimately
seems like quite a complicated way of reading a configuration file that maps
dependencies to licenses. Probably OK if you wrote the plugin but personally
I found it quite difficult to follow. Maybe I didn't spend enough time on
it. I know more about releases now so I'll take another look and see if it
is clearer.
Simon
Re: Contents of Tuscany binary archives
Posted by ant elder <an...@apache.org>.
On Jan 29, 2008 10:28 AM, Simon Laws <si...@googlemail.com> wrote:
> On Jan 29, 2008 9:11 AM, ant elder <an...@gmail.com> wrote:
>
> > On Jan 29, 2008 9:04 AM, Simon Laws <si...@googlemail.com> wrote:
> >
> > > >
> > > >
> > > > Perhaps you could issue the external dependencies in a separate
> > > > archive; that would need the appropriate N &L of course, but would
> not
> > > > change very often.
> > > >
> > >
> > > Sounds attractive. So we would have
> > >
> > > tuscany-binaries
> > > tuscany-dependencies
> > > tuscany-src
> > >
> > > I think this would be an advantage if we go ahead and split up our
> > > distributions into smaller units as suggested in [1]. At the moment
> the
> > > distribution contains everything and the chances that a dependency
> > version
> > > will change is high. With smaller, more focused distribution zips, we
> > may
> > > be
> > > able to maintain a set of dependency versions as the Tuscany function
> > > matures.
> > >
> > > Simon
> > >
> > > [1]
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg27305.html
> > >
> >
> >
> > There would still be a download available that includes both Tuscany and
> > the
> > dependency jars though right? This would just add additional downloads
> > separating Tuscany and dependencies?
> >
> > ...ant
> >
> so you mean...
>
> tuscany-binaries
> tuscany-binaries-with-dependencies
> tuscany-src
>
> Sebastien pointed us toward Spring as another example which, for the
> framework, has the slightly different pattern
>
> ?-binaries
> ?-binaries+dependencies-src-samples
>
> Whichever turns out to be the favoured style in the project I'd like to
> take
> a more static approach to dealing with and packaging binary dependencies
> and
> their associated licenses.
>
> Simon
>
An alternative to what we do now with all the licenses embedded in the one
top level LICENSE file is to include the licenses in individual files either
in a separate licenses folder or in the same folder as the dependency so its
real easy to see if any are missing and what they apply to. I thought that
was discouraged but it seems to be becoming acceptable again and makes thing
clear i think.
Another thing that would help a lot is to use the Maven plugins to help
generate our legal files instead of creating them by hand.
...ant
Re: Contents of Tuscany binary archives
Posted by Simon Laws <si...@googlemail.com>.
On Jan 29, 2008 9:11 AM, ant elder <an...@gmail.com> wrote:
> On Jan 29, 2008 9:04 AM, Simon Laws <si...@googlemail.com> wrote:
>
> > >
> > >
> > > Perhaps you could issue the external dependencies in a separate
> > > archive; that would need the appropriate N &L of course, but would not
> > > change very often.
> > >
> >
> > Sounds attractive. So we would have
> >
> > tuscany-binaries
> > tuscany-dependencies
> > tuscany-src
> >
> > I think this would be an advantage if we go ahead and split up our
> > distributions into smaller units as suggested in [1]. At the moment the
> > distribution contains everything and the chances that a dependency
> version
> > will change is high. With smaller, more focused distribution zips, we
> may
> > be
> > able to maintain a set of dependency versions as the Tuscany function
> > matures.
> >
> > Simon
> >
> > [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg27305.html
> >
>
>
> There would still be a download available that includes both Tuscany and
> the
> dependency jars though right? This would just add additional downloads
> separating Tuscany and dependencies?
>
> ...ant
>
so you mean...
tuscany-binaries
tuscany-binaries-with-dependencies
tuscany-src
Sebastien pointed us toward Spring as another example which, for the
framework, has the slightly different pattern
?-binaries
?-binaries+dependencies-src-samples
Whichever turns out to be the favoured style in the project I'd like to take
a more static approach to dealing with and packaging binary dependencies and
their associated licenses.
Simon
Re: Contents of Tuscany binary archives
Posted by ant elder <an...@gmail.com>.
On Jan 29, 2008 9:04 AM, Simon Laws <si...@googlemail.com> wrote:
> >
> >
> > Perhaps you could issue the external dependencies in a separate
> > archive; that would need the appropriate N &L of course, but would not
> > change very often.
> >
>
> Sounds attractive. So we would have
>
> tuscany-binaries
> tuscany-dependencies
> tuscany-src
>
> I think this would be an advantage if we go ahead and split up our
> distributions into smaller units as suggested in [1]. At the moment the
> distribution contains everything and the chances that a dependency version
> will change is high. With smaller, more focused distribution zips, we may
> be
> able to maintain a set of dependency versions as the Tuscany function
> matures.
>
> Simon
>
> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg27305.html
>
There would still be a download available that includes both Tuscany and the
dependency jars though right? This would just add additional downloads
separating Tuscany and dependencies?
...ant
Re: Contents of Tuscany binary archives
Posted by Simon Laws <si...@googlemail.com>.
>
>
> Perhaps you could issue the external dependencies in a separate
> archive; that would need the appropriate N &L of course, but would not
> change very often.
>
Sounds attractive. So we would have
tuscany-binaries
tuscany-dependencies
tuscany-src
I think this would be an advantage if we go ahead and split up our
distributions into smaller units as suggested in [1]. At the moment the
distribution contains everything and the chances that a dependency version
will change is high. With smaller, more focused distribution zips, we may be
able to maintain a set of dependency versions as the Tuscany function
matures.
Simon
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg27305.html
Re: Contents of Tuscany binary archives
Posted by sebb <se...@gmail.com>.
On 28/01/2008, Simon Laws <si...@googlemail.com> wrote:
> On Jan 28, 2008 2:17 PM, sebb <se...@gmail.com> wrote:
>
> > Seems to me it would be useful to create a binary archive without any
> > of the external jars.
> >
> > This would considerably reduce the size of the archive.
> >
> > Most of the jars are likely to remain the same between releases anyway.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> Hi sebb
>
> Do you mean as well as or instead of the current binary archive we have that
> includes all of the required jars?
If it was instead of, then you could simplify the accompanying N & L files.
However, that would be a pain for first-time users who would then have
to download all the dependencies.
Perhaps you could issue the external dependencies in a separate
archive; that would need the appropriate N &L of course, but would not
change very often.
And/or provide a script (e.g. Ant) to download them - this would need
to alert the user to the license requirements; not sure how easy that
is to do - but of course would be quite small and could be included in
the binary archive.
> You have hit upon one of the hot topics on the dev list at the moment, for
> example, [1][2][3]. You input is very welcome.
Thanks.
> Regards
>
> Simon
>
> [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27351.html
> [2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg27305.html
> [3] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26912.html
>
Yes, I've seen some of those, but I was not subscribed until just now.
Not sure I can join in with the thread until another message
arrives...
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Contents of Tuscany binary archives
Posted by Simon Laws <si...@googlemail.com>.
On Jan 28, 2008 2:17 PM, sebb <se...@gmail.com> wrote:
> Seems to me it would be useful to create a binary archive without any
> of the external jars.
>
> This would considerably reduce the size of the archive.
>
> Most of the jars are likely to remain the same between releases anyway.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Hi sebb
Do you mean as well as or instead of the current binary archive we have that
includes all of the required jars?
You have hit upon one of the hot topics on the dev list at the moment, for
example, [1][2][3]. You input is very welcome.
Regards
Simon
[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27351.html
[2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg27305.html
[3] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26912.html