> 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.
>
Agreed totally,
As i remember the main complaint to this proposal was the different
number of committers from one or other project, this can be resolved
doing a representative vote ( 1 project 1 vote ) in this repository..
sure this is not perfect but it's possible, a perfectionist is
stationary :),
We need to learn a lot first.... we can do plans, we can suppouse, we
can observe CPAN, but nobody knows better than ourself what is jakarta
now, and much of us are concerned about his future, let's try to build
real community now, better than tomorrow,
At internet timing decisions only can be hard to take in future, let's
go and do it when it's manageable and prepare things to when it become
inmanageable....:)
My 0.02 Eur
Saludos ,
Ignacio J. Ortega
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
