The vendor extension elements should end up in different places with field and collection tags. If not, can you demonstrate just what happens?
thanks david jencks On 2003.03.05 08:16 Michael Mattox wrote: > I build the latest version from CVS and I'm using it now. I noticed this > in > the samples: > > /** > * @jdo.field > * collection-type="collection" > * embedded-element="false" > * element-type="test.jdo.SuperChild" > * default-fetch-group="true" > * @jdo.collection-vendor-extension > * vendor-name="test" > * key="collection-key1" > * value="collection-value1" > > The @jdo.collection-vendor-extension isn't needed, > @jdo.field-vendor-extension works just fine. > > Thanks, > Michael > > > This is in cvs already. I think I even added some usage in the samples > > > > > A week ago there was a discussion about adding a generic jdo vendor > > > extension capability to the XDoclet JDO tags. Something like: > > > > > > <extension vendor-name="kodo" key="key-dependent" > > > value="true"/> > > > > > > I remember someone said it was relatively easy by modifying > jdo_xml.xdt. > > > Has there been a patch for this? I've looked at the file and it's > not > > > clear > > > to me what needs to be changed. > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > xdoclet-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-user > > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
