commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Davey <Michael.Da...@Sun.COM>
Subject Re: [JJAR] New features
Date Mon, 12 Aug 2002 09:18:03 GMT
Nicola Ken wrote:


> If I use the flag that tells JJAR not to get dependencies, and I give a 
> version, I don't need it, since the filename conversion is enough.
> In fact the tag that tells what the jar name is, is redundant, because 
> in the code you seem to check package and version from the filename... 
> can't we just remove it and assume that package-version is enough since 
> we will always have a package-version.jar?

I think it should be the other way around.  JJAR should not use the jar name to 
work out the package name and version.  If possible, JJAR should use the 
Manifest details (Name, Specification-* and Implementation-*).  Failing that, 
JJAR could use the digest of the Jar file (MD5 or SHA) and look up the package 
name and version from the repository.

Geir wrote:
 > This presents an interesting question - can a package  have dependencies
 > that change over time?  Suppose a dependency had a bug, and the authors of
 > the dependency released a fix.  I guess for now, we just punt and say that a
 > local definition in the local repo is definitive for any operation, and then
 > later add a 'refresh' op that updates the local repo jars and descriptor.

The Optional Package Versioning guide (guide/extensions/versioning.html from 
your J2SE API root) specifies 4 types of dependency:
   1  Need an API that meets specification 'w'
   2  Need an API that meets specification 'w' version 'x'
   3  Need an API that meets specification 'w' version 'x' and is supplied by 
vendor 'z'
   4  Need an API that meets specification 'w' version 'x' and is version 'y' 
supplied by vendor 'z'

I'd suggest the following behaviour for JJAR:

If package 'a' version 'b' specifies a type 1 or type 2 dependency, then once a 
jar has been supplied that meets the dependency, the jar can be replaced with 
newer versions of the jar (by the same vendor) as long as the dependency is 
still met.

Choosing the vendor in the first place and changing of vendor will most probably 
have to be done with user interaction as it is unlikely that the repository will 
be able to decide which vendor currently provides the "best" implementation.

Similarly, for type 3 dependencies, the jar can be replaced with newer versions 
by the same vendor.

For a type 4 dependency, the target jar can be replaced only as long as the 
version number still matches the supplied number.  So, if the dependency 
specifies Foo class version 1.2, JJAR can initially fetch version 1.2.0 and 
replace the dependency over time with 1.2_1, 1.2_5 and 1.2_99 but not 1.3_0.

Does this mean that as JJAR downloads a jar, it needs to keep a per-directory 
log of why the jar was downloaded (that is, what dependency a jar fulfils). 
Does this also apply to jars in the classpath, or should they always treated as 
a type 1 dependency?


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message