Mailing-List: contact torque-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Torque Developers List" <torque-dev@db.apache.org>
Received-SPF: pass (nike.apache.org: domain of greg.monroe@dukece.com
 designates 152.3.166.24 as permitted sender)
From: Greg Monroe <Greg.Monroe@dukece.com>
To: 'Apache Torque Developers List' <torque-dev@db.apache.org>
Date: Mon, 8 Mar 2010 10:56:35 -0500
Subject: RE: torque 4 site and further actions
Thread-Topic: torque 4 site and further actions
Thread-Index: Acq8rpIZYlKAbODnTiiaoR05Iv82zACHZFvw
Message-ID: 
 <55B8568AFA5F144F886F18186BAD5B2C05FC8DAA93@durham-e2k7mb1.dukece.com>
References: 
 <OF73C29172.59D75DDE-ONC12576DD.006CE964-C12576DD.00785D57@seitenbau.net>
In-Reply-To: 
 <OF73C29172.59D75DDE-ONC12576DD.006CE964-C12576DD.00785D57@seitenbau.net>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"

Take a three day weekend and=2E=2E=2E=2Elol  (BTW - Big THANKS Thomas F for=
 doing=0D=0Aall this=2E=2E=2E)=0D=0A=0D=0A> The Torque 4 site is deployed a=
t=0D=0A> http://db=2Eapache=2Eorg/torque/releases/torque-4=2E0/index=2Ehtml=
=0D=0A> It is not yet linked from the main Torque site, my plan is to do th=
at on=0D=0A> monday=2E So if you find any errors there, there is still time=
 to correct=0D=0A> them=2E=0D=0A=0D=0AHaven't had time to review=2E=2E will=
 do it later today=2E=0D=0A=0D=0A> =0D=0A> The test project is now running =
for the following databases:=0D=0A> - postgresql=0D=0A> - oracle=0D=0A> - m=
ysql=0D=0A> - mssql=0D=0A> with id method "native"=2E There are some remain=
ing problems with the id=0D=0A> methid "idbroker", but I am confident I 'll=
 have it sorted out in the=0D=0A> near future=2E=0D=0A> I also still need t=
o figure out how to best treat the conditional manager=0D=0A> and bean test=
s, but I'll document it on the site once this is done=2E=0D=0A> further act=
ions:=0D=0A=0D=0AOnce the dust settles, I may blow the dust off some test p=
roject mods I was =0D=0Aplaying with during the 3=2E3 release=2E  I was bas=
ically trying to simplify=0D=0Arunning the test project against the common =
variations of build options=0D=0Ain a standardized way=2E See:=0D=0A=0D=0Ah=
ttp://www=2Email-archive=2Ecom/torque-dev@db=2Eapache=2Eorg/msg04681=2Ehtml=
=0D=0A=0D=0A> - The external-schema support is missing, I hope I get at it =
in the near=0D=0A> future=2E  However, I'm curious to know what it is good =
for=2E Does anybody=0D=0A> have a use case ?=0D=0A=0D=0AI use this as follo=
ws:=0D=0A=0D=0AI have a core project which has its own DB schema which gene=
rates it's=0D=0Aown set of Torque packages=2E=0D=0A=0D=0AThe core project h=
as several "plug ins" that interact with various 3rd =0D=0Aparty applicatio=
ns=2E  Each "plug in" has its own Torque schema that =0D=0Amodels the 3rd p=
arty DB plus any "interface" tables that map core to =0D=0Aplug-in=2E I sep=
arate the 3rd party DB from my interface tables into=0D=0Atheir own XML fil=
es=2E  Each of these are generated into their own =0D=0Apackages=2E=0D=0A=
=0D=0AThe plug-in interface tables use keys from the core tables and the 3r=
d=0D=0Aparty schema=2E  So, I use the external-schema to include them so it=
 can =0D=0Ause the key columns required=2E=0D=0A=0D=0AI also use it with a =
master test project that builds the entire system=0D=0Awith all plug-ins (e=
=2Eg=2E master schema includes all subschema)=2E=0D=0A=0D=0AThis allows me =
to easily maintain changes in 3rd party code, interface=0D=0Acode and the c=
ore=2E   =0D=0A=0D=0A> - As the tool for code generator is called generator=
, and there is an=0D=0A> interface inside it for a class that produces text=
 for the output which=0D=0A> is also called generator , my personal opinion=
 is that the name of one=0D=0A> object should be changed to avoid confusion=
