You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xmlgraphics.apache.org by Jeremias Maerki <de...@greenmail.ch> on 2005/03/07 14:44:54 UTC
Opinion poll
I'd like to push the XML Graphics Commons idea again and therefore would
like to know what people think.
1. I think there's noone around opposing the idea of creating the common
area and making the transcoders in FOP available to the Batik team, is
there?
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?
3. Would you be opposed to converting Batik and FOP to Subversion in
preparation for the creation of the common area? This would preserve all
history of the individual classes. Time frame: within 1 month from now.
It seems to me that the infrastructure have succeeded in making
Subversion stable now.
The page with the proposal:
http://wiki.apache.org/xmlgraphics/XmlGraphicsCommonComponents
Thanks,
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
Re: Opinion poll
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 08.03.2005 16:21:47 Web Maestro Clay wrote:
> On Mar 7, 2005, at 5:52 AM, Chris Bowditch wrote:
> > Jeremias Maerki wrote:
> >> I'd like to push the XML Graphics Commons idea again and therefore
> >> would
> >> like to know what people think.
> >> 1. I think there's noone around opposing the idea of creating the
> >> common
> >> area and making the transcoders in FOP available to the Batik team, is
> >> there?
> >
> > Fine with me.
>
> Fine with me, assuming we have a clear plan on how to resolve the
> technical issues.
>
> While we're at it, are there any other items which can go into
> xmlgraphics-commons.jar?
Well, I've started a list of items on the Wiki page. And we can always
add components later once the infrastructure is there.
> >> 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.
>
> My concern is that if we move files, then someone will have to download
> the Batik & FOP binaries and/or source. If that's the case, then why
> not just merge FOP and BATIK (FATIK? BOP? ;-)). It doesn't matter much
> to me, as long as it's clear, simple and serves an established, agreed
> upon purpose.
Merging FOP and Batik wouldn't be a good idea. We implement two
different specifications. With the move of the transcoders out of FOP,
FOP will have a dependency on XGC and Batik, and Batik only on XGC. That
establishes a clean dependency tree. FOP will continue to ship a
batik.jar which will also contain the transcoders in the future (except
if they are still packed into a separate JAR which would still be
possible).
<snip/>
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
Re: Opinion poll
Posted by Thomas DeWeese <Th...@Kodak.com>.
Jeremias Maerki wrote:
> Thomas, can we restart here?
Sure.
---------------------------------------------------------------------
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
Re: Opinion poll
Posted by Jeremias Maerki <de...@greenmail.ch>.
Thomas, can we restart here?
On 09.03.2005 14:14:16 Thomas DeWeese wrote:
> I can't do that this week but sometime next week it might be
> good to do.
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
Re: Opinion poll
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 09.03.2005 14:14:16 Thomas DeWeese wrote:
> Hi Jeremias,
>
> Jeremias Maerki wrote:
> > Thomas, I apologize for the apparently bad wording. It was not my
> > intention to ignore your concerns.
>
> Ok.
>
> > 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.
>
> At some point we need to "sit down" and discuss exactly what code
> we are talking about as I think we have different ideas on this
> point (especially based on the XMLGraphics components thread).
Yes, we need to do that and then document it in the Wiki and then vote
on it.
> I can't do that this week but sometime next week it might be
> good to do.
No problem.
> > 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.
>
> There are clearly access issues that need to be addressed,
> either by building trust (i.e. when you submit patches they are
> applied in a timely manner) or by granting access and I am very
> aware of this. I would hate to see this push against the correct
> technical decision.
I think with the split of the transcoder code into Batik-dependent and
non-Batik-dependent code my concerns about access would be dealt with.
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
Re: Opinion poll
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Jeremias,
Jeremias Maerki wrote:
> Thomas, I apologize for the apparently bad wording. It was not my
> intention to ignore your concerns.
Ok.
> 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.
At some point we need to "sit down" and discuss exactly what code
we are talking about as I think we have different ideas on this
point (especially based on the XMLGraphics components thread).
I can't do that this week but sometime next week it might be
good to do.
> 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.
There are clearly access issues that need to be addressed,
either by building trust (i.e. when you submit patches they are
applied in a timely manner) or by granting access and I am very
aware of this. I would hate to see this push against the correct
technical decision.
---------------------------------------------------------------------
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
Re: Opinion poll
Posted by Glen Mazza <gr...@yahoo.com>.
--- Jeremias Maerki <de...@greenmail.ch> wrote:
>
> I
> fully understand, that
> separating the PDF and PS transcoders from the main
> Batik codebase
> 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.
Release away IMO. Transcoders are Batik's department,
not FOP's, and no active committer save yourself (and
then only rather lightly) have been working on them.
FOP devs who want to code the transcoders--nearing
zero over the past couple of years--are welcome to
submit patches to Batik.
Glen
---------------------------------------------------------------------
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
Re: Opinion poll
Posted by Jeremias Maerki <de...@greenmail.ch>.
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
Re: Opinion poll
Posted by Thomas DeWeese <Th...@Kodak.com>.
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.
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!
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.
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.
---------------------------------------------------------------------
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
Re: Opinion poll
Posted by Simon Pepping <sp...@leverkruid.nl>.
On Mon, Mar 07, 2005 at 03:08:01PM +0100, Jeremias Maerki wrote:
>
> On 07.03.2005 14:52:02 Chris Bowditch wrote:
> > Jeremias Maerki wrote:
> >
> > > I'd like to push the XML Graphics Commons idea again and therefore would
> > > like to know what people think.
> > >
> > > 1. I think there's noone around opposing the idea of creating the common
> > > area and making the transcoders in FOP available to the Batik team, is
> > > there?
> >
> > Fine with me.
Fine with me as well.
> > > 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.
In general, breaking a code base up in several pieces is better for
the developers, but may cause problems for users. The users' end
should be served by good documentation and by good organization of
release packages.
I have not followed the discussion very well, and I do not have a
clear standpoint. That is a +0 from me.
> > > 3. Would you be opposed to converting Batik and FOP to Subversion in
> > > preparation for the creation of the common area? This would preserve all
> > > history of the individual classes. Time frame: within 1 month from now.
> > > It seems to me that the infrastructure have succeeded in making
> > > Subversion stable now.
Fine with me.
Regards, Simon
--
Simon Pepping
home page: http://www.leverkruid.nl
---------------------------------------------------------------------
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
Re: Opinion poll
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 07.03.2005 14:52:02 Chris Bowditch wrote:
> Jeremias Maerki wrote:
>
> > I'd like to push the XML Graphics Commons idea again and therefore would
> > like to know what people think.
> >
> > 1. I think there's noone around opposing the idea of creating the common
> > area and making the transcoders in FOP available to the Batik team, is
> > there?
>
> Fine with me.
>
> >
> > 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.
> >
> > 3. Would you be opposed to converting Batik and FOP to Subversion in
> > preparation for the creation of the common area? This would preserve all
> > history of the individual classes. Time frame: within 1 month from now.
> > It seems to me that the infrastructure have succeeded in making
> > Subversion stable now.
>
> I havent yet checked to see if there is an easy to use Windows client available.
Windows is easiest. TortoiseSVN is one of the best clients available in
general. Integrates directory into the Explorer. The command line is
also no problem. The only problem for myself is probably the SVN support
in Eclipse that is not yet as advanced as CVS support.
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
Re: Opinion poll
Posted by Web Maestro Clay <we...@mac.com>.
On Mar 7, 2005, at 5:52 AM, Chris Bowditch wrote:
> Jeremias Maerki wrote:
>> I'd like to push the XML Graphics Commons idea again and therefore
>> would
>> like to know what people think.
>> 1. I think there's noone around opposing the idea of creating the
>> common
>> area and making the transcoders in FOP available to the Batik team, is
>> there?
>
> Fine with me.
Fine with me, assuming we have a clear plan on how to resolve the
technical issues.
While we're at it, are there any other items which can go into
xmlgraphics-commons.jar?
>> 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.
My concern is that if we move files, then someone will have to download
the Batik & FOP binaries and/or source. If that's the case, then why
not just merge FOP and BATIK (FATIK? BOP? ;-)). It doesn't matter much
to me, as long as it's clear, simple and serves an established, agreed
upon purpose.
>> 3. Would you be opposed to converting Batik and FOP to Subversion in
>> preparation for the creation of the common area? This would preserve
>> all
>> history of the individual classes. Time frame: within 1 month from
>> now.
>> It seems to me that the infrastructure have succeeded in making
>> Subversion stable now.
>
> I havent yet checked to see if there is an easy to use Windows client
> available.
>
> Chris
Mac OS X GUI (Finder-level) interface: SCPlugin
http://scplugin.tigris.org/
(missing some features--like MOVE, COPY--but very convenient!)
Windows GUI (Windows Explorer-level) interface: TortoiseSVN:
http://tortoisesvn.tigris.org/
Web Maestro Clay
--
<we...@mac.com> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet
---------------------------------------------------------------------
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
Re: Opinion poll
Posted by Chris Bowditch <bo...@hotmail.com>.
Jeremias Maerki wrote:
> I'd like to push the XML Graphics Commons idea again and therefore would
> like to know what people think.
>
> 1. I think there's noone around opposing the idea of creating the common
> area and making the transcoders in FOP available to the Batik team, is
> there?
Fine with me.
>
> 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.
>
> 3. Would you be opposed to converting Batik and FOP to Subversion in
> preparation for the creation of the common area? This would preserve all
> history of the individual classes. Time frame: within 1 month from now.
> It seems to me that the infrastructure have succeeded in making
> Subversion stable now.
I havent yet checked to see if there is an easy to use Windows client available.
Chris
---------------------------------------------------------------------
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
Re: Opinion poll
Posted by Glen Mazza <gr...@yahoo.com>.
--- Jeremias Maerki <de...@greenmail.ch> wrote:
>
> I'd like to push the XML Graphics Commons idea again
> and therefore would
> like to know what people think.
>
> 1. I think there's noone around opposing the idea of
> creating the common
> area and making the transcoders in FOP available to
> the Batik team, is
> there?
>
No problem with making the transcoders available to
the Batik team (or even giving them to that project,
for that matter.)
> 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?
>
Not so important for me, as I don't work on the
transcoders.
> 3. Would you be opposed to converting Batik and FOP
> to Subversion in
> preparation for the creation of the common area?
> This would preserve all
> history of the individual classes. Time frame:
> within 1 month from now.
> It seems to me that the infrastructure have
> succeeded in making
> Subversion stable now.
>
Either way is again fine with me, as long as Batik is
OK with it. I note that Jakarta Struts has also moved
over to Subversion, while Tomcat is apparently
choosing to remain with CVS for the forseeable future.
Thanks,
Glen
---------------------------------------------------------------------
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