Re: Contents of Tuscany binary archives
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=73357package_id=173644release_id=565295 [2] http://marc.info/?l=tuscany-devm=120102342123577 -- SebastiEn :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contents of Tuscany binary archives
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
On Jan 29, 2008 9:04 AM, Simon Laws [EMAIL PROTECTED] 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
On Jan 29, 2008 9:11 AM, ant elder [EMAIL PROTECTED] wrote: On Jan 29, 2008 9:04 AM, Simon Laws [EMAIL PROTECTED] 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
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
On 29/01/2008, Simon Laws [EMAIL PROTECTED] wrote: On Jan 29, 2008 9:11 AM, ant elder [EMAIL PROTECTED] wrote: On Jan 29, 2008 9:04 AM, Simon Laws [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contents of Tuscany binary archives
On Jan 29, 2008 12:08 PM, sebb [EMAIL PROTECTED] wrote: On 29/01/2008, Simon Laws [EMAIL PROTECTED] 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
On 29/01/2008, Simon Laws [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contents of Tuscany binary archives
On 29/01/2008, ant elder [EMAIL PROTECTED] wrote: On Jan 29, 2008 12:08 PM, sebb [EMAIL PROTECTED] wrote: On 29/01/2008, Simon Laws [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contents of Tuscany binary archives
On Jan 29, 2008 10:28 AM, Simon Laws [EMAIL PROTECTED] wrote: On Jan 29, 2008 9:11 AM, ant elder [EMAIL PROTECTED] wrote: On Jan 29, 2008 9:04 AM, Simon Laws [EMAIL PROTECTED] 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
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=73357package_id=173644release_id=565295 [2] http://marc.info/?l=tuscany-devm=120102342123577 -- SebastiEn :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contents of Tuscany binary archives
On Jan 28, 2008 2:17 PM, sebb [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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
Re: Contents of Tuscany binary archives
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contents of Tuscany binary archives
On 28/01/2008, Simon Laws [EMAIL PROTECTED] wrote: On Jan 28, 2008 2:17 PM, sebb [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
