The final case that will brake the build.xml timestamp decision is the use of -Dproperty= from the command line, then the timestamp checking on build.xml will simply not work. So I propose to not check this one at all, document the decision of generation based on timestamp completely in all aspects and leave the user choose to use the force option when he needs to. <uptodate> ant task can be used to set force to true when "any" timestamp checking is needed. Let me know if you agree.
Vincent. > > > - 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... _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
