commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Sanders" <>
Subject RE: [OT] Newcomers
Date Fri, 23 Aug 2002 03:28:11 GMT
I am going to agree with both Morgan and Geir here.  I came to the
Commons project to help STOP rewriting code I had written before several
times.  My idea on the intent of Commons was to share code across
projects, including but never limited to Jakarta projects. The idea that
some code can be extracted from an existing project (Jakarta or
otherwise) for consumption in another project with similar needs is an
absolutley great idea, and really the only way that software development
can scale to do bigger and better things.

I would have never signed up to just create APIs for other Jakarta
projects.  I came here to write and use code that I need, not code that
Tomcat needs.  But I also cannot turn a blind eye to Tomcat's needs.  I
am not going to go rip something out of Digester because I thought it
was a good idea or that the design was bad.  Again, I am here to write
code in small, discreet, digestable (pun intended) chunks that ANY
project could be able to reuse.  And yes, the majority of the committers
has the final say.  This is Apache after all, not some dictatorship.

My name is Scott Sanders, and I too am a newcomer.


> -----Original Message-----
> From: Morgan Delagrange [] 
> Sent: Thursday, August 22, 2002 4:41 PM
> To: Jakarta Commons Developers List; Ola Berg
> Subject: Re: [OT] Newcomers
> <snip/>
> > 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.
> > 
> <snip/>
> 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:   
> <mailto:commons-dev->>
> For 
> additional commands, 
> e-mail: <>

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

View raw message