Keiron Liddle wrote: > > I would like to raise an issue about this. I am not complaining, just > pointing out some things.
Remember - the point of Gump is to encourage people to communicate. Are the fop and batik people communicating, or is the gump nags the only form of communication for these changes between the two projects? > I Fop is updated to comply with the api in the current batik cvs then fop > will only work with that cvs build. > So for example if a release of fop is made in the meantime (eg. 0.20.1 and > 0.20.2) then they will only work with the batik version that comes with the > build. It is not possible for the user to get the latest version of batik, > for example batik 1.1, when it comes out and use that. > It might be possible to release a new version of fop but this is a bit more > difficult and time consuming in our current situation. > This gets worse when another project is using fop and batik (eg. cocoon) > and may also be updating the jars at various times. Absolutely correct. > Realistically a "proper" version of fop can only be released along with a > stablised api version of batik. > It seems that keeping up to date with cvs of other libs doesn't always > solve any problems and may actually create some. Agreed. My stated preference is that batik provide backwards compatible APIs, perhaps deprecated. Failing that, it would be nice if they could tell you once and for all, this is what the new API is going to be, instead of you having to discover a new change that impacts you every week or so. It may also be possible with reflection tricks or ant tricks (I can point out plenty of examples of each) to write a single source base that either can work with each, or at least can compile against each. But failing that, the options as I see it are: 1) try to stay up, and hope that batik releases first. 2) revert to the last release, but keep the gump runs and nags as "informational". 3) revert to the last releaes, keep the gump runs, but discontinue the nags 4) drop xml-fop from gump entirely at the moment. You are right to be thinking about these issues in the way that you are. I probably should start a FAQ for gump as too many people assume that any reported compilation error should be fixed, but that is not always the correct solution. - Sam Ruby P.S. In a prior time where one project was routinely breaking another, I took the step of adding a notification to the culprit if their project's name was found in any of the error messages in the compilation of the victims project. My goal is to do whatever it takes to get the projects talking. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
