You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Jeff Turner <je...@socialchange.net.au> on 2001/12/25 07:59:26 UTC
Re: Synergies between Avalon and Commons projects (was: Re: Breaking Excalibur into smaller swords)
On Mon, Dec 24, 2001 at 10:04:52AM -0500, Berin Loritsch wrote:
> Sam Ruby wrote:
>
> >Berin Loritsch wrote:
> >
> >>I have a feeling when all is said and done we will have the following
> >>distributions:
> >>
> >>excalibur-component.jar (container, component, logmanager)
> >>excalibur-datasource.jar
> >>excalibur-xml.jar (xpath, parser, xslt object, etc.)
> >>excalibur-url.jar (source, resource, etc.)
> >>excalibur-async.jar (monitor, event, etc.)
> >>
> >
> >Don't forget clutil.
> >
> >My two cents: if you have componentry which you are willing to split out
> >that does not have significant dependencies on any particular framework, it
> >will likely get greater visibility and usage if it is in either
> >jakarta-commons or xml-commons.
> >
> >I do believe that people really want to reuse already coded and debugged
> >components. It is when such components come with strings attached that the
> >hesitation begins.
>
>
> Understood, another issue comes when using code not developed with Inversion
> of Control in an environment designed for Inversion of Control. All the
> benefits of that design principal/pattern are lost.
Like using LogKit for non-IoC projects.. awkward compared to log4j.
> The only time you can mix the code is when the environments are sufficiently
> decoupled.
>
> Also, I would like to see some usage stats for Jakarta Commons. Honestly,
> your argument is under the supposition that Commons is more popular or well
> known than Avalon. Arguably, Avalon has had a little more press as we have
> been "advertising" releases to a number of different news portals.
I gather that 'stats' will be part of the new xml.apache.org:
>> The log scanner is a set of scripts that scan the logs from the CVS, the
>> mail lists and the web site to gather information on:
>>
>> 1) mail list activity (subscribers and messages)
>> 2) web site activity (hits and downloads)
>> 3) CVS activity (general commits, commits per person)
Unfortunately there are no mbox archives for Commons when the list was
called 'jakarta-commons' (see http://jakarta.apache.org/mail/).
But some stats anyway:
- In November, commons-dev got 314k traffic (.tar.gz'ed), whereas
avalon-dev + avalon-cvs got 1375k.
- So far in December, commons-dev has 2.2mb, avalon-dev+cvs has 5.8mb.
Looking at my personal archive, since 27/8/2001 when I did a 'mail
roll', here's the size rankings:
-rw------- 1 jeff jeff 43867180 Dec 25 11:09 tomcat-user
-rw------- 1 jeff jeff 37856529 Dec 25 11:09 avalon-dev
-rw------- 1 jeff jeff 35384868 Dec 25 11:09 cocoon-dev
-rw------- 1 jeff jeff 32861870 Dec 25 11:09 struts-user
-rw------- 1 jeff jeff 32397108 Dec 25 11:09 tomcat-dev
-rw------- 1 jeff jeff 26083583 Dec 25 11:09 ant-dev
-rw------- 1 jeff jeff 19062964 Dec 25 11:09 cocoon-users
-rw------- 1 jeff jeff 14521851 Dec 24 22:17 ant-user
-rw------- 1 jeff jeff 14306228 Dec 25 12:40 jakarta-commons
-rw------- 1 jeff jeff 8657045 Dec 25 11:09 struts-dev
-rw------- 1 jeff jeff 7226093 Dec 25 11:09 velocity-user
-rw------- 1 jeff jeff 5030923 Dec 23 16:47 log4j-user
-rw------- 1 jeff jeff 4869238 Dec 22 09:44 taglibs-dev
-rw------- 1 jeff jeff 4388551 Dec 25 11:09 xml-general
-rw------- 1 jeff jeff 2589660 Dec 24 13:04 jakarta-general
-rw------- 1 jeff jeff 1839254 Dec 24 18:10 log4j-dev
-rw------- 1 jeff jeff 1369219 Dec 23 11:07 taglibs-user
-rw------- 1 jeff jeff 257795 Nov 15 21:53 alexandria-dev
So avalon is doing pretty darn well :) *And* that's without the
avalon-apps list, which I forgot to subscribe to until recently.
Of course, a better way to estimate community size is the number of
unique posters to each list. So I wrote a little script to determine
this:
for i in *; do
cat $i | formail -s formail -X"From:" > $i-posters
cat $i-posters | sort | uniq > $i-posters-uniq
done
Here's the revised list:
jeff@expresso:~/Mail/apache$ for i in `ls -S1 *-posters-uniq`; do
> echo `cat $i | wc -l` $i
> done
2491 tomcat-user-posters-uniq
1356 struts-user-posters-uniq
786 cocoon-users-posters-uniq
678 ant-user-posters-uniq
516 tomcat-dev-posters-uniq
322 log4j-user-posters-uniq
317 xml-general-posters-uniq
289 ant-dev-posters-uniq
267 cocoon-dev-posters-uniq
261 velocity-user-posters-uniq
206 struts-dev-posters-uniq
158 jakarta-general-posters-uniq
162 avalon-dev-posters-uniq
159 jakarta-commons-posters-uniq
109 taglibs-user-posters-uniq
106 taglibs-dev-posters-uniq
102 log4j-dev-posters-uniq
21 alexandria-dev-posters-uniq
17 xml-commons-posters-uniq
Avalon is way down.
Conclusion: Avalon is a small project with some *very* prolific
developers :) If there were medals for commitment, Pete, Berin, Paul and
co would be getting them all.
Back to the issue at hand, Avalon and Commons are almost identical in
terms of community size. I'm guessing that Commons people are a much
more eclectic bunch, whereas Avalon's constituency reflects it's Cocoon
roots.
[..]
> There are however a number of utilities that would be easily placed in
> Commons.
> The following packages do not have direct ties to Avalon:
>
> cli (Command Line Interface)
> collections (Buffer and other utilities)
> concurrent (semaphores, mutexes, etc.)
> io (file, stream, and other IO utilities)
> pool (pool interfaces and implementations)
> event (event queues--scratchpad)
> profile (intrumentation of code--scratchpad)
> vfs (virtual file system--scratchpad)
> thread (thread pool--scratchpad, dependant on pool)
> util (various utility classes--scratchpad)
> i18n (ResourceBundle utilities, and an XMLResourceBundle in scratchpad)
>
>
> Those are the only things I can see _possibly_ moving in that direction.
>
> While this does seem like alot, there are also some other things we must
> consider. First and foremost, we would no longer be in control of their
> development life. Because some of these pieces (pooling, thread pooling,
> concurrent, and collections to name a few) are so critical to the way
> things work in Avalon, it is a scary thing to give up that control.
The evolution of Commons has been interesting. I don't think it has met
it's original goal of cross-project sharing, but it has had some hugely
beneficial effects:
- exposing bite-size APIs from existing projects, for public use
(beanutils, digester, httpclient etc)
- acting as a project sandbox, in which established contributors can
publicise previously homeless code, in the hopes of it gaining a
community (latka, jxpath, etc). It's become a jakarta-flavoured
mini-sourceforge, and that's a *good* thing.
So in practice, I think the only effect of moving code from Avalon to
Commons would be to expose it to a different, same-sized, but more
diverse, audience of users, implicitly acting as advertising for Avalon
(which is still rather insular IMHO).
It would be highly unlikely that "we" lose control, any more than James
could lose control of jxpath, or MorganD/RodW lose control of latka.
Of course, it *could* happen, and did happen in the case of httpclient,
where the API got changed under the feet of the Slide people. In that
case, we do what Remy &co. did; complain :) And it all got sorted
in the end.
> Some things like CLI might make a good contribution, and someone may really
> improve the internal architecture, and parameter parsing capabilities (i.e.
> make it able to interpret GNU style parameters, POV-Ray style parameters,
> etc).
James Strachan recently committed werken.opt to the Commons sandbox,
illustrating that if Avalon doesn't take the initiative by moving stuff
to Commons, code will materialize from somewhere else. Take a look at:
http://jakarta.apache.org/~jvanzyl/stratum-proposal.txt
cache, configuration, lifecycle, pipeline, pool... it's like a second
Excalibur, only without the IoC emphasis.
> The problem is that if the interfaces change, that change will affect a
> number of different projects: Phoenix, Cocoon, Axis, and JAMES to name
> a few.
>
> I would like to get the concensus of the Avalon team before considering
> such a move. That move will change the package names (allowing us to get
> rid of cruft and remove deprecated methods and classes in the process).
>
> Here are the issues I see with this move:
>
> 1) I personally don't have the energy/time to support yet another project,
> but I can support these utilities where they are now.
> 2) I already receive over 125 emails between 5:00pm and 8:30am the next
> morning due to the mailing lists I subscribe to. Another list with all
> the associated noise is not really feasible.
Commons gets significantly less mail than Avalon. 14 messages/day,
including CVS commits.
> 3) These utilities could possibly die in commons, where they would survive
> in Avalon.
They'd only die if Avalon people abandon them. Otherwise, exposure to a
different user group can only be beneficial for the code in question.
Interface stability is the thing to watch, though.
> 4) Commons could so tightly integrate the utilities that they no longer
> able to be used without additional cruft we have no interest in.
We'd have to get the Avalon logging interfaces accepted in
jakarta-commons/logging, or there'd be immediate conflict. Other than
that, I think Commons subprojects are quite self-contained.
It's very much up to the people at the top of Avalon's (very steep)
meritocracy :)
--Jeff
> Admittedly, some of these are FUD on my part, but they are real
> concerns that I have, and they need to be allayed before I can support
> a decision to move Avalon code outside of Avalon. All the other
> pieces are either Avalon Components, or support the Avalon
> architecture, so they will never be considered for integration with
> Commons.
>
> --
>
> "They that give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synergies between Avalon and Commons projects (was: Re:
Breaking Excalibur into smaller swords)
Posted by Jason van Zyl <jv...@zenplex.com>.
On 12/29/01 12:15 AM, "Peter Donald" <pe...@apache.org> wrote:
> On Thu, 27 Dec 2001 02:29, Jason van Zyl wrote:
>>> When I see multiple projects all with similar lifecycles, using different
>>> libraries, and thus uncompatible it makes me sick.
>>
>> C'mon, you guys have done the _exact_ same thing. Logging, pooling,
>> database connection pooling, configurations. Lots of these things existed
>> elsewhere but you wanted to try the IoC pattern with things and maybe some
>> of these existing components weren't 100% usable in their existing form but
>> I don't think anyone went out of their way really to try and work on these
>> other packages to make them fit into avalon.
>
> you would be surprised. I wasn't around at the start of Avalon but when me
> and Berin joined up there was several moves to reuse existing infrastructure.
> JDom for config, JNDI instead of ComponentManager, Log4j instead of LogKit,
> etc. In some cases they didn't suite and we couldn't change (ie JNDI). In
> both JDOM and Log4j I tried to get the developers to adopt changes to make
> them suitable for our use but in both cases the authors refused or botched
> the suggestions. We got nowhere and down the track Ceki ends up calling me a
> liar and a thief.
Not touching that one with a ten foot pole.
> Don't be so sure that we (or at least I) haven't tried to work with these
> other packages. Sometimes there was different aims between packages and
> sometimes it has been difficult people running them. In all cases it was
> cheaper to work without interaction and it produced a better framework in the
> end.
>
>> Don't be
>> surprised if the whole of avalon is rebuilt in the commons in little pieces
>> because it's going to happen.
>
> and quite a few people encourage it.
>
>> I have something nifty that I want to try in stratum and then I hope to put
>> all the pieces into the commons. I don't think stratum has a long life
>> expectancy but I need it to refactor Turbine. But in the long run I think
>> people are going to look toward the commons for components.
>
> I think Berin was irritated because you are going to push it into another
> project.
I don't see that as anything to get upset about.
> As I suspect you understand rarely is anything as temporary as
> people think and it is highly likely that it will end up living on - <insert
> obligatory SNMP was only a temp spec but look at it now story>. Given how
> close parts are likely to be to Avalon/Framework ...
Stratum hasn't gone into a repository yet and pieces that were in stratum
have already gone into the commons. The graph package is an example of that.
I realize that software that is released tends to stick around and linger,
but before turbine 3 is released I plan to move everything into the commons.
> Think of it this way. Currently I have a fork of velocity sitting on my
> hardisk as it didn't provide what I was after - namely a dynamic
> invocation/bean api (similar to that which is in almost every script language
> and present in other templating languages). When I finally upload phoenixs
> management console I doubt you would aprove if I also uploaded "raptor" a
> clone of velocity with the changes made that I needed made.
Honestly, that wouldn't bother me at all. If you need to add things so that
it works the way you need than I'm glad that the base code was a useful
start for what you needed. I have never chastised anyone for taking a piece
of code and modifying and even offering it to others to use. If you put
raptor in CVS it wouldn't bother me one iota.
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synergies between Avalon and Commons projects (was: Re: Breaking Excalibur into smaller swords)
Posted by Peter Donald <pe...@apache.org>.
On Thu, 27 Dec 2001 02:29, Jason van Zyl wrote:
> > When I see multiple projects all with similar lifecycles, using different
> > libraries, and thus uncompatible it makes me sick.
>
> C'mon, you guys have done the _exact_ same thing. Logging, pooling,
> database connection pooling, configurations. Lots of these things existed
> elsewhere but you wanted to try the IoC pattern with things and maybe some
> of these existing components weren't 100% usable in their existing form but
> I don't think anyone went out of their way really to try and work on these
> other packages to make them fit into avalon.
you would be surprised. I wasn't around at the start of Avalon but when me
and Berin joined up there was several moves to reuse existing infrastructure.
JDom for config, JNDI instead of ComponentManager, Log4j instead of LogKit,
etc. In some cases they didn't suite and we couldn't change (ie JNDI). In
both JDOM and Log4j I tried to get the developers to adopt changes to make
them suitable for our use but in both cases the authors refused or botched
the suggestions. We got nowhere and down the track Ceki ends up calling me a
liar and a thief.
Don't be so sure that we (or at least I) haven't tried to work with these
other packages. Sometimes there was different aims between packages and
sometimes it has been difficult people running them. In all cases it was
cheaper to work without interaction and it produced a better framework in the
end.
> Don't be
> surprised if the whole of avalon is rebuilt in the commons in little pieces
> because it's going to happen.
and quite a few people encourage it.
> I have something nifty that I want to try in stratum and then I hope to put
> all the pieces into the commons. I don't think stratum has a long life
> expectancy but I need it to refactor Turbine. But in the long run I think
> people are going to look toward the commons for components.
I think Berin was irritated because you are going to push it into another
project. As I suspect you understand rarely is anything as temporary as
people think and it is highly likely that it will end up living on - <insert
obligatory SNMP was only a temp spec but look at it now story>. Given how
close parts are likely to be to Avalon/Framework ...
Think of it this way. Currently I have a fork of velocity sitting on my
hardisk as it didn't provide what I was after - namely a dynamic
invocation/bean api (similar to that which is in almost every script language
and present in other templating languages). When I finally upload phoenixs
management console I doubt you would aprove if I also uploaded "raptor" a
clone of velocity with the changes made that I needed made.
--
Cheers,
Pete
*------------------------------------------------------*
| Despite your efforts to be a romantic hero, you will |
| gradually evolve into a postmodern plot device. |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synergies between Avalon and Commons projects (was: Re:
Breaking Excalibur into smaller swords)
Posted by Jason van Zyl <jv...@zenplex.com>.
On 12/26/01 8:42 AM, "Berin Loritsch" <bl...@apache.org> wrote:
>>
>> James Strachan recently committed werken.opt to the Commons sandbox,
>> illustrating that if Avalon doesn't take the initiative by moving stuff
>> to Commons, code will materialize from somewhere else. Take a look at:
>>
>> http://jakarta.apache.org/~jvanzyl/stratum-proposal.txt
>>
>> cache, configuration, lifecycle, pipeline, pool... it's like a second
>> Excalibur, only without the IoC emphasis.
>
>
> Ok, that I do *not* understand. We already have a framework project, and
> that's Avalon. If the authors want to work on a framework work on this
> one.
Who is we? After the Jserv project both Avalon and Turbine were started and
continued down their own paths. Do we not have a right to pursue what we
think a framework should be? I have some thoughts and designs that I would
like to try that might not necessarily fit in with Avalon. I am not going to
stop and try and make everything work with Avalon right off the bat.
And Avalon did not start as a general framework, it started as a server
framework and has slowly started changing it's charter over time to subsume
more and more just as Turbine has. At the moment I want to work on Turbine
not Avalon. All the code that will be pulled into stratum is code that I've
refactored and pulled out of the original turbine code base. I'm not going
to toss it all and start using Avalon.
> When I see multiple projects all with similar lifecycles, using different
> libraries, and thus uncompatible it makes me sick.
C'mon, you guys have done the _exact_ same thing. Logging, pooling, database
connection pooling, configurations. Lots of these things existed elsewhere
but you wanted to try the IoC pattern with things and maybe some of these
existing components weren't 100% usable in their existing form but I don't
think anyone went out of their way really to try and work on these other
packages to make them fit into avalon.
Now don't get me wrong, I have done the same thing in many cases myself
because it was easier to make things fit and I too didn't want to give up
control over the development of a particular component. But don't try and
tell me that Avalon has the only legitimate claim to being a framework
around here because that's just nonsense. Competition is good, diversity of
ideas is good even at the cost of the replication.
Lots of people don't want to use Avalon, even more probably don't want to
use Turbine and competing packages are showing up everywhere here and that's
the way it is. There's a new services package in the commons which I'm sure
will spawn some sort of lifecycle and configuration as always happens. That
doesn't bother me at all.
I know why people don't want to use Turbine and I honestly rarely recommend
using it because it's not for the faint of heart right now. If someone can
get the job done easier with something else like Struts than all the power
to them. Turbine exacts a high toll in terms of forcing people into a lot of
patterns (some that aren't very good I admit) and Avalon does the exact same
thing which is why many turn to the commons for components. Don't be
surprised if the whole of avalon is rebuilt in the commons in little pieces
because it's going to happen.
I have something nifty that I want to try in stratum and then I hope to put
all the pieces into the commons. I don't think stratum has a long life
expectancy but I need it to refactor Turbine. But in the long run I think
people are going to look toward the commons for components.
I think I share with you the philosophy of providing a consistent mechanism
for develop WRT to components and methodologies all wrapped up in one
package but I am always arguing with people about this. I like my arguments
with Geir because he often counters my sometimes monolithic approach to
things. I am honestly trying to provide a consistent development environment
in Turbine just as you are in Avalon but it's a monumental task. Plus I
think that around here people are more like us anyway and are going to take
the bits and pieces and roll their own systems. And the components in the
commons make this easier so it's something I'm definitely rethinking.
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synergies between Avalon and Commons projects (was: Re:
Breaking Excalibur into smaller swords)
Posted by Jason van Zyl <jv...@zenplex.com>.
On 12/26/01 8:42 AM, "Berin Loritsch" <bl...@apache.org> wrote:
>>
>> James Strachan recently committed werken.opt to the Commons sandbox,
>> illustrating that if Avalon doesn't take the initiative by moving stuff
>> to Commons, code will materialize from somewhere else. Take a look at:
>>
>> http://jakarta.apache.org/~jvanzyl/stratum-proposal.txt
>>
>> cache, configuration, lifecycle, pipeline, pool... it's like a second
>> Excalibur, only without the IoC emphasis.
>
>
> Ok, that I do *not* understand. We already have a framework project, and
> that's Avalon. If the authors want to work on a framework work on this
> one.
Who is we? After the Jserv project both Avalon and Turbine were started and
continued down their own paths. Do we not have a right to pursue what we
think a framework should be? I have some thoughts and designs that I would
like to try that might not necessarily fit in with Avalon. I am not going to
stop and try and make everything work with Avalon right off the bat.
And Avalon did not start as a general framework, it started as a server
framework and has slowly started changing it's charter over time to subsume
more and more just as Turbine has. At the moment I want to work on Turbine
not Avalon. All the code that will be pulled into stratum is code that I've
refactored and pulled out of the original turbine code base. I'm not going
to toss it all and start using Avalon.
> When I see multiple projects all with similar lifecycles, using different
> libraries, and thus uncompatible it makes me sick.
C'mon, you guys have done the _exact_ same thing. Logging, pooling, database
connection pooling, configurations. Lots of these things existed elsewhere
but you wanted to try the IoC pattern with things and maybe some of these
existing components weren't 100% usable in their existing form but I don't
think anyone went out of their way really to try and work on these other
packages to make them fit into avalon.
Now don't get me wrong, I have done the same thing in many cases myself
because it was easier to make things fit and I too didn't want to give up
control over the development of a particular component. But don't try and
tell me that Avalon has the only legitimate claim to being a framework
around here because that's just nonsense. Competition is good, diversity of
ideas is good even at the cost of the replication.
Lots of people don't want to use Avalon, even more probably don't want to
use Turbine and competing packages are showing up everywhere here and that's
the way it is. There's a new services package in the commons which I'm sure
will spawn some sort of lifecycle and configuration as always happens. That
doesn't bother me at all.
I know why people don't want to use Turbine and I honestly rarely recommend
using it because it's not for the faint of heart right now. If someone can
get the job done easier with something else like Struts than all the power
to them. Turbine exacts a high toll in terms of forcing people into a lot of
patterns (some that aren't very good I admit) and Avalon does the exact same
thing which is why many turn to the commons for components. Don't be
surprised if the whole of avalon is rebuilt in the commons in little pieces
because it's going to happen.
I have something nifty that I want to try in stratum and then I hope to put
all the pieces into the commons. I don't think stratum has a long life
expectancy but I need it to refactor Turbine. But in the long run I think
people are going to look toward the commons for components.
I think I share with you the philosophy of providing a consistent mechanism
for develop WRT to components and methodologies all wrapped up in one
package but I am always arguing with people about this. I like my arguments
with Geir because he often counters my sometimes monolithic approach to
things. I am honestly trying to provide a consistent development environment
in Turbine just as you are in Avalon but it's a monumental task. Plus I
think that around here people are more like us anyway and are going to take
the bits and pieces and roll their own systems. And the components in the
commons make this easier so it's something I'm definitely rethinking.
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synergies between Avalon and Commons projects (was: Re: Breaking Excalibur into smaller swords)
Posted by Berin Loritsch <bl...@apache.org>.
Jeff Turner wrote:
> On Mon, Dec 24, 2001 at 10:04:52AM -0500, Berin Loritsch wrote:
>
>>Sam Ruby wrote:
>>
>>
>>>Berin Loritsch wrote:
>>>
>>>
>>>>I have a feeling when all is said and done we will have the following
>>>>distributions:
>>>>
>>>>excalibur-component.jar (container, component, logmanager)
>>>>excalibur-datasource.jar
>>>>excalibur-xml.jar (xpath, parser, xslt object, etc.)
>>>>excalibur-url.jar (source, resource, etc.)
>>>>excalibur-async.jar (monitor, event, etc.)
>>>>
>>>>
>>>Don't forget clutil.
>>>
>>>My two cents: if you have componentry which you are willing to split out
>>>that does not have significant dependencies on any particular framework, it
>>>will likely get greater visibility and usage if it is in either
>>>jakarta-commons or xml-commons.
>>>
>>>I do believe that people really want to reuse already coded and debugged
>>>components. It is when such components come with strings attached that the
>>>hesitation begins.
>>>
>>
>>Understood, another issue comes when using code not developed with Inversion
>>of Control in an environment designed for Inversion of Control. All the
>>benefits of that design principal/pattern are lost.
>>
>
> Like using LogKit for non-IoC projects.. awkward compared to log4j.
They are different mindsets. But it is more awkward trying to force Log4J into
the IoC pattern--because you have to hide all the different access points that
it gives you.
>>The only time you can mix the code is when the environments are sufficiently
>>decoupled.
>>
>>Also, I would like to see some usage stats for Jakarta Commons. Honestly,
>>your argument is under the supposition that Commons is more popular or well
>>known than Avalon. Arguably, Avalon has had a little more press as we have
>>been "advertising" releases to a number of different news portals.
>>
>
> I gather that 'stats' will be part of the new xml.apache.org:
It is something that they are working towards.
> Of course, a better way to estimate community size is the number of
> unique posters to each list. So I wrote a little script to determine
> this:
> 159 jakarta-commons-posters-uniq
>
> Avalon is way down.
>
> Conclusion: Avalon is a small project with some *very* prolific
> developers :) If there were medals for commitment, Pete, Berin, Paul and
> co would be getting them all.
>
> Back to the issue at hand, Avalon and Commons are almost identical in
> terms of community size. I'm guessing that Commons people are a much
> more eclectic bunch, whereas Avalon's constituency reflects it's Cocoon
> roots.
To be more precise, it is the other way around. Avalon was first, and
Cocoon had a snapshot of Avalon being in it's CVS.
> The evolution of Commons has been interesting. I don't think it has met
> it's original goal of cross-project sharing, but it has had some hugely
> beneficial effects:
:) It seems that Avalon hasn't either. Avalon's charter was to be the
architectural core of all server side Apache projects--it succeeded for
some projects, but not for others.
> - exposing bite-size APIs from existing projects, for public use
> (beanutils, digester, httpclient etc)
I have no problems with exposing "bite-size" APIs--which is why I gave
the list I did.
> - acting as a project sandbox, in which established contributors can
> publicise previously homeless code, in the hopes of it gaining a
> community (latka, jxpath, etc). It's become a jakarta-flavoured
> mini-sourceforge, and that's a *good* thing.
I know alot of people who would be on both sides of that argument. :).
> So in practice, I think the only effect of moving code from Avalon to
> Commons would be to expose it to a different, same-sized, but more
> diverse, audience of users, implicitly acting as advertising for Avalon
> (which is still rather insular IMHO).
That's not for a lack of trying.
> It would be highly unlikely that "we" lose control, any more than James
> could lose control of jxpath, or MorganD/RodW lose control of latka.
>
> Of course, it *could* happen, and did happen in the case of httpclient,
> where the API got changed under the feet of the Slide people. In that
> case, we do what Remy &co. did; complain :) And it all got sorted
> in the end.
That's a headache that *I* don't want to deal with. However, I listed the
packages so that the Avalon committers can *vote* on whether we want to
take this action.
>>Some things like CLI might make a good contribution, and someone may really
>>improve the internal architecture, and parameter parsing capabilities (i.e.
>>make it able to interpret GNU style parameters, POV-Ray style parameters,
>>etc).
>>
>
> James Strachan recently committed werken.opt to the Commons sandbox,
> illustrating that if Avalon doesn't take the initiative by moving stuff
> to Commons, code will materialize from somewhere else. Take a look at:
>
> http://jakarta.apache.org/~jvanzyl/stratum-proposal.txt
>
> cache, configuration, lifecycle, pipeline, pool... it's like a second
> Excalibur, only without the IoC emphasis.
Ok, that I do *not* understand. We already have a framework project, and
that's Avalon. If the authors want to work on a framework work on this
one.
When I see multiple projects all with similar lifecycles, using different
libraries, and thus uncompatible it makes me sick.
>>The problem is that if the interfaces change, that change will affect a
>>number of different projects: Phoenix, Cocoon, Axis, and JAMES to name
>>a few.
>>
>>I would like to get the concensus of the Avalon team before considering
>>such a move. That move will change the package names (allowing us to get
>>rid of cruft and remove deprecated methods and classes in the process).
>>
>>Here are the issues I see with this move:
>>
>>1) I personally don't have the energy/time to support yet another project,
>> but I can support these utilities where they are now.
>>2) I already receive over 125 emails between 5:00pm and 8:30am the next
>> morning due to the mailing lists I subscribe to. Another list with all
>> the associated noise is not really feasible.
>>
>
> Commons gets significantly less mail than Avalon. 14 messages/day,
> including CVS commits.
I already spend an hour a day answering Apache mail--and that's ignoring a
bulk of it due to time constraints. I don't have the time to _police_ the
mails and make sure noone is talking about changing the Avalon originated
utilties' API.
>>3) These utilities could possibly die in commons, where they would survive
>> in Avalon.
>>
>
> They'd only die if Avalon people abandon them. Otherwise, exposure to a
> different user group can only be beneficial for the code in question.
So you just made my argument for me.
Excalibur code is exposed to another rather large group (Cocoon), it is also
rather well tested because of the number of users in that group.
>
> Interface stability is the thing to watch, though.
And that is my biggest concern. If you can succeddfully allay that fear,
I might champion the move.
>
>
>>4) Commons could so tightly integrate the utilities that they no longer
>> able to be used without additional cruft we have no interest in.
>>
>
> We'd have to get the Avalon logging interfaces accepted in
> jakarta-commons/logging, or there'd be immediate conflict. Other than
> that, I think Commons subprojects are quite self-contained.
The Logging interfaces are going to be fiercely guarded. If *any* additional
method is proposed for the logger--it will be strongly recommended that it
be a new interface.
> It's very much up to the people at the top of Avalon's (very steep)
> meritocracy :)
It's not that steep, it just seems that way. We have rough edges with our
personalities, and sometimes that scares people off.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synergies between Avalon and Commons projects (was: Re: Breaking Excalibur into smaller swords)
Posted by Berin Loritsch <bl...@apache.org>.
Jeff Turner wrote:
> On Mon, Dec 24, 2001 at 10:04:52AM -0500, Berin Loritsch wrote:
>
>>Sam Ruby wrote:
>>
>>
>>>Berin Loritsch wrote:
>>>
>>>
>>>>I have a feeling when all is said and done we will have the following
>>>>distributions:
>>>>
>>>>excalibur-component.jar (container, component, logmanager)
>>>>excalibur-datasource.jar
>>>>excalibur-xml.jar (xpath, parser, xslt object, etc.)
>>>>excalibur-url.jar (source, resource, etc.)
>>>>excalibur-async.jar (monitor, event, etc.)
>>>>
>>>>
>>>Don't forget clutil.
>>>
>>>My two cents: if you have componentry which you are willing to split out
>>>that does not have significant dependencies on any particular framework, it
>>>will likely get greater visibility and usage if it is in either
>>>jakarta-commons or xml-commons.
>>>
>>>I do believe that people really want to reuse already coded and debugged
>>>components. It is when such components come with strings attached that the
>>>hesitation begins.
>>>
>>
>>Understood, another issue comes when using code not developed with Inversion
>>of Control in an environment designed for Inversion of Control. All the
>>benefits of that design principal/pattern are lost.
>>
>
> Like using LogKit for non-IoC projects.. awkward compared to log4j.
They are different mindsets. But it is more awkward trying to force Log4J into
the IoC pattern--because you have to hide all the different access points that
it gives you.
>>The only time you can mix the code is when the environments are sufficiently
>>decoupled.
>>
>>Also, I would like to see some usage stats for Jakarta Commons. Honestly,
>>your argument is under the supposition that Commons is more popular or well
>>known than Avalon. Arguably, Avalon has had a little more press as we have
>>been "advertising" releases to a number of different news portals.
>>
>
> I gather that 'stats' will be part of the new xml.apache.org:
It is something that they are working towards.
> Of course, a better way to estimate community size is the number of
> unique posters to each list. So I wrote a little script to determine
> this:
> 159 jakarta-commons-posters-uniq
>
> Avalon is way down.
>
> Conclusion: Avalon is a small project with some *very* prolific
> developers :) If there were medals for commitment, Pete, Berin, Paul and
> co would be getting them all.
>
> Back to the issue at hand, Avalon and Commons are almost identical in
> terms of community size. I'm guessing that Commons people are a much
> more eclectic bunch, whereas Avalon's constituency reflects it's Cocoon
> roots.
To be more precise, it is the other way around. Avalon was first, and
Cocoon had a snapshot of Avalon being in it's CVS.
> The evolution of Commons has been interesting. I don't think it has met
> it's original goal of cross-project sharing, but it has had some hugely
> beneficial effects:
:) It seems that Avalon hasn't either. Avalon's charter was to be the
architectural core of all server side Apache projects--it succeeded for
some projects, but not for others.
> - exposing bite-size APIs from existing projects, for public use
> (beanutils, digester, httpclient etc)
I have no problems with exposing "bite-size" APIs--which is why I gave
the list I did.
> - acting as a project sandbox, in which established contributors can
> publicise previously homeless code, in the hopes of it gaining a
> community (latka, jxpath, etc). It's become a jakarta-flavoured
> mini-sourceforge, and that's a *good* thing.
I know alot of people who would be on both sides of that argument. :).
> So in practice, I think the only effect of moving code from Avalon to
> Commons would be to expose it to a different, same-sized, but more
> diverse, audience of users, implicitly acting as advertising for Avalon
> (which is still rather insular IMHO).
That's not for a lack of trying.
> It would be highly unlikely that "we" lose control, any more than James
> could lose control of jxpath, or MorganD/RodW lose control of latka.
>
> Of course, it *could* happen, and did happen in the case of httpclient,
> where the API got changed under the feet of the Slide people. In that
> case, we do what Remy &co. did; complain :) And it all got sorted
> in the end.
That's a headache that *I* don't want to deal with. However, I listed the
packages so that the Avalon committers can *vote* on whether we want to
take this action.
>>Some things like CLI might make a good contribution, and someone may really
>>improve the internal architecture, and parameter parsing capabilities (i.e.
>>make it able to interpret GNU style parameters, POV-Ray style parameters,
>>etc).
>>
>
> James Strachan recently committed werken.opt to the Commons sandbox,
> illustrating that if Avalon doesn't take the initiative by moving stuff
> to Commons, code will materialize from somewhere else. Take a look at:
>
> http://jakarta.apache.org/~jvanzyl/stratum-proposal.txt
>
> cache, configuration, lifecycle, pipeline, pool... it's like a second
> Excalibur, only without the IoC emphasis.
Ok, that I do *not* understand. We already have a framework project, and
that's Avalon. If the authors want to work on a framework work on this
one.
When I see multiple projects all with similar lifecycles, using different
libraries, and thus uncompatible it makes me sick.
>>The problem is that if the interfaces change, that change will affect a
>>number of different projects: Phoenix, Cocoon, Axis, and JAMES to name
>>a few.
>>
>>I would like to get the concensus of the Avalon team before considering
>>such a move. That move will change the package names (allowing us to get
>>rid of cruft and remove deprecated methods and classes in the process).
>>
>>Here are the issues I see with this move:
>>
>>1) I personally don't have the energy/time to support yet another project,
>> but I can support these utilities where they are now.
>>2) I already receive over 125 emails between 5:00pm and 8:30am the next
>> morning due to the mailing lists I subscribe to. Another list with all
>> the associated noise is not really feasible.
>>
>
> Commons gets significantly less mail than Avalon. 14 messages/day,
> including CVS commits.
I already spend an hour a day answering Apache mail--and that's ignoring a
bulk of it due to time constraints. I don't have the time to _police_ the
mails and make sure noone is talking about changing the Avalon originated
utilties' API.
>>3) These utilities could possibly die in commons, where they would survive
>> in Avalon.
>>
>
> They'd only die if Avalon people abandon them. Otherwise, exposure to a
> different user group can only be beneficial for the code in question.
So you just made my argument for me.
Excalibur code is exposed to another rather large group (Cocoon), it is also
rather well tested because of the number of users in that group.
>
> Interface stability is the thing to watch, though.
And that is my biggest concern. If you can succeddfully allay that fear,
I might champion the move.
>
>
>>4) Commons could so tightly integrate the utilities that they no longer
>> able to be used without additional cruft we have no interest in.
>>
>
> We'd have to get the Avalon logging interfaces accepted in
> jakarta-commons/logging, or there'd be immediate conflict. Other than
> that, I think Commons subprojects are quite self-contained.
The Logging interfaces are going to be fiercely guarded. If *any* additional
method is proposed for the logger--it will be strongly recommended that it
be a new interface.
> It's very much up to the people at the top of Avalon's (very steep)
> meritocracy :)
It's not that steep, it just seems that way. We have rough edges with our
personalities, and sometimes that scares people off.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synergies between Avalon and Commons projects (was: Re: Breaking Excalibur into smaller swords)
Posted by Peter Donald <pe...@apache.org>.
On Tue, 25 Dec 2001 17:59, Jeff Turner wrote:
> Of course, it *could* happen, and did happen in the case of httpclient,
> where the API got changed under the feet of the Slide people. In that
> case, we do what Remy &co. did; complain :) And it all got sorted
> in the end.
Thats the problem. Remy had to do oodles more work for relatively little
benefit in the end. I am not sure if I was subscribed for the whole thing but
I recall that it went on for ages where Slide was broken enough that they
ended up forking back to original code. I have enough work on my plate as it
is and have no want to add more work.
--
Cheers,
Pete
*---------------------------------------------------------*
| Programming today is a race between software engineers |
| striving to build bigger and better idiot-proof |
| programs,and the universe trying to produce bigger and |
| better idiots. So far, the universe is winning. |
| - Richard Cook |
*---------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>