You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@commons.apache.org by Greg Stein <gs...@lyra.org> on 2003/09/18 02:54:48 UTC
Re: DbUtils
On Wed, Sep 17, 2003 at 11:26:45PM +0100, robert burrell donkin wrote:
>...
> anyway, rather than go over all the old arguments again, i'd say that it'd
> be better to go forward by looking at the positives that apache commons
> can offer (rather than getting into an argument about the jakarta mission
> scope).
Well, to be honest, that is kind of a weird question to me. "what do you
have to offer?" Euh... project space?
I mean really. The ASF is the same across the board. I don't see that
there needs to be a one-up-man-ship here. "ooh! we have X and they don't!"
That may not be what you meant, but when I read "what do you have to
offer", that is how I translate it.
Personally, I see Commons provide a community for building reusable
components. Those components are independent, rather than beholden to some
larger project. Of course, there *does* need to be recognition and respect
for your users, so versioning and API stability is very important. But
Commons *is* a separate TLP which sets its own goals.
The Commons Project also has a bit of self-definition to complete, too.
One of the outstanding questions is partitioning of commit rights. At the
moment, I'm in favor of zero partitioning within TLPs. If you're a Commons
committer, then you have rights on all components. Social norms and
recognizing your knowledge/strenghts/weaknesses should keep people from
breaking components outside of their typical areas of work. But from a
responsibility standpoint, it is expected that all Commons committers
would become part of the PMC, and that PMC is responsible for everything.
Partitioning just monkeys all of that up.
There is also a question of whether to have a sandbox. Do we allow people
to run with a good idea? To start it from scratch? If we allow "from
scratch" components here, then do we impose a minimum number of committers
"signing up" to work on it? (i.e. no one-man component starts)
Things like that.
Oh, and the part of me that prefers unification rather than replication
wants to ask, "so Apache Commons will be here in five years. how about the
other foo-commons projects?" :-) hehehe...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Purpose of Multiple Commons was Re: DbUtils
Posted by Tim O'Brien <to...@discursive.com>.
On Thu, 2003-09-18 at 10:00, Justin Erenkrantz wrote:
> --On Thursday, September 18, 2003 10:53 AM -0400 Henri Yandell
> <ba...@generationjava.com> wrote:
>
> > A Java HTTP Client project can learn a lot from a C HTTP Client, but no
> > user of a Java HTTP Client will ever consider the C HTTP Client as a valid
> > alternative [okay, very small % might].
>
> That was what my consideration was - the developers would gain from the
> synergy. The users might not gain directly though. -- justin
>
The way to go about building this synergy is to engage the existing
HttpClient project in the Jakarta Commons right now. Commons HttpClient
and Serf may be completely dissimilar at this stage (serf uses APR and
is written in C, and Commons HttpClient is in Java), but it might be
beneficial to get both communities working together. to create similar
products.
Serf and HttpClient would continue as separate implementations, but one
would try to synchronize feature-sets and releases. This approach would
be similar to the way that Xerces is available in both Java and C++.
Re: Purpose of Multiple Commons was Re: DbUtils
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, September 18, 2003 10:53 AM -0400 Henri Yandell
<ba...@generationjava.com> wrote:
> A Java HTTP Client project can learn a lot from a C HTTP Client, but no
> user of a Java HTTP Client will ever consider the C HTTP Client as a valid
> alternative [okay, very small % might].
That was what my consideration was - the developers would gain from the
synergy. The users might not gain directly though. -- justin
Re: Purpose of Multiple Commons
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Sep 18, 2003 at 01:08:04PM -0400, Daniel F. Savarese wrote:
>...
> Here's my take. Consumers of libraries just want canned code that solves
> a problem they're facing. They don't care if the code happens to reside
> along with other libraries written in/for different languages. After
> categorizing by functionality, you still have to subcategorize by language
Agreed.
>...
> I don't
> believe Jakarta Commons/XML Commons/etc. projects should be forced to move
> into Apache Commons
Agreed, although I would hope that (in the long run), all of the various
commons projects will become unified by choice.
> (if that's what we're talking about),
Nope. The thread is really why we might have multiple Commons projects,
and also partly to answer "which one is best for my component?"
Migration of existing components from Foo Commons into Apache Commons is a
choice of the dev community, and a vote from the two relevant PMCs (the
existing governance PMC, and the Commons PMC) to allow the move.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Purpose of Multiple Commons was Re: DbUtils
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 18 Sep 2003, Justin Erenkrantz wrote:
> --On Thursday, September 18, 2003 9:09 AM +0100 Stephen Colebourne
> <sc...@btopenworld.com> wrote:
>
> >> I think the ultimate question here is what organization best benefits the
> >> committers.
> > Huh! Is this not very self centered? Surely we should be asking what is best
> > for ours customers/users.
>
> No. Because whether it is in Jakarta Commons, or ASF Commons, the users get
> the same 'deal.' It's under the Apache Software License, freely available.
> Websites are available, the infrastructure is the same. So, I think the user
> wouldn't care whether its under ASF Commons or Jakarta Commons.
>
> I believe the only difference, in this case, is what the committers believe.
>
> > My problem with Commons remains its cross-language aims, and I have always
> > disagreed with division by functionality. (For example start thinking about
> > what the website home page will be like. It will have an introduction and
> > then a list of Java components, and a list of Perl components and a list of
> > C# components....... No way is that ever serving the users well.)
>
> Then, I think you are taking a very short-sighted view of the world.
> Everything is not just Java. I think functional groupings are probably more
> useful. Is an HTTP Client in Java and C *that* fundamentally different? I
> don't believe so.
We're back to this chestnut again, which I think will only be shown in the
proof of the pudding [metaphors r us]. Both sides are short-sighted:
1) Yes, everything is not just Java. Java sites that use PHP+Apache for
their sites fight this regularly.
2) Java is an insular community [due I believe to the fact that the other
communities ostracised it]. Java developers are very tired of having to
deal with antagonistic MS and open-source attitudes.
A Java HTTP Client project can learn a lot from a C HTTP Client, but no
user of a Java HTTP Client will ever consider the C HTTP Client as a valid
alternative [okay, very small % might].
Now, Ant, Maven, Tomcat could all be written in C without a problem [I
don't think a Java Web server has to be written in Java, just has to be
able to compile/plugin Java], but I imagine it's unlikely to happen.
> The problems that they have to solve are essentially the same. I
> believe it'd be beneficial to pool our resources aligned on functional
> groupings rather than language barriers that aren't very strong to begin
> with. -- justin
This is also short-sighted. There is a very strong language barrier
between Java and other languages. It's not a wonderful thing to have, but
pretending that it's the same strength as C to Tcl, or Perl to Python will
just ostracise the Java [read Jakarta] bits more.
Hen
Re: Purpose of Multiple Commons was Re: DbUtils
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, September 18, 2003 9:09 AM +0100 Stephen Colebourne
<sc...@btopenworld.com> wrote:
>> I think the ultimate question here is what organization best benefits the
>> committers.
> Huh! Is this not very self centered? Surely we should be asking what is best
> for ours customers/users.
No. Because whether it is in Jakarta Commons, or ASF Commons, the users get
the same 'deal.' It's under the Apache Software License, freely available.
Websites are available, the infrastructure is the same. So, I think the user
wouldn't care whether its under ASF Commons or Jakarta Commons.
I believe the only difference, in this case, is what the committers believe.
> My problem with Commons remains its cross-language aims, and I have always
> disagreed with division by functionality. (For example start thinking about
> what the website home page will be like. It will have an introduction and
> then a list of Java components, and a list of Perl components and a list of
> C# components....... No way is that ever serving the users well.)
Then, I think you are taking a very short-sighted view of the world.
Everything is not just Java. I think functional groupings are probably more
useful. Is an HTTP Client in Java and C *that* fundamentally different? I
don't believe so.
The problems that they have to solve are essentially the same. I believe it'd
be beneficial to pool our resources aligned on functional groupings rather
than language barriers that aren't very strong to begin with. -- justin
Re: Purpose of Multiple Commons was Re: DbUtils
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Sep 18, 2003 at 10:35:24AM -0400, Henri Yandell wrote:
> On Thu, 18 Sep 2003, Justin Erenkrantz wrote:
>...
> > Okay, there's a size factor that you've missed. I believe we've always
> > maintained that if a Commons component could be self-sufficient, it should be
> > spun off into its own TLP. So, I don't think we'd have a problem 'spinning'
> > off a component from Commons if it got to be 'too big.'
> >
> > I believe APR certainly satisfies the size component where it doesn't need to
> > be under Commons. It has a group of developers and community that can manage
> > it successfully. -- justin
>
> Sounds great. Would be nice to outline an exit-strategy in the STATUS.
Done.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Purpose of Multiple Commons was Re: DbUtils
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, September 18, 2003 10:35 AM -0400 Henri Yandell
<ba...@generationjava.com> wrote:
> The developer/community clause you suggest sounds like incubation to me,
> not Commons. Size is good, but I'd like to know how we measure it, or the
> ways in which we can measure it. I'm not looking for hard numbers, just
> something that states expected reasons for exit'ing, and how an exit
> occurs.
It is and it isn't incubation. It's that having a Commons PMC allows for the
creation of reusable components that are probably too small to stand on their
own. There are just some things that aren't ever going to be big enough to
justify a TLP.
I believe Serf (C HTTP Client) can never be big enough to warrant being a TLP.
It's home is as a reusable library. Now, if we suddenly found 4 other active
HTTP Clients within the ASF and wanted to merge them under one TLP, would Serf
follow? Probably. So, if HttpClient went to be its own TLP, then I'd be
championing Serf to accompany it. Again, tightly-scoped functionally grouped
TLPs seem to do better within the ASF than broad language-grouped TLPs.
This is something that we'd like to solidify and we'd have to see how it works
out. *shrug* -- justin
Re: Purpose of Multiple Commons was Re: DbUtils
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 18 Sep 2003, Justin Erenkrantz wrote:
> --On Thursday, September 18, 2003 9:23 AM -0400 Henri Yandell
> <ba...@generationjava.com> wrote:
>
> > From a Jakarta Commons view, I think we should experiment with ASF Commons
> > and see how it fits. I'd like to see ORO/Regexp merge into one project in
> > ASF Commons, and for APR to move over to ASF Commons.
>
> Okay, there's a size factor that you've missed. I believe we've always
> maintained that if a Commons component could be self-sufficient, it should be
> spun off into its own TLP. So, I don't think we'd have a problem 'spinning'
> off a component from Commons if it got to be 'too big.'
>
> I believe APR certainly satisfies the size component where it doesn't need to
> be under Commons. It has a group of developers and community that can manage
> it successfully. -- justin
Sounds great. Would be nice to outline an exit-strategy in the STATUS.
The developer/community clause you suggest sounds like incubation to me,
not Commons. Size is good, but I'd like to know how we measure it, or the
ways in which we can measure it. I'm not looking for hard numbers, just
something that states expected reasons for exit'ing, and how an exit
occurs.
Jakarta-Commons has never really actively managed the exit strategy,
though I'll have to dig into archives to find out how Cactus managed to
leave JC. Things like HttpClient have the activity/community to happily
leave JC, but as a project it is such a good fit in JC. Jelly has the
size/complexity to leave JC, but probably not the active community (I
could be sluring Jelly's name here, I think it might have a lot of
invisible activity).
Hen
Re: Purpose of Multiple Commons was Re: DbUtils
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, September 18, 2003 9:23 AM -0400 Henri Yandell
<ba...@generationjava.com> wrote:
> From a Jakarta Commons view, I think we should experiment with ASF Commons
> and see how it fits. I'd like to see ORO/Regexp merge into one project in
> ASF Commons, and for APR to move over to ASF Commons.
Okay, there's a size factor that you've missed. I believe we've always
maintained that if a Commons component could be self-sufficient, it should be
spun off into its own TLP. So, I don't think we'd have a problem 'spinning'
off a component from Commons if it got to be 'too big.'
I believe APR certainly satisfies the size component where it doesn't need to
be under Commons. It has a group of developers and community that can manage
it successfully. -- justin
Re: Purpose of Multiple Commons was Re: DbUtils
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 18 Sep 2003, Garrett Rooney wrote:
> Henri Yandell wrote:
>
> > Yep, but subversion developers are not ASF developers [at least not
> > wearing their ASF developer hats]. The real question here is:
>
> I don't see how that's relevant. I'm just pointing out that the APR
> developers (at least from what I've seen) do not feel that APR exists
> 'for ASF C projects'. You seem to be implying that APR exists just for
> ASF projects, and in my experience that simply is not the case. In fact
> most of the APR developers seem to be pushing to reduce the tight
> coupling between httpd and APR by moving toward rolling separate
> releases for APR etc.
Even with separate roll-outs, I doubt it'll ever reach a point where httpd
is not the de-facto chief consumer for httpd, but I don't want it to be
the de-jure chief consumer.
> I have very little pull here (being only a minor contributor to any ASF
> project at all), but it seems like ASF Commons should be a separate TLP
> aiming to product reusable code for any and all who wish to use it.
> Making some artificial distinction that ASF projects somehow get more
> pull with regard to ASF Commons projects seems wrong to me.
I agree.
> > This has happened in Jakarta Commons. Code is donated, the original
> > donaters are not actively monitoring the code [and not a part of the
> > community therefore]. When simple changes are made that break their API,
> > they feel naturally aggrieved. The basic philosophy of the Commons is what
> > drives the settlement here. ASF or the People.
>
> If you're not actively involved in the project in question, it doesn't
> seem like being afiliated with the ASF should give you some sort of
> advantage here. An ASF project that uses code that lives in the ASF
> Commons is just another consumer, and should (IMO) have their opinions
> treated the same as any other.
I agree :)
Hen
Re: Purpose of Multiple Commons was Re: DbUtils
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Henri Yandell wrote:
>
> On Thu, 18 Sep 2003, Garrett Rooney wrote:
>
>
>>Henri Yandell wrote:
>>
>>
>>>>Huh! Is this not very self centered? Surely we should be asking what is best
>>>>for ours customers/users.
>>>
>>>
>>>The committers are the chief consumers :) At least, Apache Commons seems
>>>to have the same concepts as Jakarta Commons in that respect, that ASF
>>>projects are the chief consumers with external consumers being a major
>>>bonus point.
>>>
>>>ie) APR exists for ASF C projects, and not for C in general.
>>
>>Us Subversion developers would probably dissagree with you there... APR
>>is used in a number of non-ASF projects.
>
>
> Yep, but subversion developers are not ASF developers [at least not
> wearing their ASF developer hats]. The real question here is:
I don't see how that's relevant. I'm just pointing out that the APR
developers (at least from what I've seen) do not feel that APR exists
'for ASF C projects'. You seem to be implying that APR exists just for
ASF projects, and in my experience that simply is not the case. In fact
most of the APR developers seem to be pushing to reduce the tight
coupling between httpd and APR by moving toward rolling separate
releases for APR etc.
> Jakarta Commons exists for Jakarta [in the charter]. XML Commons for XML
> [I think]. Does ASF Commons exist for ASF, or is it a TLP aiming at
> contributors. If an ASF project donates some code to ASF Commons, and the
> people in the ASF Commons community make a decision based on user
> feedback, is the original ASF project able to veto these, or have a larger
> say?
I have very little pull here (being only a minor contributor to any ASF
project at all), but it seems like ASF Commons should be a separate TLP
aiming to product reusable code for any and all who wish to use it.
Making some artificial distinction that ASF projects somehow get more
pull with regard to ASF Commons projects seems wrong to me.
> This has happened in Jakarta Commons. Code is donated, the original
> donaters are not actively monitoring the code [and not a part of the
> community therefore]. When simple changes are made that break their API,
> they feel naturally aggrieved. The basic philosophy of the Commons is what
> drives the settlement here. ASF or the People.
If you're not actively involved in the project in question, it doesn't
seem like being afiliated with the ASF should give you some sort of
advantage here. An ASF project that uses code that lives in the ASF
Commons is just another consumer, and should (IMO) have their opinions
treated the same as any other.
-garrett
Re: Purpose of Multiple Commons was Re: DbUtils
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 18 Sep 2003, Garrett Rooney wrote:
> Henri Yandell wrote:
>
> >>Huh! Is this not very self centered? Surely we should be asking what is best
> >>for ours customers/users.
> >
> >
> > The committers are the chief consumers :) At least, Apache Commons seems
> > to have the same concepts as Jakarta Commons in that respect, that ASF
> > projects are the chief consumers with external consumers being a major
> > bonus point.
> >
> > ie) APR exists for ASF C projects, and not for C in general.
>
> Us Subversion developers would probably dissagree with you there... APR
> is used in a number of non-ASF projects.
Yep, but subversion developers are not ASF developers [at least not
wearing their ASF developer hats]. The real question here is:
Jakarta Commons exists for Jakarta [in the charter]. XML Commons for XML
[I think]. Does ASF Commons exist for ASF, or is it a TLP aiming at
contributors. If an ASF project donates some code to ASF Commons, and the
people in the ASF Commons community make a decision based on user
feedback, is the original ASF project able to veto these, or have a larger
say?
This has happened in Jakarta Commons. Code is donated, the original
donaters are not actively monitoring the code [and not a part of the
community therefore]. When simple changes are made that break their API,
they feel naturally aggrieved. The basic philosophy of the Commons is what
drives the settlement here. ASF or the People.
Hen
Re: Purpose of Multiple Commons was Re: DbUtils
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Henri Yandell wrote:
>>Huh! Is this not very self centered? Surely we should be asking what is best
>>for ours customers/users.
>
>
> The committers are the chief consumers :) At least, Apache Commons seems
> to have the same concepts as Jakarta Commons in that respect, that ASF
> projects are the chief consumers with external consumers being a major
> bonus point.
>
> ie) APR exists for ASF C projects, and not for C in general.
Us Subversion developers would probably dissagree with you there... APR
is used in a number of non-ASF projects.
-garrett
RE: Purpose of Multiple Commons was Re: DbUtils
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 18 Sep 2003, Sander Striker wrote:
> > From: Henri Yandell [mailto:bayard@generationjava.com]
> > Sent: Thursday, September 18, 2003 3:23 PM
>
> [...]
> > From a Jakarta Commons view, I think we should experiment with ASF Commons
> > and see how it fits. I'd like to see ORO/Regexp merge into one project in
> > ASF Commons, and for APR to move over to ASF Commons.
>
> Move APR over to Commons?! APR is way too big a project to be under Commons.
> It's a complete portability library. Anyway, I see no need to disband a
> perfectly good functioning PMC for seemingly experimental purposes.
*grin* I may have been poking a bit :)
So what's the size limit for ASF Commons?
RE: Purpose of Multiple Commons was Re: DbUtils
Posted by Sander Striker <st...@apache.org>.
> From: Henri Yandell [mailto:bayard@generationjava.com]
> Sent: Thursday, September 18, 2003 3:23 PM
[...]
> From a Jakarta Commons view, I think we should experiment with ASF Commons
> and see how it fits. I'd like to see ORO/Regexp merge into one project in
> ASF Commons, and for APR to move over to ASF Commons.
Move APR over to Commons?! APR is way too big a project to be under Commons.
It's a complete portability library. Anyway, I see no need to disband a
perfectly good functioning PMC for seemingly experimental purposes.
Sander
Re: Purpose of Multiple Commons was Re: DbUtils
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 18 Sep 2003, Stephen Colebourne wrote:
> From: "Justin Erenkrantz" <ju...@erenkrantz.com>
> > I think the ultimate question here is what organization best benefits the
> > committers.
> Huh! Is this not very self centered? Surely we should be asking what is best
> for ours customers/users.
The committers are the chief consumers :) At least, Apache Commons seems
to have the same concepts as Jakarta Commons in that respect, that ASF
projects are the chief consumers with external consumers being a major
bonus point.
ie) APR exists for ASF C projects, and not for C in general.
> My problem with Commons remains its cross-language aims, and I have always
> disagreed with division by functionality. (For example start thinking about
> what the website home page will be like. It will have an introduction and
> then a list of Java components, and a list of Perl components and a list of
> C# components....... No way is that ever serving the users well.)
>
> The multi-language battle seems to be lost however, but the battle for
> location of Java common code is still not settled. So I can still resist any
> move of j-c to a multi-language area.
I hope it's not over. It's a classic information architecture problem, a 2
dimensional index. A bit more complex because info architects rarely worry
about mailing lists.
I'm firmly in the camp that I don't want to shovel through lots of emails
in 'languages' I don't understand each morning. Be it German or C, both
of which I need a book to speak happily.
> > Where there is not a strong tie to another Jakarta project, I
> > firmly believe that the Jakarta Commons model causes exactly what Henri
> > described:
> >
> > > The next step for these coders is to create more re-usable components.
> > > However, these were not created by a Jakarta project, and have no
> internal
> > > community. They don't feel very Apache-y.
> >
> > I think we (as in the ASF) can do better. I think a project that is
> > specifically tailored to this developer audience is required. One that
> > cultivates new reusable libraries that people can use and improve.
>
> Yes, its called Jakarta Commons. Java reusable components. Now thats not
> what the charter says, but thats how it operates nowadays. Jakarta== Java.
Yep. Can we evangelize these to the rest of ASF? Maybe the solution to the
Jakarta Commons charter inaccuracy is to make ASF Commons be the solution
that works.
While it would have been political to have named Jakarta/Xml Commons as
the new ASF Commons, the dominance of the Java coders would have probably
kept the rest out, in much the same way that ASF Commons' lack of active
Java makes it hard for Jakarta to envision what life will be like there.
Re: Purpose of Multiple Commons was Re: DbUtils
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Justin Erenkrantz" <ju...@erenkrantz.com>
> I think the ultimate question here is what organization best benefits the
> committers.
Huh! Is this not very self centered? Surely we should be asking what is best
for ours customers/users.
My problem with Commons remains its cross-language aims, and I have always
disagreed with division by functionality. (For example start thinking about
what the website home page will be like. It will have an introduction and
then a list of Java components, and a list of Perl components and a list of
C# components....... No way is that ever serving the users well.)
The multi-language battle seems to be lost however, but the battle for
location of Java common code is still not settled. So I can still resist any
move of j-c to a multi-language area.
> Where there is not a strong tie to another Jakarta project, I
> firmly believe that the Jakarta Commons model causes exactly what Henri
> described:
>
> > The next step for these coders is to create more re-usable components.
> > However, these were not created by a Jakarta project, and have no
internal
> > community. They don't feel very Apache-y.
>
> I think we (as in the ASF) can do better. I think a project that is
> specifically tailored to this developer audience is required. One that
> cultivates new reusable libraries that people can use and improve.
Yes, its called Jakarta Commons. Java reusable components. Now thats not
what the charter says, but thats how it operates nowadays. Jakarta== Java.
Stephen
Purpose of Multiple Commons was Re: DbUtils
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, September 17, 2003 9:16 PM -0400 Sam Ruby <ru...@apache.org>
wrote:
> More seriously, I like to believe that this is a country where Boston
> Commons and Yosemite National Park can coexist.
You keep bringing up this example, but I think it's fatally flawed.
I think your prevailing attitude leads towards separation when we should be
trying to work together to achieve a common goal (no pun intended). We're all
in the same boat. Regardless of where code lives, it will be owned by the ASF.
I think the ultimate question here is what organization best benefits the
committers. Where there is not a strong tie to another Jakarta project, I
firmly believe that the Jakarta Commons model causes exactly what Henri
described:
> The next step for these coders is to create more re-usable components.
> However, these were not created by a Jakarta project, and have no internal
> community. They don't feel very Apache-y.
I think we (as in the ASF) can do better. I think a project that is
specifically tailored to this developer audience is required. One that
cultivates new reusable libraries that people can use and improve.
And, I'd almost be certain that this Commons PMC would look very different
than a lot of other PMCs. This ASF thing is all a grand experiment anyway.
-- justin
Re: DbUtils
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Sep 17, 2003 at 09:16:04PM -0400, Sam Ruby wrote:
> Greg Stein wrote:
> >
> > Oh, and the part of me that prefers unification rather than replication
> > wants to ask, "so Apache Commons will be here in five years. how about the
> > other foo-commons projects?" :-) hehehe...
>
> While I fully recognize that this is your master plan, there is a
What? Master plan?! I have *no* idea what you're talking about. Yah.
Really. Trust me...
:-)
> distinct possibility that there will be another chairman in place five
> years from now. :-) hehehe...
hehe. You bet.
> More seriously, I like to believe that this is a country where Boston
> Commons and Yosemite National Park can coexist.
>
> Furthermore, I believe that if you look hard enough, you will find
> microcommons in pretty much every code base - typically in a directory
> or package or module named utils or somesuch. This is where the umpteen
> implementations of base64 encoding live.
>
> Small pieces, loosely joined. Sure, unification of the large stuff for
> all the obvious reasons, but don't sweat the small stuff.
Agreed. But it also interferes with my rose-colored view, so knock it off.
:-)
--
Greg Stein, http://www.lyra.org/
Re: DbUtils
Posted by Sam Ruby <ru...@apache.org>.
Greg Stein wrote:
>
> Oh, and the part of me that prefers unification rather than replication
> wants to ask, "so Apache Commons will be here in five years. how about the
> other foo-commons projects?" :-) hehehe...
While I fully recognize that this is your master plan, there is a
distinct possibility that there will be another chairman in place five
years from now. :-) hehehe...
More seriously, I like to believe that this is a country where Boston
Commons and Yosemite National Park can coexist.
Furthermore, I believe that if you look hard enough, you will find
microcommons in pretty much every code base - typically in a directory
or package or module named utils or somesuch. This is where the umpteen
implementations of base64 encoding live.
Small pieces, loosely joined. Sure, unification of the large stuff for
all the obvious reasons, but don't sweat the small stuff.
Just my 2 cents.
> Cheers,
> -g
- Sam Ruby
Re: DbUtils
Posted by robert burrell donkin <rd...@apache.org>.
On Thursday, September 18, 2003, at 07:16 AM, Justin Erenkrantz wrote:
<snip>
> I don't buy that thread pools belong in Jakarta Commons. I'd believe
> that servlet containers belong in Jakarta Commons though. There's a
> qualitative difference. If people don't see that difference, then...
i think that people have misunderstood the point i was trying to make. i
think that there is a difference but try defining a rational policy that
quantifies where the line is drawn and you'll see the difficulties :)
to continue the example, is a thread pool contained within tomcat (for
example) out of scope because thread pools are out of scope? or does it
only become out-of-scope if it is factored out of tomcat so that it can be
more easily maintained and reused?
qualitative differences just come down to opinion. arguments about opinion
in the end can't really be settled rationally.
IMHO if the scope for jakarta (as intended by the board) cannot be
quantified and the board (and the members) are unhappy with the way that
scope has been quantified (by concensus) in jakarta then the i'd say that
the only fair thing to do would be to stop complaining about jakarta (and
its scope) and move all decisions about which projects and components are
in scope for jakarta up a level. the board should go through and decide
which can stay and which must go.
- robert
Re: DbUtils
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, September 17, 2003 11:52 PM -0400 Henri Yandell
<ba...@generationjava.com> wrote:
> 1) Is your project a child of an existing Jakarta project [see jelly]? Or
> a plan for adoption [see hivemind].
> If yes: Jakarta Commons. If no: Continue.
>
> 2) Is your project a child of a DB project [some component of OJB]?
> If yes: DB Commons. If no: Continue.
>
> 3) Apache Commons.
>
> Except...Xml Commons should be in there too. Also, Jelly is a child of
> Maven, and yet Maven is no longer a Jakarta project.
>
> What other options of input are there?
That's pretty much what I'd see as the litmus test. Ideally, I would like to
see a strong relationship with the 'children' residing in *-commons. Those
without such strong relationships belong in Commons.
I don't buy that thread pools belong in Jakarta Commons. I'd believe that
servlet containers belong in Jakarta Commons though. There's a qualitative
difference. If people don't see that difference, then...
Note that the HTTP Server PMC rejected serf because it's a client not a
server. I realize tight scopes of projects is unusual to people outside of
httpd-land, but it works for some of us. =)
>> But Commons *is* a separate TLP which sets its own goals.
>
> Ooo. A worthy advantage, Apache Commons is at a higher level in the ASF
> realm :)
Exactly. I believe the oversight within Commons TLP would be much stronger
than *-commons. One primary difference would be that Commons would be
specifically tailored for smaller projects.
> Tricky. A lot of code begins as one-man components, so do we just stick
> our fingers in our ears and ignore it until it becomes two-men components,
> ignoring the loss of cvs history, comments, and backup ability. Plus it
> makes it harder for the one-man to share.
I wouldn't have a problem with the following procedure:
1) Committer proposes new project idea on general@commons
2) PMC member decides to sponsor new project via email to PMC
3) If no one in PMC objects, committer can start project in commons repository
This allows one-man projects to start, but it has to pass the sanity check of
the Commons PMC. If the Commons PMC thinks it is a idea destined for failure,
they'll say so and reject it.
I don't know how that'll work in practice, but that's my suggestion. -- justin
Re: DbUtils
Posted by Henri Yandell <ba...@generationjava.com>.
On Wed, 17 Sep 2003, Greg Stein wrote:
> On Wed, Sep 17, 2003 at 11:26:45PM +0100, robert burrell donkin wrote:
> >...
> > anyway, rather than go over all the old arguments again, i'd say that it'd
> > be better to go forward by looking at the positives that apache commons
> > can offer (rather than getting into an argument about the jakarta mission
> > scope).
>
> Well, to be honest, that is kind of a weird question to me. "what do you
> have to offer?" Euh... project space?
>
> I mean really. The ASF is the same across the board. I don't see that
> there needs to be a one-up-man-ship here. "ooh! we have X and they don't!"
>
> That may not be what you meant, but when I read "what do you have to
> offer", that is how I translate it.
It is kind of what I meant, but not the spirit. In effect it's much like
having 'jakarta-oro and jakarta-regexp' to the average java user. They
just sit there and go...."huh?" and want someone to tell them which to
choose. We (the users) have to somehow be able to make a decision.
So there's a project foetus that is written in Java, about databases and
is reusable code. Because there is no dictatorial demands coming down from
on high [for reasons of cat-herding I would presume?], I'm trying to
figure out what the rules are I should apply to my basic set. For example:
1) Is your project a child of an existing Jakarta project [see jelly]? Or
a plan for adoption [see hivemind].
If yes: Jakarta Commons. If no: Continue.
2) Is your project a child of a DB project [some component of OJB]?
If yes: DB Commons. If no: Continue.
3) Apache Commons.
Except...Xml Commons should be in there too. Also, Jelly is a child of
Maven, and yet Maven is no longer a Jakarta project.
What other options of input are there?
Community seems a big one. Do I think that a project in Xxx Commons will
gain more from the community. Unless I'm scared of the number of people in
the community, the established Commons' [Jakarta, maybe XML] will be the
choice there. I might want to choose Apache Commons because it currently
feels quite httpd commons and therefore might have a high
knowledge/fraternity for non-Java code.
> Personally, I see Commons provide a community for building reusable
> components.
Matches the other Commons' I think.
> Those components are independent, rather than beholden to some
> larger project.
In charter, Jakarta Commons disagrees here. In reality it is the same.
Dunno for Xml and Db.
> Of course, there *does* need to be recognition and respect
> for your users, so versioning and API stability is very important.
No different than other Commons'.
> But Commons *is* a separate TLP which sets its own goals.
Ooo. A worthy advantage, Apache Commons is at a higher level in the ASF
realm :)
> The Commons Project also has a bit of self-definition to complete, too.
Yep. It's a large part of why I'm asking the questions.
> One of the outstanding questions is partitioning of commit rights. At the
> moment, I'm in favor of zero partitioning within TLPs. If you're a Commons
> committer, then you have rights on all components. Social norms and
> recognizing your knowledge/strenghts/weaknesses should keep people from
> breaking components outside of their typical areas of work.
Shouldn't be any problems with this. Apart from the usual language wars,
but we all know the rules for that kind of thing [obey the project
standard, obey the style of the original code etc].
> But from a
> responsibility standpoint, it is expected that all Commons committers
> would become part of the PMC, and that PMC is responsible for everything.
> Partitioning just monkeys all of that up.
Yep. This is a real plus of Apache Commons being a TLP. It is able to have
a functioning PMC and not just a loud corner.
> There is also a question of whether to have a sandbox. Do we allow people
> to run with a good idea? To start it from scratch? If we allow "from
> scratch" components here, then do we impose a minimum number of committers
> "signing up" to work on it? (i.e. no one-man component starts)
Tricky. A lot of code begins as one-man components, so do we just stick
our fingers in our ears and ignore it until it becomes two-men components,
ignoring the loss of cvs history, comments, and backup ability. Plus it
makes it harder for the one-man to share.
> Oh, and the part of me that prefers unification rather than replication
> wants to ask, "so Apache Commons will be here in five years. how about the
> other foo-commons projects?" :-) hehehe...
With one project a year being added, I think the other foo-commons
projects will have to still exist ;)
Hen
Re: DbUtils
Posted by robert burrell donkin <rd...@apache.org>.
On Thursday, September 18, 2003, at 01:54 AM, Greg Stein wrote:
> On Wed, Sep 17, 2003 at 11:26:45PM +0100, robert burrell donkin wrote:
>> ...
>> anyway, rather than go over all the old arguments again, i'd say that it'
>> d
>> be better to go forward by looking at the positives that apache commons
>> can offer (rather than getting into an argument about the jakarta mission
>> scope).
>
> Well, to be honest, that is kind of a weird question to me. "what do you
> have to offer?" Euh... project space?
i meant that i think it's important to be positive rather than negative.
(i didn't intend it to be a question.)
taking the (hypothetical) example of the thread pool, i would say that it'
s negative to say 'a thread pool is out of scope in jakarta and therefore
should be moved to apache commons'. a example of a positive encouragement
would be 'move to apache commons because the apache commons community can
help you learn to build better threading pools'. another example of a
positive encouragement would be 'a thread pool is more in-scope here and
will benefit from a move to apache commons since the community and goals
are better aligned than at jakarta'.
- robert