Jakarta-tools ? Re: Code Sharing Concepts

[cm...@yahoo.com]

What about starting the "reuse" quest by reusing the jakarta-tools
repository ?

IMHO it is a perfect place to start - if you remember it used to be a
place where various tools _shared_ by tomcat and watchdog were placed.
( and I'm talking about ant and moo ). It seemed that it worked pretty
well ( given that ant is now a big success ).

All we need is someone with karma to add all the jakarta commiters to
jakarta-tools.

I don't think we need too many new rules - except common sense.

> >In the case of a jakarta-util project, a contituency of projects willing to
> >use this code base would be helpful.

As a tomcat commiter I would do it, I'm sure other will. ( watchdog is
already using it :-).

> Avalon and Ant2.x (if not ant1.x) will use it (at least if I have any say
> ;-]). 

I'm glad to hear that, I don't know if I'm still ant committer but there
are some pieces I really don't want to duplicate but use...


> Possible contributed code;
> 
> * Command Line parsing utils (conforms to GNU standard)

I would be happy to use them in tomcat :-)

As long as each is in it's own package - that's perfect.

IMHO this should be driven by 2 factors:
- people willing to share ( and spending the time on re-packaging it to 
jakarta-tools and fixing the build.xml to use the sharable piece )

- people needing code from other projects. Instead of cut&paste we can try
to make the code sharable. 

The only special thing is a good description of each package ( with
dependencies on other package in jakarta-tools ) and no external
dependencies.

Let's try this first - if it works we can create a top level project (
jakarta-utils, cjan - it already happened with ant :-), if it doesn't work
- jakarta-tools is not really used too much ( except to store the moo )


BTW, it is very important to not try to "decide" about other
people's modules - even if we'll have 5 StringManagers and many other
collections, each of them used by a different project, having them in the
same place is a big step and time will probably decide which will survive. 


-- 
Costin

Re: Jakarta-tools ? Re: Code Sharing Concepts

[cm...@yahoo.com]

> > What about starting the "reuse" quest by reusing the jakarta-tools
> > repository ?
> 
> Wouldn't that break the "old" version of Watchdog ("jakarta-watchdog") that still
> has dependencies here?

In what way ? By adding new directories and tools the old one shouldn't be
affected. Watchdog is using moo.jar ( which is also used by tomcat3.3 to 
run the watchdog from a web application ).

> At any rate, the process questions need to be settled now (before any of us get
> any more entrenched in our attitudes :-) -- IMHO it is premature to start checking
> in code.

I don't expect too much code to be checked in in the close future, but I
hope this will move us from "talk" state into "do" state, and maybe at
least 1-2 tools will be checked in to jumpstart the process and to allow
us to test the concepts.

It's hard to know if something will work you don't try.

-- 
Costin

Re: Jakarta-tools ? Re: Code Sharing Concepts

["Craig R. McClanahan" <Cr...@eng.sun.com>]

cmanolache@yahoo.com wrote:

> What about starting the "reuse" quest by reusing the jakarta-tools
> repository ?
>

Wouldn't that break the "old" version of Watchdog ("jakarta-watchdog") that still
has dependencies here?

At any rate, the process questions need to be settled now (before any of us get
any more entrenched in our attitudes :-) -- IMHO it is premature to start checking
in code.

> Costin
>

Craig

Re: Jakarta-tools ? Re: Code Sharing Concepts

["Geir Magnusson Jr." <ge...@optonline.net>]

cmanolache@yahoo.com wrote:
> 
> > For meritocracy to work, it's important that people feel being a
> > Committer is a privilege that they have earned.
> 
> > Giving every Committer karma to every package in the library dilutes
> > that privilege, and fosters the idea that everyone is welcome to make
> > whatever changes suites them.
> 
> Every commiter in jakarta projects has made contributions and won his
> privilege.

agreed.

> Sharing shouldn't require special permissions, nor reusing.

Agreed.
 
> In all projects commiters have the right to make changes and review
> and reject changes made by other, same should work for jakarta-tools.
> 

I don't agree here.  I haven't been working here in Jakarta-land very
long (5 months), and only on one of the smaller projects (Velocity), so
take this all with a grain of salt, of course...

To me, it seems that the committers for a project act as gatekeepers,
reponsible both to the code base, the charter of the project, and to
that project's community of users, developers, and other participants. 
The key here, as I see it, is their responsibility to the project was (I
assume) recognized through participation, and therefore they were
granted committer status.

I think that for a tool project to succeed you will need the same sort
of thing : naturally select dedicated and interested committers through
the same process that seems to be working in all the other projects -
active interest with valuable contribution results in committer status.

Granted, you have a bootstrap problem, but that might be solved simply
by granted committer status to one person from each jakarta project such
that all projects have equal representation and input, and then let
nature take it's course.

> > IMHO, shared packages won't work unless they are managed independently,
> > and we call can trust the people working on them to do what's best for
> > the shared package.
> 
> IMHO shared package won't work unless the people who are developing
> and using them are also managing them. The only people who can decide
> what's best for the shared package are the commiters that are working with
> the package.

