You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Henri Yandell <ba...@generationjava.com> on 2003/01/23 14:25:41 UTC
Re: [Fwd: Bzip, tar, zip, etc]
The problem with these is that the developer community never followed the
code. I assume this is some political issue in Jakarta I'm not aware of.
As far as I know, the Commons idea is that the group who donate the code
are seen as the ones who are the maintainers. The very concept of a
'Commons committer' is anathema to the Commons charter [although such a
thing does evolve over time].
bzip/tar/zip ended up just sitting in Commons waiting for a developer
community to arrive.
There are a few things here, in decreasing importance:
1) Code must be maintained to be worth using.
2) Code must have a community to be maintained.
3) The same code ought not to live in more than one place.
4) Reusable code ought to be in Jakarta Commons.
Now, if the Ant developers are the only ones doing 1), and they are the
only 2) for the code, then according to 3) the code should be in one
place. This place ought to be Jakarta Commons, but if this is not possible
then it should be in Ant as 4) is the least important of the 4 things.
So, +1 to the Ant guys managing the code inside Commons, +0 to the Ant
guys offering the jars as a separate build.
Hen
On Thu, 23 Jan 2003, Nicola Ken Barozzi wrote:
>
> Forgot to cc here.
>
> -------- Original Message --------
> Subject: Bzip, tar, zip, etc
> Date: Wed, 22 Jan 2003 18:10:47 +0100
> From: Nicola Ken Barozzi <ni...@apache.org>
> Reply-To: Avalon Developers List <av...@jakarta.apache.org>,
> nicolaken@apache.org
> Organization: Apache Software Foundation
> To: Ant Developers List <an...@jakarta.apache.org>
> CC: Avalon Developers List <av...@jakarta.apache.org>
>
>
> Ant has packages for zip, bzip and tar stuff. Really?
> Ok, I know you all know. ;-)
>
> The point is that some of these packages IIUC were copied in Avalon repo
> as indipendent packages, and then since they were not in scope I put
> them in commons sandbox, and now we are deprecating the avalon versions.
>
> Now, we have asked some time back, "why not let Ant use the commons
> versions"?
>
> Gump... blah blah blah... bootstrap... blah blah blah...
>
> Now that they have been put in commons for some time, it's quite evident
> that there, they are dead.
>
> So, the solution seems simply to make these separate jars and make them
> available also separately from Ant.
>
> ant.jar
> ant-zip.jar
> ant-bzip.jar
> ant-tar.jar
>
> Ant keeps them, they are maintained, and we get separate jars to use in
> other projects.
>
> Comments?
>
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Fwd: Bzip, tar, zip, etc]
Posted by Henri Yandell <ba...@generationjava.com>.
On 23 Jan 2003, Stefan Bodewig wrote:
> On Thu, 23 Jan 2003, Henri Yandell <ba...@generationjava.com> wrote:
>
> > As far as I know, the Commons idea is that the group who donate the
> > code are seen as the ones who are the maintainers.
>
> Please note that it has not been the Ant community who donated the
> code to commons.
>
> > So, +1 to the Ant guys managing the code inside Commons,
>
> As I said, there hasn't been much to manage in the past.
So it's not so much that it's Ant code, as it's been floating from Ant
through Avalon to Commons. There is not really any community.
How about this:
We find a name which encompasses tar, bzip2 and zip packages. I was
calling it 'compress', but am happy with any other name.
The project is setup, with 3 jars being output. Ant uses CVS to get the
jars or source to build?
A site is put up. Myself, Stefan and Nicola are put down as the three
maintainers. We forget about it until some obscure user using Kaffe on an
AmigaOS points out an obscure bug??
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Fwd: Bzip, tar, zip, etc]
Posted by Henri Yandell <ba...@generationjava.com>.
On 23 Jan 2003, Stefan Bodewig wrote:
> On Thu, 23 Jan 2003, Henri Yandell <ba...@generationjava.com> wrote:
>
> > As far as I know, the Commons idea is that the group who donate the
> > code are seen as the ones who are the maintainers.
>
> Please note that it has not been the Ant community who donated the
> code to commons.
>
> > So, +1 to the Ant guys managing the code inside Commons,
>
> As I said, there hasn't been much to manage in the past.
So it's not so much that it's Ant code, as it's been floating from Ant
through Avalon to Commons. There is not really any community.
How about this:
We find a name which encompasses tar, bzip2 and zip packages. I was
calling it 'compress', but am happy with any other name.
The project is setup, with 3 jars being output. Ant uses CVS to get the
jars or source to build?
A site is put up. Myself, Stefan and Nicola are put down as the three
maintainers. We forget about it until some obscure user using Kaffe on an
AmigaOS points out an obscure bug??
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Fwd: Bzip, tar, zip, etc]
Posted by Henri Yandell <ba...@generationjava.com>.
On 23 Jan 2003, Stefan Bodewig wrote:
> On Thu, 23 Jan 2003, Henri Yandell <ba...@generationjava.com> wrote:
>
> > As far as I know, the Commons idea is that the group who donate the
> > code are seen as the ones who are the maintainers.
>
> Please note that it has not been the Ant community who donated the
> code to commons.
>
> > So, +1 to the Ant guys managing the code inside Commons,
>
> As I said, there hasn't been much to manage in the past.
So it's not so much that it's Ant code, as it's been floating from Ant
through Avalon to Commons. There is not really any community.
How about this:
We find a name which encompasses tar, bzip2 and zip packages. I was
calling it 'compress', but am happy with any other name.
The project is setup, with 3 jars being output. Ant uses CVS to get the
jars or source to build?
A site is put up. Myself, Stefan and Nicola are put down as the three
maintainers. We forget about it until some obscure user using Kaffe on an
AmigaOS points out an obscure bug??
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Fwd: Bzip, tar, zip, etc]
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 23 Jan 2003, Henri Yandell <ba...@generationjava.com> wrote:
> The problem with these is that the developer community never
> followed the code.
See my first port.
> As far as I know, the Commons idea is that the group who donate the
> code are seen as the ones who are the maintainers.
Please note that it has not been the Ant community who donated the
code to commons.
> So, +1 to the Ant guys managing the code inside Commons,
As I said, there hasn't been much to manage in the past.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Fwd: Bzip, tar, zip, etc]
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 23 Jan 2003, Henri Yandell <ba...@generationjava.com> wrote:
> The problem with these is that the developer community never
> followed the code.
See my first port.
> As far as I know, the Commons idea is that the group who donate the
> code are seen as the ones who are the maintainers.
Please note that it has not been the Ant community who donated the
code to commons.
> So, +1 to the Ant guys managing the code inside Commons,
As I said, there hasn't been much to manage in the past.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Fwd: Bzip, tar, zip, etc]
Posted by Nicola Ken Barozzi <ni...@apache.org>.
J.Pietschmann wrote:
> Henri Yandell wrote:
>
>> On Thu, 23 Jan 2003, Nicola Ken Barozzi wrote:
>>
>>> Well said, apart from 4 which I would say "could" instead of "ought to".
>>
>>
>> I thought you had buy in now that Commons was the place for low level
>> reusable bits if possible? ;)
>
>
> I'd say yes if there weren't several other places, in particular
> XML Commons.
> Many projects also have their own repositories for low level
> reusable bits, look for example into the excalibur scratchpad...
Xml Commons is possibly a bit overlapping but ATM quite defined.
As for Excalibur, we're removing all low-level reusable bits that are
not necessarily Avalon-related... so yes, I agree with Henri, but I
don't find it as compulsory as some seem to think.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Fwd: Bzip, tar, zip, etc]
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Henri Yandell wrote:
> On Thu, 23 Jan 2003, Nicola Ken Barozzi wrote:
>>Well said, apart from 4 which I would say "could" instead of "ought to".
>
> I thought you had buy in now that Commons was the place for low level
> reusable bits if possible? ;)
I'd say yes if there weren't several other places, in particular
XML Commons.
Many projects also have their own repositories for low level
reusable bits, look for example into the excalibur scratchpad...
J.Pietschmann
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Fwd: Bzip, tar, zip, etc]
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 23 Jan 2003, Nicola Ken Barozzi wrote:
>
>
> Henri Yandell wrote:
> > There are a few things here, in decreasing importance:
> >
> > 1) Code must be maintained to be worth using.
> > 2) Code must have a community to be maintained.
> > 3) The same code ought not to live in more than one place.
> > 4) Reusable code ought to be in Jakarta Commons.
>
> Well said, apart from 4 which I would say "could" instead of "ought to".
I thought you had buy in now that Commons was the place for low level
reusable bits if possible? ;)
> > Now, if the Ant developers are the only ones doing 1), and they are the
> > only 2) for the code, then according to 3) the code should be in one
> > place. This place ought to be Jakarta Commons, but if this is not possible
> > then it should be in Ant as 4) is the least important of the 4 things.
>
> This is why it was put in Commons, but the magic didn't happen ;-)
There is no magic/spoon [depending on movie/book of your choice].
> > So, +1 to the Ant guys managing the code inside Commons, +0 to the Ant
> > guys offering the jars as a separate build.
>
> I think the main issue with this is that Ant is somewhat at the top of
> the Gump dependency graph, and splitting things out is not something
> that fast and easy to do correctly.
Yep. If Ant people can be happy with it, I'm happy to build the three jars
in a Commons project and publish it on the site. Otherwise, I'm just
waiting for a nod to remove the source from the Commons repositories :)
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Fwd: Bzip, tar, zip, etc]
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 23 Jan 2003, Nicola Ken Barozzi wrote:
>
>
> Henri Yandell wrote:
> > There are a few things here, in decreasing importance:
> >
> > 1) Code must be maintained to be worth using.
> > 2) Code must have a community to be maintained.
> > 3) The same code ought not to live in more than one place.
> > 4) Reusable code ought to be in Jakarta Commons.
>
> Well said, apart from 4 which I would say "could" instead of "ought to".
I thought you had buy in now that Commons was the place for low level
reusable bits if possible? ;)
> > Now, if the Ant developers are the only ones doing 1), and they are the
> > only 2) for the code, then according to 3) the code should be in one
> > place. This place ought to be Jakarta Commons, but if this is not possible
> > then it should be in Ant as 4) is the least important of the 4 things.
>
> This is why it was put in Commons, but the magic didn't happen ;-)
There is no magic/spoon [depending on movie/book of your choice].
> > So, +1 to the Ant guys managing the code inside Commons, +0 to the Ant
> > guys offering the jars as a separate build.
>
> I think the main issue with this is that Ant is somewhat at the top of
> the Gump dependency graph, and splitting things out is not something
> that fast and easy to do correctly.
Yep. If Ant people can be happy with it, I'm happy to build the three jars
in a Commons project and publish it on the site. Otherwise, I'm just
waiting for a nod to remove the source from the Commons repositories :)
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Fwd: Bzip, tar, zip, etc]
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 23 Jan 2003, Nicola Ken Barozzi wrote:
>
>
> Henri Yandell wrote:
> > There are a few things here, in decreasing importance:
> >
> > 1) Code must be maintained to be worth using.
> > 2) Code must have a community to be maintained.
> > 3) The same code ought not to live in more than one place.
> > 4) Reusable code ought to be in Jakarta Commons.
>
> Well said, apart from 4 which I would say "could" instead of "ought to".
I thought you had buy in now that Commons was the place for low level
reusable bits if possible? ;)
> > Now, if the Ant developers are the only ones doing 1), and they are the
> > only 2) for the code, then according to 3) the code should be in one
> > place. This place ought to be Jakarta Commons, but if this is not possible
> > then it should be in Ant as 4) is the least important of the 4 things.
>
> This is why it was put in Commons, but the magic didn't happen ;-)
There is no magic/spoon [depending on movie/book of your choice].
> > So, +1 to the Ant guys managing the code inside Commons, +0 to the Ant
> > guys offering the jars as a separate build.
>
> I think the main issue with this is that Ant is somewhat at the top of
> the Gump dependency graph, and splitting things out is not something
> that fast and easy to do correctly.
Yep. If Ant people can be happy with it, I'm happy to build the three jars
in a Commons project and publish it on the site. Otherwise, I'm just
waiting for a nod to remove the source from the Commons repositories :)
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Fwd: Bzip, tar, zip, etc]
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Henri Yandell wrote:
> The problem with these is that the developer community never followed the
> code. I assume this is some political issue in Jakarta I'm not aware of.
>
> As far as I know, the Commons idea is that the group who donate the code
> are seen as the ones who are the maintainers. The very concept of a
> 'Commons committer' is anathema to the Commons charter [although such a
> thing does evolve over time].
>
> bzip/tar/zip ended up just sitting in Commons waiting for a developer
> community to arrive.
>
> There are a few things here, in decreasing importance:
>
> 1) Code must be maintained to be worth using.
> 2) Code must have a community to be maintained.
> 3) The same code ought not to live in more than one place.
> 4) Reusable code ought to be in Jakarta Commons.
Well said, apart from 4 which I would say "could" instead of "ought to".
> Now, if the Ant developers are the only ones doing 1), and they are the
> only 2) for the code, then according to 3) the code should be in one
> place. This place ought to be Jakarta Commons, but if this is not possible
> then it should be in Ant as 4) is the least important of the 4 things.
This is why it was put in Commons, but the magic didn't happen ;-)
> So, +1 to the Ant guys managing the code inside Commons, +0 to the Ant
> guys offering the jars as a separate build.
I think the main issue with this is that Ant is somewhat at the top of
the Gump dependency graph, and splitting things out is not something
that fast and easy to do correctly.
MHO is that it would be possible to have Gump bootstrap these packages
by using simple javac, give them to Ant that does the same, etc, but it
gets complicated quite easily... dunno, I'm not going to do it, and
someone has to for these to live in J-C without duplication...
So yes, I agree with you. But we have to see if someone is willing to do
the Gump changes, or we have to fallback on the ant.multi-jar option.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Fwd: Bzip, tar, zip, etc]
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Henri Yandell wrote:
> The problem with these is that the developer community never followed the
> code. I assume this is some political issue in Jakarta I'm not aware of.
>
> As far as I know, the Commons idea is that the group who donate the code
> are seen as the ones who are the maintainers. The very concept of a
> 'Commons committer' is anathema to the Commons charter [although such a
> thing does evolve over time].
>
> bzip/tar/zip ended up just sitting in Commons waiting for a developer
> community to arrive.
>
> There are a few things here, in decreasing importance:
>
> 1) Code must be maintained to be worth using.
> 2) Code must have a community to be maintained.
> 3) The same code ought not to live in more than one place.
> 4) Reusable code ought to be in Jakarta Commons.
Well said, apart from 4 which I would say "could" instead of "ought to".
> Now, if the Ant developers are the only ones doing 1), and they are the
> only 2) for the code, then according to 3) the code should be in one
> place. This place ought to be Jakarta Commons, but if this is not possible
> then it should be in Ant as 4) is the least important of the 4 things.
This is why it was put in Commons, but the magic didn't happen ;-)
> So, +1 to the Ant guys managing the code inside Commons, +0 to the Ant
> guys offering the jars as a separate build.
I think the main issue with this is that Ant is somewhat at the top of
the Gump dependency graph, and splitting things out is not something
that fast and easy to do correctly.
MHO is that it would be possible to have Gump bootstrap these packages
by using simple javac, give them to Ant that does the same, etc, but it
gets complicated quite easily... dunno, I'm not going to do it, and
someone has to for these to live in J-C without duplication...
So yes, I agree with you. But we have to see if someone is willing to do
the Gump changes, or we have to fallback on the ant.multi-jar option.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Fwd: Bzip, tar, zip, etc]
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Henri Yandell wrote:
> The problem with these is that the developer community never followed the
> code. I assume this is some political issue in Jakarta I'm not aware of.
>
> As far as I know, the Commons idea is that the group who donate the code
> are seen as the ones who are the maintainers. The very concept of a
> 'Commons committer' is anathema to the Commons charter [although such a
> thing does evolve over time].
>
> bzip/tar/zip ended up just sitting in Commons waiting for a developer
> community to arrive.
>
> There are a few things here, in decreasing importance:
>
> 1) Code must be maintained to be worth using.
> 2) Code must have a community to be maintained.
> 3) The same code ought not to live in more than one place.
> 4) Reusable code ought to be in Jakarta Commons.
Well said, apart from 4 which I would say "could" instead of "ought to".
> Now, if the Ant developers are the only ones doing 1), and they are the
> only 2) for the code, then according to 3) the code should be in one
> place. This place ought to be Jakarta Commons, but if this is not possible
> then it should be in Ant as 4) is the least important of the 4 things.
This is why it was put in Commons, but the magic didn't happen ;-)
> So, +1 to the Ant guys managing the code inside Commons, +0 to the Ant
> guys offering the jars as a separate build.
I think the main issue with this is that Ant is somewhat at the top of
the Gump dependency graph, and splitting things out is not something
that fast and easy to do correctly.
MHO is that it would be possible to have Gump bootstrap these packages
by using simple javac, give them to Ant that does the same, etc, but it
gets complicated quite easily... dunno, I'm not going to do it, and
someone has to for these to live in J-C without duplication...
So yes, I agree with you. But we have to see if someone is willing to do
the Gump changes, or we have to fallback on the ant.multi-jar option.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Fwd: Bzip, tar, zip, etc]
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 23 Jan 2003, Henri Yandell <ba...@generationjava.com> wrote:
> The problem with these is that the developer community never
> followed the code.
See my first port.
> As far as I know, the Commons idea is that the group who donate the
> code are seen as the ones who are the maintainers.
Please note that it has not been the Ant community who donated the
code to commons.
> So, +1 to the Ant guys managing the code inside Commons,
As I said, there hasn't been much to manage in the past.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>