commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory" <ggreg...@seagullsw.com>
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
page

http://download.eclipse.org/downloads/index.php

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: 

http://download2.eclipse.org/downloads/drops/N-N20040601-200406010010/te
stResults.php

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

Thank you,
Gary 

> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> 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,
if
> 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
used
> the
> word coupling instead that would help? In the Validate case, there is
no
> need for Validate to be coupled to StringUtils and ArrayUtils. It
wasn't
> in
> its original design, I was just reverting code back to 2.0.
> 
> This extends to other packages - ideally, no subpackage within lang
should
> depend on another. We won't achieve that, but it should be a basic
goal.
> (It
> should be noted that in [collections] I introduced more
> dependencies/coupling between classes in v3.0 and it has since been
shown
> to
> be a Bad Thing)
> 
> As I've tried to explain elsewhere, [lang] is not one jar file but
many.
> 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
all,
> 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
many
> 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
our
> 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
out,
> 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" <matth@apache.org>
> > Gary Gregory wrote:
> > > Sorry for the flame but this is a 'shake-my-head-in-disbelief'
moment
> > > 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),
and
> > the project has shifted into
> > maintenance mode.  Along with this came a certain identity crisis,
and
> > 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
the
> > library.  In losing that ability, I believe that
> > the quality of the code suffers.  And for someone like me, it makes
me
> > 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: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message