Summary: | dev-java/xerces-2.9.0 version bump | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Vlastimil Babka (Caster) (RETIRED) <caster> |
Component: | New packages | Assignee: | Java team <java> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://xerces.apache.org/xerces2-j/releases.html | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Vlastimil Babka (Caster) (RETIRED)
![]() b seems like the best choice here. Okay, will implement it in migrated-overlay first and see what breaks :) initial ebuild of xalan-serializer is in the migrated overlay need to polish the building of rest if xalan, probably fixing bug 113894 on the way... then I can commit it together with xerces and let the testing begin Everything is now in the overlay. The split xalan: dev-java/xalan-serializer-2.7.0 dev-java/xalan-2.7.0-r4 xerces: dev-java/xerces-2.9.0 All of this seems pretty finished on my side, except xalan could be tweaked to exclude serializer.jar's classes also from javadoc and sources packed by java-pkg_dosrc. What it definitely needs before merging to portage is extensive testing - both of split-xalan and xerces itself. I've tried maximum backwards compatibility for now, by recording serializer.jar into xalan's CLASSPATH in package.env like split-mx4j does, and also creating it as symlink, should anything reference it with absolute path. After it's merged and stabled, we can remove this backwards compatibility in ~arch (or p.mask) revbump and test stuff to see if something builds against the classes in serializer.jar and thus needs to be updated to xalan-serializer DEPEND as well. Xerces needs to be tested if anything breaks with it (and thus needs new slot, god please no). Sat in overlay for long enough. Had no probs with it. Commited to tree. |