> > - Another check which is missing is Ant <property/> checks. > > As you know it's for some time that xdoclet also supports > > setting @tag parameter values via Ant properties. I'm > > wondering how we can also check this one! If done correctly I > > think xdoclet's regeneration mechanism will be complete. > > True, I did not think about that. > > > Maybe a good solution is to check build.xml's timestamp and > > assume a property change when the file is modified? I don't > > know whether there's a way to find out the current build.xml > > file via Ant's API or not. But that's even more complicated, > > because user can specify properties in a separate property > > file. A through look at Ant's API will show us whether it's > > possible or not.
Mmmm after thinking a bit more this will have a bad consequence : if I add a new task for some new beans (or if I change anything else than this property in fact), then a force generation will be made even if I don't need it. So this would be better if this check only happens if a property is set in the build file and not in other cases. Which will complicate what we need from Ant's API... I will have a deeper look though... > > Let me add another one : when a xdoclet developer modify a > Class or a J file, the generation should be forced as well, I > don't see how to handle that except having a xdoclet version > (a verbose one with a timestamp or > sth) that change every time xdoclet.jar is changed (and that > solve the problem (**) as well). An auto version in the > Manifest of xdoclet.jar looked back by the class inside the > JAR itself. Don't know... The solution was easier in fact : now I checked the timestamp of JARS inside the doclet classpath, if xdoclet has changed, xdoclet.jar has changed and a re-generation is done. Vincent _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
