Ara, > 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 :) 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) :) Vincent. _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
