> > I agree with all items except -Dxdoclet.force=true. > > I think there's no need for this parameter if we do a good > > job of checking all cases correctly (merge files, > > superclasses, etc). And I think we can further improve it by > > making it more implicit (I've already went that path, for > > example by making ejb:bean name param optional). We can > > indeed handle the ejb-jar.xml regeneration issue too, again > > if we tackle all cases. > > My problem is that if one issue that is not linked to timestamp occurs, > we still have to touch the files to force the regeneration. > For example, if I restore a file with an old timestamp, If I change a > superclass with another one that already exists, ... > Having to keep an Ant task with the touch on the individual files force > me to remember wich files are xdoclet-generated and I don't like that. > I also believe some day use tags on "interfaces" could give something > like multiple inheritance to java (for entity beans mainly), then the > complexity of timestamp checking will even be more complex to follow. > > Please reconsider this :)
Well, then please do a clean before building it :-) and I guess that's what force does. Only for those cases. But hardly force param is good for dummies :-) > BTW, I have the force implemented now :) > I have also timestamp checking on superclasses working :) > I am going through DD generation now (and merge files timestamp checking > as well) which imho will make xdoclet the killer app for ejb > configuration (while it is already for ejb deployment) :) Really? Wow! A major feature! Please commit it ASAP, I'm very interested. Who do you handle merge files?? Ara. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
