Edwin Goei wrote: > [EMAIL PROTECTED] wrote: > >> Hi Gopal, >> >> Thanks for the suggestions; they both do indeed work. >> >> But this still doesn't seem to be a very good situation: To compile a >> modern version of Xalan, I first need a compiled version of modern Xalan. >> i.e., as soon as I make a change which would be incompatible with the >> current Xalan jar I'm using on the bootclasspath or as the target of the >> java.endorsed.dirs property, I've got to use an older JDK to build a new >> jar. Then I can return to 1.4.x and use this new jar for additional >> compilations/tests. >> >> Because of the way Sun JDK's are packaged--with everything including >> Xalan >> and the kitchen sink in rt.jar--I've come to the conclusion that no good >> solution exists on this platform. In JDK's that are packaged with >> different components in different jars, it'll be possible to exclude the >> appropriate jars from javac's bootclasspath so that it will be >> possible to >> dynamically build entirely new Xerces/Xalan jars without reference to >> pre-existing ones. It's just unfortunate that Sun JDK's aren't packaged >> differently. >> >> Can anyone else see any workaround? Anybody know whether this is how Sun >> JDK's will always be packaged? > > > After reading this thread in xalan-dev, I think I understand the issue. > I would suggest as a workaround to use the -bootclasspath option of > javac and prepend the *new* xalan classes before rt.jar.
Actually, after trying it out myself. I believe, what you actually want is to use the -sourcepath option of javac, along with the -d option. See for example, http://java.sun.com/j2se/1.4.1/docs/tooldocs/solaris/javac.html#searching for more details. This will cause javac to look for *newer* versions of the *source* instead of using old precompiled versions. BTW, I haven't been following this thread and I have noticed other replies since my last post. I will reply to those separately. -Edwin
