On Dec 5, 2005, at 4:26 PM, Radu Preotiuc-Pietro wrote:
But actually, I
realized that the more important reason we keep the source jars around
is that we have custom modifications to the respective codebases.
Okay, that does make more sense.
I also don't understand how XmlBeans finds the source JAR to begin
with. If it's not on the CLASSPATH (which wouldn't make sense anyway
because it doesn't contain classes), how does XmlBeans find the JAR?
Hm, not sure I understand this question.
Basically, I'm trying to set up a system-wide installation of
XmlBeans. That way, each user doesn't have to install redundant
copies of the XmlBeans JARs. For instance, the shell scripts
(sfactor, xsbdump, etc.) could be placed into, say, /usr/local/bin/
and xbean.jar could be placed into /usr/share/java/. A system-wide
CLASSPATH, set automatically when a user logs in, would then include
this JAR.
All that should work fine (I think) except for the source JARs. Where
do I put them? If I put them in, say, /usr/local/xmlbeans, how does
XmlBeans know that's where I put them?
Where would this interference come from? As long as the version you
want to use is on your CLASSPATH and the one XmlBeans uses isn't,
there wouldn't be any conflict, right?
As long as. But if both this other version and XmlBeans' version
were on
the classpath, then you would either have to use the same version that
XmlBeans uses, or XmlBeans may break due to minute differences between
versions.
Hmm, then it sounds like a system-wide installation of XmlBeans is
impossible. In other words, if I put xbean.jar in my CLASSPATH, and I
also have the "real" JAM or Piccolo JARs in my CLASSPATH, then
something's going to break. For instance, apps that require the real
JAM might find the XmlBeans JAM, or XmlBeans might grab the real JAM,
depending on the order of JARs in the CLASSPATH. Either way,
something can go wrong.
Not here. xcresolver(*), stax-api and saxon (*) are used as normal
dependencies from a jar that you have to have on the classpath
(*) if you need the specific feature that the jar provides, you can
run
without them
Do you mean... if I *don't* need the specific feature the JAR
provides? Also, what do you mean by (*)?
Thanks,
Trevor
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
