commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ola Berg <>
Subject RE: [OT] Newcomers
Date Fri, 23 Aug 2002 07:29:36 GMT
costinm writes:
>Ola, there are plenty of projects and places where you can do that.

I know. But I want to help _here_ (since I make money out of a lot of jakarta stuff), and
just wants to know the directions since I have some code and time that I am willing to contribute.
That\'s all.

ssanders writes:
>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.

My goal and opinion too.

steve.downey writes:
>It may be well placed for it, but it\'s out of scope for the Jakarta project.
>Jakarta, as chartered, is for the purpose of creating server-side software.

But server side software needs good, stable and versatile foundational API:s. As scolebourne
pointed out which I agree on, things in the bottom fit for many different use-cases _has_
to be engineered and modelled more carefully and with slightly different priorities than if
they are designed to support only one or two projects. 

Designing for reusability in many use cases (both jakarta and outside) is special. One has
to reason and do trade offs differently. Things like minimizing public APIs becomes more important,
drop support for X in package Y in favor of letting X be handled by package Z instead (since
Z handles X more versatile or efficient) is a common redesign movement. It is inconvenient
at first, but will pay off in the long run. Think of all the code you don\'t have to support
any more!

Doing the basic stuff within jakarta means that jakarta has some kind of control over it,
but that also means that the donor project will have to accept modifications when the commons
developers adopts the components to all the use cases and the design principles they see fit
(not to mention the public/private constructor debate here, where I for the sake of versatility
am all for the deprecated public ctor in static util classes).

costinm writes:
>I would again sugest Avalon - where people seem to share your point
>of view about \'perfect code\' ( and at least they used to share
>your point about breaking existing code ). 

I think that the Avalon people has these opinions, because they also know what designing foundational
APIs for reusability means.

When it comes to backwards compatibility: if the commons developers decides that breaking
it is the right thing to do (and I am not saying that it should be done lightly without care
for the existing user base), I think that the donor projects will have to see the commons
reasons for it, and accept that since it is in the commons, it will have a broader user base
(and thus having to take more things into consideration) than before.

Isn\'t one of the problems that the donor projects are a bit too quick to migrate into the
commons version? Wouldn\'t the natural thing to do be:

1) donate the code
2) wait for commons to integrate it according to commons need for overall consistency etc
(&I am not implying creating an f****work here), and by all means take part in that process
but driven by commons\' needs to be the best for all?
3) then, eventually maybe becoming dependant on commons, when the commonsified version has
stabilized. Adapting to reuse is a slower process, since there are more things to take into
consideration. It would be bad if that process is either rushed (we need this release _now_)
or if it slows down development of the donor project.

During phase 2) there will be a fork for a while, but wouldn\'t the benefit outweight the
inconvenience in the long run? 

>There are many smart 
>people there.

The mighty Lords of Avalon are smart, no doubt. But still: Avalon is a different thing (COP,
IoC etc). Why else do the avaloners now outfactor code that isn\'t dependant on COP and IoC,
into commons?


0733 - 99 99 17

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

View raw message