=2E As the name for the module =0D=0A> is quite old, the interface name sho=
uld be changed, and the references to =0D=0A> it in the configuration=2E I'=
m still not sure which name to use=2E possible =0D=0A> candidates that come=
 to my mind are TextWriter, TextCreator, OutputWriter,=0D=0A> OutputCreator=
=2E=2E=2E any recommendations or other ideas ?=0D=0A=0D=0A+1 on removing ov=
erloaded terminology=2E=2E not sure what it should be =0D=0Acalled but in t=
his age of auto completing editors=2E=2E=2E don't be afraid of =0D=0Along n=
ames like GeneratorInterface=2E  FWIW - In naming stuff, I tend to =0D=0Atr=
y to distill down what the class will be responsible for=2E  I generally =
=0D=0Astart with trying to get first Javadoc line as clear as possible then=
=0D=0Ago from there=2E=0D=0A=0D=0A> - Currently the maven2 generator plugin=
 is just a frontend for the=0D=0A> current code generator=2E However, there=
 are a few goals from the old =0D=0A> generator which should probably remai=
n like jdbc2xml=2E I'd like to =0D=0A> investigate whether we want to provi=
de the functionality or if we can =0D=0A> use ddlutils for some tasks=2E=0D=
=0A=0D=0AMore on this in a separate e-mail=2E=2E=2E FWIW - When I've pushed=
 DDLUtils=0D=0Ain the past, I was thinking more about using it's API to sup=
port =0D=0ATorque's targets rather than dropping them=2E  It would be less =
of a=0D=0A"shock" to current users=2E=0D=0A=0D=0A> - Ant integration for th=
e generator is still missing=2E This should not be=0D=0A> a big problem, bu=
t needs to be done=2E In my opinion, this should go into a=0D=0A> separate =
small package torque-ant-tools=0D=0A=0D=0ASound good=2E=2E=2E IMHO - we can=
't release a Torque package without ant support=2E=0D=0A=0D=0A> - Do we sti=
ll want to support java 1=2E4 in Torque 4 runtime & generated=0D=0A> classe=
s ?=0D=0A=0D=0A+1 on moving to 1=2E5=2E  This would probably simplify the t=
emplates greatly=2E=0D=0A=0D=0A> - Which databases do we want to support in=
 Torque 4 ? I believe e=2Eg=2E the=0D=0A> claim that we support db2 in Torq=
ue 3=2E3 is just nonsense, we do not have=0D=0A> a driver for any recent db=
2 database=2E So my suggestion is to concentrate =0D=0A> on the databases t=
hat we really support and which we test with each release=2E=0D=0A> A sugge=
stion for this set would be mysql, postgresql, mssql, oracle, derby=0D=0A> =
and hsqldb=2E What do you think ?=0D=0A=0D=0AI agree on focusing/testing on=
 these popular dbs=2E=2E but I don't think we=0D=0Ashould drop "db2" from t=
he docs=2E  Perhaps we could have a "testing and=0D=0Asupported" DB list an=
d a "legacy " list (e=2Eg=2E db2, Sybase, and MS Access=0D=0Acome to mind)=
=2E  These could have a note that we'd welcome someone who=0D=0Awants to fu=
lly support one of these=2E  The idea is to focus but still=0D=0Ashow flexi=
bility=2E=0D=0A=0D=0A=0D=0ADukeCE Privacy Statement:=0D=0APlease be advised=
 that this e-mail and any files transmitted with=0Ait are confidential comm=
unication or may otherwise be privileged or=0Aconfidential and are intended=
 solely for the individual or entity=0Ato whom they are addressed=2E If you=
 are not the intended recipient=0Ayou may not rely on the contents of this =
email or any attachments,=0Aand we ask that you please not read, copy or re=
transmit this=0Acommunication, but reply to the sender and destroy the emai=
l, its=0Acontents, and all copies thereof immediately=2E Any unauthorized=
=0Adissemination, distribution or copying of this communication is=0Astrict=
ly prohibited=2E

---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org