[Avalon Packages -> Commons] Move Status - Executive Proposal

[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] Move Status - Executive Proposal

[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>