Project Jigsaw goals and requirements

[David M. Lloyd]

On 06/02/2011 09:50 AM, Tom Marble wrote:
> On 06/01/2011 03:55 PM, David M. Lloyd wrote:
>> The two aren't mutually exclusive. [..] testing it in the modular environment is a different problem.
> I understand.
>
>> [...] If build-time version ranges are employed then it's possible that the maintainer of
>> widget could end up testing different classes, and ultimately be unable to reproduce the problem.
> The idea of the range is, IMHO, that the underlying API semantics are
> reliable.

Yes, that is true.  The problem though isn't with the API semantics, 
it's with the mechanics of class generation, which could cause surprise 
linkage errors.  The problem is further compounded when you consider 
things like Maven's "shade" plugin, wherein dependency classes are 
copied into the new artifact (generally under a different package), 
which could in turn affect API semantics after all.  This is a thing 
that should be supported by a robust build system.

This problem even shows up for non-Java things.  I remember my days 
running Gentoo Linux... if you update packages in the wrong order or 
build things when the wrong packages were present, you could introduce 
creeping time-bombs into your system.  And no Gentoo system is exactly 
like another, which means that troubleshooting becomes quite a lot more 
difficult.

It's all about reducing the number of variables.  The fewer variables, 
the more reliable the system.

> Are you really proposing updating the 'build-depends' graph
> to *exact* versions for building (possibly with relaxing the versions to
> become ranges at install and runtime)?

Yes, that is exactly what I am proposing, though I'd drop the word 
"possibly" as it would be an inevitable requirement to be able to update 
a package without a massive cascading dependency graph update.  As long 
as the build versions were current at one time within a version 
environment though, it is not too hard to maintain since the artifacts 
are always available at build time.

Maven in fact does this very thing, though this (like many other things) 
it approaches from the wrong end.  Artifacts (in a sane build) have a 
fixed-version dependency graph, which generally come in transitively 
most of the time, and it is up to the consumer of the dependency to 
override the version it uses, particularly important at test-time (which 
is as close a thing as Maven has to a run time).

> I see your rationale, but it (exact build dep versions) does sound
> like a lot of work to maintain.  Are you using that approach now
> for the Java related dependency graph of *.rpm's in Red Hat?

Yes and no... sometimes... it depends on whether you're talking about 
Fedora or RHEL, and even then it's sometimes a gray area depending on a 
few other factors.

However fixing this is among my goals for the year, and the fix will 
probably involve JBoss Modules (our module system) at some level.

> Separately you are probably the expert on RPM version syntax...
> Can you point us to an authoritative grammar?  (A fair answer,
> of course, would be to use-the-source of rpm).

I'm afraid I am not, but asking around yielded this information:

http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Package_Versioning

Note that this is the guidelines for Fedora, not for RPM itself.  And 
also note that JPackage packages follow different rules, maddeningly:

http://fedoraproject.org/wiki/Packaging/JPackagePolicy

-- 
- DML