[kepler-dev] Duplicate Jar information
kruland at ku.edu
Fri Aug 12 20:00:13 PDT 2005
One thing I didn't notice until later, the xercesImpl.jar in jwsdp is
Sun's repackaged xerces. I don't believe they've distributed this with
jwsdp for quite some time.
Dan Higgins wrote:
> Hi Kevin,
> Thanks a lot for compiling this information. (and the suggestions).
> Almost all of the duplications are apparently the result of adding
> the /jswp dir to the jars folder. I think this was done recently by
> jagan to get the 'griddles' package working. This jar duplication
> creates a problem that we haven't yet solved. Changing the jar name to
> include the version is a great idea, but it doesn't help the problem
> of duplicate class names inside the jar. You might have noticed that
> we already add a command line arg to java in the 'run' and 'run-dev'
> tasks in ant to place one set of jars in the jave 'endorsed'
> directory to insure it is linked first.
> i.e. <jvmarg value="-Djava.endorsed.dirs=./lib/jar/apache"/>
> This was removed by jagan to get his griddles package working, but
> removing it breaks all the ecogrid packages! (So it is back in the
> build file for now.) [In this case, we are overriding classes
> distributed with Java.]
> I am not sure how we are going to keep everyone happy considering
> these versioning issues. The KSW packages that Chad is working on will
> solve some of the problems in that jars needed only by specific actors
> will be pulled out of our huge classpath list and included in the
> *.ksw packages (i.e. included with the actor code). The number of jars
> used by Kepler itself should be significantly reduced. We are also
> going to need to get dynamic class loading (and unloading) working to
> allow multiple versions of classes with the same names to be used.
> Kevin Ruland wrote:
>> Hi all.
>> Since I'm the new guy, and struggled to make a working eclipse build, I
>> decided to share some of the information I've gathered.
>> I went through all the jars in lib/jars to look for blatent duplicates
>> and this is what I found:
>> activation.jar . - Probably JAF 1.0.2 build by jdk 1.3
>> activation.jar ./jwsdp - Probably JAF 1.0.2 built by jdk 1.4.2_05
>> commons-logging.jar . - 1.0.3
>> commons-logging.jar ./jwsdp - 1.0.3
>> commons-logging.jar ./sms - 1.0.3
>> jax-qname.jar . - Version ?? (jdk 1.3.1_04)
>> jax-qname.jar ./jwsdp - Version 1.1 (jdk 1.4.1_02)
>> log4j-1.2.7.jar .
>> log4j-1.2.8.jar .
>> namespace.jar . - Version ?? (jdk 1.3.1_04)
>> namespace.jar ./jwsdp - Version 1.0.1
>> relaxngDatatype.jar . - Version ?? (jdk 1.4.1_02)
>> relaxngDatatype.jar ./jwsdp - Version ?? (jdk 1.4.1_02)
>> xalan.jar ./apache - Version 2.4.0
>> xalan.jar ./jwsdp - Version 2.6.0
>> xercesImpl.jar ./jwsdp - from manifest Xerces 2.6.2
>> xercesImpl.jar ./sms - from manifest Xerces 2.6.1 ( This one jena
>> works with - perhaps it's an older jena?).
>> xmlsec.jar ./ecogrid_client_lib - Version 1.0.4
>> xmlsec.jar ./jwsdp - Version 1.1.0
>> xsdlib.jar . - Version ?? (jdk 1.3.1_04)
>> xsdlib.jar ./jwsdp - Version ?? (Ant 1.6.2)
>> There are some bookkeeping which I have found very useful in previous
>> large projects:
>> - Rename the jars. If a 3rd party jar is needed, rename the jar with
>> the version number. So for example, rename xercesImpl.jar to
>> xercesImpl-2.6.2.jar This makes it completely obvious what the version
>> is (and people like me don't need to dig through manifests.)
>> - Use version named directories for larger packages. jwsdk (Java Web
>> Services Developer Pack) has had numerous releases. Create a directory
>> say jwsdk-1.5 and put only the jwsdk1-5 jars inside. It appears that
>> there is one version of jwsdp (in it's own directory) and another whos
>> contents has been put in lib/jar
>> - Seperate runtime/buildtime jars from code generation jars. What I
>> mean here is something like jaxb. It has a very large code-generation
>> piece (jaxb-xjc, jaxb-qname, relaxng, and others) which are only needed
>> to generate the bound java classes. Then it has a supporting cast
>> (jaxb-api, jaxb-impl, jaxb-libs) which is required for build and
>> runtime. The runtime jars are needed by ant when the source is compiled
>> and executed, but the cg jars are only needed to generate source.
>> - Don't mix logical units. It sees the jwsdp directory is a combination
>> of JWSDP (as distributed by sun, which version, I don't know), apache
>> xerces/commons, and some mystery sun jar (PackageFormat.jar).
>> - Know your target audience. The xml-apis.jar is very notable. This
>> jar is only needed when building with jdk 1.2 or earlier. jdk1.3 and
>> newer included it in rt.jar. I believe we're targeting jdk 1.4 and
>> therefore this jar is not needed at all.
>> Kepler-dev mailing list
>> Kepler-dev at ecoinformatics.org
More information about the Kepler-dev