db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Dudziak <to...@first.gmd.de>
Subject Re: XDoclet Module (and other tools)
Date Wed, 12 Nov 2003 15:29:31 GMT
> Erik and Andrew both feel that the best place is in the OJB repository, 
> or rather, outside of XDoclet as the XDoclet team is apparently trying 
> to push all the "included" modules out and get the various vendors to 
> maintain them directly. Andrew indicated that he would be willing to 
> check it in for the 1.X branch, but that the 1.X branch isn't going to 
> be around past the next release -- and for 2.0 they are apparently 
> trying to push the vendor specific (which OJB falls under) modules back 
> out to the vendors to maintain and only include core stuff (generic 
> EJB, servlet, etc, I imagine) in their repository.


This seems like a reasonable notion as it would shift the maintenance to
the people that actually use the module (e.g. the JBoss, TJDO, ... people
ensure that the xdoclet module for them work). Also this allows for a
better build/release schedule as the module development should have higher
performance than the complete xdoclet tree.


> Right now we are keeping a jar in the contrib project of our cvs 
> repository -- I would like to find a place to put the source under CVS 
> as well. I think that helping keep tool support up to date and easily 
> available is important for OJB's larger acceptance, so we should think 
> about this some.
> 
> As the number of tools in the OJB repository is growing I think it 
> might be good to consider their appropriate homes. This includes the 
> reversedb, xdoclet module, middlegen module, etc.
> 
> So, some options that I see:
> 
> 1) Create a tools CVS module under OJB and give them their own build 
> chain(s).
> 2) Create an ojb-tools project analogous to velocity-tools
> 3) Host at java.net or SF and prominently advertise them on the OJB site
> 
> 2 doesn't seem completely appropriate
> 1 keeps communication open and makes it easier to distribute things 
> en-masse
> 3 allows for easier licensing flexibility for things like the OSCache 
> ObjectCache


I don't know about the velocity-tools project, so I cannot say
much about option 2. As for options 1 and 3, the major difference
(ignoring technical and infrastructural aspects) is the level of
association to OJB. When tools are hosted by OJB, then they are tied to
OJB, e.g. people with problems will call for help on the OJB mailing
lists. If they are related projects but on SF or elsewhere, they probably
have to and will ask on the respective mailing lists and forums there. So
I guess both options are reasonable.
For instance, I'd say the xdoclet module is rather tightly related to OJB,
so hosting it on OJB makes sense to me. Whereas tools in the direction of
Druid (which is of course not OJB specific, but anyway) should "only" be
heavily advertised on OJB, but not integrated into the CVS tree of OJB.
Of course, there already are projects tightly related to OJB outside of
the OJB CVS. At least one, the OJB console (http://ojbc.sourceforge.net),
comes to my mind. Perhaps the developers of this project can say
something about which option is better ?

Tom


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


Mime
View raw message