[kepler-dev] Duplicated jar contents.

[Shawn Bowers]

Some problems (I'm in a hurry, so it's a bit terse):

  1. Other projects might not appreciate us writing them
     asking for them to rewrite their code so that it works
     with the "latest" release of a jar -- or some dependency
     on a jar that another project uses (this point doesn't
     seem to be addressed in the emails so far; that there
     are complex dependencies not controlled by the "contributor"
     of the jars ...)

  2. Figuring out when code breaks because we swap out some
     "old" code (jar) with "new" code will require major/extensive
     testing

  3. Yanking out all but a few core jars will cripple Kepler and
     will probably result in major schedule slips for any type of
     alpha/beta/full release we want to do

-shawn




Matt Jones wrote:
> 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
>>
>