compile: [mkdir] Created dir: /var/tmp/portage/dev-java/itext-2.0.2/work/build/bin/classes [javac] Compiling 458 source files to /var/tmp/portage/dev-java/itext-2.0.2/work/build/bin/classes [javac] /var/tmp/portage/dev-java/itext-2.0.2/work/src/com/lowagie/text/pdf/PdfGraphics2D.java:1353: package com.sun.image.codec.jpeg does not exist [javac] com.sun.image.codec.jpeg.JPEGImageEncoder encoder = com.sun.image.codec.jpeg.JPEGCodec.createJPEGEncoder(baos); [javac] ^ [javac] /var/tmp/portage/dev-java/itext-2.0.2/work/src/com/lowagie/text/pdf/PdfGraphics2D.java:1353: package com.sun.image.codec.jpeg does not exist [javac] com.sun.image.codec.jpeg.JPEGImageEncoder encoder = com.sun.image.codec.jpeg.JPEGCodec.createJPEGEncoder(baos); [javac] ^ [javac] /var/tmp/portage/dev-java/itext-2.0.2/work/src/com/lowagie/text/pdf/PdfGraphics2D.java:1354: package com.sun.image.codec.jpeg does not exist [javac] com.sun.image.codec.jpeg.JPEGEncodeParam param = com.sun.image.codec.jpeg.JPEGCodec.getDefaultJPEGEncodeParam(scaled); [javac] ^ [javac] /var/tmp/portage/dev-java/itext-2.0.2/work/src/com/lowagie/text/pdf/PdfGraphics2D.java:1354: package com.sun.image.codec.jpeg does not exist [javac] com.sun.image.codec.jpeg.JPEGEncodeParam param = com.sun.image.codec.jpeg.JPEGCodec.getDefaultJPEGEncodeParam(scaled); [javac] ^ [javac] 4 errors Upstream should should to using javax.imageio found in standard J2SE classes. || ( 1.6 1.5 1.4 ) does not work in this case because the classes are missing at runtime instead of API breaking.
It seems 2.0.3 is out. Hopefully fixed there but I doubt. http://www.lowagie.com/iText/download.html
Actually using || ( 1.6 1.5 1.4 ) could probably work as they seem to do detecting if the class is available: http://itext.cvs.sourceforge.net/itext/src/com/lowagie/text/pdf/PdfGraphics2D.java?revision=1.67&view=markup But they should still be using imageio so these tricks are not needed but for now we should exclude 1.7 until upstream gets their act together.
How is upstream supposed to get their act together when 1.7 is not even official released? They are releasing early access snapshots. But that's hardly official yet, and I don't believe they will have a official release till closer to December. I would not expect upstream to start addressing 1.7 issues for several months. Not sure if they would welcome patches or what. At this time they recommend 1.4 or above. Which the com.sun.* starts spitting out deprecation stuff I believe in 1.5, for sure 1.6. So not really required to deal till they decide to support 1.7. As for iText 2.0.3, upstream does not announce their releases which is quite annoying. Bumping now will commit to tree shortly.
(In reply to comment #3) > How is upstream supposed to get their act together when 1.7 is not even > official released? And please remember that the com.sun.* classes are not in any !sun JDK either.
(In reply to comment #4) > (In reply to comment #3) > > How is upstream supposed to get their act together when 1.7 is not even > > official released? > > And please remember that the com.sun.* classes are not in any !sun JDK either. So is this why itext-2.0.2 dropped ppc/ppc64 keywords and there's even no bug about it? Upstream should be poked...
(In reply to comment #4) > (In reply to comment #3) > > How is upstream supposed to get their act together when 1.7 is not even > > official released? > > And please remember that the com.sun.* classes are not in any !sun JDK either. > Well really the argument there should have been ImageIO was introduced in 1.4 and all com.sun.*.JPEG* stuff was removed from docs and etc. So upstream should have addressed this at some point. Waiting till 1.7 comes out, does seem kinda last minute. Since deprecation warnings start in 1.5. (In reply to comment #5) > > So is this why itext-2.0.2 dropped ppc/ppc64 keywords and there's even no bug > about it? bcprov and bcmail did not have them. They would need to be keyworded first then itext re-keyworded. Don't believe a bug is required when dropping keywords, although a request to add might have been nice. If ppc/ppc64 wasn't such a pita. they are to archs :) Rarely ever in sync stabilization wise. Plus with the com.sun stuff, I believe was in 1.4.x as well. Was it really able to run properly on that arch? > Upstream should be poked... > Made a patch. Tested it out a bit. Just committed to tree. Adding example test apps here that should call and test the modifications. Closing bug as this is addressed now in 2.0.3. I will see about removing 2.0.2 sometime soon. If my patch causes problems or etc. Likely open a new bug to track that, but should be good to go.
Created attachment 120713 [details] Test case for new ImageIO functionality modified upstream example
(In reply to comment #6) > (In reply to comment #5) > > > > So is this why itext-2.0.2 dropped ppc/ppc64 keywords and there's even no bug > > about it? > > bcprov and bcmail did not have them. They would need to be keyworded first then > itext re-keyworded. Don't believe a bug is required when dropping keywords, > although a request to add might have been nice. If ppc/ppc64 wasn't such a > pita. they are to archs :) Rarely ever in sync stabilization wise. If we ignore it then they really won't be in sync. I always ask arches to rekeyword with new deps when that happens (usually right in the version bump bug). I think some policy even requires it... (strictly I think it says you preferably should ask for deps to be keyworded first, and then bump, but I prefer if they test the deps with the bump, which they have to when rekeywording :) > Plus with the com.sun stuff, I believe was in 1.4.x as well. Was it really able > to run properly on that arch? Maybe it was. Not all com.sun.* stuff is missing from other vendor jdk's. > > Upstream should be poked... > > > > Made a patch. Tested it out a bit. Just committed to tree. Adding example test > apps here that should call and test the modifications. Great :) Even greater if you send that upstream as well :)
(In reply to comment #8) > > If we ignore it then they really won't be in sync. If it's in use, or heavily used others will usually notice and keyword or request it be keyworded. Both those are not mainstream archs and a pita to have to deal with and care about. > I always ask arches to > rekeyword with new deps when that happens (usually right in the version bump > bug). There was not version bump bug. I noticed a new version was out and bumped package. As it was it had new deps which I had to address. > I think some policy even requires it... To my knowlege police requires that it be mentioned in changelog or etc. Which I did. *itext-2.0.1 (25 Mar 2007) 25 Mar 2007; William L. Thomson Jr. <wltjr@gentoo.org> +files/compile_xml.patch, -itext-2.0.0.ebuild, +itext-2.0.1.ebuild: Bumped package to latest version. Stopped downloading deps and switched to system installed versions per bug #171900. Dropped ~ppc/~ppc64 keywords due to bcmail keywords. Still looking into if 2.0.x should be slotted or not > (strictly I think it says you > preferably should ask for deps to be keyworded first, The one dep, bcmail was not in tree and I had to add that. > and then bump, but I > prefer if they test the deps with the bump, which they have to when > rekeywording :) > It was all to new. A new MAJOR version release of iText. Not a minor or bug fix release. Not to mention it had new deps which weren't in tree thus lacking keywords. Guess I could have filed a bug, but don't really care about ppc/ppc64 and had enough to deal with for the bump. Patches, package deps, etc. > > Great :) Even greater if you send that upstream as well :) > If you all give me a damn second I will. As I just did not even 5 minutes after committing to tree.
(In reply to comment #9) > > To my knowlege police requires that it be mentioned in changelog or etc. Which > I did. > Filing keyword request bugs when dropping keywords if for examples tested in the end of mentoring quiz.
