Stefano Mazzocchi wrote: > > I think Keiron has a good point: wouldn't it be possible for Gump to use > a particular tagged version of another project instead of the latest one > from CVS?
Would it be possible? Yes. Simply specify a tag= attribute on the project you wish to lock on a specific target. One need not even modify any project definition, you can simply add this information in your workspace. This is all documented. Now let me get to the real underlying root cause of the issue. It would be my preference if FOP were able to be run against a range of versions of Batik, not merely against one specific snapshot and that one specific snapshot only. More specifically, my preference would be that the range of supported versions of batik included at least two Released versions. For this to work, Batik would have to respect some level of backwards compatibility. Deprecating interfaces. Renaming classes when a substantial change is required that is not backwards compatible. Or FOP would have to employ a bit of reflection to invoke the desired interface. The real question in my mind is - is the information provided by Gump useful? Would it be made any more or less useful by nailing down the version of Batik that FOP was compiled against? - Sam Ruby -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
