Sam Ruby wrote:
Berin Loritsch wrote:
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.
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.
Is that my argument? If so, I don't recognize it.
Then what exactly *is* your argument?
This is only one data point, and anecdotal at that, but Axis has a small -
one class - command line utility package. You suggested that Avalon
Excalibur be used instead. The initial reaction was that that was
significantly overkill. You succeeded by being able to demonstrate that
the component was, in fact, decoupled.
I am still trying to convince the Axis group that it is more beneficial to
use a tried and tested architecture instead of reinventing their own--which
is frustrating as hell. I can't *make* them do it, but I can *help* them
do it.
Avalon Framework is not significantly overkill for that project, and it can
really help them in the long run. However, it's not easy convincing the crew.
I tried advocating to someone respected in the Apache/Cocoon project that
instead of creating his own wrapper for SOAP objects, he should let Axis handle
that--then I got involved with the project.
I see that "victory" as only one step toward the final goal.
My argument is that small, decoupled components will see greater use than
large tightly coupled components.
Hense the awareness that I am bringing to the Avalon group about Excalibur
being packaged in smaller separate jars (as well as the large monolithic one).
Excalibur's purpose is to provide Components and utilities that assist in
server side programming. It was that way *before* commons was concidered.
So if there are any frictions, it is of the PMC's own doing.
Inside the avalon family of cvs trees there are such components. However,
by virtue in their placement in an Avalon cvs tree, the perception is that
the emphasis is on the integration instead of the reuse potential.
Perhaps that is due to the ardent evangelizing we do of our own projects.
Taken as a whole, Avalon is incredibly flexible, scalable, and well architected.
When I see something in Jakarta Commons, I don't get that same warm fuzzy.
Of course, I've never depended on Jakarta Commons for anything yet.
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.
Get over it. ;-)
One thing for sure, I can alert you - generally within 24 hours - after
such a change goes into development. That should give you plenty of
opportunity to block incompatible changes from ever making it into a
release.
Hey, I'm being honest with you. I can assure you that nothing will happen
in this direction without the approval of the Avalon committers. I'm not
the only one to convince--but I *can* be convinced.
You have been invaluable in assisting us in creating a project that has a
stable API, and that is very much appreciated.
1) I personally don't have the energy/time to support yet another project,
but I can support these utilities where they are now.
Let me get this straight - if "x" is renamed to "y" you have time, but if
it is renamed to "z", you don't? The argument seems specious to me.
Get off your high horse on this. There is *alot* more than a simple package
rename involved in supporting a project. There are user questions,
documentation (since many of them only have javadocs), developer questions,
defending the API, etc.
Since I can't spend 40 hours a week on Apache stuff anymore, I have to scale
back--which right now means that my focus is on Avalon alone. I am lending
email support to Cocoon right now, but I don't have the time to support them
with code right now.
There are several projects in Apache, like Ant and Cocoon, that would
clearly survive if the top leader or three were to all disappear. There
are others, like Gump and parts of Avalon, that exist by the sole virtue of
a single person - or at most a small number of people's - dedication.
We need to continue to strive to find ways to convert projects of the
latter type into the former.
Again, not for a lack of trying. But people who are stuck in their ways
are hard to convince--and that is on both sides of this conversation.
I admit that, and I expect the same admission from you (or you are deceiving
yourself).
3) These utilities could possibly die in commons, where they would survive
in Avalon.
The reverse is also true. Generally, the place where the code can gather
the largest community is the one with the best odds for success.
Mmhmm.
So there is Avalon (admittedly small), Cocoon (admittedly large), JAMES,
Jesktop, FOP, and others not under the Apache billing. That's not large
enough?
There is alot of utility code that is clearly beneficial, but little interest
will be garnered by their submission to Commons.
This may be unfounded, and it may be, I don't know, but when I see Commons,
I see a bunch of disjunct and possibly competing code. When I see Avalon,
it has a consistent focus and feel to it. It actually *helps* development.
Again, this is coming from someone who has never messed with Commons code,
so take my opinion (and that's what it is) with a grain of salt.
4) Commons could so tightly integrate the utilities that they no longer
able to be used without additional cruft we have no interest in.
That is essentially against the charter of Commons. However, well within
the charter of Avalon, which is why I would suggest that a move to commons
might allay some people's fears and increase the size of the community.
But clearly this should only be contemplated for small, decoupleable
components.
Could you more expound on these fears toward Avalon that you are aware of,
since I was honest and forthcoming enough to share the ones I have toward
Commons?
Do I want to increase the Avalon community? Definitely! I don't see how
moving Avalon code outside of Avalon increases *Avalon's* community. I can
see how it increases *Commons* community.
Perhaps the smaller swords will be all that is needed.
Personally, I think that anything which increases the use of Avalon
compatible components will only benefit the Avalon community.
Definition of Avalon compatible components (since it is Component based):
Components use the Avalon lifecycle interfaces and the Component marker
interface. If the component complies with these requirements, it is
Avalon compatible.
_Anything_ else is not a _Component_, it is a utility or class.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
