There is an issue with this bump. As the changelog says: Migrated the DOM Level 3 serialization support onto a common serialization codebase shared with Xalan and deprecated Xerces' native serializer. This means the upstream binary comes with bundled serializer.jar from xalan (xalan itself consists of xalan.jar and serializer.jar). I've already tested building of xerces-2.9.0 and although it will build fine without serializer.jar (uses dynamic class loading and can fallback to own implementation if xalan's not found), I think it's better to go with upstream suggestion and let xerces use xalan's serializer. But that's a problem, xalan depends on xerces so we can't let xerces depend on xalan (circular dep). So here's the possible solutions I see: a) let xerces build without symlink to serializer.jar (as it's not needed build-time) but somehow (extend eclass to be able to) record the dep to package.env dependency, and put xalan in PDEPEND to ensure it will be there. b) move serializer.jar out of xalan to separate package (xalan-serializer?) and let both xalan and xerces depend on it.
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.
