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]
