Re: [VOTE] Merge FOP color branch into trunk
I've fixed the unit test errors. Thanks for running them on OpenJDK. I didn't expect color management to differ so much between Java runtimes. On 29.01.2011 21:06:58 Simon Pepping wrote: I paid a little attention to the conditions determining the type of ColorSpace, and came up with some questions: GraphicsSetProcessColor(Color color): Would it be possible to implement and use ColorSpace.getNumComponents() instead of hard coding the number of components here? I've changed that as per your suggestion. GraphicsSetProcessColor.writeToStream and PtocaBuilder.setExtendedTextColor: Ideally the data written out are contained in the ColorSpace class instead of being contained in this method for all types of ColorSpace; are they not? Sorry, but I don't understand what you're saying here. These are only minor points. Apart from the junit problems signalled in my earlier email, I am in favour of merging this work into trunk: +1. Thanks for this work. Simon On Sat, Jan 29, 2011 at 04:14:41PM +0100, Simon Pepping wrote: I get three failures on the color branch junit tests: java version 1.6.0_18 OpenJDK Runtime Environment (IcedTea6 1.8.3) (6b18-1.8.3-2) OpenJDK Server VM (build 16.0-b13, mixed mode) OS: GNU/Linux (Debian testing) [echo] Apache Ant version 1.8.0 compiled on March 11 2010 [echo] VM: 16.0-b13, Sun Microsystems Inc. [junit] Testcase: testSeparationColor(org.apache.fop.util.ColorUtilTestCase): FAILED [junit] expected:255.0 but was:250.0 [junit] Testcase: testNamedColorProfile(org.apache.fop.util.ColorUtilTestCase): FAILED [junit] expected:255.0 but was:253.0 [junit] Testcase: color_1.xml(org.apache.fop.intermediate.IntermediateFormatTestSuite$1): FAILED [junit] org.custommonkey.xmlunit.Diff [junit] [different] Expected number of child nodes '14' but was '13' - comparing viewport... at /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1] to viewport... at /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1] Simon On Wed, Jan 19, 2011 at 11:56:34AM +0100, Jeremias Maerki wrote: I've cleaned up the color branch, tweaked a few things and did some more testing. I'm happy with the current state, so I'm calling for a vote to merge the current FOP color branch into trunk. https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color +1 from me, obviously. Jeremias Maerki Jeremias Maerki
Re: [VOTE] Merge FOP color branch into trunk
The color branch is now merged into Trunk: http://svn.apache.org/viewvc?rev=1069439view=rev Phew. Now Batik... Jeremias Maerki
Re: [VOTE] Merge FOP color branch into trunk
You are right. I got confused by various issues in my tools. The jar file was built by 'ant jar-main'. This target includes all cruft that is present in the build directory. The build files could do with an includes attribute in the jar task. Simon On Mon, Jan 31, 2011 at 09:12:10PM +0100, Jeremias Maerki wrote: Hi Simon Huh? What revision are you looking at? I've merged Trunk into Temp_Color on January 18 (http://svn.apache.org/viewvc?rev=1060241view=rev) copying the XGC.jar unchanged from Trunk. Temp_Color is long working against java2d.color and is compiling just fine like that. Looking at the XGC.jar in Trunk OTOH, it contains some junk in the root directory and test classes further down the hierarchy. If anything we need to rebuild the XGC.jar from Trunk and do another merge into Temp_Color. Something must have gone wrong during the compilation of that JAR. http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_Color/lib/xmlgraphics-commons-1.5svn.jar?view=logpathrev=1060241 I'll look at your other points shortly. Thanks for the review.
Re: [VOTE] Merge FOP color branch into trunk
Hmm, I don't see how any cruft can accumulate in there. Main and test classes are properly separated. jar-main only packs build/classes. Anyway, when Andreas moves ColorProfileUtil to XGC (or shall I, Andreas?), we need to update the JAR anyway. On 01.02.2011 12:06:56 Simon Pepping wrote: You are right. I got confused by various issues in my tools. The jar file was built by 'ant jar-main'. This target includes all cruft that is present in the build directory. The build files could do with an includes attribute in the jar task. Simon On Mon, Jan 31, 2011 at 09:12:10PM +0100, Jeremias Maerki wrote: Hi Simon Huh? What revision are you looking at? I've merged Trunk into Temp_Color on January 18 (http://svn.apache.org/viewvc?rev=1060241view=rev) copying the XGC.jar unchanged from Trunk. Temp_Color is long working against java2d.color and is compiling just fine like that. Looking at the XGC.jar in Trunk OTOH, it contains some junk in the root directory and test classes further down the hierarchy. If anything we need to rebuild the XGC.jar from Trunk and do another merge into Temp_Color. Something must have gone wrong during the compilation of that JAR. http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_Color/lib/xmlgraphics-commons-1.5svn.jar?view=logpathrev=1060241 I'll look at your other points shortly. Thanks for the review. Jeremias Maerki
Re: [VOTE] Merge FOP color branch into trunk
On 01 Feb 2011, at 13:24, Jeremias Maerki wrote: Hmm, I don't see how any cruft can accumulate in there. Main and test classes are properly separated. jar-main only packs build/classes. Anyway, when Andreas moves ColorProfileUtil to XGC (or shall I, Andreas?), we need to update the JAR anyway. Sure, I can take care of the migration of ColorProfileUtil in the same go. Do we move it to java2d.color.profile (similar to ColorUtil, which is placed under java2d.color)? See attached patch XGC_ColorProfileUtil for the proposal. Just added a method to deal with the getInstance(byte[]) variant used in XGC, and for the sake of completeness, provided one for the String variant as well. Additionally, looked up the places where one of the getInstance() methods was being used and replaced them by a corresponding call to ColorProfileUtil.getICC_Profile(). As it turns out, there were only two occurrences: ImageLoaderRawJPEG and ImageLoaderImageIO. Are there any special steps to be taken to replace the JAR in FOP, or do I just commit the new '...1.5svn' JAR? On FOP's end, after the JAR has been replaced, the changes then become as in attached patch FOP_ColorProfileUtil. For now, I deprecated the class and redirected the existing methods. The calls to getICC_Profile() are done directly against XGC, so no need to add those to FOP's ColorProfileUtil anymore. I also cleaned up the remaining references to other methods (= basically just replaced import statements in the affected classes), so fop.util.ColorProfileUtil is actually unused. To be removed at a later date? The harder part would be to come up with some test cases, in order to verify that this actually fixes the behavior... Notoriously difficult in the case of race conditions, especially if they are located in code that is outside of our control. XGC_ColorProfileUtil.diff Description: Binary data FOP_ColorProfileUtil.diff Description: Binary data Regards, Andreas ---
Re: [VOTE] Merge FOP color branch into trunk
Looks perfect. Thanks! If it's not too much trouble, please svn copy the ColorProfileUtil from FOP Trunk so we retain the history and document where this came from. I don't think it makes sense to put a lot of time in trying to test for a race condition. That's going to be difficult to reproduce. And to prove that it's no longer there. For me, the important thing is that this problem is documented in ColorProfileUtil like you did. For the JAR: just do a clean compile (with Java 1.5, i.e. lowest possible) and replace the ...1.5svn.jar in FOP's lib directory. On 01.02.2011 19:40:38 Andreas Delmelle wrote: On 01 Feb 2011, at 13:24, Jeremias Maerki wrote: Hmm, I don't see how any cruft can accumulate in there. Main and test classes are properly separated. jar-main only packs build/classes. Anyway, when Andreas moves ColorProfileUtil to XGC (or shall I, Andreas?), we need to update the JAR anyway. Sure, I can take care of the migration of ColorProfileUtil in the same go. Do we move it to java2d.color.profile (similar to ColorUtil, which is placed under java2d.color)? See attached patch XGC_ColorProfileUtil for the proposal. Just added a method to deal with the getInstance(byte[]) variant used in XGC, and for the sake of completeness, provided one for the String variant as well. Additionally, looked up the places where one of the getInstance() methods was being used and replaced them by a corresponding call to ColorProfileUtil.getICC_Profile(). As it turns out, there were only two occurrences: ImageLoaderRawJPEG and ImageLoaderImageIO. Are there any special steps to be taken to replace the JAR in FOP, or do I just commit the new '...1.5svn' JAR? On FOP's end, after the JAR has been replaced, the changes then become as in attached patch FOP_ColorProfileUtil. For now, I deprecated the class and redirected the existing methods. The calls to getICC_Profile() are done directly against XGC, so no need to add those to FOP's ColorProfileUtil anymore. I also cleaned up the remaining references to other methods (= basically just replaced import statements in the affected classes), so fop.util.ColorProfileUtil is actually unused. To be removed at a later date? The harder part would be to come up with some test cases, in order to verify that this actually fixes the behavior... Notoriously difficult in the case of race conditions, especially if they are located in code that is outside of our control. Jeremias Maerki
Re: [VOTE] Merge FOP color branch into trunk
On 01 Feb 2011, at 20:23, Jeremias Maerki wrote: Looks perfect. Thanks! If it's not too much trouble, please svn copy the ColorProfileUtil from FOP Trunk so we retain the history and document where this came from. Done. All related changes committed to both XGC and FOP. Regards, Andreas ---
Re: [VOTE] Merge FOP color branch into trunk
Thanks, Andreas! On 01.02.2011 21:09:15 Andreas Delmelle wrote: On 01 Feb 2011, at 20:23, Jeremias Maerki wrote: Looks perfect. Thanks! If it's not too much trouble, please svn copy the ColorProfileUtil from FOP Trunk so we retain the history and document where this came from. Done. All related changes committed to both XGC and FOP. Regards, Andreas --- Jeremias Maerki
Re: [VOTE] Merge FOP color branch into trunk
Hi Simon Huh? What revision are you looking at? I've merged Trunk into Temp_Color on January 18 (http://svn.apache.org/viewvc?rev=1060241view=rev) copying the XGC.jar unchanged from Trunk. Temp_Color is long working against java2d.color and is compiling just fine like that. Looking at the XGC.jar in Trunk OTOH, it contains some junk in the root directory and test classes further down the hierarchy. If anything we need to rebuild the XGC.jar from Trunk and do another merge into Temp_Color. Something must have gone wrong during the compilation of that JAR. http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_Color/lib/xmlgraphics-commons-1.5svn.jar?view=logpathrev=1060241 I'll look at your other points shortly. Thanks for the review. On 30.01.2011 12:36:10 Simon Pepping wrote: I noticed that the XGC jar file in the Temp_Color branch differs from the current state of the XGC code in an important aspect for the Temp_Color branch: A number of classes, e.g. ColorWithAlternatives, have been moved from package java2d to java2d.color. I think that that change must be made in the Temp_Color branch before the merge. If not, the change must be made at the moment when the XGC jar file is updated, which is not a good moment. That changes my vote to -1 for the moment, until this change has been made. Simon On Sat, Jan 29, 2011 at 09:06:58PM +0100, Simon Pepping wrote: I paid a little attention to the conditions determining the type of ColorSpace, and came up with some questions: GraphicsSetProcessColor(Color color): Would it be possible to implement and use ColorSpace.getNumComponents() instead of hard coding the number of components here? GraphicsSetProcessColor.writeToStream and PtocaBuilder.setExtendedTextColor: Ideally the data written out are contained in the ColorSpace class instead of being contained in this method for all types of ColorSpace; are they not? These are only minor points. Apart from the junit problems signalled in my earlier email, I am in favour of merging this work into trunk: +1. Thanks for this work. Simon On Sat, Jan 29, 2011 at 04:14:41PM +0100, Simon Pepping wrote: I get three failures on the color branch junit tests: java version 1.6.0_18 OpenJDK Runtime Environment (IcedTea6 1.8.3) (6b18-1.8.3-2) OpenJDK Server VM (build 16.0-b13, mixed mode) OS: GNU/Linux (Debian testing) [echo] Apache Ant version 1.8.0 compiled on March 11 2010 [echo] VM: 16.0-b13, Sun Microsystems Inc. [junit] Testcase: testSeparationColor(org.apache.fop.util.ColorUtilTestCase): FAILED [junit] expected:255.0 but was:250.0 [junit] Testcase: testNamedColorProfile(org.apache.fop.util.ColorUtilTestCase): FAILED [junit] expected:255.0 but was:253.0 [junit] Testcase: color_1.xml(org.apache.fop.intermediate.IntermediateFormatTestSuite$1): FAILED [junit] org.custommonkey.xmlunit.Diff [junit] [different] Expected number of child nodes '14' but was '13' - comparing viewport... at /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1] to viewport... at /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1] Simon On Wed, Jan 19, 2011 at 11:56:34AM +0100, Jeremias Maerki wrote: I've cleaned up the color branch, tweaked a few things and did some more testing. I'm happy with the current state, so I'm calling for a vote to merge the current FOP color branch into trunk. https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color +1 from me, obviously. Jeremias Maerki Jeremias Maerki
Re: [VOTE] Merge FOP color branch into trunk
I noticed that the XGC jar file in the Temp_Color branch differs from the current state of the XGC code in an important aspect for the Temp_Color branch: A number of classes, e.g. ColorWithAlternatives, have been moved from package java2d to java2d.color. I think that that change must be made in the Temp_Color branch before the merge. If not, the change must be made at the moment when the XGC jar file is updated, which is not a good moment. That changes my vote to -1 for the moment, until this change has been made. Simon On Sat, Jan 29, 2011 at 09:06:58PM +0100, Simon Pepping wrote: I paid a little attention to the conditions determining the type of ColorSpace, and came up with some questions: GraphicsSetProcessColor(Color color): Would it be possible to implement and use ColorSpace.getNumComponents() instead of hard coding the number of components here? GraphicsSetProcessColor.writeToStream and PtocaBuilder.setExtendedTextColor: Ideally the data written out are contained in the ColorSpace class instead of being contained in this method for all types of ColorSpace; are they not? These are only minor points. Apart from the junit problems signalled in my earlier email, I am in favour of merging this work into trunk: +1. Thanks for this work. Simon On Sat, Jan 29, 2011 at 04:14:41PM +0100, Simon Pepping wrote: I get three failures on the color branch junit tests: java version 1.6.0_18 OpenJDK Runtime Environment (IcedTea6 1.8.3) (6b18-1.8.3-2) OpenJDK Server VM (build 16.0-b13, mixed mode) OS: GNU/Linux (Debian testing) [echo] Apache Ant version 1.8.0 compiled on March 11 2010 [echo] VM: 16.0-b13, Sun Microsystems Inc. [junit] Testcase: testSeparationColor(org.apache.fop.util.ColorUtilTestCase): FAILED [junit] expected:255.0 but was:250.0 [junit] Testcase: testNamedColorProfile(org.apache.fop.util.ColorUtilTestCase): FAILED [junit] expected:255.0 but was:253.0 [junit] Testcase: color_1.xml(org.apache.fop.intermediate.IntermediateFormatTestSuite$1): FAILED [junit] org.custommonkey.xmlunit.Diff [junit] [different] Expected number of child nodes '14' but was '13' - comparing viewport... at /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1] to viewport... at /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1] Simon On Wed, Jan 19, 2011 at 11:56:34AM +0100, Jeremias Maerki wrote: I've cleaned up the color branch, tweaked a few things and did some more testing. I'm happy with the current state, so I'm calling for a vote to merge the current FOP color branch into trunk. https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color +1 from me, obviously. Jeremias Maerki
Re: Subversion merge or GIT merge? [was: Re: [VOTE] Merge FOP color branch into trunk]
Would the decision to move from SVN to another VCS be in the hands of the wider ASF community? Discussions about migrating from SVN to GIT are often held on infrastructure-...@apache.org and I imagine it is only a matter of time before this happens across the projects, and with sensible consideration. GIT certainly makes the creation and merging of branches easier to manage and this is just one of many features that FOP developers would gain from a switch to GIT or another DVCS (Distributed VCS). Another aspect of particular interest to contributors without committer status is that a DVCS gives every developer first class version control of their local development workflow, something that is not possible using SVN alone. Combining both SVN and GIT can get you a long way but as long as SVN is the central VCS there will remain a steep learning curve required to contribute effectively to FOP, and no satisfactory way of addressing the issue of submitting patches: Currently, contributors are encouraged to submit SVN compatible diffs to a Bugzilla issue, however this format does not contain the richness of information potential contained within a series local GIT commits. Submitting a GIT generated diff preserves the original workflow, but then defers the responsibility of handling the GiT SVN bridge onto the committer, further adding a layer of complexity to a job that the time stretched few currently struggle to keep on top of! I find GIT an indispensable tool and encourage all members of this community to investigate GIT, or perhaps other next generation DVCS (Distributed VCS), and see how they may help on both an individual and collaborative basis. Pete On Sat, Jan 29, 2011 at 10:08 PM, The Web Maestro the.webmaes...@gmail.com wrote: Are you saying you think we should consider: a) moving from SVN to GIT b) using GIT as a timesaver for conflicts? Clay Sent from my iPhone On Jan 29, 2011, at 12:24 PM, Simon Pepping spepp...@leverkruid.eu wrote: I read in the literature that GIT and Mercurial merge would be very much better at resolving possible conflicts than subversion. Today I tested this with the merge of the Temp_Color branch into trunk. In GIT I used the GIT repository at https://github.com/apache/fop. The merge of Temp_Color resulted in one conflict, in status.xml. The conflict was presented precisely, and was easily resolved. The merge in Subversion resulted in the following: Summary of conflicts: Text conflicts: 16 Property conflicts: 1 Tree conflicts: 68 The many tree conflicts were files that were removed in the branch and trunk or added in both. Obviously they were caused by the merges of trunk into Temp_Color earlier. After the merge in GIT I got no compilation errors. I got three failures in the junit tests, which were also present in the branch. I investigated a few cases which gave a conflict in subversion. They were resolved correctly in GIT. This merge result is a huge time saver, and I thought I should let you know. Simon On Wed, Jan 19, 2011 at 11:56:34AM +0100, Jeremias Maerki wrote: I've cleaned up the color branch, tweaked a few things and did some more testing. I'm happy with the current state, so I'm calling for a vote to merge the current FOP color branch into trunk. https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color +1 from me, obviously. Jeremias Maerki
Re: [VOTE] Merge FOP color branch into trunk
I get three failures on the color branch junit tests: java version 1.6.0_18 OpenJDK Runtime Environment (IcedTea6 1.8.3) (6b18-1.8.3-2) OpenJDK Server VM (build 16.0-b13, mixed mode) OS: GNU/Linux (Debian testing) [echo] Apache Ant version 1.8.0 compiled on March 11 2010 [echo] VM: 16.0-b13, Sun Microsystems Inc. [junit] Testcase: testSeparationColor(org.apache.fop.util.ColorUtilTestCase): FAILED [junit] expected:255.0 but was:250.0 [junit] Testcase: testNamedColorProfile(org.apache.fop.util.ColorUtilTestCase): FAILED [junit] expected:255.0 but was:253.0 [junit] Testcase: color_1.xml(org.apache.fop.intermediate.IntermediateFormatTestSuite$1): FAILED [junit] org.custommonkey.xmlunit.Diff [junit] [different] Expected number of child nodes '14' but was '13' - comparing viewport... at /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1] to viewport... at /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1] Simon On Wed, Jan 19, 2011 at 11:56:34AM +0100, Jeremias Maerki wrote: I've cleaned up the color branch, tweaked a few things and did some more testing. I'm happy with the current state, so I'm calling for a vote to merge the current FOP color branch into trunk. https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color +1 from me, obviously. Jeremias Maerki
Re: [VOTE] Merge FOP color branch into trunk
I paid a little attention to the conditions determining the type of ColorSpace, and came up with some questions: GraphicsSetProcessColor(Color color): Would it be possible to implement and use ColorSpace.getNumComponents() instead of hard coding the number of components here? GraphicsSetProcessColor.writeToStream and PtocaBuilder.setExtendedTextColor: Ideally the data written out are contained in the ColorSpace class instead of being contained in this method for all types of ColorSpace; are they not? These are only minor points. Apart from the junit problems signalled in my earlier email, I am in favour of merging this work into trunk: +1. Thanks for this work. Simon On Sat, Jan 29, 2011 at 04:14:41PM +0100, Simon Pepping wrote: I get three failures on the color branch junit tests: java version 1.6.0_18 OpenJDK Runtime Environment (IcedTea6 1.8.3) (6b18-1.8.3-2) OpenJDK Server VM (build 16.0-b13, mixed mode) OS: GNU/Linux (Debian testing) [echo] Apache Ant version 1.8.0 compiled on March 11 2010 [echo] VM: 16.0-b13, Sun Microsystems Inc. [junit] Testcase: testSeparationColor(org.apache.fop.util.ColorUtilTestCase): FAILED [junit] expected:255.0 but was:250.0 [junit] Testcase: testNamedColorProfile(org.apache.fop.util.ColorUtilTestCase): FAILED [junit] expected:255.0 but was:253.0 [junit] Testcase: color_1.xml(org.apache.fop.intermediate.IntermediateFormatTestSuite$1): FAILED [junit] org.custommonkey.xmlunit.Diff [junit] [different] Expected number of child nodes '14' but was '13' - comparing viewport... at /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1] to viewport... at /document[1]/page-sequence[1]/page[1]/content[1]/viewport[1] Simon On Wed, Jan 19, 2011 at 11:56:34AM +0100, Jeremias Maerki wrote: I've cleaned up the color branch, tweaked a few things and did some more testing. I'm happy with the current state, so I'm calling for a vote to merge the current FOP color branch into trunk. https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color +1 from me, obviously. Jeremias Maerki
Subversion merge or GIT merge? [was: Re: [VOTE] Merge FOP color branch into trunk]
I read in the literature that GIT and Mercurial merge would be very much better at resolving possible conflicts than subversion. Today I tested this with the merge of the Temp_Color branch into trunk. In GIT I used the GIT repository at https://github.com/apache/fop. The merge of Temp_Color resulted in one conflict, in status.xml. The conflict was presented precisely, and was easily resolved. The merge in Subversion resulted in the following: Summary of conflicts: Text conflicts: 16 Property conflicts: 1 Tree conflicts: 68 The many tree conflicts were files that were removed in the branch and trunk or added in both. Obviously they were caused by the merges of trunk into Temp_Color earlier. After the merge in GIT I got no compilation errors. I got three failures in the junit tests, which were also present in the branch. I investigated a few cases which gave a conflict in subversion. They were resolved correctly in GIT. This merge result is a huge time saver, and I thought I should let you know. Simon On Wed, Jan 19, 2011 at 11:56:34AM +0100, Jeremias Maerki wrote: I've cleaned up the color branch, tweaked a few things and did some more testing. I'm happy with the current state, so I'm calling for a vote to merge the current FOP color branch into trunk. https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color +1 from me, obviously. Jeremias Maerki
Re: Subversion merge or GIT merge? [was: Re: [VOTE] Merge FOP color branch into trunk]
Are you saying you think we should consider: a) moving from SVN to GIT b) using GIT as a timesaver for conflicts? Clay Sent from my iPhone On Jan 29, 2011, at 12:24 PM, Simon Pepping spepp...@leverkruid.eu wrote: I read in the literature that GIT and Mercurial merge would be very much better at resolving possible conflicts than subversion. Today I tested this with the merge of the Temp_Color branch into trunk. In GIT I used the GIT repository at https://github.com/apache/fop. The merge of Temp_Color resulted in one conflict, in status.xml. The conflict was presented precisely, and was easily resolved. The merge in Subversion resulted in the following: Summary of conflicts: Text conflicts: 16 Property conflicts: 1 Tree conflicts: 68 The many tree conflicts were files that were removed in the branch and trunk or added in both. Obviously they were caused by the merges of trunk into Temp_Color earlier. After the merge in GIT I got no compilation errors. I got three failures in the junit tests, which were also present in the branch. I investigated a few cases which gave a conflict in subversion. They were resolved correctly in GIT. This merge result is a huge time saver, and I thought I should let you know. Simon On Wed, Jan 19, 2011 at 11:56:34AM +0100, Jeremias Maerki wrote: I've cleaned up the color branch, tweaked a few things and did some more testing. I'm happy with the current state, so I'm calling for a vote to merge the current FOP color branch into trunk. https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color +1 from me, obviously. Jeremias Maerki
Re: [VOTE] Merge FOP color branch into trunk
On 19 Jan 2011, at 11:56, Jeremias Maerki wrote: I've cleaned up the color branch, tweaked a few things and did some more testing. I'm happy with the current state, so I'm calling for a vote to merge the current FOP color branch into trunk. No detailed review done here, but from what I did see, it indeed looks good, so +1 Regards, Andreas ---
Re: [VOTE] Merge FOP color branch into trunk
No formal review but the code looks good. +1 Sent from my iPhone On Jan 19, 2011, at 2:56 AM, Jeremias Maerki d...@jeremias-maerki.ch wrote: I've cleaned up the color branch, tweaked a few things and did some more testing. I'm happy with the current state, so I'm calling for a vote to merge the current FOP color branch into trunk. https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color +1 from me, obviously. Jeremias Maerki
Re: [VOTE] Merge FOP color branch into trunk
I'm afraid I've not had time to review so +0. Cheers, Adrian. On Jan 22, 2011, at 6:04 AM, The Web Maestro the.webmaes...@gmail.com wrote: No formal review but the code looks good. +1 Sent from my iPhone On Jan 19, 2011, at 2:56 AM, Jeremias Maerki d...@jeremias-maerki.ch wrote: I've cleaned up the color branch, tweaked a few things and did some more testing. I'm happy with the current state, so I'm calling for a vote to merge the current FOP color branch into trunk. https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color +1 from me, obviously. Jeremias Maerki
[VOTE] Merge FOP color branch into trunk
I've cleaned up the color branch, tweaked a few things and did some more testing. I'm happy with the current state, so I'm calling for a vote to merge the current FOP color branch into trunk. https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_Color +1 from me, obviously. Jeremias Maerki
