I'll try again:

1. As someone said, "community is more important than code"

2. I think the real problem here is not "code sharing" - the fact that
people are reticent to reuse code developed in other projects is just an
effect

3. I think the real problem is that each project has it's own community
and commiters, instead of a shared "jakarta community".

4. I think the only way to solve the reuse problem is to make sure that 
all jakarta commiters are part of the "tools/utils" project. 

That's my point - I'm not proposing to create ( now ) a repository open to
everyone in the world, just to all interested jakarta commiters. 

Beeing a commiter in one of the projects means more than the fact that you
have CVS access and the right to vote - it means you feel part of the
project community. If you are commiter in one of the jakarta projects and
you are interested in working on any "shared" code, you should
automatically be a commiter for the shared piece.

My proposal is to create a place where all jakarta commiters have a common
interest - the shared tools. 

If we can't manage this - that means something is broken in the concept of
"jakarta community" - and a different solution is needed. 

But it's worth trying ( starting with few small tools ), and see if we can
manage to work togheter. 

We can have 10 different Pools or StringManagers - in time they'll
converge or specialize and cover different niche. 
There is nothing wrong with having 4 solutions for a test suite, as long
as all people working on this are sharing a common repository and
community, and the community is open to new code ( even if it's
duplicated ) as long as the code is shared.

I think all "tools" should be shared - but the code is less important in
this case, we should share the community ( by making all jakarta commiters
members of the tools project ). 


Costin 

 

 

> [EMAIL PROTECTED] wrote:
> > Again, I don't like the idea of "framework" - i.e. a team managing all
> > tools and releasing them as a whole. It seems what works is the idea of
> > modules ( like CPAN modules ). And the modules should have independent
> > life and evolution. We can tag individual packages for each project that
> > includes it.
> 
> I don't think anyone has meant to propose that. 
> 
> I have suggested that we create a Jakarta Components Library as a
> microcosm of the greater project. There would be a core group of
> Committers (like the PMC) who would act as the overall gatekeepers of
> the library. Each component in the library would have its own set of
> Committers, which would usually be the person or persons who wrote the
> original code, and who has a vested interest in the component. Each
> component would have its own release schedule and versioning, stable
> versions and latest builds. Of course, as a convenience, there might be
> a full library JAR of all the stable versions.
> 
> If we can get this library to work for our own tools, then, of course,
> we should look at creating a greater CJAN library. Something like this
> would be more like CPAN or SourceForge, and be open to all comers. But
> we should weed our own garden first.
> 
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 425-0252; Fax 716 223-2506.
> -- http://www.husted.com/about/struts/
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-- 
Costin


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to