Bugzilla Bug 161011

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