commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory" <>
Subject RE: [lang] Designs and Futures
Date Wed, 02 Jun 2004 00:49:29 GMT
A couple of thoughts on the non-controversial "release early release
often" topic.

I do agree that for commons and [lang] in particular, we do not release
often enough. That said, and from the other end of the spectrum we do
provide nightly builds. I use the term "provide" and not "release" in
this case because there is no indication of the quality of nightly
builds. I think the confidence level for nightly builds could be
dramatically increased if a history would be provided with unit test
results in a similar fashion to the eclipse builds. For example, on the

When you click on a build, you can see if unit tests passed or not
(green check or red cross). You can then click on the icon and see what
went wrong, for example:

It would be nice if we could provide a similar view for commons

Thank you,

> -----Original Message-----
> From: Stephen Colebourne []
> Sent: Tuesday, June 01, 2004 16:46
> To: Jakarta Commons Developers List
> Subject: Re: [lang] Designs and Futures
> There are two areas that I see commons as poor at achieving - release
> early
> release often and dependencies. The code itself is generally very good
> (despite what some might say).
> [lang] is an example of this. It has needed a release for some time,
> only
> to fix some of the glaring bugs in 2.0. It has also had changes
applied to
> it that increase dependencies.
> I know that many reading this don't get my point here. Perhaps if I
> the
> word coupling instead that would help? In the Validate case, there is
> need for Validate to be coupled to StringUtils and ArrayUtils. It
> in
> its original design, I was just reverting code back to 2.0.
> This extends to other packages - ideally, no subpackage within lang
> depend on another. We won't achieve that, but it should be a basic
> (It
> should be noted that in [collections] I introduced more
> dependencies/coupling between classes in v3.0 and it has since been
> to
> be a Bad Thing)
> As I've tried to explain elsewhere, [lang] is not one jar file but
> It
> is a place where these tiny pieces of code can be grouped together and
> looked after, because even smaller projects tend not to work. After
> we
> ought to be able to create an exception jar, or an enums jar, or a
> validate
> jar if we wanted.
> Finally, it should be noted that [lang] has about 30 open calls, and
> are valid. This suggests a wide user base who want this component
> supported
> and improved. The issue for us is more to do with [lang] satisfying
> own
> personal isues already, so we don't feel motivated to do anything
about it
> -
> its not our itch any more. But somehow, we need to at least get 2.1
> then take it from there.
> [lang] is actually a great achievement, as almost certainly the most
> widely
> used library of its type. Lets not loose that achievement.
> Stephen
> ----- Original Message -----
> From: "matthew.hawthorne" <>
> > Gary Gregory wrote:
> > > Sorry for the flame but this is a 'shake-my-head-in-disbelief'
> > > that I find discouraging.
> >
> > I pretty much agree, but from my POV [lang] stopped moving forward a
> > while ago anyway.  Most new requests
> > or ideas are rejected as "out of scope" (which is usually valid),
> > the project has shifted into
> > maintenance mode.  Along with this came a certain identity crisis,
> > that's why the cut-and-paste
> > philosophy came along.
> >
> > As another example, I've never even liked the public constructor in
> > *Utils classes, even though I understand why it's
> > done.  Helping and supporting users is important, but I think there
is a
> > certain line that has to be drawn.
> > I think that developers should have the freedom to make classes and
> > methods final where appropriate,
> > and make other design decisions that may limit the possible uses of
> > library.  In losing that ability, I believe that
> > the quality of the code suffers.  And for someone like me, it makes
> > less motivated to become involved or share ideas.
> >
> > I may be dead wrong, these are just some feelings that I have.
> >
> >
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message