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]
