Santiago Gala wrote:
Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:
It seems that we are converging toward a stable gump setup. This is very nice and very useful to help us solidify our contracts and make it visible for other projects underneath our food chain to watch us.
Currently, 6 blocks fail. I'm listing the problems
<snip/>
the really broken ones are:
- fop
Latest FOP release is fop-0.20.5rc2 coming from the maintainance branch. This release still has org.apache.fop.apps.Options class. But in CVS head it was removed (in favor of something better, I presume. AFAIK fop is moving towards Avalon).
As we recenlty agreed, Cocoon should base on the released stuff. Thus, I don't see how GUMP could be fixed.
Nagging FOP developers to deprecate those classes but keep an implementation in term of the new ones at least during one full development/release cycle?
They have those classes. In the branch. Same situation as we had recently before repository split-up.
But, If they have documented (http://xml.apache.org/fop/embedding.html) the use of the Options class, they should be aware that users are not like computers, i.e. they need time to understand changes, plan for migration and migrate.
They could keep them in HEAD, and have them in the first 1.0 release, deprecated. Or, alternatively, a "fop-020-compatibility.jar" could be kept in HEAD with impls of those missing classes, to ease migration. This would bring the extra added value of having users able to test the new stuff without having to change code, while keeping them conscious that they are relying on deprecated, dangerous stuff.
I think (I'm not sure) this is the approach Avalon is taking.
The good thing about gump is that it makes us aware of such stuff much in advance.
Vadim
-- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog
