/usr/share/java as maven repository?

[Dalibor Topic]

Marcus Better wrote:
> Paul Cager wrote:
>> E.g. the POM could require JUnit-3.8.1 but Debian has packaged version
>> 3.8.2. In this case we would set up a link in the temporary Maven
>> repository:
>>
>>   debian/.m2/repository/.../junit-3.8.1.jar -> /usr/share/java/junit.jar
>> -> /usr/share/java/junit-3.8.2.jar
> 
>> We should check that the Debian version is not *older* than the version
>> required by the POM, but we are still relying on releases being backwards
>> compatible. Any comments?
> 
> This is a recipe for disaster since the dependencies will likely break ABI
> at some point. Then our package will FTBFS if we are lucky, or build and
> run with the wrong version and give very interesting bugs later on. (On the
> other hand it's similar to what we already do...)
> 
> It seems to me that we must keep track of ABI compatibility. This is a bit
> complicated, but it's our job if we want to be a well-integrated
> distribution. In other words we should try to solve the library versioning
> problem first, and only then try to build packages with Maven.

There are two sides to that: ABI compatibility tells us if class A will 
continue to link to class B. It does not tell us anything about classes 
using reflection, for example. So it's not a substitute for rebuilding 
and rerunning the test suite, just a quick way of confirming that a 
combination of classes would cause trouble.

I think the stricter criterium (builds & runs tests successfully) is 
sufficient, and does not require maintaining ABI information.

cheers,
dalibor topic