commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject Re: [JJAR] New features
Date Mon, 12 Aug 2002 09:40:17 GMT
On 8/12/02 5:18 AM, "Michael Davey" <Michael.Davey@Sun.COM> wrote:

> Nicola Ken wrote:
> [snip]
>> 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.

If it's there.  The idea is that the [distributed] repository is managed, so
the jar name can be trusted in each case.

But I like the idea of turning to the manifest as well.

> 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.

That's reasonable, but this seems to be more tailored to sun's suggestion of
how the world should work, rather than how it does work.  Maybe that's a
little harsh, but look at any of the commonly used non-JSR stuff, and there
is no notion of multiple vendor for a given spec, as there isn't a spec.
For example, there is no log4j, velocity or dom4j 'spec' per se, and there
is only one source for each of the above.

> 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.

Agreed.  For the repos that an open-source community might provide (like the
Maven one) you don't choose a vendor for this stuff, as they are
single-source projects, and anything that does have multiple-vendor choice
will probably commercial implementations of Java specs (like JMS), which you
couldn't distribute. (And in my experience with things like JMS, the
looseness of the specs tends to mean that vendors aren't "drop in"
replaceable anyway...)

> 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.

I would trust this *only* if the specifier of the dependency (i.e. The
package owner) stated that 1.2_x works...

> 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?

Interesting - I'm not sure I would make this automatic, again as I'm not
sure how much you could trust dependency/spec claims..

Geir Magnusson Jr. 
Research & Development, Adeptra Inc.

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

View raw message