commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Morgan Delagrange <>
Subject Re: [OT] Newcomers
Date Thu, 22 Aug 2002 23:40:50 GMT

> scoulebourne writes:
> >That the charter should be
> >amended to emphasise commons right to exist as a
> top level jakarta component
> >in its own right. Give commons the mandate to do
> what it is perfectly placed
> >to do, build high quality low level libraries for
> the Java community, of
> >which jakarta is a part.
> No Stephen. Commons came into existence with a
> reason, before you and I (and others) entered the
> scene. As things stand, you and I are sometimes
> blocking (you) and disturbing (I) that goal. A
> project where the existing jakarta projects can do
> compromises in order to share a common code base is
> justified and welcome. 
> I just happen to think that building \"high quality
> low level libraries for the Java community\" in an
> ASF style is justified too, and that I very much
> would like to be a part of that process. Commons as
> it stands should do its thing. 


Plenty of emails prior and since, but this seems to be
the best place to interject.  It's not correct that
Commons was only created to host code from other
projects.  There were quite a lot of views on the
subject.  Some favored tightly binding code to
projects and rejecting components that were not hosted
somewhere else initially.  Some (including me,
obviously) thought that we should scratch our itches
regardless of whether or not a particular project was
hosting, as long as the end result was generally
useful.  Certainly there are sandbox components, both
current and graduated, that fit that description. 
Language in the charter that required sponsoring
projects for every component was ultimately rejected
by the majority as overly restrictive.  The entire
body of initial Commons committers definitely did
_not_ view the project as only a repository for
shared, Jakarta-only code.

I think juggling the needs for quality design and
extra-project compatibility is certainly difficult and
must be handled on a case by case basis.  However I
don't believe in protracting it to the extent of late
and for minor issues we should tend toward
compatibility.  I would think this is almost
self-evident, but perhaps not.

If you want my opinion as an example, this constructor
debate right now seems overblown.  Velocity is
bean-based.  They need public constructors for
instantiation.  Certainly, constructors for stateless,
completely static classes isn't ideal, but a simple
Javadoc on the constructor would suffice to clear up
any potential confusion, and otherwise the impact on
the class is precisely zero.  I haven't heard anything
yet to convince me that this is not a religious issue,
in which case let's tend toward convenience.

Something like the Slide/HttpClient debate of old
seems a little different to me.  HttpClient had bugs
to fix and new features to add, and a lot of the
developers felt that the existing API was awkward.  So
we had to decide whether breaking compatilibity was
worthwhile in comparison to the potential gain of
redesign.  In that particular case, the considerations
were non-trivial, and I think a revolution was the
right choice (after, of course, insuring that Slide
had a workable version to use until they could adopt
the new API).

- Morgan

Morgan Delagrange

Do You Yahoo!?
HotJobs - Search Thousands of New Jobs

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message