There is a new version of the reference implementation. The ebuilds would need the date updated to 20070711. I haven't checked yet if any of the Gentoo modifications would become obsolete. Notice that sun-jdk-1.6* provides a JAXB reference implementation as well, but they are not always up to date, and the two won't conflict according to https://jaxb.dev.java.net/guide/Which_JAXB_RI_is_included_in_which_JDK_.html
Cross references: bug 188009 about ant tasks bug 188011 about the schemagen command line tool The ant tasks require different source files, which could probably be used for the main jaxb builds as well. I don't know if there would be anything to gain, and the file used is way bigger than the one the jaxb ebuilds currently use. You can have a look at https://jaxb.dev.java.net/2.1.4/jaxb-ri-2_1_4.src.zip
Created attachment 127173 [details, diff] bump dev-java/jaxb to 1.4.1 The DATE of the new ebuild is 20070711. I reused the build file from 2.1.2. The libs directory after the Gentoo unpack doesn't exacly match the one directly after unpacking, but as everything compiles I guess that's all right.
Created attachment 127190 [details, diff] bump dev-java/jaxb-tools to 1.4.1 With the ebuild from bug 188015 I got jaxb-tools-2.1.4 emerged as well. Again I reused the build.xml from 2.1.2. The Dependencies were updated according to build errors I got during my experiments.
jaxb-tools-2.1.2 won't emerge with jaxb-2.1.4 so there should perhaps be a matching dependency to express this, so that when people need to downgrade, portage can sort out the right order. For a given input file, both 2.1.2 and 2.1.4 xjc will give me this error message if jaxb-tools was compiled using sun-jdk-1.6 but run on sun-jdk-1.5: Exception in thread "main" java.lang.ClassFormatError: Illegal class modifiers in class com/sun/tools/xjc/reader/xmlschema/bindinfo/package-info: 0x1600 I got this only when I got an uncaught NullPointerException with the matching VM, so there is some other bug as well and the two might be related. But still, a class that the VM doesn't like feels bad. I guess we have two alternatives, either try extra hard to build with 1.6 only if nothing else is installed, or pass --vm to the invocations of java-pkg_dolauncher if an 1.6 vm is used. I guess for both there might be a lot of useful stuff in the eclasses, but some help in the right direction would be appreciated.
(In reply to comment #0) > Notice that sun-jdk-1.6* provides a JAXB reference implementation as well, but > they are not always up to date, and the two won't conflict according to > https://jaxb.dev.java.net/guide/Which_JAXB_RI_is_included_in_which_JDK_.html Not as easy as one would hope. With sun-jdk-1.6.0.02 I get this error message: Exception in thread "main" java.lang.LinkageError: JAXB 2.0 API is being loaded from the bootstrap classloader, but this RI (from jar:file:/usr/share/jaxb-2/lib/jaxb-impl.jar!/com/sun/xml/bind/v2/model/impl/ModelBuilder.class) needs 2.1 API. Use the endorsed directory mechanism to place jaxb-api.jar in the bootstrap classloader. (See http://java.sun.com/j2se/1.5.0/docs/guide/standards/) A viable solution might be to have the java launcer script contain this line: gjl_java_args="-Xbootclasspath/p:/usr/share/jaxb-2/lib/jaxb-api.jar" It should be possible to do so using --java_args="..." in the ebuild. I have no idea what this will do when hit with non-Sun VMs. We could even include a small script in the launcher that recognizes the current VM and sets that variable only when known to work. Suggestions appreciated. BTW: I guess the same would hold for jaxb-2.1.2 though I haven't tried it.
(In reply to comment #5) > Not as easy as one would hope. With sun-jdk-1.6.0.02 I get this error message: The binary release works out of the box. I wonder how they do this. Would be nice if we could reproduce this for Gentoo. I begin to feel like we would really want to build from the huge snapshot zip so we can hopefully get all these goodies.
(In reply to comment #6) > I begin to feel like we would really want to build from the huge snapshot > zip so we can hopefully get all these goodies. Builds all right and fairly quick with a simple "ant dist", even with ANT_TASKS=none. OK, the sources seem to be self contained, using the common istack might be a problem, but I doubt that's worth it. The only issue I had was that I had to recode /crlf.. the xjc.sh to remove carriage returns. An unzip -a on the original zip file works equally well. (In reply to comment #4) > I got this only when I got an uncaught NullPointerException with the matching > VM, so there is some other bug as well and the two might be related. This one went away as well when using that zip file build. I'm too tired now to trust myself to write an ebuild for this, but atm I'm in favor of using that build. Replacing the jar files contained within that zip with ones installed in Gentoo we'll probably ensure things work together nicely at runtime if they work together at compiletime. However there are ten jar files in tools/lib/util that I could match to no ebuild. For six of them there are source files included with the ZIP, but for the first four I don't know of any sources (yet). ant-fsget.jar jam.jar maven-repository-importer.jar package-rename-task.jar args4j-1.0-RC.jar codemodel-annotation-compiler.jar jing-rnc-driver.jar pretty-printer.jar sfx4j-1.0.jar txwc2.jar I'm not sure whether we'd want ebuilds for those as well, or whether we'd simply use the version from the ebuild and assume it is only a build time dependency, or whether we should build those as part of jaxb and forget about them after the install. Maybe the build will even work without some of those, I don't know.
This report here is almost a year old, and still contains only my own comments. Meanwhile jaxb has reached 2.1.7. Is there any point in writing and submitting new ebuilds, would you rather drop jaxb from the tree as unmaintained, or simply leave it at its outdated version?
(In reply to comment #8) > This report here is almost a year old, and still contains only my own comments. > Meanwhile jaxb has reached 2.1.7. Is there any point in writing and submitting > new ebuilds, would you rather drop jaxb from the tree as unmaintained, or > simply leave it at its outdated version? > Best bet is to come by #gentoo-java, request overlay access, prove your skills and become a Gentoo developer.
sci-biology/cytoscape (bug #215877) will need this package
Created attachment 188750 [details] jaxb-tools-2.1.10.ebuild Working ebuild on ~x86. It gets picked up by cytoscape build pipeline. Please commit.
I forgot to put a notice here, but I had committed a largely rewritten version of jaxb 2.1.9 to java-experimental some time ago. It is based on a different source archive, and includes the jaxb-tools in the main jaxb ebuild, as this is how the upstream working tree builds them. Have a look. http://overlays.gentoo.org/proj/java/browser/java-experimental/dev-java/jaxb
(In reply to comment #12) > I forgot to put a notice here, but I had committed a largely rewritten version > of jaxb 2.1.9 to java-experimental some time ago. It is based on a different > source archive, and includes the jaxb-tools in the main jaxb ebuild, as this is > how the upstream working tree builds them. Have a look. > http://overlays.gentoo.org/proj/java/browser/java-experimental/dev-java/jaxb > # ebuild jaxb-2.1.5.ebuild digest >>> Downloading 'http://gentoo.mirror.web4u.cz/distfiles/JAXB2_src_20090917.jar' --2009-04-18 20:37:31-- http://gentoo.mirror.web4u.cz/distfiles/JAXB2_src_20090917.jar Resolving gentoo.mirror.web4u.cz... 81.91.81.13 Connecting to gentoo.mirror.web4u.cz|81.91.81.13|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2009-04-18 20:37:31 ERROR 404: Not Found. >>> Downloading 'https://jaxb.dev.java.net/2.1.5/JAXB2_src_20090917.jar' --2009-04-18 20:37:31-- https://jaxb.dev.java.net/2.1.5/JAXB2_src_20090917.jar Resolving jaxb.dev.java.net... 204.16.104.198 Connecting to jaxb.dev.java.net|204.16.104.198|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2009-04-18 20:37:36 ERROR 404: Not Found. !!! Couldn't download 'JAXB2_src_20090917.jar'. Aborting. !!! Fetch failed for JAXB2_src_20090917.jar, can't update Manifest # Martin, would you please re-test the ebuild and fix the digests? Bets if you could provide 2.1.10 so I can test just latest. Thanks.
(In reply to comment #13) > Martin, would you please re-test the ebuild and fix the digests? Bets if you > could provide 2.1.10 so I can test just latest. Thanks. Seems my last comment on this bug here got lost. Probably missed the notice about concurrent modifications of the bug report. Digests fixed now, and ebuild for 2.1.10 comitted. The jaxb-tools-2.1.10 ebuild attached seems to be based on my own for 2.1.9, which is basically a placeholder to ease transition. New ebuilds should depend directly on jaxb. There is no need to bump jaxb-tools-2.1.10. The ebuild from comment #11 has some added sources, so it might actually compile something, but it sure doesn't install anything except a symlink. And it has an unsatisfied dependency without my ebuild for jaxb-2.1.10.
# emerge -pv jaxb These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] dev-java/codemodel-2.1 USE="-source" 5,115 kB [0] [ebuild N ] dev-java/apt-mirror-1.0 USE="-source" 21 kB [0] [ebuild N ] dev-java/relaxngcc-1.12-r1 USE="-doc -examples -source" 2,112 kB [0] [ebuild N ] dev-java/rngom-20051226 USE="-doc -source" 1,339 kB [0] [ebuild N ] dev-java/jakarta-oro-2.0.8-r2 USE="-doc -examples -source" 338 kB [0] [ebuild N ] dev-java/sun-dtdparser-1.0 USE="-doc -source" 66 kB [0] [ebuild N ] dev-java/ant-junit-1.7.1 0 kB [0] [ebuild N ] dev-java/args4j-1.0 USE="-doc -source" 10 kB [1] [ebuild N ] dev-java/commons-codec-1.3-r2 USE="-doc -source -test" 87 kB [0] [ebuild N ] dev-java/commons-collections-3.2.1 USE="-doc -source -test -test-framework" 596 kB [0] [ebuild N ] dev-java/jzlib-1.0.7-r1 USE="-doc -source" 50 kB [0] [ebuild N ] dev-java/args4j-2.0.9 USE="-doc -source" 17 kB [1] [ebuild N ] dev-java/saxon-8.8 USE="-doc -source" 9,495 kB [2] [ebuild N ] dev-java/commons-httpclient-3.1 USE="-doc -examples -source -test" 1,839 kB [0] [ebuild N ] dev-java/xsom-20060901 USE="-doc -source" 103 kB [0] [ebuild N ] dev-java/jsch-0.1.37-r1 USE="zlib -doc -examples -source" 263 kB [0] [ebuild N ] app-text/jing-20030619-r3 USE="-doc -source" 2,465 kB [0] [ebuild N ] dev-java/codemodel-annotation-compiler-2.1 USE="-doc -source" 4 kB [1] [ebuild N ] dev-java/istack-commons-tools-20070711 USE="-source" 16 kB [1] [ebuild N ] dev-java/commons-net-1.4.1-r1 USE="-doc -examples -source" 224 kB [0] [ebuild N ] dev-java/txw2-compiler-20070407 USE="-source" 1,157 kB [1] [ebuild NS ] dev-java/jaxb-1.0.6-r1 [2.1.5] USE="-source" 6,242 kB [1] [ebuild N ] dev-java/commons-vfs-1.0 USE="-doc -source" 273 kB [0] [ebuild N ] dev-java/ant-ivy-1.4.1 USE="-doc -examples -source -test" 735 kB [1] [ebuild N ] dev-java/ant-contrib-1.0_beta3 USE="-doc -source" 3,221 kB [0] [ebuild U ] dev-java/jaxb-2.1.10 [2.1.5] USE="-doc% -source" 0 kB [1] Total: 26 packages (1 upgrade, 24 new, 1 in new slot), Size of downloads: 35,775 kB Portage tree and overlays: [0] /usr/portage [1] /usr/local/java-experimental [2] /usr/local/portage/layman/java-overlay # am going to compile ...
OK, have unmerged jaxb-tools and emerged jaxb-2.1.10 and it went all fine. Please drop all the unnecessary ebuilds of jaxb-tools* from overlays if possible. Or, this jaxb ebuild should block them. Please fix the sci-biology/cytoscape ebuild so that it does not require dev-java/jaxb-tools-2.1.10 from java-experimental. Thanks.
(In reply to comment #16) > OK, have unmerged jaxb-tools and emerged jaxb-2.1.10 and it went all fine. > Please drop all the unnecessary ebuilds of jaxb-tools* from overlays if > possible. Or, this jaxb ebuild should block them. Why? The transition ebuild has several benefits. It depends on jaxb, so the jaxb tools which are part of a jaxb installation do get installed. Furthermore, it installs a symlink, so "java-config -dp jaxb-tools-2" will give you a classpath from which you can execute xjc. The notice from the ebuild tells users who have jaxb-tools in their world list that the package is a transition package, and that they may remove it if they wish, using jaxb instead. The jaxbe ebuild already does block versions of jaxb-tools before 2.1.9. > Please fix the sci-biology/cytoscape ebuild so that it does not require > dev-java/jaxb-tools-2.1.10 from java-experimental. Thanks. Andrey, I'll not mess with your stuff. Please take care of it.
Bumped to 2.1.11 in the java-experimental overlay, without ebuild modification. Also had a look at the 2.2 early access version. Won't compile as the apt-mirror jar file, called jam.jar in the snapshot, was for some reason removed from the classpath. This needs some more work. 2.1.11 should be good enough for now, though.
Bumped to 2.1.12 in the java-experimental overlay. The modifications to the ebuild seem suitable to compile the 2.2 EA as well, so if anyone should need 2.2, I think I can provide an ebuild.
(In reply to comment #19) > Bumped to 2.1.12 in the java-experimental overlay. The modifications to the > ebuild seem suitable to compile the 2.2 EA as well, so if anyone should need > 2.2, I think I can provide an ebuild. > Try to help us with building the cytoscape ebuild. ;-) But maybe it does not ned the newest version, I really do not know and java is not my piece of cake. ;) See comment #10.
Bumped ebuild in java-experimental overlay to 2.2.
Created attachment 397722 [details] jaxb-2.2.1.ebuild Since the java-experimental overlay seems to be gone, and It doesn't look as if my ebuild had made it to any other overlay, here is the latest working ebuild I found on my HDD. To preserve it for posterity. If there is any interest at all in writing an ebuild for an up-to-date version of jaxb, let me know and I'll be happy to help. As it is, I don't feel like investing time which noone seems to appreciate, so I guess I'll stick to maintaining my own setup of jaxb and its tools, without bothering portage.
(In reply to Martin von Gagern from comment #22) > Created attachment 397722 [details] > jaxb-2.2.1.ebuild > > Since the java-experimental overlay seems to be gone, and It doesn't look as > if my ebuild had made it to any other overlay, here is the latest working > ebuild I found on my HDD. To preserve it for posterity. If there is any > interest at all in writing an ebuild for an up-to-date version of jaxb, let > me know and I'll be happy to help. As it is, I don't feel like investing > time which noone seems to appreciate, so I guess I'll stick to maintaining > my own setup of jaxb and its tools, without bothering portage. sorry for our lack of attention. we as a java team are understaffed so any help is welcome. in fact we need more help of people like you. but the fact that only gentoo devs can commit ebuilds means that we have to go through every contribution and commit that ourselves which is huge amount of work considering that we also have to fix other bugs, maintain packages, work on eclasses etc. that is why we are looking for other wanna-be gentoo java devs so that the state of java packages in gentoo improves over time. so please be patient with us.
both packages have been removed. Closing as WONTFIX.