On Feb 2, 2008, at 2:08 PM, nicolas de loof wrote:
on [EMAIL PROTECTED],
http://mail-archives.apache.org/mod_mbox/www-repository/200802.mbox/thread
LICENSE, NOTICE and other *.txt files (release note, readme ...) have
been added at jar root.
I can rebuild the jars with those files in META-INF if required.
The script was not designed for reproductibility but to avoid
manually browse on repo, download, unzip and so on..
Here is the code. It is not portable (based on my computer path and
tools) and produces on System.out DOS commands to get executed. Some
downloaded artifacts also required some folder name fix as they
didn't follow other commons-* conventions.
I'm OK to publish it under Apache license ;-)
This discussion should move to the dev@commons.apache.org mailing
list, since the Commons PMC is responsible for whatever is released
for that project. The thread has been cross-posted between [EMAIL PROTECTED]
, [EMAIL PROTECTED] and [EMAIL PROTECTED] I'm cross-
posting to [EMAIL PROTECTED], but this should be the last post on
that list until the issue is resolved in the commons PMC.
The one -sources.jar that I looked at commons-beanutil-1.6-sources.jar
did not have a NOTICE file anywhere in the release. It did have a
LICENSE.txt in the root directory, but that was a ASL 1.1, not ASL 2.0.
In addition, the source files in that release do not adhere to the ASF
Source Header and Copyright Notice Policy to which all ASF releases
created after November 1. 2006 must comply.
As such, the sources.jar would not be acceptable in a new release. I
don't think that there would be an exception for a new repackaging of
a prior release, but I'd like to see that checked against legal-
discuss or [EMAIL PROTECTED], but that is the Commons PMC's responsibility.
My take would be:
a) A sources repackaging of a commons release that adheres to the ASF
Source Header Policy is achievable. I'd prefer to see it done with
something much more portable (Apache Ant would be my choice). There
should be some automated check for proper Source Headers and presence
of NOTICE and LICENSE. The artifacts should be posted (as the current
ones have been) and a formal vote called on the
[EMAIL PROTECTED] After a successful conclusion of that vote
(72 hours elapsed, 3 +1's from PMC members, et al), then the
candidates could be copied to the rsync master.
b) Releases that predate or otherwise don't adhere to the ASF Source
Header Policy should not have retroactive sources.jar releases. You
can't change the source to change the notice and still be consistent
with the previous release and you can't release anything new (at least
in my opinion) that does not conform to the current ASF release
policies. If you really want to get the sources to a project that has
non-conforming source code, then you should do the sources.jar as part
of a new complete release even if the only change is the source
headers. Again that should be subject to a standard release vote.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
