You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/02/20 18:21:18 UTC
[Excalibur] Release Path
Currently, Cocoon requires the following Excalibur packages:
CLI
Collections
Concurrent
i18n
instrument
instrument-manager
instrument-manager-interfaces
IO
Logger
Monitor
Naming
Pool
SourceResolve
Store
XMLUtil
Cornerstone
Cornerstone-excalibur-thread
Cornerstone-excalibur-threadcontext
DataSource
AltRMI
AltRMI Registry
AltRMI Server (IMpl/Interfaces)
Component (AKA ECM)
Some of these we don't want to continue to support, so we
need to perform the education and deprecation strategies.
Collections and Concurrent are already deprecated,
but we need to look into the future.
I personally would like to deprecate CLI in favor of the
commons variation.
As to the rest of them, we need some education ourselves
to see what and how everything is being used in Cocoon.
I think this should be our first cut of Excalibur components.
We should do the minimal ECM set, and then the full Cocoon
required set. Lastly, we should do the Fortress set.
That way we can provide the assistance and guidance to
upgrade their current source base.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Excalibur] Release Path
Posted by Peter Donald <pe...@realityforge.org>.
Hi,
It seems we want to
naming has already been moved out and further development has go on at
spice.sf.net/jndikit. converter has also moved there.
baxter should be killed off as no one uses it, it encourages bad design and
has never been released.
threadcontext/jprocess can be merged and moved out of Avalon. I will do that
in a couple of weeks but there needs to be a bunch of work on them as neither
is really done well.
configuration should move to sandbox.
cli/i18n/extension can be migrated out.
datasource should be deprecated in favour of a wrapper around Commons DBCP.
mpool/pool can be deprecate in favour of Commons Pool
threadpool I can move out and provide a migration target.
loader can move out
policy can move out
event can move out.
xmlutil/sourceresolve can move to cocoon
monitor can be cleaned up/moved out
--
Cheers,
Peter Donald
-----------------------------------------------------------
Don't take life too seriously --
you'll never get out of it alive.
-----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Excalibur] Release Path
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>
>
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>Excalibur Configuration +1
>>Excalibur Context - not sure what your referring to.
>>
>>
>
>(Not quite sure myself...)
>
>http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/context/?hideattic=0#
>dirlist
>
>Didn't see that it was a deleted project.
>
>
The context stuff was merged into the configuration package (one class
that built a context obejct from a confiuration).
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [Excalibur] Release Path
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Excalibur Configuration +1
> Excalibur Context - not sure what your referring to.
(Not quite sure myself...)
http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/context/?hideattic=0#
dirlist
Didn't see that it was a deleted project.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Excalibur] Release Path
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>
>
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>Currently, Cocoon requires the following Excalibur packages:
>>
>>CLI
>>
>>
>
>Leaves Avalon - out of scope.
>
>
>
>>Collections
>>
>>
>
>Leaves Avalon - out of scope.
>
>
>
>>Concurrent
>>
>>
>
>Leaves Avalon - out of scope.
>
>
>
>>i18n
>>
>>
>
>No opinion.
>
>
Two classes - used in a lot of places - don't see a problem leaving
it where it is. It could also go to commons.
>
>
>>instrument
>>instrument-manager
>>instrument-manager-interfaces
>>
>>
>
>I'm continuously confounded by this project. Architecturally it is at
>Framework-level (maybe a step above), and not at all an independent
>component. My random though is this:
>
> instrument -> framework
>
>
Agree in principal - last time I looked there was a lot of additional
documentation needed (instrumentation suite in general).
> instrument-manager
> and -> Merge into one project(?) and keep in excalibur
> instrument-client
>
>
I disagree with the merge suggestion. Instrument manager needs to be
structurally seperated from the transport. This has been done at the
level of the code but not at the level of the build (the build still
depends on AltRMI). Instrument client seems to be transport specific -
for example you will find AltRMI references in things like the menubar
implementation. My guess is that the client could be made transport
indepndent - but I'm confident that the current implementation does not
pass that test.
Personally I think instrumentation should move to sandbox until its
ready for a release.
>
>
>>IO
>>
>>
>
>Leaves Avalon - out of scope.
>
>
Agree.
>
>
>>Logger
>>
>>
>
>Stays.
>
>
>
>>Monitor
>>
>>
>
>No opinion.
>
>
Me neither.
>
>
>>Naming
>>
>>
>
>Leaves Avalon - out of scope.
>
>
There is something going on with a JNDI at Tomcat - a spinoff of a
facility to do similar things. I need to do more checking.
>
>
>>AltRMI
>>
>>
>
>Leaves Avalon - out of scope.
>
>
>
>>AltRMI Registry
>>
>>
>
>Leaves Avalon - out of scope.
>
>
>
>>AltRMI Server (IMpl/Interfaces)
>>
>>
>
>Leaves Avalon - out of scope.
>
>
>
>>Component (AKA ECM)
>>
>>
>
>Deprecate.
>
>// ---------------------------------------------
>
>BRIEF COMMENTS ON EXCALIBUR
>
>Generally, when looking at Excalibur, we have a ton
>of really good stuff - naming, pool, etc. that should
>be in java.util, if I had my way. But while the projects
>are extremely useful, they aren't really components
>in the Avalon sense.
>
>I would very much like to see three things happening with
>Excalibur:
>
> 1. Moving away many things into Commons. Basically,
> any project that is more like a bean or that has
> no Avalon dependencies (naming, io, i18n),
> can go to Commons and be of much more use.
>
+1
>
> 2. A reduction of dependencies.
> We saw a circular dependency brought up by Leo Simons
> a couple of days ago. I think some of the code we have
> can be de-Avalonized and rewritten as beans (Monitor, Cache,
> for example. And why is AltRMI dependent on cornerstone and
> can AltRMI be split into a non-Phoenix part and a Phoenix part?)
> I think we went over this a while ago, having realized that
> there is such a thing as "over-Avalonization".
>
> As for the dependencies, quoting Leo Simons:
>
> http://marc.theaimsgroup.com/?l=avalon-dev&m=104566027617644&w=2
>
> altrmi depends on cornerstone, which depends on datasource,
> which depends on testcase and component, which depend on
> instrument-manager, which has an optional dependency on altrmi.
>
> Which is not good. I wonder if we could layer the
> projects in some way so that projects may only depend on
> projects below them in the layering. The de-avalonization would
> reduce make this much easier. Another approach would be to
> differentiate between build dependencies and runtime/testnig
> dependencies. Build dependencies may not be circular, but if A
> depends on B to compile, but B depends on A for its unit tests,
> then you can compile B, compile A, and *then* test B and A. If
> you don't differentiate between these, you get a circular
> dependency: A -> B -> A ...
>
>
This is all a result of the fact that out current Excalbur build does
not distingish between structural versus tool dependencies. The bulk of
these recursive depndecies exist only because Excalibur Testcase is
includes as a structural dependency. Personally I would like to see a
migration away from Excalibur Testcase in favour of pure JUnit testing.
On a side note - the approach to this in Maven is good - the resources
you need for applying actions in a build are based on plugins that have
their own dependencies which are independent of the dependencies of the
target of the build. This means for example that I can use Merlin to
test a component that may be part of the actual Merlin system without
getting into a dependency issue.
>
> Another thought: Can we clean things up maybe? I noticed that Event
> has its own pool code - to avoid being dependent on pool, I guess.
> But can it instead depend on a de-avalonized excalibur-threadpool?
>
>
I think we couold do a lot of cleaning up - but I also think this needs
to be done after we address the Meven/Centerpede question.
> 3. Consolidation
> Now that we are breaking up framework into interface/impl, could
> we move Excalibur/Configuration and Excalibur/Context into the
> impl part?
>
Excalibur Configuration +1
Excalibur Context - not sure what your referring to.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [Excalibur] Release Path
Posted by "Noel J. Bergman" <no...@devtech.com>.
> >>Naming
> >
> >
> > Leaves Avalon - out of scope.
>
> Going where? There is no clear commons package where
> this would go. Any opinions?
There is org.apache.naming, which deals with JNDI. I haven't looked at the
Naming part of Avalon (where is it?), but org.apache.naming should probably
be moved into Commons, anyway, to be available to other similar
applications. We're starting to review using it in James.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [Excalibur] Release Path
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> What about merging this with Commons Resource?
That would be a good choice. +1 definitively.
> >>Naming
> >
> >
> > Leaves Avalon - out of scope.
>
> Going where? There is no clear commons package where
> this would go. Any opinions?
Don't know really. I'm not alien to proposing a new commons
project - Commons/Naming or something suitable. Basically, I
see all our non-component projects either becoming part of
Commons or being the seed for a new commons project.
The Excalibur/Naming project does provide useful code,
it shouldn't be impossible to find a project with the
proper scope or create one. For Naming, I can imagine
a Commons/J2EE project, or simply a Commons/Naming -
extensions to java.naming and javax.naming.
I have similar thoughts about Monitor (see my [RT] on
layers.)
There is a need for something similar to C++Boost in Java,
and I think Commons might be that. A set of packages that
should really be included in the Java platform (much as
C++Boost should/could/may fills holes in the C++ standard
library).
(Check www.boost.org for more info about boost if you're curious).
> >>AltRMI
> >>AltRMI Registry
> >>AltRMI Server (IMpl/Interfaces)
> >
> >
> > Leaves Avalon - out of scope.
>
> Essentially done. It is in Incubator right now.
Yes, but we still have dependencies going a bit all
over the place...
> I started out with a separate replacement for Pool, which got
> merged into Event. I prefer having Event not depend on
> Threadpool at all because the code has some bugs. I prefer
> to use the better tested Doug Lea utils.
Given that util.concurrent is set to make it into Java1.5,
perhaps dumping threadpool is the best?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Excalibur] Release Path
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>Currently, Cocoon requires the following Excalibur packages:
>>
>>CLI
>
>
> Leaves Avalon - out of scope.
We should be able to do this--Commons CLI has all the same
functionality.
>>Collections
>
>
> Leaves Avalon - out of scope.
Already done--we have a graveyard deprecated sub project still
in CVS
>>Concurrent
>
>
> Leaves Avalon - out of scope.
Same here
>>i18n
>
>
> No opinion.
What about merging this with Commons Resource?
>>IO
>
>
> Leaves Avalon - out of scope.
Commons IO has all this functionality and more.
>>Monitor
>
>
> No opinion.
>
>
>>Naming
>
>
> Leaves Avalon - out of scope.
Going where? There is no clear commons package where
this would go. Any opinions?
>>AltRMI
>>AltRMI Registry
>>AltRMI Server (IMpl/Interfaces)
>
>
> Leaves Avalon - out of scope.
Essentially done. It is in Incubator right now.
>>Component (AKA ECM)
>
>
> Deprecate.
Not yet though. We need to get Fortress out
there first, and provide the proper migration
for ECM based users.
> // ---------------------------------------------
>
> BRIEF COMMENTS ON EXCALIBUR
>
> Generally, when looking at Excalibur, we have a ton
> of really good stuff - naming, pool, etc. that should
> be in java.util, if I had my way. But while the projects
> are extremely useful, they aren't really components
> in the Avalon sense.
>
> I would very much like to see three things happening with
> Excalibur:
>
> 1. Moving away many things into Commons. Basically,
> any project that is more like a bean or that has
> no Avalon dependencies (naming, io, i18n),
> can go to Commons and be of much more use.
I agree.
> 2. A reduction of dependencies.
> We saw a circular dependency brought up by Leo Simons
> a couple of days ago. I think some of the code we have
> can be de-Avalonized and rewritten as beans (Monitor, Cache,
> for example. And why is AltRMI dependent on cornerstone and
> can AltRMI be split into a non-Phoenix part and a Phoenix part?)
> I think we went over this a while ago, having realized that
> there is such a thing as "over-Avalonization".
Cache was started, but never fully finished. There is already a
Commons cache. Things like that need to be looked at and decided
whether we are going to simply drop it or merge it in with something
else that is currently supported.
> As for the dependencies, quoting Leo Simons:
>
> http://marc.theaimsgroup.com/?l=avalon-dev&m=104566027617644&w=2
>
> altrmi depends on cornerstone, which depends on datasource,
> which depends on testcase and component, which depend on
> instrument-manager, which has an optional dependency on altrmi.
>
> Which is not good. I wonder if we could layer the
> projects in some way so that projects may only depend on
> projects below them in the layering. The de-avalonization would
> reduce
> make this much easier. Another approach would be to differentiate
> between
> build dependencies and runtime/testnig dependencies. Build
> dependencies
> may not be circular, but if A depends on B to compile, but B depends
> on
> A for its unit tests, then you can compile B, compile A, and *then*
> test
> B and A. If you don't differentiate between these, you get a
> circular
> dependency: A -> B -> A ...
We do need to consider the layering approach. It is a common diagram
for many API developers. It will make our lives alot easier to
graphically show how the different projects interrelate in layers. It
is very clean, and easy to explain.
> Another thought: Can we clean things up maybe? I noticed that Event
> has its own pool code - to avoid being dependent on pool, I guess.
> But can it instead depend on a de-avalonized excalibur-threadpool?
I started out with a separate replacement for Pool, which got merged
into Event. I prefer having Event not depend on Threadpool at all
because the code has some bugs. I prefer to use the better tested
Doug Lea utils.
> 3. Consolidation
> Now that we are breaking up framework into interface/impl, could we
> move
> Excalibur/Configuration and Excalibur/Context into the impl part?
:)
Yes. I do believe that the breakup is going to be post 4.1.4 release
due to what it will take in CVS restructuring (to do it cleanly).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Instrument interfaces (was Re: [Excalibur] Release Path)
Posted by Peter Royal <pr...@apache.org>.
On Thursday, February 20, 2003, at 01:50 PM, Leo Sutic wrote:
>> instrument
>> instrument-manager
>> instrument-manager-interfaces
>
> I'm continuously confounded by this project. Architecturally it is at
> Framework-level (maybe a step above), and not at all an independent
> component. My random though is this:
>
> instrument -> framework
>
> instrument-manager
> and -> Merge into one project(?) and keep in
> excalibur
> instrument-client
How about putting the instrument interfaces as well as the
InstrumentManager interface into framework?
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [Excalibur] Release Path
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Currently, Cocoon requires the following Excalibur packages:
>
> CLI
Leaves Avalon - out of scope.
> Collections
Leaves Avalon - out of scope.
> Concurrent
Leaves Avalon - out of scope.
> i18n
No opinion.
> instrument
> instrument-manager
> instrument-manager-interfaces
I'm continuously confounded by this project. Architecturally it is at
Framework-level (maybe a step above), and not at all an independent
component. My random though is this:
instrument -> framework
instrument-manager
and -> Merge into one project(?) and keep in excalibur
instrument-client
> IO
Leaves Avalon - out of scope.
> Logger
Stays.
> Monitor
No opinion.
> Naming
Leaves Avalon - out of scope.
> AltRMI
Leaves Avalon - out of scope.
> AltRMI Registry
Leaves Avalon - out of scope.
> AltRMI Server (IMpl/Interfaces)
Leaves Avalon - out of scope.
> Component (AKA ECM)
Deprecate.
// ---------------------------------------------
BRIEF COMMENTS ON EXCALIBUR
Generally, when looking at Excalibur, we have a ton
of really good stuff - naming, pool, etc. that should
be in java.util, if I had my way. But while the projects
are extremely useful, they aren't really components
in the Avalon sense.
I would very much like to see three things happening with
Excalibur:
1. Moving away many things into Commons. Basically,
any project that is more like a bean or that has
no Avalon dependencies (naming, io, i18n),
can go to Commons and be of much more use.
2. A reduction of dependencies.
We saw a circular dependency brought up by Leo Simons
a couple of days ago. I think some of the code we have
can be de-Avalonized and rewritten as beans (Monitor, Cache,
for example. And why is AltRMI dependent on cornerstone and
can AltRMI be split into a non-Phoenix part and a Phoenix part?)
I think we went over this a while ago, having realized that
there is such a thing as "over-Avalonization".
As for the dependencies, quoting Leo Simons:
http://marc.theaimsgroup.com/?l=avalon-dev&m=104566027617644&w=2
altrmi depends on cornerstone, which depends on datasource,
which depends on testcase and component, which depend on
instrument-manager, which has an optional dependency on altrmi.
Which is not good. I wonder if we could layer the
projects in some way so that projects may only depend on
projects below them in the layering. The de-avalonization would
reduce
make this much easier. Another approach would be to differentiate
between
build dependencies and runtime/testnig dependencies. Build
dependencies
may not be circular, but if A depends on B to compile, but B depends
on
A for its unit tests, then you can compile B, compile A, and *then*
test
B and A. If you don't differentiate between these, you get a
circular
dependency: A -> B -> A ...
Another thought: Can we clean things up maybe? I noticed that Event
has its own pool code - to avoid being dependent on pool, I guess.
But can it instead depend on a de-avalonized excalibur-threadpool?
3. Consolidation
Now that we are breaking up framework into interface/impl, could we
move
Excalibur/Configuration and Excalibur/Context into the impl part?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org