You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by nicolas de loof <ni...@apache.org> on 2008/02/01 21:09:44 UTC
apache commons-* -sources.jar
Hello,
Many apache commons have no -source.jar bundle in maven "central" repo. I've
created some of them based on the official source distribution for my
personnal use.
Would you allow me use
/x1/www/people.apache.org/repo/m1-ibiblio-rsync-repository/ for adding them,
or do you prefer a more formal MAVENUPLOAD / MEV request ?
Nicolas.
Re: apache commons-* -sources.jar
Posted by Torsten Curdt <tc...@vafer.org>.
I had a brief look into some of them. License seems to be in there.
As they are compiled from the source dist I am all for a quick vote
to push those out to the maven repo. Any other opinions?
cheers
--
Torsten
On 02.02.2008, at 10:56, nicolas de loof wrote:
> I've put some -sources.jars in :
>
> http://people.apache.org/~nicolas/missing-commons-sources.jar/
>
> Those one have been created by a script :
>
> - create list of commons-* without -sources.jar in repo
> - search for a src-zip distribution in www.apache.org/dist
> - wget available ones
> - unzip, jar a src/java + src/resources + *.txt
>
> Nico.
>
> 2008/2/1, Torsten Curdt <tc...@apache.org>:
>>
>>
>> On 01.02.2008, at 21:09, nicolas de loof wrote:
>>
>>> Hello,
>>>
>>> Many apache commons have no -source.jar bundle in maven "central"
>>> repo. I've
>>> created some of them based on the official source distribution
>>> for my
>>> personnal use.
>>>
>>> Would you allow me use
>>> /x1/www/people.apache.org/repo/m1-ibiblio-rsync-repository/ for
>>> adding them,
>>> or do you prefer a more formal MAVENUPLOAD / MEV request ?
>>
>> Well, going through the ibiblio sync should be fine ...but could you
>> put the artifacts up somewhere else first? As they are still
>> artifacts the PMC should probably vote for them first.
>>
>> cheers
>> --
>> Torsten
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
Re: apache commons-* -sources.jar
Posted by nicolas de loof <ni...@apache.org>.
commons-beanutils-1.6-sources.jar is created from
commons-beanutils-1.6-src.zip that does not contain the required NOTICE file
(only LICENSE)
Can I vote -1 to release beanutils-1.6 ? ;-p
2008/2/2, Curt Arnold carnold@apache.org:
>
>
> I looked at commons-beanutils-1.6-sources.jar and it did not contain a
> LICENSE and NOTICE file in the META-INF directory as required by
> http://www.apache.org/dev/release.html#distribute-raw-artifact
> . I assume that is likely the case for the other source jar files.
> That is a mandatory -1 on these as releases for me.
>
> The script used to prepare the source jars should be made available so
> that others can confirm that the build process is repeatable. If I
> can look at the script, run it myself and compare my results with your
> results, I have more confidence that the process is repeatable and
> honest. Obviously, the script should be ASL v2 licensed.
>
>
Re: apache commons-* -sources.jar
Posted by Dennis Lundberg <de...@apache.org>.
Phil Steitz wrote:
> On Feb 2, 2008 3:44 PM, Dennis Lundberg <de...@apache.org> wrote:
>> simon wrote:
>>> On Sat, 2008-02-02 at 15:25 -0600, Curt Arnold wrote:
>>>> On Feb 2, 2008, at 2:08 PM, nicolas de loof wrote:
>>>> on repository@apache.org, 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 repository@apache.org
>>>> , pmc@commons.apache.org and dev@commons.apache.org. I'm cross-
>>>> posting to repository@apache.org, 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 board@apache, 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
>>>> dev@commons.apache.org. 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.
>>> I think all this legalese stuff is rather excessive.
>> I agree. These are not *new* releases. The -sources jars should follow
>> the policy and license that were current when the original release was made.
>>
>>
>>> All these files already have binary releases that do have valid
>>> copyright and notice statements in them. These source jars are only for
>>> the convenience of people using IDEs.
>>>
>>> Each source file has an appropriate header on it, and if people have any
>>> further questions about the licensing of the source they see, then
>>> either the binary or the svn repository has the correct answer.
>>>
>>> Remember that in the absence of a license to redistribute, people do NOT
>>> have the right to redistribute. So we are not turning these files into
>>> public domain even if no license is provided at all.
>>>
>>> The only question I see is whether the source is *right*. It would be
>>> rather embarrassing to publish source that does not quite match the
>>> binary, so a second check on these is probably a good idea. But even
>>> then it isn't fatal; changing a binary once it has been published in a
>>> maven repository is a really bad idea because it makes builds
>>> unrepeatable. However changing the source is not such a big issue, and
>>> could be fixed after the fact if necessary.
>>>
>>> Nicolas is right that this would be a nice service to some Apache
>>> software users. It's not a big thing because these releases that are
>>> being fixed are all old ones (we have our act together now) but it's
>>> still nice to do. Let's not make this harder than it needs to be.
>>>
>>> And anyway, if notice/license is to be put in these source jars I would
>>> just take it from the equivalent binary jar's META-INF directory. If the
>>> project was originally published under ASF1.1, it seems right to me that
>>> the same license should be attached to the source jar.
>>>
>>> So unless there is an official statement from the board, or a qualified
>>> lawyer says this is wrong, I'm +1 on releasing these sources jars, but
>>> suggest that people be given a few days to check that they have the
>>> right contents first.
>>>
>
> First we have to decide whether this maven repo pushing business
> constititutes a release. If its us (i.e. ASF and not some third party
> package-maker) who is doing the publication, then I think it does.
> This means we have to VOTE before we do anything.
>
> I will vote -1 for anything new that we release that does not include
> NOTICE and LICENSE as part of the distribution. I view source
> distributions as equally - in fact more - important than binaries,
> which are really just a convenience for users, so re-releasing sources
> needs to be done carefully. This is not legalese, it is appropriate
> PMC oversight and release management.
Yes, the re-packaged jar file must follow the same rules as the original
zip file. These files must all be checked by the PMC. A vote before they
are published seems reasonable.
> Given the hassle of doing this, committing whatever is necessary to
> reproduce the new source releases, review and vote on them, etc; might
> it be better to just publish a script or instructions somewhere on how
> to make an IDE/maven-lovable sources jars from a commons source zip or
> tarball? That way users could create these themselves from the actual
> source distributions. Is that unreasonable?
Yes, I think it is unreasonable. Publishing -sources jars to the central
repository is so that users don't have to do this packaging themselves.
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: apache commons-* -sources.jar
Posted by simon <si...@chello.at>.
On Sat, 2008-02-02 at 16:09 -0700, Phil Steitz wrote:
> First we have to decide whether this maven repo pushing business
> constititutes a release. If its us (i.e. ASF and not some third party
> package-maker) who is doing the publication, then I think it does.
> This means we have to VOTE before we do anything.
>
> I will vote -1 for anything new that we release that does not include
> NOTICE and LICENSE as part of the distribution. I view source
> distributions as equally - in fact more - important than binaries,
> which are really just a convenience for users, so re-releasing sources
> needs to be done carefully. This is not legalese, it is appropriate
> PMC oversight and release management.
>
> Given the hassle of doing this, committing whatever is necessary to
> reproduce the new source releases, review and vote on them, etc; might
> it be better to just publish a script or instructions somewhere on how
> to make an IDE/maven-lovable sources jars from a commons source zip or
> tarball? That way users could create these themselves from the actual
> source distributions. Is that unreasonable?
But the data that will be in these jars has already been published.
Nicolas specifically wrote a script that just takes the src.zip file we
published in the dist dir and repackages the source code from there as a
jar.
It's a minor transformation of existing published info, which for me
doesn't qualify as a "new release".
Everyone is entitled to their own view of course, but for me the PMC is
here to ensure that stuff published is (a) legal, and (b) of reasonable
quality. I don't see how Nicolas' work endangers either of these, as
this is just extracting a subset of stuff we have *already* released,
and then applying a different compression method (jar, not zip).
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: apache commons-* -sources.jar
Posted by Phil Steitz <ph...@gmail.com>.
On Feb 2, 2008 3:44 PM, Dennis Lundberg <de...@apache.org> wrote:
>
> simon wrote:
> > On Sat, 2008-02-02 at 15:25 -0600, Curt Arnold wrote:
> >> On Feb 2, 2008, at 2:08 PM, nicolas de loof wrote:
> >> on repository@apache.org, 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 repository@apache.org
> >> , pmc@commons.apache.org and dev@commons.apache.org. I'm cross-
> >> posting to repository@apache.org, 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 board@apache, 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
> >> dev@commons.apache.org. 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.
> >
> > I think all this legalese stuff is rather excessive.
>
> I agree. These are not *new* releases. The -sources jars should follow
> the policy and license that were current when the original release was made.
>
>
> > All these files already have binary releases that do have valid
> > copyright and notice statements in them. These source jars are only for
> > the convenience of people using IDEs.
> >
> > Each source file has an appropriate header on it, and if people have any
> > further questions about the licensing of the source they see, then
> > either the binary or the svn repository has the correct answer.
> >
> > Remember that in the absence of a license to redistribute, people do NOT
> > have the right to redistribute. So we are not turning these files into
> > public domain even if no license is provided at all.
> >
> > The only question I see is whether the source is *right*. It would be
> > rather embarrassing to publish source that does not quite match the
> > binary, so a second check on these is probably a good idea. But even
> > then it isn't fatal; changing a binary once it has been published in a
> > maven repository is a really bad idea because it makes builds
> > unrepeatable. However changing the source is not such a big issue, and
> > could be fixed after the fact if necessary.
> >
> > Nicolas is right that this would be a nice service to some Apache
> > software users. It's not a big thing because these releases that are
> > being fixed are all old ones (we have our act together now) but it's
> > still nice to do. Let's not make this harder than it needs to be.
> >
> > And anyway, if notice/license is to be put in these source jars I would
> > just take it from the equivalent binary jar's META-INF directory. If the
> > project was originally published under ASF1.1, it seems right to me that
> > the same license should be attached to the source jar.
> >
> > So unless there is an official statement from the board, or a qualified
> > lawyer says this is wrong, I'm +1 on releasing these sources jars, but
> > suggest that people be given a few days to check that they have the
> > right contents first.
> >
First we have to decide whether this maven repo pushing business
constititutes a release. If its us (i.e. ASF and not some third party
package-maker) who is doing the publication, then I think it does.
This means we have to VOTE before we do anything.
I will vote -1 for anything new that we release that does not include
NOTICE and LICENSE as part of the distribution. I view source
distributions as equally - in fact more - important than binaries,
which are really just a convenience for users, so re-releasing sources
needs to be done carefully. This is not legalese, it is appropriate
PMC oversight and release management.
Given the hassle of doing this, committing whatever is necessary to
reproduce the new source releases, review and vote on them, etc; might
it be better to just publish a script or instructions somewhere on how
to make an IDE/maven-lovable sources jars from a commons source zip or
tarball? That way users could create these themselves from the actual
source distributions. Is that unreasonable?
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: apache commons-* -sources.jar
Posted by Dennis Lundberg <de...@apache.org>.
simon wrote:
> On Sat, 2008-02-02 at 15:25 -0600, Curt Arnold wrote:
>> On Feb 2, 2008, at 2:08 PM, nicolas de loof wrote:
>> on repository@apache.org, 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 repository@apache.org
>> , pmc@commons.apache.org and dev@commons.apache.org. I'm cross-
>> posting to repository@apache.org, 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 board@apache, 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
>> dev@commons.apache.org. 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.
>
> I think all this legalese stuff is rather excessive.
I agree. These are not *new* releases. The -sources jars should follow
the policy and license that were current when the original release was made.
> All these files already have binary releases that do have valid
> copyright and notice statements in them. These source jars are only for
> the convenience of people using IDEs.
>
> Each source file has an appropriate header on it, and if people have any
> further questions about the licensing of the source they see, then
> either the binary or the svn repository has the correct answer.
>
> Remember that in the absence of a license to redistribute, people do NOT
> have the right to redistribute. So we are not turning these files into
> public domain even if no license is provided at all.
>
> The only question I see is whether the source is *right*. It would be
> rather embarrassing to publish source that does not quite match the
> binary, so a second check on these is probably a good idea. But even
> then it isn't fatal; changing a binary once it has been published in a
> maven repository is a really bad idea because it makes builds
> unrepeatable. However changing the source is not such a big issue, and
> could be fixed after the fact if necessary.
>
> Nicolas is right that this would be a nice service to some Apache
> software users. It's not a big thing because these releases that are
> being fixed are all old ones (we have our act together now) but it's
> still nice to do. Let's not make this harder than it needs to be.
>
> And anyway, if notice/license is to be put in these source jars I would
> just take it from the equivalent binary jar's META-INF directory. If the
> project was originally published under ASF1.1, it seems right to me that
> the same license should be attached to the source jar.
>
> So unless there is an official statement from the board, or a qualified
> lawyer says this is wrong, I'm +1 on releasing these sources jars, but
> suggest that people be given a few days to check that they have the
> right contents first.
>
> Regards,
>
> Simon
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: apache commons-* -sources.jar
Posted by simon <si...@chello.at>.
On Sat, 2008-02-02 at 15:25 -0600, Curt Arnold wrote:
> On Feb 2, 2008, at 2:08 PM, nicolas de loof wrote:
> on repository@apache.org, 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 repository@apache.org
> , pmc@commons.apache.org and dev@commons.apache.org. I'm cross-
> posting to repository@apache.org, 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 board@apache, 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
> dev@commons.apache.org. 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.
I think all this legalese stuff is rather excessive.
All these files already have binary releases that do have valid
copyright and notice statements in them. These source jars are only for
the convenience of people using IDEs.
Each source file has an appropriate header on it, and if people have any
further questions about the licensing of the source they see, then
either the binary or the svn repository has the correct answer.
Remember that in the absence of a license to redistribute, people do NOT
have the right to redistribute. So we are not turning these files into
public domain even if no license is provided at all.
The only question I see is whether the source is *right*. It would be
rather embarrassing to publish source that does not quite match the
binary, so a second check on these is probably a good idea. But even
then it isn't fatal; changing a binary once it has been published in a
maven repository is a really bad idea because it makes builds
unrepeatable. However changing the source is not such a big issue, and
could be fixed after the fact if necessary.
Nicolas is right that this would be a nice service to some Apache
software users. It's not a big thing because these releases that are
being fixed are all old ones (we have our act together now) but it's
still nice to do. Let's not make this harder than it needs to be.
And anyway, if notice/license is to be put in these source jars I would
just take it from the equivalent binary jar's META-INF directory. If the
project was originally published under ASF1.1, it seems right to me that
the same license should be attached to the source jar.
So unless there is an official statement from the board, or a qualified
lawyer says this is wrong, I'm +1 on releasing these sources jars, but
suggest that people be given a few days to check that they have the
right contents first.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: apache commons-* -sources.jar
Posted by Curt Arnold <ca...@apache.org>.
On Feb 2, 2008, at 2:08 PM, nicolas de loof wrote:
on repository@apache.org, 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 repository@apache.org
, pmc@commons.apache.org and dev@commons.apache.org. I'm cross-
posting to repository@apache.org, 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 board@apache, 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
dev@commons.apache.org. 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.
Re: apache commons-* -sources.jar
Posted by nicolas de loof <ni...@apache.org>.
That's right, but both ant and maven require the project to
script/configure that -source.jar creation. As only recent versions (based
on maven2) does, all archived releases require some changes to get
the existing build produce this bundle.
Based on existing -srz.zip dist bundles, the -source.jar creation is only an
"unzip" + "jar" operation.
Can I point out that Apache provide two complete build tools to avoid
> you doing this kind of housekeeping in Java.
>
> >
> > I'm OK to publish it under Apache license ;-)
> >
> >
> >
> >
> > import java.io.File;
> > import java.io.FilenameFilter;
> >
> > public class Sources
> > {
> >
> > /**
> > * @param args
> > */
> > public static void main( String[] args )
> > {
> > getMissingSourceDist();
> > extractSrcDist();
> > createSrcBundle();
> > }
> >
> > private static void createSrcBundle()
> > {
> > File repo = new File( "H:/java/repo1.maven.org/maven2" );
> > File[] groups = repo.listFiles();
> > for ( File group : groups )
> > {
> > if ( !group.getName().endsWith( "-src.zip" ) )
> > {
> > continue;
> > }
> > String dist = group.getName().substring( 0,
> > group.getName().length() - "-src.zip".length() );
> > File dir = new File( repo, dist );
> > if ( !dir.exists() )
> > {
> > dir = new File( repo, dist + "-src" );
> > if ( !dir.exists() )
> > {
> > dir = new File( repo, dist );
> > if ( !dir.exists() )
> > {
> > System.err.println( "no dir for " + dist );
> > continue;
> > }
> > }
> > }
> >
> > String f = group.getName().substring( 0,
> > group.getName().length() - "-src.zip".length() );
> > if ( new File( dir, "src/java" ).exists() )
> > {
> > System.out.println( "jar cf " + f + "-sources.jar -C " +
> dir
> > + "\\src\\java ." );
> > }
> > else if ( new File( dir, "src/main/java" ).exists() )
> > {
> > System.out.println( "jar cf " + f + "-sources.jar -C " +
> dir
> > + "\\src\\main\\java ." );
> > }
> > else if ( new File( dir, "src/share" ).exists() )
> > {
> > System.out.println( "jar cf " + f + "-sources.jar -C " +
> dir
> > + "\\src\\share ." );
> > }
> > else
> > {
> > System.err.println( "no src/java for " + dist );
> > }
> > if ( new File( dir, "src/resources" ).exists() )
> > {
> > System.out.println( "jar uf " + f + "-sources.jar -C " +
> dir
> > + "\\src\\resources ." );
> > }
> > if ( new File( dir, "src/javascript" ).exists() )
> > {
> > System.out.println( "jar uf " + f + "-sources.jar -C " +
> dir
> > + "\\src\\javascript ." );
> > }
> > File[] txt = dir.listFiles( new FilenameFilter()
> > {
> > @Override
> > public boolean accept( File dir, String name )
> > {
> > return name.endsWith( ".txt" );
> > }
> > } );
> > for ( File file : txt )
> > {
> > System.out.println( "jar uf " + f + "-sources.jar -C " +
> dir
> > + " " + file.getName() );
> > }
> > }
> > }
> >
> > private static void extractSrcDist()
> > {
> > File repo = new File( "H:/java/repo1.maven.org/maven2" );
> > File[] groups = repo.listFiles();
> > for ( File group : groups )
> > {
> > if ( !group.getName().endsWith( "-src.zip" ) )
> > {
> > continue;
> > }
> > System.out.println( "\"c:\\Program Files\\7-Zip\\7z.exe\" x
> " +
> > group.getName() );
> > }
> > }
> >
> > private static void getMissingSourceDist()
> > {
> > File repo = new File( "H:/java/repo1.maven.org/maven2" );
> > File[] groups = repo.listFiles();
> > for ( File group : groups )
> > {
> > if ( !group.isDirectory() || !group.getName().startsWith(
> > "commons" ) )
> > {
> > continue;
> > }
> > File pr = new File( group, group.getName() );
> > File[] versions = pr.listFiles();
> > for ( File version : versions )
> > {
> > if ( !version.isDirectory() )
> > {
> > continue;
> > }
> > if ( new File( version, group.getName() + "-" +
> > version.getName() + "-sources.jar" ).exists() )
> > {
> > System.out.println( "rem " + group.getName() + ":" +
> > version.getName() + " has sources" );
> > continue;
> > }
> >
> > String g = group.getName().substring(
> "commons-".length() );
> > System.out.println( "wget -nd
> > http://archive.apache.org/dist/commons/" + g + "/source/" +
> group.getName()
> > +
> > "-" + version.getName() + "-src.zip" );
> > }
> > }
> > }
> >
> > }
> >
> >
> >
> > 2008/2/2, Curt Arnold <ca...@apache.org>:
> > >
> > > On Feb 2, 2008, at 3:56 AM, nicolas de loof wrote:
> > >
> > > > I've put some -sources.jars in :
> > > >
> > > > http://people.apache.org/~nicolas/missing-commons-sources.jar/
> > > >
> > > > Those one have been created by a script :
> > > >
> > > > - create list of commons-* without -sources.jar in repo
> > > > - search for a src-zip distribution in www.apache.org/dist
> > > > - wget available ones
> > > > - unzip, jar a src/java + src/resources + *.txt
> > > >
> > > > Nico.
> > > >
> > >
> > >
> > > I looked at commons-beanutils-1.6-sources.jar and it did not contain a
> > > LICENSE and NOTICE file in the META-INF directory as required by
> > http://www.apache.org/dev/release.html#distribute-raw-artifact
> > > . I assume that is likely the case for the other source jar files.
> > > That is a mandatory -1 on these as releases for me.
> > >
> > > The script used to prepare the source jars should be made available so
> > > that others can confirm that the build process is repeatable. If I
> > > can look at the script, run it myself and compare my results with your
> > > results, I have more confidence that the process is repeatable and
> > > honest. Obviously, the script should be ASL v2 licensed.
> > >
> > >
> >
> >
>
Re: apache commons-* -sources.jar
Posted by Steve Loughran <st...@gmail.com>.
On Feb 2, 2008 8:08 PM, nicolas de loof <ni...@apache.org> wrote:
> 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.
Can I point out that Apache provide two complete build tools to avoid
you doing this kind of housekeeping in Java.
>
> I'm OK to publish it under Apache license ;-)
>
>
>
>
> import java.io.File;
> import java.io.FilenameFilter;
>
> public class Sources
> {
>
> /**
> * @param args
> */
> public static void main( String[] args )
> {
> getMissingSourceDist();
> extractSrcDist();
> createSrcBundle();
> }
>
> private static void createSrcBundle()
> {
> File repo = new File( "H:/java/repo1.maven.org/maven2" );
> File[] groups = repo.listFiles();
> for ( File group : groups )
> {
> if ( !group.getName().endsWith( "-src.zip" ) )
> {
> continue;
> }
> String dist = group.getName().substring( 0,
> group.getName().length() - "-src.zip".length() );
> File dir = new File( repo, dist );
> if ( !dir.exists() )
> {
> dir = new File( repo, dist + "-src" );
> if ( !dir.exists() )
> {
> dir = new File( repo, dist );
> if ( !dir.exists() )
> {
> System.err.println( "no dir for " + dist );
> continue;
> }
> }
> }
>
> String f = group.getName().substring( 0,
> group.getName().length() - "-src.zip".length() );
> if ( new File( dir, "src/java" ).exists() )
> {
> System.out.println( "jar cf " + f + "-sources.jar -C " + dir
> + "\\src\\java ." );
> }
> else if ( new File( dir, "src/main/java" ).exists() )
> {
> System.out.println( "jar cf " + f + "-sources.jar -C " + dir
> + "\\src\\main\\java ." );
> }
> else if ( new File( dir, "src/share" ).exists() )
> {
> System.out.println( "jar cf " + f + "-sources.jar -C " + dir
> + "\\src\\share ." );
> }
> else
> {
> System.err.println( "no src/java for " + dist );
> }
> if ( new File( dir, "src/resources" ).exists() )
> {
> System.out.println( "jar uf " + f + "-sources.jar -C " + dir
> + "\\src\\resources ." );
> }
> if ( new File( dir, "src/javascript" ).exists() )
> {
> System.out.println( "jar uf " + f + "-sources.jar -C " + dir
> + "\\src\\javascript ." );
> }
> File[] txt = dir.listFiles( new FilenameFilter()
> {
> @Override
> public boolean accept( File dir, String name )
> {
> return name.endsWith( ".txt" );
> }
> } );
> for ( File file : txt )
> {
> System.out.println( "jar uf " + f + "-sources.jar -C " + dir
> + " " + file.getName() );
> }
> }
> }
>
> private static void extractSrcDist()
> {
> File repo = new File( "H:/java/repo1.maven.org/maven2" );
> File[] groups = repo.listFiles();
> for ( File group : groups )
> {
> if ( !group.getName().endsWith( "-src.zip" ) )
> {
> continue;
> }
> System.out.println( "\"c:\\Program Files\\7-Zip\\7z.exe\" x " +
> group.getName() );
> }
> }
>
> private static void getMissingSourceDist()
> {
> File repo = new File( "H:/java/repo1.maven.org/maven2" );
> File[] groups = repo.listFiles();
> for ( File group : groups )
> {
> if ( !group.isDirectory() || !group.getName().startsWith(
> "commons" ) )
> {
> continue;
> }
> File pr = new File( group, group.getName() );
> File[] versions = pr.listFiles();
> for ( File version : versions )
> {
> if ( !version.isDirectory() )
> {
> continue;
> }
> if ( new File( version, group.getName() + "-" +
> version.getName() + "-sources.jar" ).exists() )
> {
> System.out.println( "rem " + group.getName() + ":" +
> version.getName() + " has sources" );
> continue;
> }
>
> String g = group.getName().substring( "commons-".length() );
> System.out.println( "wget -nd
> http://archive.apache.org/dist/commons/" + g + "/source/" + group.getName()
> +
> "-" + version.getName() + "-src.zip" );
> }
> }
> }
>
> }
>
>
>
> 2008/2/2, Curt Arnold <ca...@apache.org>:
> >
> > On Feb 2, 2008, at 3:56 AM, nicolas de loof wrote:
> >
> > > I've put some -sources.jars in :
> > >
> > > http://people.apache.org/~nicolas/missing-commons-sources.jar/
> > >
> > > Those one have been created by a script :
> > >
> > > - create list of commons-* without -sources.jar in repo
> > > - search for a src-zip distribution in www.apache.org/dist
> > > - wget available ones
> > > - unzip, jar a src/java + src/resources + *.txt
> > >
> > > Nico.
> > >
> >
> >
> > I looked at commons-beanutils-1.6-sources.jar and it did not contain a
> > LICENSE and NOTICE file in the META-INF directory as required by
> http://www.apache.org/dev/release.html#distribute-raw-artifact
> > . I assume that is likely the case for the other source jar files.
> > That is a mandatory -1 on these as releases for me.
> >
> > The script used to prepare the source jars should be made available so
> > that others can confirm that the build process is repeatable. If I
> > can look at the script, run it myself and compare my results with your
> > results, I have more confidence that the process is repeatable and
> > honest. Obviously, the script should be ASL v2 licensed.
> >
> >
>
>
Re: apache commons-* -sources.jar
Posted by Curt Arnold <ca...@apache.org>.
On Feb 2, 2008, at 2:08 PM, nicolas de loof wrote:
on repository@apache.org, 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 repository@apache.org
, pmc@commons.apache.org and dev@commons.apache.org. I'm cross-
posting to repository@apache.org, 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 board@apache, 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
dev@commons.apache.org. 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: apache commons-* -sources.jar
Posted by nicolas de loof <ni...@apache.org>.
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 ;-)
import java.io.File;
import java.io.FilenameFilter;
public class Sources
{
/**
* @param args
*/
public static void main( String[] args )
{
getMissingSourceDist();
extractSrcDist();
createSrcBundle();
}
private static void createSrcBundle()
{
File repo = new File( "H:/java/repo1.maven.org/maven2" );
File[] groups = repo.listFiles();
for ( File group : groups )
{
if ( !group.getName().endsWith( "-src.zip" ) )
{
continue;
}
String dist = group.getName().substring( 0,
group.getName().length()
- "-src.zip".length() );
File dir = new File( repo, dist );
if ( !dir.exists() )
{
dir = new File( repo, dist + "-src" );
if ( !dir.exists() )
{
dir = new File( repo, dist );
if ( !dir.exists() )
{
System.err.println( "no dir for " + dist );
continue;
}
}
}
String f = group.getName().substring( 0, group.getName().length()
- "-src.zip".length() );
if ( new File( dir, "src/java" ).exists() )
{
System.out.println( "jar cf " + f + "-sources.jar -C " + dir
+ "\\src\\java <file://src//java> ." );
}
else if ( new File( dir, "src/main/java" ).exists() )
{
System.out.println( "jar cf " + f + "-sources.jar -C " + dir
+ "\\src\\main\\java <file://src//main//java> ." );
}
else if ( new File( dir, "src/share" ).exists() )
{
System.out.println( "jar cf " + f + "-sources.jar -C " + dir
+ "\\src\\share <file://src//share> ." );
}
else
{
System.err.println( "no src/java for " + dist );
}
if ( new File( dir, "src/resources" ).exists() )
{
System.out.println( "jar uf " + f + "-sources.jar -C " + dir
+ "\\src\\resources <file://src//resources> ." );
}
if ( new File( dir, "src/javascript" ).exists() )
{
System.out.println( "jar uf " + f + "-sources.jar -C " + dir
+ "\\src\\javascript <file://src//javascript> ." );
}
File[] txt = dir.listFiles( new FilenameFilter()
{
@Override
public boolean accept( File dir, String name )
{
return name.endsWith( ".txt" );
}
} );
for ( File file : txt )
{
System.out.println( "jar uf " + f + "-sources.jar -C " + dir
+ " " + file.getName() );
}
}
}
private static void extractSrcDist()
{
File repo = new File( "H:/java/repo1.maven.org/maven2" );
File[] groups = repo.listFiles();
for ( File group : groups )
{
if ( !group.getName().endsWith( "-src.zip" ) )
{
continue;
}
System.out.println( "\"c:\\Program Files\\7-Zip\\7z.exe\" x " +
group.getName() );
}
}
private static void getMissingSourceDist()
{
File repo = new File( "H:/java/repo1.maven.org/maven2" );
File[] groups = repo.listFiles();
for ( File group : groups )
{
if ( !group.isDirectory() || !group.getName().startsWith(
"commons" ) )
{
continue;
}
File pr = new File( group, group.getName() );
File[] versions = pr.listFiles();
for ( File version : versions )
{
if ( !version.isDirectory() )
{
continue;
}
if ( new File( version, group.getName() + "-" +
version.getName() + "-sources.jar" ).exists() )
{
System.out.println( "rem " + group.getName() + ":" +
version.getName() + " has sources" );
continue;
}
String g = group.getName().substring( "commons-".length() );
System.out.println( "wget -nd
http://archive.apache.org/dist/commons/" + g + "/source/" + group.getName()
+
"-" + version.getName() + "-src.zip" );
}
}
}
}
2008/2/2, Curt Arnold <ca...@apache.org>:
>
>
> On Feb 2, 2008, at 3:56 AM, nicolas de loof wrote:
>
> > I've put some -sources.jars in :
> >
> > http://people.apache.org/~nicolas/missing-commons-sources.jar/
> >
> > Those one have been created by a script :
> >
> > - create list of commons-* without -sources.jar in repo
> > - search for a src-zip distribution in www.apache.org/dist
> > - wget available ones
> > - unzip, jar a src/java + src/resources + *.txt
> >
> > Nico.
> >
>
>
> I looked at commons-beanutils-1.6-sources.jar and it did not contain a
> LICENSE and NOTICE file in the META-INF directory as required by
> http://www.apache.org/dev/release.html#distribute-raw-artifact
> . I assume that is likely the case for the other source jar files.
> That is a mandatory -1 on these as releases for me.
>
> The script used to prepare the source jars should be made available so
> that others can confirm that the build process is repeatable. If I
> can look at the script, run it myself and compare my results with your
> results, I have more confidence that the process is repeatable and
> honest. Obviously, the script should be ASL v2 licensed.
>
>
Re: apache commons-* -sources.jar
Posted by Curt Arnold <ca...@apache.org>.
On Feb 2, 2008, at 3:56 AM, nicolas de loof wrote:
> I've put some -sources.jars in :
>
> http://people.apache.org/~nicolas/missing-commons-sources.jar/
>
> Those one have been created by a script :
>
> - create list of commons-* without -sources.jar in repo
> - search for a src-zip distribution in www.apache.org/dist
> - wget available ones
> - unzip, jar a src/java + src/resources + *.txt
>
> Nico.
>
I looked at commons-beanutils-1.6-sources.jar and it did not contain a
LICENSE and NOTICE file in the META-INF directory as required by http://www.apache.org/dev/release.html#distribute-raw-artifact
. I assume that is likely the case for the other source jar files.
That is a mandatory -1 on these as releases for me.
The script used to prepare the source jars should be made available so
that others can confirm that the build process is repeatable. If I
can look at the script, run it myself and compare my results with your
results, I have more confidence that the process is repeatable and
honest. Obviously, the script should be ASL v2 licensed.
Re: apache commons-* -sources.jar
Posted by nicolas de loof <ni...@apache.org>.
I've put some -sources.jars in :
http://people.apache.org/~nicolas/missing-commons-sources.jar/
Those one have been created by a script :
- create list of commons-* without -sources.jar in repo
- search for a src-zip distribution in www.apache.org/dist
- wget available ones
- unzip, jar a src/java + src/resources + *.txt
Nico.
2008/2/1, Torsten Curdt <tc...@apache.org>:
>
>
> On 01.02.2008, at 21:09, nicolas de loof wrote:
>
> > Hello,
> >
> > Many apache commons have no -source.jar bundle in maven "central"
> > repo. I've
> > created some of them based on the official source distribution for my
> > personnal use.
> >
> > Would you allow me use
> > /x1/www/people.apache.org/repo/m1-ibiblio-rsync-repository/ for
> > adding them,
> > or do you prefer a more formal MAVENUPLOAD / MEV request ?
>
> Well, going through the ibiblio sync should be fine ...but could you
> put the artifacts up somewhere else first? As they are still
> artifacts the PMC should probably vote for them first.
>
> cheers
> --
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: apache commons-* -sources.jar
Posted by nicolas de loof <ni...@apache.org>.
I've put some -sources.jars in :
http://people.apache.org/~nicolas/missing-commons-sources.jar/
Those one have been created by a script :
- create list of commons-* without -sources.jar in repo
- search for a src-zip distribution in www.apache.org/dist
- wget available ones
- unzip, jar a src/java + src/resources + *.txt
Nico.
2008/2/1, Torsten Curdt <tc...@apache.org>:
>
>
> On 01.02.2008, at 21:09, nicolas de loof wrote:
>
> > Hello,
> >
> > Many apache commons have no -source.jar bundle in maven "central"
> > repo. I've
> > created some of them based on the official source distribution for my
> > personnal use.
> >
> > Would you allow me use
> > /x1/www/people.apache.org/repo/m1-ibiblio-rsync-repository/ for
> > adding them,
> > or do you prefer a more formal MAVENUPLOAD / MEV request ?
>
> Well, going through the ibiblio sync should be fine ...but could you
> put the artifacts up somewhere else first? As they are still
> artifacts the PMC should probably vote for them first.
>
> cheers
> --
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: apache commons-* -sources.jar
Posted by Torsten Curdt <tc...@apache.org>.
On 01.02.2008, at 21:09, nicolas de loof wrote:
> Hello,
>
> Many apache commons have no -source.jar bundle in maven "central"
> repo. I've
> created some of them based on the official source distribution for my
> personnal use.
>
> Would you allow me use
> /x1/www/people.apache.org/repo/m1-ibiblio-rsync-repository/ for
> adding them,
> or do you prefer a more formal MAVENUPLOAD / MEV request ?
Well, going through the ibiblio sync should be fine ...but could you
put the artifacts up somewhere else first? As they are still
artifacts the PMC should probably vote for them first.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: apache commons-* -sources.jar
Posted by Curt Arnold <ca...@apache.org>.
On Feb 1, 2008, at 2:09 PM, nicolas de loof wrote:
> Hello,
>
> Many apache commons have no -source.jar bundle in maven "central"
> repo. I've created some of them based on the official source
> distribution for my personnal use.
>
> Would you allow me use /x1/www/people.apache.org/repo/m1-ibiblio-
> rsync-repository/ for adding them, or do you prefer a more formal
> MAVENUPLOAD / MEV request ?
>
> Nicolas.
I'm just a lurker on the repo list, but I'd think that this would look
like a ASF released and a consumer would assume that it had the
blessing of the associated PMC. If the source jars were prepared,
posted people.apache.org/builds and a vote called on the appropriate
mailing list to accept them for publication, then I could see placing
them in the repo upon conclusion of a favorable vote. Otherwise, it
looks like a single committer just did an end-run around the ASF
release policy.