[kepler-dev] Duplicated jar contents.

[Matt Jones]

I'd have to agree with Kevin here -- the problem is that we're only 
using one classloader in Kepler now and so there can only be one loaded 
class, even when people have added jars that have conflicting 
dependencies.  Up until now we've been pretty loose about what jars 
people can add to Kepler, with the result that we easily can generate 
conflicts when the people adding jars don't consider the whole 
application.  In order to move to a stable release we all need to bite 
the bullet and become far more formal about which jars we ship, what 
their dependencies are, and how we test for conflicts.

I've asked Kevin to try and work this out so that we have something 
workable for the freeze date, but he can't do it without the help of the 
people that might have contributed the jars in the first place.  If 
Kevin has to work it out by himself, I think the only sensible solution 
would be to remove everything except a few core jars, and then work with 
the original contributors to add them back in.  But it might be easier 
if those developers worked with him now to identify requirements for 
their code.

Once we identify a non-conflicting set of jars, we should probably 
institute a policy of no new jars added to CVS without a discussion 
first on the mailing list, and maybe even lock down the jars directory 
to only allow one person write access, and that person becomes 
responsible for conflict review.

Over the longer term we'd like to utilize different classloaders for 
each actor, which would allow actors to have conflicting dependencies 
and would make things easier for actor developers.  But the underlying 
Kepler engine would still have a shared loader, so some degree of 
interoperability must be acheived here.

Matt

Kevin Ruland wrote:
> 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
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matt Jones                                   Ph: 907-789-0496
jones at nceas.ucsb.edu                    SIP #: 1-747-626-7082
National Center for Ecological Analysis and Synthesis (NCEAS)
UC Santa Barbara     http://www.nceas.ucsb.edu/ecoinformatics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~