> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:xdoclet-devel-admin@;lists.sourceforge.net]On Behalf Of David > Jencks > Sent: 17. oktober 2002 18:39 > To: xdoclet-devel > Subject: [Xdoclet-devel] How many jdo modules do we need? One per > vendor? > > > Hi, > > Ludovic Claude submitted some nice subtasks for doing vendor extensions in > the jdo module. He's written them as a separate module for each > jdo vendor > (currently 2, LiDO and Solarmetric/KODO) More are sure to come soon (I > have to write one for tjdo). These vendor specific subtasks are going to > have about 2 files each. > > Do we want them as a separate module for each vendor or should they all go > under the jdo module? >
I think they should be kept as distinct modules. The new architecture (in the xdoclet2 CVS module) will have a one-one relationship between <subtask> and plugin directory. (plugin is the new name for module). One per vendor. > At a more fundamental level, he's implemented these based on tags like > > @kodo.table > > I think a lot of these tags will be essentially the same for all jdo > implementations based on rdbms. I wonder if we should try to be more > universal, like > > @jdo table="blah" > > or even > > @jdo persistence-location="blah" > > Any comments? > I do :-) I participated in some email discussions a few days ago with the people on cc here about representing "database metadata" as tags. I wrote some words about this in my blog: http://roller.anthonyeden.com/page/rinkrank/. Scroll down to "Synergy!!" and read the last part of that post. My point is that I think we should settle on something even more generic than @jdo and @ejb, because the information we put in these tags is the same. IMO it should be @sql, @jdbc or @rdbms. Further, I think we should stick to namespaces (dotted tag names) for the sake of consistency. Who knows, they might have a programmatic sense one day, and it would be a shame if we invented lots of "namespace-less" tags. My suggestion is therefore: Instead of @ejb.persistence table-name="blah" @jdo table="blah" We could go for @sql.table name="blah" Then who knows, maybe you can write a simple java bean, and let XDoclet decide whether it should turn it into a JDO, EJB or some other persistent-aware class. This is kind of the way I think when I do OO programming. Anything generic that can be used in different scenarios deserves its own class. It should be the same way for @tags, and I think this is a perfect example for that. We already have a (albeit dirty) mechanism for supporting BWC on the tag level, and this can be made better in xdoclet2. What do you think? > thanks > david jencks > > > ------------------------------------------------------- > This sf.net email is sponsored by: viaVerio will pay you up to > $1,000 for every account that you consolidate with us. > http://ad.doubleclick.net/clk;4749864;7604308;v? > http://www.viaverio.com/consolidator/osdn.cfm > _______________________________________________ > Xdoclet-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-devel ------------------------------------------------------- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
