You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Jeremias Maerki <de...@greenmail.ch> on 2003/04/09 15:20:03 UTC
Re: Are xml-fop and cocoon-block-fop friends of Gump? [was: How to detect "Friends of Gump"]
On 08.04.2003 22:54:36 Sam Ruby wrote:
> Jeremias Maerki wrote:
> > Uh, I think we should try to create a second Gump run for the
> > maintenance branch of FOP. The Cocoon FOP block is based on the
> > maintenance branch and should be for the next few months. But FOP's Gump
> > run is loaded from HEAD and represents the FOP currently in redesign.
> > And that API has changed and will change again.
> >
> > The tag to use would be: fop-0_20_2-maintain in the xml-fop module
> >
> > Is that an easy thing to do?
> >
> > On 08.04.2003 19:25:05 Sam Ruby wrote:
> >
> >>Question: is cocoon-block-fop a friend of gump?
> >
> > Jeremias Maerki
>
> Is is possible? Yes.
>
> Will I resist it? Yes.
>
> What is 2 to the 100th power? A very big number.
>
> Permit me to explain.
Good thing you do. :-)
> This is not the first time in the history of Gump that Fop has had a
> major redesign.
When did Gump start? I'm following the FOP project since Fall 2000 and
I am a committer for 12 months now and there's only one redesign effort
I'm aware of. More below.
> Like Avalon was for the first year or so of Gump, Fop
> seems to be a project in perpetual alpha.
Not true. Only because our releases have version numbers like 0.20.4,
0.20.5 doesn't mean we're in perpetual alpha. The general agreement is
that version 1.0 should be the version that supports at least basic
conformance level of the XSL-FO spec. Maybe that decision was bad with
hindsight. Fact is that a lot of people use FOP in production and most
are very happy even if we still haven't reache basic confirmance level.
> Avalon I now have some real
> hope for. I'm not so sure of Fop. I know that seems unduly harsh, but
> I sense that that's the real essence of the metric that Stefano is
> seeking: projects that one dare not depend on because they are currently
> (and possibly perpetually?) in redesign.
Being in redesign and having an unstable API are two different things.
Redesign started in fall 2001 and continues today. The reason was to be
able to reach basic conformance level in the first place because it was
found that it wasn't possible with the existing codebase. Releases come
from the maintenance branch mentioned in the other mail. We're finally
reaching consensus not to release another version from that branch after
version 0.20.5 which is due soon. The two-track way cost us a lot of
power especially in this light: It happens that the whole team with the
exception of about two people gradually left the project being replaced
by others. But I'm pretty sure that wasn't because (!) the redesign got
started even if you may get the impression. Loss of know-how and power
while our pretty huge user base remained and had to be made happy.
Well, maybe the FOP team should have requested a separate CVS space for
the redesign as other projects did. Maybe that had brought us some
different feedback in this matter. Maybe we shouldn't have called our
production releases 0.20.x.
> The reason I asked the question above is that the initial metrics that
> Stefano proposed would lead one to the conclusion that fop is like junit
> - one never sees a failure. And that cocoon-block-fop is like xindice -
> fails continuously but nobody cares.
Double-nag Cocoon and FOP! Helps the Cocoon guys and prevents us FOP
guys from accidentally changing the API (which I admit happened before).
> Now, to answer your question: it IS possible to build individual
> versions of each dependency. So we can build 2 versions of fop. Now
> consider the sheer combinatorics of building the individual versions of
> each dependency that each project has declared that they depend on.
> That's a very big number.
In this light you should probably delete quite a bunch of Gump projects.
Fact is that FOP still has two main development tracks as do other
projects so it may make sense to have the two even if it is just for our
feedback.
> Now lets look at the information value of doing such a build. Presumaby
> the people within Cocoon frequently build with the snapshot version of
> fop that they have checked into their cvs. That path is therefore well
> tested. Reproducing that build with the maintenance version of fop
> provides marginal additional information.
No. It would give the Cocoon guys greater confidence if they want to
upgrade their version of FOP and that's not marginal IMO. Also makes
sure that it's easier for a Cocoon user to upgrade the FOP version
locally without asking for trouble.
> Depending on my mood, my recommendation is to either to remove the nag
> but keep the build for cocoon-block-fop. Or to change the destination
> of the nag to be fop's dev mailing list, i.e., the true culprits.
As I said: double-nag. That's what encourages communication. Blaming
anyone doesn't help.
> Now, let me turn the question around: is is possible for fop to create a
> deprecated compatibility api to ease the transition for projects like
> cocoon who have been valued 'customers' of fop since pretty much the
> beginning of the project?
Should be doable although I'm pretty unhappy to reintroduce some ugly
things from the past (MessageHandler). I'll ping the team. We're trying
(with the redesign) to get away from the bloody static constructs used
all around FOP. Just look at the Cocoon-FOP-block sources to see how the
Cocoon guys dislike FOP's API. And they are right.
My take:
- Add a Gump run for FOP's maintenance branch
- Let cocoon-block-fop depend on the maintenance branch for the moment
- Double-nag FOP and Cocoon lists for cocoon-block-fop
- FOP team will look into improving the API situation
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Are xml-fop and cocoon-block-fop friends of Gump? [was: How to detect "Friends of Gump"]
Posted by Jeremias Maerki <de...@greenmail.ch>.
Stephan Michels already did the change. :-)
On 10.04.2003 11:18:24 Stefano Mazzocchi wrote:
> on 4/10/03 10:39 AM Jeremias Maerki wrote:
>
>
> >>>- Let cocoon-block-fop depend on the maintenance branch for the moment
> >>>- Double-nag FOP and Cocoon lists for cocoon-block-fop
> >
> >
> > I don't have write access to Cocoon's gump descriptor. Will drop them a
> > note.
>
> I'm doing it right now.
Jeremias Maerki
Re: Are xml-fop and cocoon-block-fop friends of Gump? [was: How to detect "Friends of Gump"]
Posted by Jeremias Maerki <de...@greenmail.ch>.
*GRIN*
Well, this one is easy enough to fix and I had already handled it for
HEAD/redesign. Have just fixed it in CVS.
But you're right, I should probably nag the Batik guys about that thing.
One more mailing list to subscribe to. :-(
On 10.04.2003 11:33:46 Stefan Bodewig wrote:
> On Thu, 10 Apr 2003, Jeremias Maerki <de...@greenmail.ch>
> wrote:
>
> > Thanks, Stefan. I've added a "gump" target in the build.xml.
>
> Seems as if you could now start nagging others because they have
> introduced backwards incompatible changes 8-)
>
> [javac] Compiling 746 source files to /javastuff/gump/xml-fop-maintenance/build/classes
> [javac] This version of java does not support the classic compiler; upgrading to modern
> [javac] /javastuff/gump/xml-fop-maintenance/build/src/org/apache/fop/svg/SVGElement.java:175: <anonymous org.apache.fop.svg.SVGElement$1> should be declared abstract; it does not define getScreenTransform() in
> [javac] public float getFontSize(){
> [javac] ^
> [javac] Note: /javastuff/gump/xml-fop-maintenance/build/src/org/apache/fop/tools/anttasks/Fop.java uses or overrides a deprecated API.
> [javac] Note: Recompile with -deprecation for details.
> [javac] 1 error
>
> BUILD FAILED
> /javastuff/gump/xml-fop-maintenance/build.xml:550: Compile failed; see the compiler error output for details.
>
> Total time: 1 minute 48 seconds
Jeremias Maerki
Re: Are xml-fop and cocoon-block-fop friends of Gump? [was: How to detect "Friends of Gump"]
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 10 Apr 2003, Jeremias Maerki <de...@greenmail.ch>
wrote:
> Thanks, Stefan. I've added a "gump" target in the build.xml.
Seems as if you could now start nagging others because they have
introduced backwards incompatible changes 8-)
[javac] Compiling 746 source files to /javastuff/gump/xml-fop-maintenance/build/classes
[javac] This version of java does not support the classic compiler; upgrading to modern
[javac] /javastuff/gump/xml-fop-maintenance/build/src/org/apache/fop/svg/SVGElement.java:175: <anonymous org.apache.fop.svg.SVGElement$1> should be declared abstract; it does not define getScreenTransform() in
[javac] public float getFontSize(){
[javac] ^
[javac] Note: /javastuff/gump/xml-fop-maintenance/build/src/org/apache/fop/tools/anttasks/Fop.java uses or overrides a deprecated API.
[javac] Note: Recompile with -deprecation for details.
[javac] 1 error
BUILD FAILED
/javastuff/gump/xml-fop-maintenance/build.xml:550: Compile failed; see the compiler error output for details.
Total time: 1 minute 48 seconds
Stefan
Re: Are xml-fop and cocoon-block-fop friends of Gump? [was: How to detect "Friends of Gump"]
Posted by Jeremias Maerki <de...@greenmail.ch>.
Thanks, Stefan. I've added a "gump" target in the build.xml. Would you
try again? I've left out the javadocs target because it fails rightnow.
That a problem?
On 10.04.2003 11:07:46 Stefan Bodewig wrote:
> On Thu, 10 Apr 2003, Jeremias Maerki <de...@greenmail.ch>
> wrote:
>
> > Done. I hope I did it right.
>
> I fixed the CVS module name (defaults to the name of the Gump module)
> and tried to build after updating:
>
> Buildfile: build.xml
>
> BUILD FAILED
> Target `gump' does not exist in this project.
>
> Total time: 11 seconds
Jeremias Maerki
Re: Are xml-fop and cocoon-block-fop friends of Gump? [was: How to detect "Friends of Gump"]
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 10 Apr 2003, Jeremias Maerki <de...@greenmail.ch>
wrote:
> Done. I hope I did it right.
I fixed the CVS module name (defaults to the name of the Gump module)
and tried to build after updating:
Buildfile: build.xml
BUILD FAILED
Target `gump' does not exist in this project.
Total time: 11 seconds
Stefan
Re: Are xml-fop and cocoon-block-fop friends of Gump? [was: How to
detect "Friends of Gump"]
Posted by Stefano Mazzocchi <st...@apache.org>.
on 4/10/03 10:39 AM Jeremias Maerki wrote:
>>>- Let cocoon-block-fop depend on the maintenance branch for the moment
>>>- Double-nag FOP and Cocoon lists for cocoon-block-fop
>
>
> I don't have write access to Cocoon's gump descriptor. Will drop them a
> note.
I'm doing it right now.
--
Stefano.
Re: Are xml-fop and cocoon-block-fop friends of Gump? [was: How to detect "Friends of Gump"]
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 09.04.2003 22:02:44 Sam Ruby wrote:
> Jeremias Maerki wrote:
> >
> > When did Gump start? I'm following the FOP project since Fall 2000 and
> > I am a committer for 12 months now and there's only one redesign effort
> > I'm aware of. More below.
> >
> > Redesign started in fall 2001 and continues today.
>
> I wasn't aware that it was a single continuous effort. I only recall
> two points in time (including the current situation) where such
> redesigns unilaterally impacted cocoon.
The first was probably when we switched from LogKit Logging to Avalon's
Logger abstraction. That was not very elegant.
The second simply results from the fact that we started to get rid of
some old stuff we didn't like. That resulted in a divergence of APIs
between FOP redesign and FOP maintenance.
> > Double-nag Cocoon and FOP! Helps the Cocoon guys and prevents us FOP
> > guys from accidentally changing the API (which I admit happened before).
>
> Works for me. Go ahead and commit the change to the descriptor.
>
> > My take:
> > - Add a Gump run for FOP's maintenance branch
Done. I hope I did it right.
> > - Let cocoon-block-fop depend on the maintenance branch for the moment
> > - Double-nag FOP and Cocoon lists for cocoon-block-fop
I don't have write access to Cocoon's gump descriptor. Will drop them a
note.
> > - FOP team will look into improving the API situation
On the todo list.
> +1
>
> The purpose behind my resistance was merely to cause this discussion to
> occur and for the implications of this to be thought through, and in
> particular to motivate what you captured in the last bullet above.
I figured as much.
Jeremias Maerki
Re: Are xml-fop and cocoon-block-fop friends of Gump? [was: How to detect "Friends of Gump"]
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 09.04.2003 22:02:44 Sam Ruby wrote:
> Jeremias Maerki wrote:
> >
> > When did Gump start? I'm following the FOP project since Fall 2000 and
> > I am a committer for 12 months now and there's only one redesign effort
> > I'm aware of. More below.
> >
> > Redesign started in fall 2001 and continues today.
>
> I wasn't aware that it was a single continuous effort. I only recall
> two points in time (including the current situation) where such
> redesigns unilaterally impacted cocoon.
The first was probably when we switched from LogKit Logging to Avalon's
Logger abstraction. That was not very elegant.
The second simply results from the fact that we started to get rid of
some old stuff we didn't like. That resulted in a divergence of APIs
between FOP redesign and FOP maintenance.
> > Double-nag Cocoon and FOP! Helps the Cocoon guys and prevents us FOP
> > guys from accidentally changing the API (which I admit happened before).
>
> Works for me. Go ahead and commit the change to the descriptor.
>
> > My take:
> > - Add a Gump run for FOP's maintenance branch
Done. I hope I did it right.
> > - Let cocoon-block-fop depend on the maintenance branch for the moment
> > - Double-nag FOP and Cocoon lists for cocoon-block-fop
I don't have write access to Cocoon's gump descriptor. Will drop them a
note.
> > - FOP team will look into improving the API situation
On the todo list.
> +1
>
> The purpose behind my resistance was merely to cause this discussion to
> occur and for the implications of this to be thought through, and in
> particular to motivate what you captured in the last bullet above.
I figured as much.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Are xml-fop and cocoon-block-fop friends of Gump? [was: How to
detect "Friends of Gump"]
Posted by Sam Ruby <ru...@apache.org>.
Jeremias Maerki wrote:
>
> When did Gump start? I'm following the FOP project since Fall 2000 and
> I am a committer for 12 months now and there's only one redesign effort
> I'm aware of. More below.
>
> Redesign started in fall 2001 and continues today.
I wasn't aware that it was a single continuous effort. I only recall
two points in time (including the current situation) where such
redesigns unilaterally impacted cocoon.
> Double-nag Cocoon and FOP! Helps the Cocoon guys and prevents us FOP
> guys from accidentally changing the API (which I admit happened before).
Works for me. Go ahead and commit the change to the descriptor.
> My take:
> - Add a Gump run for FOP's maintenance branch
> - Let cocoon-block-fop depend on the maintenance branch for the moment
> - Double-nag FOP and Cocoon lists for cocoon-block-fop
> - FOP team will look into improving the API situation
+1
The purpose behind my resistance was merely to cause this discussion to
occur and for the implications of this to be thought through, and in
particular to motivate what you captured in the last bullet above.
> Jeremias Maerki
- Sam Ruby