You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2002/06/20 08:51:56 UTC
[Avalon Packages -> Commons] We want to move packages to Commons:
can you help?
The Avalon project has decided that it's time to move some packages of
the jakarta-avalon-excalibur module to Commons.
Some of the packages there eligible for the move are:
io
bzip2
tar
zip
thread
threadcontext
cli
collections
util
There are also others (notably i18n, naming, baxter).
Since many of these packages are already being developed in Commons
proper+sandbox, we need the help of the developers of these packages:
how can we integrate?
Everyone is kindly invited to checkout jakarta-avalon-excalibur and see
/what/ can be moved, and /how/.
Please append [Commons-Avalon:packagename] or similar to the messages so
we can filter them easily.
I'm on both lists, and will help in coordinating the effort.
If you wish: avalon-dev-subscribe@jakarta.apache.org
Thank you in advance :-)
--
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: [Avalon Packages -> Commons] Move Status - Executive Proposal
Posted by Henri Yandell <ba...@generationjava.com>.
> thread, threadcontext
> ------------------------
> [unassigned]
> Will go under lang as
> lang.thread
> lang.threadcontext
Not sure if it is decided as to whether these go in lang or whether there
will be a Thread subproject. Peter Donald suggested that there are reasons
for thread and threadcontext not wanting to live in the same project.
> cli
> ------
> [unassigned]
> Needs to be merged with commons-cli.
Peter suggested that the commons-cli does not focus on GNU adherence
whereas the excalibur one does. I believe that the commons one is
currently moving towards ORO like ability to have a common engine but
different front ends. ie) GnuParser, PosixParser, JavaParser or whatever.
> util
> ------
> [unassigned]
> To be merged in commons-util
Nah. To be split off into various places. I think there are 4 different
chunks of functionality currently in Excalibur.Util.
StringUtil into Lang.Strings. [I volunteer]
StackIntrospector into Util or Lang.exceptions?
SystemUtil into util.system? or util.system.cpu?
CPUParser Or should we have a for platform
system.anOS specificness?? Commons.System?
ComponentStateValidator This shouldn't go into Commons.
The last class has lots of dependencies on avalon and its functionality
appears to be aimed squarely at avalon, so I think this should remain
somewhere in Avalon.
>
>
>
> i18n
> ------
> [unassigned]
> Proposed project: commons-i18n
This needs more thinking before it has the strength to stand on its own I
think. Currently it's not really commons-i18n but is commons-resource,
providing helper functionality for resource bundles. That would be
expected to be a small sub-part of Util I'd guess. Util as a project does
have a problem in that it always seems stuck in the sandbox.
Other directions: commons-text, trying to add to java.text functionality,
i18n being an aspect of this. or commons-i18n with a lot more planned in
the way of i18n support.
> There are still about as many other packages in excalibur that can be
> put in commons, and will.
Cool :) What you guys are doing is great.
> Let's concentrate on these for now; I think it's a challenge enough ATM ;-)
Definitely.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[Avalon Packages -> Commons] Move Status - Executive Proposal
Posted by Nicola Ken Barozzi <ni...@apache.org>.
First of all, thanks to everyone that is giving a hand in this move.
We appreciate it :-)
Since there is good interest, the discussion will continue in Commons,
and I will continue my coordination effort.
Below are the packages listed one by one, along with the issues and
proposals.
Whoever wants to be in charge of the move of a package, please put his
name under it, so that I know I don't have to move the stuff myself ;-)
What I *don't* want to see is that our packages become duplications of
one already there, it would be useless.
Commons (both sandbox and proper) is growing with so many projects that
it's starting to make sense to have projects with mini-projects.
This means having, for example, thread in the lang project, but with the
code kept internally separate.
io
----
[unassigned]
No issues arised to date.
Will be merged with commons-io
bzip2, tar, zip
-----------------
[unassigned]
No issues arised to date.
Proposed package: compress
Io is more generic, and it's better to focus on compression.
Need to keep codebases separate:
compress.bzip
compress.tar
compress.zip
Need to merge with Ant versions.
Need to discuss on Ant-dev a technical solution to make Ant build
himself easily; recursive dependency is a problem.
thread, threadcontext
------------------------
[unassigned]
Will go under lang as
lang.thread
lang.threadcontext
cli
------
[unassigned]
Needs to be merged with commons-cli.
collections
--------------
[unassigned]
Discussion is very vivid on this, and developers have already committed
stuff (YAY! :-)
Please enhance this with what still needs to be done.
util
------
[unassigned]
To be merged in commons-util
i18n
------
[unassigned]
Proposed project: commons-i18n
naming
--------
[unassigned]
Proposed project: commons-naming
Needs to gain stuff from Tomcat.
Suggestions welcome.
baxter
--------
[unassigned]
Easy MBeans.
Needs merge with Modeler.
Help needed.
There are still about as many other packages in excalibur that can be
put in commons, and will.
Let's concentrate on these for now; I think it's a challenge enough ATM ;-)
--
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: [Avalon Packages -> Commons] We want to move packages to
Commons: can you help? [Commons-Avalon]
Posted by Peter Donald <pe...@apache.org>.
At 05:06 AM 6/21/2002 -0400, you wrote:
>On Fri, 21 Jun 2002, Peter Donald wrote:
>
> > >1)
> > >Zip, tar and bzip2 seem like potential packages of one project. Codec? Or
> > >a new one named Compress or some such?
> >
> > bzip should be kept separate as it is useful outside of those who use it to
> > compress archives.
>
>I'm not getting you here. What are the other uses for bzip?
No idea. Compression of blocks of data for network transmission has been
the one of the requests and also compression of image data prior to
explosion on end system.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon Packages -> Commons] We want to move packages to Commons: can you help? [Commons-Avalon]
Posted by Peter Royal <pr...@apache.org>.
On Friday 21 June 2002 05:06 am, Henri Yandell wrote:
> On Fri, 21 Jun 2002, Peter Donald wrote:
> > >1)
> > >Zip, tar and bzip2 seem like potential packages of one project. Codec?
> > > Or a new one named Compress or some such?
> >
> > bzip should be kept separate as it is useful outside of those who use it
> > to compress archives.
>
> I'm not getting you here. What are the other uses for bzip?
The bzip2 package just has a CBZip2InputStream and OutputStream, so its
stream-oriented whereas the tar and zip packages are for archive creation.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon Packages -> Commons] We want to move packages to Commons:
can you help? [Commons-Avalon]
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 21 Jun 2002, Peter Donald wrote:
> >1)
> >Zip, tar and bzip2 seem like potential packages of one project. Codec? Or
> >a new one named Compress or some such?
>
> bzip should be kept separate as it is useful outside of those who use it to
> compress archives.
I'm not getting you here. What are the other uses for bzip?
> >I notice the tar stuff is from Tim
> >Endres. Is this now the definitive version of his work and the ice.com
> >stuff at gjt.org is just an oldie, or has it been forked?
>
> The tar stuff comes from ant which I believe was forked back ages ago (I
> believe Tim wanted to continue using (L)GPL which Ant couldn't use). I
> think the ant one has a few more features (handles sun/gnu tars) but not
> entirely sure.
>
It appears to be public domain now. I wonder what the state of gjt.org is
nowadays. Has seemed quiet for quite a long time.
> >Thread stuff. Any reason not to merge these into a subproject called
> >thread? I can understand not putting them in Lang. Doesn't make sense to
> >fatten that up with stuff just because Thread is in java.lang.
>
> The different components have different dependencies and at different
> stages of evolution so it doesn't seem wise to try and keep them together.
I see what you mean. The Thread package seems quite tied to Avalon [from a
brief look at imports] while ThreadContext looks very generic and a good
candidate for org.apache.commons.lang.thread.
I see what you mean. ThreadContext looks pretty generic and reusable. Do
you see it as being something that can slip into the Lang project at
org.apache.commons.lang.thread, or as something that would live as its own
ThreadContext project? The proposal for Lang is that it provides
enhancements to packages within the java.lang package. Up until now this
has basically meant primitive/common types and common classes like
Exception. java.lang.Thread qualifies under this, but probably has the
scope to be its own project.
Thread on the other hand seems to be more highlevel with dependencies on
Avalon [none of them seem that tight] and some design considerations for
linking to Avalon things like Executable. Of course I'm not that clued up
on Avalon yet.
>
> >3)
> >Cli. Peter Donald's cli is quoted as one of the sources of Commons.Cli.
> >I guess Peter/Bob/John would need to discuss whether Commons.Cli fully
> >replaces Exc.Cli yet.
>
>
> Had a brief look and it does not look like commons one is (or intends to
> be) the same as GNU standard.
I think they may support the GNU standard as an option [or plan to],
similar to Jakarta ORO's support of different forms of regexp. I could be
wrong though.
Thanks,
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon Packages -> Commons] We want to move packages to
Commons: can you help? [Commons-Avalon]
Posted by Peter Donald <pe...@apache.org>.
At 09:28 AM 6/20/2002 -0400, you wrote:
>1)
>Zip, tar and bzip2 seem like potential packages of one project. Codec? Or
>a new one named Compress or some such?
bzip should be kept separate as it is useful outside of those who use it to
compress archives.
>I notice the tar stuff is from Tim
>Endres. Is this now the definitive version of his work and the ice.com
>stuff at gjt.org is just an oldie, or has it been forked?
The tar stuff comes from ant which I believe was forked back ages ago (I
believe Tim wanted to continue using (L)GPL which Ant couldn't use). I
think the ant one has a few more features (handles sun/gnu tars) but not
entirely sure.
>Thread stuff. Any reason not to merge these into a subproject called
>thread? I can understand not putting them in Lang. Doesn't make sense to
>fatten that up with stuff just because Thread is in java.lang.
The different components have different dependencies and at different
stages of evolution so it doesn't seem wise to try and keep them together.
>3)
>Cli. Peter Donald's cli is quoted as one of the sources of Commons.Cli.
>I guess Peter/Bob/John would need to discuss whether Commons.Cli fully
>replaces Exc.Cli yet.
Had a brief look and it does not look like commons one is (or intends to
be) the same as GNU standard.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[Avalon Packages -> Commons] Move Status - Executive Proposal
Posted by Nicola Ken Barozzi <ni...@apache.org>.
First of all, thanks to everyone that is giving a hand in this move.
We appreciate it :-)
Since there is good interest, the discussion will continue in Commons,
and I will continue my coordination effort.
Below are the packages listed one by one, along with the issues and
proposals.
Whoever wants to be in charge of the move of a package, please put his
name under it, so that I know I don't have to move the stuff myself ;-)
What I *don't* want to see is that our packages become duplications of
one already there, it would be useless.
Commons (both sandbox and proper) is growing with so many projects that
it's starting to make sense to have projects with mini-projects.
This means having, for example, thread in the lang project, but with the
code kept internally separate.
io
----
[unassigned]
No issues arised to date.
Will be merged with commons-io
bzip2, tar, zip
-----------------
[unassigned]
No issues arised to date.
Proposed package: compress
Io is more generic, and it's better to focus on compression.
Need to keep codebases separate:
compress.bzip
compress.tar
compress.zip
Need to merge with Ant versions.
Need to discuss on Ant-dev a technical solution to make Ant build
himself easily; recursive dependency is a problem.
thread, threadcontext
------------------------
[unassigned]
Will go under lang as
lang.thread
lang.threadcontext
cli
------
[unassigned]
Needs to be merged with commons-cli.
collections
--------------
[unassigned]
Discussion is very vivid on this, and developers have already committed
stuff (YAY! :-)
Please enhance this with what still needs to be done.
util
------
[unassigned]
To be merged in commons-util
i18n
------
[unassigned]
Proposed project: commons-i18n
naming
--------
[unassigned]
Proposed project: commons-naming
Needs to gain stuff from Tomcat.
Suggestions welcome.
baxter
--------
[unassigned]
Easy MBeans.
Needs merge with Modeler.
Help needed.
There are still about as many other packages in excalibur that can be
put in commons, and will.
Let's concentrate on these for now; I think it's a challenge enough ATM ;-)
--
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: [Avalon Packages -> Commons] We want to move packages to Commons: can you help? [Commons-Avalon]
Posted by Rob Oxspring <ro...@imapmail.org>.
Hang on though,
The jars checked into ant's cvs (xerces etc, junit) are all built by ant at
one stage or another anyway, so why not just take the same approach step by
step:
1) Merge the code into o.a.c.codec.zip/tar/bzip or whereever
2) Make a release
3) Make ant depend on the released jar
This probably won't be a problem as it won't affect Ant 1.5 (too close) and
could easily be done in time for ant 1.6 (ages away I expect). Ant (and
IMHO most projects) shouldn't be depending on anything but released code
anyway.
Rob
----- Original Message -----
From: "Kurt Schrader" <ks...@karmalab.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
<ni...@apache.org>
Sent: Thursday, June 20, 2002 4:23 PM
Subject: Re: [Avalon Packages -> Commons] We want to move packages to
Commons: can you help? [Commons-Avalon]
> Ant needs to be able to build itself without a depenedency on using Ant to
> build something else first, which is what this would introduce.
>
> -Kurt
>
> On Thu, 20 Jun 2002, Nicola Ken Barozzi wrote:
>
> >
> > Stefan Bodewig wrote:
> > > On Thu, 20 Jun 2002, Nicola Ken Barozzi <ni...@apache.org> wrote:
> > >
> > >>So, what about Ant using the commons version of these packages?
> > >
> > > The only thing I was concerned about is how to bootstrap Ant.
> >
> > Excuse my ignorance on this matter, but isn't putting this
> > commons package in ANT_HOME/lib enough?
> > Maybe there is something I'm missing...
> >
> > --
> > 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: <mailto:commons-dev-unsubscribe@jakarta.apache.o
rg>
> 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: [Avalon Packages -> Commons] We want to move packages to Commons: can you help? [Commons-Avalon]
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 20 Jun 2002, Juozas Baliuka <ba...@mwm.lt> wrote:
> Ant uses itself to build it, doe's not it ?
No - at least not a different version than the one you are building.
Ant uses javac to compile a very basic version of its latest code and
then builds itself using this version.
It is rather common that you can not build Ant with the version that
is just one commit away as build.xml already uses the feature just
committed.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon Packages -> Commons] We want to move packages to
Commons: can you help? [Commons-Avalon]
Posted by Juozas Baliuka <ba...@mwm.lt>.
At 17:42 2002.06.20 +0200, Nicola Ken Barozzi wrote:
>Stefan Bodewig wrote:
>>On Thu, 20 Jun 2002, Kurt Schrader <ks...@karmalab.org> wrote:
>>
>>>Ant needs to be able to build itself without a depenedency on using
>>>Ant to build something else first
>>Exactly.
Ant uses itself to build it, doe's not it ?
Just build depenedency as usual , copy it to Ant's Lib and build Ant as usual.
I don't see any problems in this case.
<snip>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon Packages -> Commons] We want to move packages to Commons: can you help? [Commons-Avalon]
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 20 Jun 2002, Nicola Ken Barozzi <ni...@apache.org> wrote:
> Wouldn't the tar etc Tasks depend on them anyway?
The tasks would consequently go with the utility classes.
> What is the real stringent need for having to use the commons-jar?
The main difference is that the zip package provides access to ZIP's
external attributes (which java.util.zip doesn't) - this is where Unix
permissions get stored. If you create a ZIP with Java's classes, your
directories are missing the executable bit.
<jar> extends <zip>, after all a JAR is a ZIP with a manifest - and
<zip> is supposed to store directories in a usable way.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon Packages -> Commons] We want to move packages to Commons:
can you help? [Commons-Avalon]
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefan Bodewig wrote:
> On Thu, 20 Jun 2002, Kurt Schrader <ks...@karmalab.org> wrote:
>
>>Ant needs to be able to build itself without a depenedency on using
>>Ant to build something else first
>
> Exactly.
Aahhhhh ok.
> There is no problem with tar and bzip2 as they are only needed to
> build a distribution,
Wouldn't the tar etc Tasks depend on them anyway?
> but the jar task (which creates ant.jar) uses
> the zip classes. The only way out would be a <zip> task that would
> fall back to java.util.zip if commons-zip (or whatever) was not
> available.
>
> Possible but not too pretty.
What is the real stringent need for having to use the commons-jar?
> Something ant-dev would have to talk
> about, of course.
Hmmm... and have commons not be build with ant but just javac?
Would it help in some way?
--
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: [Avalon Packages -> Commons] We want to move packages to Commons: can you help? [Commons-Avalon]
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 20 Jun 2002, Henri Yandell <ba...@generationjava.com> wrote:
> How about keeping the code in ant, but having a Commons page which
> offers up that code as a separate jar?
Fine with me, maybe the package should be renamed (inside Ant's CVS it
lives in org.apache.tools.zip).
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon Packages -> Commons] We want to move packages to Commons:
can you help? [Commons-Avalon]
Posted by Henri Yandell <ba...@generationjava.com>.
How about keeping the code in ant, but having a Commons page which offers
up that code as a separate jar? Or jsut describes it in a generic way?
On 20 Jun 2002, Stefan Bodewig wrote:
> On Thu, 20 Jun 2002, Kurt Schrader <ks...@karmalab.org> wrote:
>
> > Ant needs to be able to build itself without a depenedency on using
> > Ant to build something else first
>
> Exactly.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon Packages -> Commons] We want to move packages to Commons: can you help? [Commons-Avalon]
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 20 Jun 2002, Kurt Schrader <ks...@karmalab.org> wrote:
> Ant needs to be able to build itself without a depenedency on using
> Ant to build something else first
Exactly.
There is no problem with tar and bzip2 as they are only needed to
build a distribution, but the jar task (which creates ant.jar) uses
the zip classes. The only way out would be a <zip> task that would
fall back to java.util.zip if commons-zip (or whatever) was not
available.
Possible but not too pretty. Something ant-dev would have to talk
about, of course.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon Packages -> Commons] We want to move packages to Commons:
can you help? [Commons-Avalon]
Posted by Kurt Schrader <ks...@karmalab.org>.
Ant needs to be able to build itself without a depenedency on using Ant to
build something else first, which is what this would introduce.
-Kurt
On Thu, 20 Jun 2002, Nicola Ken Barozzi wrote:
>
> Stefan Bodewig wrote:
> > On Thu, 20 Jun 2002, Nicola Ken Barozzi <ni...@apache.org> wrote:
> >
> >>So, what about Ant using the commons version of these packages?
> >
> > The only thing I was concerned about is how to bootstrap Ant.
>
> Excuse my ignorance on this matter, but isn't putting this
> commons package in ANT_HOME/lib enough?
> Maybe there is something I'm missing...
>
> --
> 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: [Avalon Packages -> Commons] We want to move packages to Commons:
can you help? [Commons-Avalon]
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefan Bodewig wrote:
> On Thu, 20 Jun 2002, Nicola Ken Barozzi <ni...@apache.org> wrote:
>
>>So, what about Ant using the commons version of these packages?
>
> The only thing I was concerned about is how to bootstrap Ant.
Excuse my ignorance on this matter, but isn't putting this
commons package in ANT_HOME/lib enough?
Maybe there is something I'm missing...
--
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: [Avalon Packages -> Commons] We want to move packages to Commons: can you help? [Commons-Avalon]
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 20 Jun 2002, Nicola Ken Barozzi <ni...@apache.org> wrote:
> So, what about Ant using the commons version of these packages?
The only thing I was concerned about is how to bootstrap Ant.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon Packages -> Commons] We want to move packages to Commons:
can you help? [Commons-Avalon]
Posted by Henri Yandell <ba...@generationjava.com>.
> > It is almost identical to Ant's code, I think Peter Donald has found a
> > problem in the tar classes, but the rest should be the same.
> >
> > tar is forked from Tim Endress' code (forked in 1999 AFAIK) and has
> > gained a bunch of features after that. bzip2 is rather new code
> > originally written by Keiron Liddle (FOP committer, ASF member ...),
> > zip has been written mostly by myself and has been part of Ant since
> > early Ant 1.4alpha.
>
> So, what about Ant using the commons version of these packages?
>
> We could put our in, you merge with the Ant ones, and we have a
> really *common* set of packages :-)
So Exc.tar and Exc.bzip can both be considered to be the latest versions.
Exc.zip needs to be considered against Ant.zip to decide which is most
featureful/recent, then that one migrated into Commons [if Ant is
acceptable of Commons dependencies] and the other's differences merged in?
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon Packages -> Commons] We want to move packages to Commons:
can you help? [Commons-Avalon]
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefan Bodewig wrote:
> On Thu, 20 Jun 2002, Remy Maucherat <re...@apache.org> wrote:
>
>
>>Doesn't Ant have code like that ?
>>I would assume that the Ant code is better tested; is it a duplicate
>>of that.
>
>
> It is almost identical to Ant's code, I think Peter Donald has found a
> problem in the tar classes, but the rest should be the same.
>
> tar is forked from Tim Endress' code (forked in 1999 AFAIK) and has
> gained a bunch of features after that. bzip2 is rather new code
> originally written by Keiron Liddle (FOP committer, ASF member ...),
> zip has been written mostly by myself and has been part of Ant since
> early Ant 1.4alpha.
So, what about Ant using the commons version of these packages?
We could put our in, you merge with the Ant ones, and we have a
really *common* set of packages :-)
--
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: [Avalon Packages -> Commons] We want to move packages to Commons: can you help? [Commons-Avalon]
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 20 Jun 2002, Remy Maucherat <re...@apache.org> wrote:
> Doesn't Ant have code like that ?
> I would assume that the Ant code is better tested; is it a duplicate
> of that.
It is almost identical to Ant's code, I think Peter Donald has found a
problem in the tar classes, but the rest should be the same.
tar is forked from Tim Endress' code (forked in 1999 AFAIK) and has
gained a bunch of features after that. bzip2 is rather new code
originally written by Keiron Liddle (FOP committer, ASF member ...),
zip has been written mostly by myself and has been part of Ant since
early Ant 1.4alpha.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon Packages -> Commons] We want to move packages to
Commons: can you help? [Commons-Avalon]
Posted by John Keyes <jb...@mac.com>.
> >> 3)
> >> Cli. Peter Donald's cli is quoted as one of the sources of Commons.Cli.
> >> I guess Peter/Bob/John would need to discuss whether Commons.Cli fully
> >> replaces Exc.Cli yet.
>
> Yup. I read that too.
> Comments are welcome.
I have only had a quick look at this before. I will look into
this when I get a chance and see if there is anything that should
make its way into CLI. I'll post back when I have had a chance
to do this.
-John K
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon Packages -> Commons] We want to move packages to Commons: can you help? [Commons-Avalon]
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Henri Yandell" <ba...@generationjava.com>
> > > 1) org.apache.commons.thread in project Thread
> > > org.apache.commons.compress in project Compress
> > >
> > > 2) org.apache.commons.lang.thread in project Lang
> > > org.apache.commons.io.compress in project IO
> > >
> > > 3) org.apache.commons.lang.thread in project Thread
> > > org.apache.commons.io.compress in project Compress.
I dislike #3, the part after commons should be the project name. The other
two is a key decision for commons.
I'm interested because (in another thread) I proposed that low level
reflection code should be extracted from its current locations. (This thread
isn't about whether thats good or bad but... ) Were it to happen two options
have been proposed, a separate Reflect project, or part of Lang. Thus to
expand on the options:
1) org.apache.commons.thread in project Thread
org.apache.commons.compress in project Compress
org.apache.commons.reflect in project Reflect
2) org.apache.commons.lang.thread in project Lang
org.apache.commons.lang.reflect in project Lang
org.apache.commons.io.compress in project IO
#1 gives more jars and thus more potential version confusion. But it does
give more control over separate release cycles, and tightly focussed
projects. There is also the possibility of very small jars, so small that
people might decide that they might as well write their own version of the
code rather than have the hassle of another jar.
#2 gives less jars, but potentially causes you to pickup code you don't want
to get at the code you do. The projects are less focussed. This could also
lead to sub-projects within sub-projects.
I'm not obsessed with either, but it is what we have to decide on. I think I
tend towards #2, so each jar has a critical mass.
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon Packages -> Commons] We want to move packages to Commons:
can you help? [Commons-Avalon]
Posted by Henri Yandell <ba...@generationjava.com>.
> > 1) org.apache.commons.thread in project Thread
> > org.apache.commons.compress in project Compress
> >
> > 2) org.apache.commons.lang.thread in project Lang
> > org.apache.commons.io.compress in project IO
> >
> > 3) org.apache.commons.lang.thread in project Thread
> > org.apache.commons.io.compress in project Compress.
> >
> > I'll ignore the fourth combination as being wrong. Anyone with any
> > preferences?
>
> I'd say 2), but keep the code separate as for the Excalibur miniprojects.
>
> So one could make single jars for thread, compress, etc or include them
> in a catchall io or lang package.
This has previously been frowned on too. Having the same code available in
different jars. I think the reasoning is that it confuses and can also
cause 'dll hell' a la the w3c dom being in crimson and xerces.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon Packages -> Commons] We want to move packages to Commons:
can you help? [Commons-Avalon]
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Henri Yandell wrote:
>
>>>>1)
>>>>Zip, tar and bzip2 seem like potential packages of one project. Codec? Or
>>>>a new one named Compress or some such?
>>>
>>how about org.apache.commons.io.compress?
>
> Re: Threads
>
>>>>I can understand not putting them in Lang. Doesn't make sense to
>>>>fatten that up with stuff just because Thread is in java.lang.
>>>
>>org.apache.commons.lang.thread
>
> There's a worry that things like IO and Lang might lose focus if lots of
> things end up in them. The other side of the coin is that having lots of
> jars and projects around makes things more confusing. Seems the choices
> are:
>
> 1) org.apache.commons.thread in project Thread
> org.apache.commons.compress in project Compress
>
> 2) org.apache.commons.lang.thread in project Lang
> org.apache.commons.io.compress in project IO
>
> 3) org.apache.commons.lang.thread in project Thread
> org.apache.commons.io.compress in project Compress.
>
> I'll ignore the fourth combination as being wrong. Anyone with any
> preferences?
I'd say 2), but keep the code separate as for the Excalibur miniprojects.
So one could make single jars for thread, compress, etc or include them
in a catchall io or lang package.
--
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: [Avalon Packages -> Commons] We want to move packages to Commons:
can you help? [Commons-Avalon]
Posted by Henri Yandell <ba...@generationjava.com>.
> >> 1)
> >> Zip, tar and bzip2 seem like potential packages of one project. Codec? Or
> >> a new one named Compress or some such?
>
> how about org.apache.commons.io.compress?
Re: Threads
> >> I can understand not putting them in Lang. Doesn't make sense to
> >> fatten that up with stuff just because Thread is in java.lang.
>
> org.apache.commons.lang.thread
There's a worry that things like IO and Lang might lose focus if lots of
things end up in them. The other side of the coin is that having lots of
jars and projects around makes things more confusing. Seems the choices
are:
1) org.apache.commons.thread in project Thread
org.apache.commons.compress in project Compress
2) org.apache.commons.lang.thread in project Lang
org.apache.commons.io.compress in project IO
3) org.apache.commons.lang.thread in project Thread
org.apache.commons.io.compress in project Compress.
I'll ignore the fourth combination as being wrong. Anyone with any
preferences?
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon Packages -> Commons] We want to move packages to Commons:
can you help? [Commons-Avalon]
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Remy Maucherat wrote:
> Henri Yandell wrote:
>
>> To provide an initial set of suggestions for people to haggle over:
>>
>> Obviously io/collections map nicely over to their respective partners at
>> Commons.
>>
>> 1)
>> Zip, tar and bzip2 seem like potential packages of one project. Codec? Or
>> a new one named Compress or some such?
how about org.apache.commons.io.compress?
> Doesn't Ant have code like that ?
> I would assume that the Ant code is better tested; is it a duplicate of
> that.
IMHO we need a merge.
>> 2)
>> Thread stuff. Any reason not to merge these into a subproject called
>> thread?
No reason not to merge -> merge ok :-)
>> I can understand not putting them in Lang. Doesn't make sense to
>> fatten that up with stuff just because Thread is in java.lang.
org.apache.commons.lang.thread
>> 3)
>> Cli. Peter Donald's cli is quoted as one of the sources of Commons.Cli.
>> I guess Peter/Bob/John would need to discuss whether Commons.Cli fully
>> replaces Exc.Cli yet.
Yup. I read that too.
Comments are welcome.
>> 4)
>> Util. i18N.
>> These both look to include nice juicy bits that will each need
>> consideration for movement elsewhere.
ok.
>> 5) Baxter. Naming.
>> ??
>
>
> Tomcat 4 also has a JNDI component.
> It is completely independent from Tomcat, and could be moved to the
> commons in the future if there is some interest (so far, there has been
> none).
If someone who knows that could look in the Avalon one, we could decide
on how to "merge" them.
I'd be more than happy to reuse that code from Tomcat :-)
--
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: [Avalon Packages -> Commons] We want to move packages to Commons:
can you help? [Commons-Avalon]
Posted by co...@covalent.net.
+1 on moving the components.
For the record, there is no rule against duplication ( AFAIK ).
If we have 2 components doing the same thing, and each has some
specific features - they can live both in commons. In time they
may merge or not.
Of course, it would be nice to merge where possible and if the
implementation is the same.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon Packages -> Commons] We want to move packages to Commons:
can you help? [Commons-Avalon]
Posted by Remy Maucherat <re...@apache.org>.
Henri Yandell wrote:
> To provide an initial set of suggestions for people to haggle over:
>
> Obviously io/collections map nicely over to their respective partners at
> Commons.
>
> 1)
> Zip, tar and bzip2 seem like potential packages of one project. Codec? Or
> a new one named Compress or some such? I notice the tar stuff is from Tim
> Endres. Is this now the definitive version of his work and the ice.com
> stuff at gjt.org is just an oldie, or has it been forked?
Doesn't Ant have code like that ?
I would assume that the Ant code is better tested; is it a duplicate of
that.
> 2)
> Thread stuff. Any reason not to merge these into a subproject called
> thread? I can understand not putting them in Lang. Doesn't make sense to
> fatten that up with stuff just because Thread is in java.lang.
>
> 3)
> Cli. Peter Donald's cli is quoted as one of the sources of Commons.Cli.
> I guess Peter/Bob/John would need to discuss whether Commons.Cli fully
> replaces Exc.Cli yet.
>
> 4)
> Util. i18N.
> These both look to include nice juicy bits that will each need
> consideration for movement elsewhere.
>
> 5) Baxter. Naming.
> ??
Tomcat 4 also has a JNDI component.
It is completely independent from Tomcat, and could be moved to the
commons in the future if there is some interest (so far, there has been
none).
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon Packages -> Commons] We want to move packages to Commons:
can you help? [Commons-Avalon]
Posted by Henri Yandell <ba...@generationjava.com>.
To provide an initial set of suggestions for people to haggle over:
Obviously io/collections map nicely over to their respective partners at
Commons.
1)
Zip, tar and bzip2 seem like potential packages of one project. Codec? Or
a new one named Compress or some such? I notice the tar stuff is from Tim
Endres. Is this now the definitive version of his work and the ice.com
stuff at gjt.org is just an oldie, or has it been forked?
2)
Thread stuff. Any reason not to merge these into a subproject called
thread? I can understand not putting them in Lang. Doesn't make sense to
fatten that up with stuff just because Thread is in java.lang.
3)
Cli. Peter Donald's cli is quoted as one of the sources of Commons.Cli.
I guess Peter/Bob/John would need to discuss whether Commons.Cli fully
replaces Exc.Cli yet.
4)
Util. i18N.
These both look to include nice juicy bits that will each need
consideration for movement elsewhere.
5) Baxter. Naming.
??
Just ideas, but shoot em down.
Hen
On Thu, 20 Jun 2002, Nicola Ken Barozzi wrote:
> The Avalon project has decided that it's time to move some packages of
> the jakarta-avalon-excalibur module to Commons.
>
> Some of the packages there eligible for the move are:
>
> io
> bzip2
> tar
> zip
> thread
> threadcontext
> cli
> collections
> util
>
> There are also others (notably i18n, naming, baxter).
>
> Since many of these packages are already being developed in Commons
> proper+sandbox, we need the help of the developers of these packages:
>
> how can we integrate?
>
> Everyone is kindly invited to checkout jakarta-avalon-excalibur and see
> /what/ can be moved, and /how/.
>
> Please append [Commons-Avalon:packagename] or similar to the messages so
> we can filter them easily.
> I'm on both lists, and will help in coordinating the effort.
> If you wish: avalon-dev-subscribe@jakarta.apache.org
>
> Thank you in advance :-)
>
> --
> 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: [Avalon Packages -> Commons] We want to move packages to Commons:
can you help? [Commons-Avalon]
Posted by Henri Yandell <ba...@generationjava.com>.
To provide an initial set of suggestions for people to haggle over:
Obviously io/collections map nicely over to their respective partners at
Commons.
1)
Zip, tar and bzip2 seem like potential packages of one project. Codec? Or
a new one named Compress or some such? I notice the tar stuff is from Tim
Endres. Is this now the definitive version of his work and the ice.com
stuff at gjt.org is just an oldie, or has it been forked?
2)
Thread stuff. Any reason not to merge these into a subproject called
thread? I can understand not putting them in Lang. Doesn't make sense to
fatten that up with stuff just because Thread is in java.lang.
3)
Cli. Peter Donald's cli is quoted as one of the sources of Commons.Cli.
I guess Peter/Bob/John would need to discuss whether Commons.Cli fully
replaces Exc.Cli yet.
4)
Util. i18N.
These both look to include nice juicy bits that will each need
consideration for movement elsewhere.
5) Baxter. Naming.
??
Just ideas, but shoot em down.
Hen
On Thu, 20 Jun 2002, Nicola Ken Barozzi wrote:
> The Avalon project has decided that it's time to move some packages of
> the jakarta-avalon-excalibur module to Commons.
>
> Some of the packages there eligible for the move are:
>
> io
> bzip2
> tar
> zip
> thread
> threadcontext
> cli
> collections
> util
>
> There are also others (notably i18n, naming, baxter).
>
> Since many of these packages are already being developed in Commons
> proper+sandbox, we need the help of the developers of these packages:
>
> how can we integrate?
>
> Everyone is kindly invited to checkout jakarta-avalon-excalibur and see
> /what/ can be moved, and /how/.
>
> Please append [Commons-Avalon:packagename] or similar to the messages so
> we can filter them easily.
> I'm on both lists, and will help in coordinating the effort.
> If you wish: avalon-dev-subscribe@jakarta.apache.org
>
> Thank you in advance :-)
>
> --
> 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: [Commons-Avalon:collections] code integration
Posted by "Michael A. Smith" <ma...@apache.org>.
On Thu, 20 Jun 2002, Berin Loritsch wrote:
> > From: Michael A. Smith [mailto:mas@apache.org]
>
> > I do have a couple of concerns with the BucketMap. In a
> > quick glance, it looks like it doesn't follow the Map
> > contract -- the colletion views are not backed by the map.
> > The new commons collections test suite for Map
> > implementations should check for that, along with potentially other
> > differences from the Map contract. Any differences in contract would
> > have to be resolved.
>
> BTW, I wrote the BucketMap. My primary concern while
> writing it was fine-grained locking. At that it excells. The
> process of adding, removing, and looking up information far
> exceeds a Synchronized Map or Hashtable when multiple threads
> are trying to do the same thing.
>
> The main focus was an add/remove/lookup--not the rest of the
> Map contracts. That is because of the focus of what it is
> used for.
yup, I understand that... My point is that the rest of the map contract
should be addressed as well. :)
btw, one thing that java.util.HashMap and java.util.Hashtable provide is
the ability to have the underlying hashtable grow when the contents of
the hashtable grow to a certain load factor of the size of the
underlying table. I didn't see the same feature in BucketMap. Wouldn't
that mean that BucketMap would degrade in performance significantly
(compared with java.util's hash based maps) as the size of the map
increases well beyond its number of buckets?
btw, I'd be happy to fix that issue in BucketMap once it's moved over.
It's really not that difficult to do and wouldn't have an impact on
thread contention, although it probably would increase the memory
footprint a bit and add a couple of operations for each lookup (a
bitwise &, an array dereference, a comparison to see if the
expansion threshold had been reached, and the amortized cost of table
expansion).
regards
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Commons-Avalon:collections] code integration
Posted by Berin Loritsch <bl...@apache.org>.
> From: Michael A. Smith [mailto:mas@apache.org]
> I do have a couple of concerns with the BucketMap. In a
> quick glance, it looks like it doesn't follow the Map
> contract -- the colletion views are not backed by the map.
> The new commons collections test suite for Map
> implementations should check for that, along with potentially other
> differences from the Map contract. Any differences in contract would
> have to be resolved.
BTW, I wrote the BucketMap. My primary concern while
writing it was fine-grained locking. At that it excells. The
process of adding, removing, and looking up information far
exceeds a Synchronized Map or Hashtable when multiple threads
are trying to do the same thing.
The main focus was an add/remove/lookup--not the rest of the
Map contracts. That is because of the focus of what it is
used for.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[Commons-Avalon:collections] code integration
Posted by "Michael A. Smith" <ma...@apache.org>.
On Thu, 20 Jun 2002, Nicola Ken Barozzi wrote:
> The Avalon project has decided that it's time to move some packages of
> the jakarta-avalon-excalibur module to Commons.
>
> Some of the packages there eligible for the move are:
[snip]
> collections
It looks like most of collections was already copied over some time ago
(just over a year ago). The only things missing are the Buffer classes
and the BucketMap.
> how can we integrate?
The code that had already been moved over differs a bit, but i have a
feeling it's mostly just by "style" since the avalon versions went
through a reformatting of the code 3 months ago. I'd be more than happy
to assist in looking for actual code differences and integrating them.
I won't have a chance for at least a week though.
I do have a couple of concerns with the BucketMap. In a quick glance,
it looks like it doesn't follow the Map contract -- the colletion views
are not backed by the map. The new commons collections test suite for
Map implementations should check for that, along with potentially other
differences from the Map contract. Any differences in contract would
have to be resolved.
regards,
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>