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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
