In this email, I address two concerns:
1) policy for promoting commons-sandbox to commons
2) the general direction of Jakarta
1) ON POLICY FOR COMMONS
This is a general observation, and not made with respect to the ARMI
proposal itself, but about project organisation at Jakarta.
On Wed, 9 Jan 2002, Geir Magnusson Jr. wrote:
> The point of the sandbox is to build/introduce something and see if it as a
> project can get momentum, build a community, get a clear picture if there is
> enough interest behind something to bring to Commons with the expectation of
> success towards a release, not just a 'dressing room...'
The point about commons not being a 'dressing room' is good.
However, there is an obvious tension:
1. projects are encouraged to componentise and make facilities
reusable
2. 'baby components' start in commons-sandbox, and don't get promoted
to maturity in commons until there are 'enough' committers.
3. projects should only rely on mature components in commons
So it seems like the path to spinning a good idea into the commons is
going to mean maintaining 2 separate codebases for the same idea for a
while ( one in the project, one in the sandbox ), until the comitter
community catches up and it can become one codebase ( in the commons )?
I don't think the right place to nip this cyclical dependency is to
rush maybe-good ideas to premature 'maturity'. But maybe something
else could change?
Perhaps the maturity distinction could be based on:
sandbox/immature: only 1 PROJECT using it
commons/mature: more than 1 project using it
and constraint 3 relaxed?
( ie. maturity based on actual dependencies, rather than a raw count of
comitters ... the support needed to ensure its continued existence is
pretty much guaranteed if 2 projects actually *rely* on it, and it has
proved its stripes in being reusable as soon as >1 project actually does
use it ).
This kind of policy makes for a 'commons' for genuine *components OF*
top-level projects.
Maybe there is another kind of policy ( say, 'incubator' ) for aspiring
top-level projects, and maybe the 'count of comitters' metric is more
appropriate here.
Of course, one would need separate CVS repositories for projects
under each policy, to avoid confusion.
2) ON FOCUS and LEADERSHIP
On another thread, there are some very loud yells of 'no better
than sourceforge' and 'duplication!'
I personally think that Jakarta have been a little too lax in
really qualifying their ideas. The criticism of duplication can
apply not just intra-Jakarta but intra- the open-source community.
[ I find some of the discussion quite amusing given this angle ]
For example, at the time that J2EEUnit became Cactus, an
alternative project, JUnitEE, existed. It did not cater to
the testing of JSP's, but the architecture was much cleaner
and simpler to use. There was no discussion at the time if
Cactus' contorted multiple proxy idea was in fact the best way
to get the job done. Someone just said, 'how about this?' and
it got in!
Nobody asked 'well, what does it really mean to try to run JUnit
tests in this environment', and identify facts like that there is no
way to use the ServletContext's log stream from within a test-case
even if you write your own TestRunner. If someone had come up
with a list of issues like this and then approached the JUnit authors
with a proposal, maybe contributed, or maybe offered to adopt the
codebase, who can doubt that testing of J2EE and other application
with JUnit would be much simpler today and Cactus a much less
cumbersome and more popular product? Especially given that Jakarta
is custodian of the javax.servlet.http API too!
As has been pointed out, it is up to volunteers to contribute their
time and they cannot be *forced* to contribute in a particular way, but
that is no reason why the PMC cannot get volunteers to qualify and
improve thier ideas, consider a bigger picture, before they get
started coding. Most people will quite readily accept the
challenge of a bigger picture, and you would probably get the
same non-initiating volunteer base because it is still a 'famous'
organisation to contribute to, and there is a genuine need for good
J2EE testing software and many people like to not start from scratch
by themselves.
Guess that must be close to a dime? The exchange rate is pretty
bad from this end ;-)
cheers,
David.
--
----
David Bullock - [EMAIL PROTECTED] +61 4 0290 1228
http://www.lisasoft.com/ (Architect) http://www.auug.org.au/ (President, SA)
http://www.ajug.org.au/sajug/sa.html (Activist) Sun Cert'd Programmer for Java 2
"The key ingredients of success are a crystal-clear goal, a realistic attack plan to
achieve that goal, and consistent, daily action to reach that goal."
Steve Maguire, "Debugging the Development Process".
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
