I completely agree with Geir. IMAO, what is bad is when people in a project ignore (sometimes deliberately) all prior art and even newer ideas about the same subject that their project covers.
But duplication as many advantages. Different styles, different choices. And I don't give a shit about how it looks to the outside because: - This is not a commercial organization; - If we have a specific target audience, it is a technical one that makes a well informed choice... or they would be flocking toward organizations with a more corporate look and culture. Have fun, Paulo Gaspar > -----Original Message----- > From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 26, 2002 9:35 PM > To: Jakarta Commons Developers List > Subject: Re: [PROPOSAL] Commons-API (was Re: [pool] PROPOSAL: add > collecting of statistics to pool implementations) > > > On 4/26/02 2:54 PM, "Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote: > > > > > I have tried myself to make projects cooperate on Jakarta, and there are > > cases in which one part simply refuses to do it. > > > > This is the reason why there are duplicate projects, and why > projects keep > > making subprojects that have less an less to do with the > original project. > > That's *one* reason why. Sometimes just taking a different path to > solutionof the problem is the reason, and that's good enough. > > (See Turbine + Struts) > > > It seems to me, and to many outside viewers, that there is a > sort of anarchy > > in the way subprojects are created, making code duplication a reality. > > Which I think has some very positive qualities. > > > There is not a unified vision, if not the Apache license and > the "server" > > mission. > > Indeed. > > > I can live with this, and I see that it can bring good things. > If projects > > compete, they can benefit from each other, since the source is > there to see > > and the license permits it. > > > > The downside is how we are seen from the outside... > > > > -oOo- > > > > IMHO Jakarta should favor the use of common interfaces. > > No. I think subprojects should do whatever the participants in the > subproject decide. If there is a compelling set of interfaces or > components > and they wish to use them, that's great. If not, that's great. > > > Interfaces can become standards, and this is how Apache can create > > "de-facto" APIs. > > > > This way projects can give the user functionality without > locking him into > > their API for common functionality. > > > > What about *Commons-API*? > > > > Kinda smells like a framework. :) > > We have a de-facto commons API. That's what the components are, all > independent, and the overlap in the community means that there tends to be > quite a bit of interdependence between them, which strengthens those that > seem to work well. > > So I would say that in a sense, we already have one. > > > -- > Geir Magnusson Jr. [EMAIL PROTECTED] > System and Software Consulting > "We will be judged not by the monuments we build, but by the monuments we > destroy" - Ada Louise Huxtable > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
