commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject RE: [lang] Designs and Futures
Date Wed, 02 Jun 2004 03:26:48 GMT

It's really a shame that the nightly built files are not a part of the
gump site. The gump site is not a developer's site [see next link], but
would provide some information.

I've been doing:

http://builds.osjava.org/

which I think is the kind of site you are after. It's actually been
running in the basement for Commons, but I lack the bandwidth to publish
it.

Hen

On Tue, 1 Jun 2004, Gary Gregory wrote:

> 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
>


---------------------------------------------------------------------
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