commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: [Avalon Packages -> Commons] Move Status - Executive Proposal
Date Fri, 21 Jun 2002 08:47:43 GMT


>   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:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message