While trying to emerge eclipse-sdk, I discovered a circular dependency. dev-java/bsf-r4 lists dev-java/xalan as a COMMON_DEP, and dev-java/xalan-2.7.0-r3 lists =dev-java/bsf-2.3* as a COMMON_DEP. I was able to work around it by emerging xalan with the --nodeps flag. I was not able to emerge bsf with --nodeps. Maybe bsf should be removed from xalan's dependency list. Reproducible: Always
(In reply to comment #0) > While trying to emerge eclipse-sdk, I discovered a circular dependency. > dev-java/bsf-r4 lists dev-java/xalan as a COMMON_DEP Sorry, that should have read dev-java/bsf-2.3.0-r4
Thanks for reporting. For now I've removed xalan dependency from bsf. It's used there to build additional functionality, and I added it there only yesterday. But as you say, xalan can be built without bsf on compile-time, it will use it only during runtime. So if we could make xalan PDEPEND on bsf and record bsf.jar dep into package env before it's installed, the circular dependency is solved easily. I'll leave this open until that's considered.
When you remove the xalan dep from bsf, and it actually is using xalan, it could be using a bundled version of xalan that comes with the JDK. I'm not positive if this is the case, but I do know some libraries like xerces are bundled.
(In reply to comment #3) > When you remove the xalan dep from bsf, and it actually is using xalan, it > could be using a bundled version of xalan that comes with the JDK. > This is only a problem with something like blackdown-jdk that still uses org.apache.* packages. For example sun-jdk >=1.5 use com.sun.org.apache so that there is no possibility for packages to get xalan from the jdk.
OK here's more info. bsf's build.xml has <available> check for "org.apache.xalan.xstl.EnvironmentCheck" that triggers building of additional classes. I removed these checks because they can survive even build.sysclasspath=ignore which was causing problems with optional jython and rhino deps. I also though that due to this checks, most people in the past was passing this check due to xalan being on ant's runtime (didn't realize that xalan was depending on bsf, so for new clean installations this wouldn't be true, but after remerging bsf due to updates with xalan already installed it would be nevertheless) so I made xalan dep mandatory and trigerred building of the classes by passing -Dxalan.present=true explicitly, instead of the automagical tests. But as I just checked, although build.xml checks for xalan-specific class, the additional classes are just using the generic interface javax.xml.transformer. So it doesn't need Xalan specifically, just some XSLT implementation. And as ant's manual says, "If you use JDK 1.4+, an XSL transformer is already included, so you need not do anything special.". I've checked and there's no problem building it without xalan, using sun-1.4+1.6, blackdown, kaffe. So I think I can just pass the trigger for building these classes, without any xalan dep at all, because we are already 1.4+.
(In reply to comment #5) > So I think I can just pass the trigger for building these classes, without any > xalan dep at all, because we are already 1.4+. in bsf-2.3.0-r5
