xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <dev.jerem...@greenmail.ch>
Subject Re: Opinion poll
Date Tue, 08 Mar 2005 09:15:56 GMT
Thomas, I apologize for the apparently bad wording. It was not my
intention to ignore your concerns. That's why I answered to Chris'
comment in the first place, but being minimalistic and sometimes not
very accurate in my work I managed to screw up. I fully understand, that
separating the PDF and PS transcoders from the main Batik codebase
introduce some difficulties, but you also have to realize that the FOP
team releases some amount of control over this part if we transfer it
into the main Batik codebase. The opinion poll was my attempt to get
additional comments on the different approaches that we've come up with
and to be able to determine what the best course of action would be.

(more comments inline)

On 08.03.2005 04:12:37 Thomas DeWeese wrote:
> Hi Jeremias,
>  >>>2. Do you prefer the transfer of the transcoders to the Batik
>  >>>   subproject as Thomas suggested or do you think that the
>  >>>   transcoders should be in a separate area that is easily accessible
>  >>>   by both teams? Or is that particular question not so important for
>  >>>   you?
>     As I have stated before I think there is a real build
> issue with the PDF transcoder not being in the Batik source
> base.  Starting an opinion poll without noting that individuals
> involved have raised technical issues is not very friendly.
> Given the wording of the question one could hardly vote
> against splitting it out.

Those who have followed the discussions before can, but I'm sorry it
sounded that way.

>     There are classes in Batik that the transcoder depends
> on (all of GVT) and classes in Batik that will depend on
> it (rasterizer app). It is not just a matter of making it
> harder for people to find things, the build processes will
> involve jumping through hoops in many cases (copying jar
> files back and forth).  I gave specific examples of the impact
> of this the last time you raised this issue, you seemed to
> have ignored that response, and in your response actively
> downplayed my issues!

In a modern IDE such as Eclipse there's no problem setting up such a
structure. Even Ant, when the directory structure is chosen in a clever
way, can deal with the split without the need of copying around JARs.
But I agree that a split introduces a certain amount of complexity which
is unwelcome.

>     Take a look at the code, it's dealing with internal
> structures of Batik (like replacing the standard text and
> image bridges for example), the fact that it is currently
> external is due to history and the fact that it has been
> just as impossible for the PDF code to be split out of FOP.

It was not impossible. It was never more difficult than it is now
(technically). There's simply some amount of work to be done and now we
have a suitable, organizational starting point (the XML Graphics project)
to factor out this part.

> Jeremias Maerki wrote:
> >>>2. Do you prefer the transfer of the transcoders to the Batik subproject
> >>>as Thomas suggested or do you think that the transcoders should be in a
> >>>separate area that is easily accessible by both teams? Or is that
> >>>particular question not so important for you?
> >>
> >>I think Transcoders should be accessible to both sets of committers. So 
> >>therefore in their own separate area. I seem to remember from previous 
> >>discussions that this was difficult to achieve for technical reasons.
> > 
> > Not really technical, rather organizational. It could be difficult for
> > people to find what they need. The Batik build would be more scattered.
>    A build that involves the PDF code would in the general case involve
> building Batik (without any of the modifications that depend on
> the new PDF code, but including modifications needed by the PDF code),
> copying the Batik jar file to the PDF build tree, building the PDF code
> with it's modifications, moving the PDF jar file back to the Batik tree,
> making modifications that rely on the new PDF code and rebuilding the
> Batik project again.  This is hardly a good work flow.
>    Please let me know what _technical_ advantage we get by having it
> in a separate package I have already pointed out the technical
> disadvantage.

There is no technical advantage. There are only technical disadvantages.
The proposal came out of the desire not to release all control over that
part. Your counterproposal which I also put on the Wiki page is clearly
better even if it means we lose overall control over this part. I'm
pretty much the only one (besides Keiron, who's inactive, unfortunately)
maintained the transcoders. But I wanted to give everyone a chance to
say: No we can't do that. I totally screwed up and the meaning didn't
get through. I'm sorry.

Jeremias Maerki

Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org

View raw message