I meant +1 to jakarta-commons going TLP Concerning incubation: Why? Which of the things that should be cleared up while being incubated is missing in commons-sql?
Oliver On Thu, 9 Dec 2004 15:59:44 +0000 (UTC), Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: > Oliver Zeigermann <[EMAIL PROTECTED]> writes: > > >Jakarta Commons is so huge that I'd be +1 to make it a TLP. > > What? Jakarta-Commons or commons-sql? > > +0 to jakarta-commons going TLP > > -1 to commons-sql > > -0 to put common-sql directly into DB > > I skimmed the commons-sql code a bit and IMHO this needs > incubation. The code sat in the CVS for quite a while until recently a > few people started hacking on it. > > The structure is quite similar to some of the SQL generation parts of > the torque-generator so limiting this project to SQL generation would > IMHO be a bad move. > > I fact, commons-sql could even be split into multiple parts: > > - a data model (currently focused on database, table, column) > > - a templating backend that builds output files from the data > model (currently commons-sql just builds SQL files; the > torque-generator can build SQL files and source for Torque and OJB) > > - a driver which controls the generation process. There is a > limited driver with the Texen part of Velocity > > In fact, only the implementation of the first two parts is really DB > scope. > > commons-sql IMHO must show into which direction it wants to > evolve: > > - Being an abstract data model for a database (then we lack things > like sequence or view representations) which can be used in things > like a code or SQL generator > > - Being an SQL code generator, thus omitting the possible distinction > > - Being an all-purpose SQL swiss knife. > > In any case, IMHO it should go through incubation. > > Regards > Henning > > > > > >Oliver > > >On Wed, 8 Dec 2004 18:04:08 -0500, Henri Yandell <[EMAIL PROTECTED]> wrote: > >> To repeat my objections slightly more in full: > >> > >> I think commons-sql should become db.apache.org/sql or some new name. > >> Unless there are a lot of components at db.apache.org; I think we > >> should be careful before kicking another commons repository into > >> action and increasing confusion. > >> > >> If the commons part is really important, but being inside Jakarta is a > >> problem, I think we should start thinking again about asking for TLP > >> for Jakarta Commons, bringing Xml Commons into it and dealing with the > >> growth/scope issues as they happen. > >> > >> Hen > >> > >> > >> > >> On Wed, 08 Dec 2004 21:32:30 +0100, Thomas Dudziak <[EMAIL PROTECTED]> > >> wrote: > >> > (This is a repost from a vote that I started earlier today, but where I > >> > did not include commons-dev. This omission has been pointed out to me, > >> > and I agree that including commons-dev is important, so I repost the > >> > vote hereby) > >> > > >> > Hi all, > >> > > >> > I'd like to start a cross-vote (Jakarta PMC and commons-dev, DB PMC) > >> > about moving the jakarta sandbox project commons-sql > >> > (http://jakarta.apache.org/commons/sandbox/sql/) over to db.apache.org, > >> > for instance into the currently vacant db-commons space > >> > (http://db.apache.org/commons/). > >> > > >> > The reasons why we want to move commons-sql, are twofold: > >> > > >> > * The two active committers (Martin Kalén and myself) are DB comitters, > >> > but not comitters to another Jakarta project. As a result we would > >> > rather not subscribe to commons-dev/commons-user because very few mails > >> > there deal with commons-sql (one or two per month). Also, db-commons > >> > already has all setup'd (mailing lists, CVS space etc.), not to mention > >> > that the exposure of the project would be much greater. > >> > > >> > * No other Jakarta project that I'm aware of, uses commons-sql. In > >> > contrast, OJB will do so (beginning with the upcoming 1.1 version), and > >> > so it would be good to provide access to the commons-sql repository to > >> > the OJB comitters. The same might also be true for Torque as > >> > commons-sql's functionality overlaps in some parts with Torque > >> > functionality, which opens up an opportunity to combine this > >> > functionality into a base component which both OJB and Torque could use. > >> > > >> > Please post your opinion until next wednesday, the 15th of december, and > >> > please reply to all recipients. > >> > > >> > Votes cast so far: > >> > > >> > +1 Brian McCallister > >> > +1 Henri Yandell > >> > (though with objections regarding moving it into db-commons, > >> > http://db.apache.org/commons) > >> > +1 Henning Schmiedehausen > >> > > >> > regards, > >> > Thomas Dudziak > >> > > >> > PS: I'm not sure if this is the correct procedure, but I thought a vote > >> > is at least a good way to get the ball rolling, so to speak. If there is > >> > a defined way to handle movement of projects, then please let me know. > >> > > >> > --------------------------------------------------------------------- > >> > 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] > > -- > Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH > [EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/ > > RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire > Linux, Java, perl, Solaris -- Consulting, Training, Development > > What is more important to you... > [ ] Product Security > or [ ] Quality of Sales and Marketing Support > -- actual question from a Microsoft customer survey > > > > --------------------------------------------------------------------- > 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]
