[kepler-dev] Duplicate Jar information

[Kevin Ruland]

Dan,

Perhaps the best solution is a custom classloader for each actor?  The
actor would be configured with it's own classpath.  This would be quite
a bit like the j2ee classloader.

The easy alternative is to have very strict control of 3rd party
dependent jars.  Then if somebody needs/wants to use an alternative,
they need to present the appropriate case *and* test the other impacted
code.

Kevin

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.
>
> Dan
>
> ----
>
> 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.
>>
>> Kevin
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at ecoinformatics.org
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>  
>>
>
>