Hello,
Liliana Marie Prikler <liliana.prik...@ist.tugraz.at> writes:
> Am Montag, dem 17.10.2022 um 22:45 -0400 schrieb Maxim Cournoyer:
>> Hi Julien,
>>
>> Julien Lepiller <jul...@lepiller.eu> writes:
>>
>> > You're right, java package don't retain references to there input,
>> > that's why we propagate required dependencies (mh… sometimes). I
>> > don't
>> > know how they could reference dependencies directly.
>>
>> Could we, along with installing Java classes as directories instead
>> of .jar archive files [0] at a more specific prefix, define a search
>> path specification that'd set CLASSPATH? Currently I don't see
>> anything setting CLASSPATH outside of the build systems, so even if
>> we propagate Java things, I don't see how it'd find them in a
>> profile.
> I'd recommend writing an xml file like
>
> <path id="${java-package-name}.classpath">
> <pathelement location="${output-jar}" />
> <pathelement path="${input1.classpath}" />
> ...
> <pathelement path="${inputn.classpath}" />
> </path>
>
> to a well-known location. Then we could reuse those files in ant-
> build-system.
A nice read is [0], which mentions the existence of a 'Class-Path' main
attribute that can go in the manifest file. If using unpacked jars
works the same as .jars (which are just zip files) for Java, then we
could not only have dependency correctly referenced and loaded via
'Class-Path', but also the grafting mechanism would work, since the
paths would appear in clear (not obfuscated due to zip compression).
Our current usage of JarIndex doesn't suite the bill it was intended
for; this is a performance trick to index all the .jars of a .jar pack;
it'll only list its dependencies if they are packed in the same jar,
which is not what we do or want as a distribution.
[0] https://docs.oracle.com/en/java/javase/19/docs/specs/jar/jar.html
--
Thanks,
Maxim
