[kepler-dev] Duplicated jar contents.

[Kevin Ruland]

Shawn Bowers wrote:

> Kevin Ruland wrote:
>
>> The SMS system jars have significant overlap with other jars and is also
>> very complex.  I would appreciate it if you would document what the
>> requirements of the code is.  This includes revisions of specific jars
>> which are know to be compatible and those which are know to not work.
>
>
> I think you are completely missing the point: Many of the jars are 
> required
> exactly by the packages used by code in kepler -- not by the kepler code
> directly!
>
The analysis I did which produced this report was essentially a diff of 
the jar's contents looking for overlap.  All it states is that certain 
classes appear in more than one jar file on the classpath and indicates 
which particular copy of that class would be used if it's used at all.  
It does not attempt to distinguish which source in kepler requires which 
particular classes.  That report will be out soon.

The unfortunate situation is if another class in kepler or some other 
actor requires a class, it can be provided by a different jar than 
anticipated.  Even if you think your jar is only used by your piece of 
code, in fact, you might be using somebody else's jar.  This is exactly 
what I'm trying to point out.  As you can see from my analysis below,  
even though the sms developers might have thought they were using the 
edu.stanford.db.* classes from lib/jar/sms/rdf-api-2001-01-19.jar, in 
fact they were pciked up from lib/jar/scia/sf_edu.jar.

And since java 1.4 was so nice to bundle org.apache.xerces in rt.jar, 
where you thought you were using lib/jar/sms/xercesImpl.jar, in fact you 
were using that in rt.jar.   What version of xerces that is, I do not know.

> For SMS, the only code we rely on right now is Jena -- you can go to 
> their
> web-page to find out which packages are required for the particular 
> release
> we are currently using ...
>
I have never developed with Jena but I do know there are about 4 or 5 
different released versions.  I have no clue which version was placed in 
lib/jar so I have no idea how to determine its runtime requirements.  
Instead of trying to figure this out, I would be inclined to just blow 
away the existing jars and place a known version in the repository.  
Since that is probably not what you want, and could very likely break 
things, I would appreciate it if you could track this down.

Kevin