The problem is not that JCS is broken.. The problem is that Jakarta has a lot of subprojects that don't have the same focus. The consequence is that people not having any relationship with JCS, could make decisions that are not in the best interest for JCS (other way around is also possible). This is one of the main reasons for this thread.
Mvgr, Martin Tim Cronin wrote: > If it's not broke don't fix it. :D > > We use it with hibernate, caching of xsl transformations, etc... > > it seems like a stand alone project to us. > > -----Original Message----- > From: Aaron Smuts [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 23, 2007 3:50 PM > To: JCS Developers List > Subject: Re: turbine.apache.org? > > Is there any pressing reason why we need to worry > about this right now. Can we just get the release out > and them maybe revisit the question of JCS's home in a > few months? > > Cheers, > > Aaron > > --- Henri Yandell <[EMAIL PROTECTED]> wrote: > >> On 5/19/07, Scott Eade <[EMAIL PROTECTED]> >> wrote: >> >>> What you are really hinting at is that jakarta >> needs to find a home for >>> all of it's current sub-projects and that jcs is >> one of the these that >>> does not really have strong ties, community or >> otherwise, to any of the >>> projects currently spawning out of jakarta. >> It was more of a random thought - but yes, we do >> need to be thinking >> about where JCS's direction lies. >> >>> So as I see it there are really four options: >>> >>> 1. Approach db torque as a possible new home. >> In my opinion this is >>> less than ideal since the association is >> relatively arbitrary and >>> it would in effect be asking to become a >> sub-sub-project again (as >>> it was when it previously lived under >> turbine). >>> 2. Approach the new turbine TLP as a possible >> new home. Again, I >>> think this is a relatively arbitrary >> association. >>> 3. Propose to become a TLP. This isn't really >> an option I think - >>> jcs doesn't have the community to support >> it. >> >> An argument I have here is that if a project can't >> be a TLP then it >> can't be a Jakarta subproject. ie) >> The way we treat Jakarta subprojects now is pretty >> much the same as a >> TLP - if you don't have a large enough slice of the >> PMC performing >> oversight then it's a problem. Large enough = 3; and >> while we allow >> that it does seem tight for a TLP. >> >>> 4. Approach commons about jcs becoming a >> releasable component. To me >>> this seems like it might be the best way to >> go as it would not >>> bury jcs under an arbitrarily unrelated >> project, but rather it >>> would include it in a collection of useful >> components where it >>> could gain better exposure than it currently >> does. >> >> Commons would mean merging dev (and probably user) >> mailing lists into >> commons-dev/commons-user. That's the biggest change. >> >> Hen >> >> > --------------------------------------------------------------------- >> 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] > > > > --------------------------------------------------------------------- > 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]