Exactly.

> In any case, a system where a tool is managed "independently" has no
> chance ( IMHO ).

I disagree.  In my limited experience, Velocity is a mere tool for
others to use wherever they need to, both within a framework environment
(like Turbine) or outside in regular servlets (what I do). It has been
integrated into Turbine as the recommended template engine, but Velocity
is still a free entity - while things have been done to make life easier
for Turbine integration, it was done recognizing that Turbine was the
biggest 'customer' at the time, and nothing was added that was Turbine
specific - it was simply a real use-case that we had to support.  We got
something out of it, and Turbine got something out of it.

geir

> > Once the library subproject was proposed and installed, all the usual
> > rules of revolution and evolution would apply. If different Committers
> > wanted to work on different implementations, they could. That's their
> > privilege as Committers. But the team would decide whether an
> > implementation is released to the public or not, or what name it was
> > released under. Darwin works here too.
> 
> Yes. The only question is which "team". And my proposal is that all
> jakarta commiters should be part of the team - that's the best way to make
> this work. Of course, it's likely that only commiters from the projects
> that use a particular tool will vote about that tool, but anyone should
> feel ownership over the shared code.
> 
> The idea of "jakarta-tools" or CJAN is that multiple tools ( or
> sub-sets) will exist at any time ( for example, "ant" and "moo" where part
> of jakarta-tools ).
> 
> 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.
> 
> The worse thing that can happen is 2 projects sharing a tool and having
> different needs. In which case that particular tool can be forked (
> i.e. revert to the current status, but at least we tried )
> 
> Costin
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org

-- 
Geir Magnusson Jr.                               geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity

Re: Jakarta-tools ? Re: Code Sharing Concepts

[cm...@yahoo.com]

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 

 

 

> cmanolache@yahoo.com 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: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
> 

-- 
Costin

Re: Jakarta-tools ? Re: Code Sharing Concepts

[Ted Husted <ne...@husted.com>]

cmanolache@yahoo.com 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/

Re: Jakarta-tools ? Re: Code Sharing Concepts

[cm...@yahoo.com]

> For meritocracy to work, it's important that people feel being a
> Committer is a privilege that they have earned. 
 
> Giving every Committer karma to every package in the library dilutes
> that privilege, and fosters the idea that everyone is welcome to make
> whatever changes suites them. 

Every commiter in jakarta projects has made contributions and won his
privilege. 

Sharing shouldn't require special permissions, nor reusing. 

In all projects commiters have the right to make changes and review
and reject changes made by other, same should work for jakarta-tools.

 
> IMHO, shared packages won't work unless they are managed independently,
> and we call can trust the people working on them to do what's best for
> the shared package. 

IMHO shared package won't work unless the people who are developing
and using them are also managing them. The only people who can decide
what's best for the shared package are the commiters that are working with
the package.

In any case, a system where a tool is managed "independently" has no
chance ( IMHO ). 

> Once the library subproject was proposed and installed, all the usual
> rules of revolution and evolution would apply. If different Committers
> wanted to work on different implementations, they could. That's their
> privilege as Committers. But the team would decide whether an
> implementation is released to the public or not, or what name it was
> released under. Darwin works here too. 

Yes. The only question is which "team". And my proposal is that all
jakarta commiters should be part of the team - that's the best way to make
this work. Of course, it's likely that only commiters from the projects
that use a particular tool will vote about that tool, but anyone should
feel ownership over the shared code.

The idea of "jakarta-tools" or CJAN is that multiple tools ( or
sub-sets) will exist at any time ( for example, "ant" and "moo" where part
of jakarta-tools ). 

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. 

The worse thing that can happen is 2 projects sharing a tool and having
different needs. In which case that particular tool can be forked (
i.e. revert to the current status, but at least we tried ) 

Costin

Re: Jakarta-tools ? Re: Code Sharing Concepts

[Ted Husted <ne...@husted.com>]

On 2/9/2001 at 7:45 AM cmanolache@yahoo.com wrote:

>I don't think we need too many new rules - except common sense.

Agreed. We should apply the rules we already have. 

Jakarta was started by taking Apache rules and applying them to
multiple products. 

We should continue that process by applying the same rules to multiple
subproducts. 

For meritocracy to work, it's important that people feel being a
Committer is a privilege that they have earned. 

Giving every Committer karma to every package in the library dilutes
that privilege, and fosters the idea that everyone is welcome to make
whatever changes suites them. 

IMHO, shared packages won't work unless they are managed independently,
and we call can trust the people working on them to do what's best for
the shared package. 

On 2/9/2001 at 7:54 AM cmanolache@yahoo.com wrote:

>The alternative is to debate for the next 6 months about which
>DBPool is the best and why. And we may reach the wrong conclusion.

Once the library subproject was proposed and installed, all the usual
rules of revolution and evolution would apply. If different Committers
wanted to work on different implementations, they could. That's their
privilege as Committers. But the team would decide whether an
implementation is released to the public or not, or what name it was
released under. Darwin works here too. 

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