commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: [core] Scope, you choose!
Date Mon, 09 Dec 2002 18:29:36 GMT


On Fri, 6 Dec 2002, Costin Manolache wrote:

> There is no dual maintainance. Everyone maintains the code that
> he cares about and uses.

There is however inter-project debate. Which will run like this:

Robert creates a better, leaner, nicer reflection library.
Robert refactors beanutils to use this. Refactoring involves removing



> > What I have consistently failed to understand about this debate is how
> > commons can ask other jakarta projects to refactor out their common code
> > when commons is unwilling to do the same job within its own borders.
>
> Commons is not asking other projects to refactor common code just for the
> sake of moving code around and creating dependencies. If someone feels
> a piece of code would benefit from having more hands and more diverse
> opinions - and is willing to take the risks of more diverse opinions -
> then commons may be a good idea.
>
> It is not in commons charter to create a one-size-fits-all introspection
> library.
>
> What I fail to understand is what is the real issue of debate -
> if you want to create a library for reflection, do it.
> That doesn't mean you have to force everyone to use it or to stop
> people from working on other reflection libraries or to say that the other
> reflection code should move to your component.

The problem comes when beanutils is refactored to use that library. While
I agree that that should be dealt with when that point is reached, it is
difficult to find the mental energy to create a library with the aim of
using it in some form of application [such as another library] only to
find that using that library is blocked in that application.

> If a piece of code works well, is stable, fast, clean and does
> what it is needed - it will be used, and people will stop working
> on other implementations. If some other implementation does
> something different and people need that - then probably both
> will exist for a while.

The biggest issue is the common Commons mailing list. Arguments leak over
projects. You say that projects can quite happily run in parallel,
duplicating code, but the nature of one mailing list means that they'll
keep bumping heads.

Discussions about reflection in Lang get tangled with questions as to
whether BeanUtils should refactor to use that. Rod adding code to
beanutils [which is pretty much his right] will slam into Robert
refactoring that code in a month [which is also his right]. If Rod's code
is unreleased by then [and robert has the right to -1 and argue against it
being released, though it pushes the line a bit] then there's no reason
why Robert has to worry about refactoring that work out.

So that's what I think the underlying issue is. Yes everyone can run
around and do their own thing with one hat on, but there repurcussions
down the line to be dealt with and people are trying to forsee them and
plan for them.

> We must mind our own itches. That's the real issue that people
> don't seem to understand.

It's the best thing you're saying. In short, do what you want and debate
when you're finished. Plus it's the only way open-source ever works,
because we're scratching away for our own pleasure.

Hen


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


Mime
View raw message