On Wed, 30 Jan 2019 at 21:15, Hartmut Goebel h.goebel@crazy-compilers.com wrote:

Hi,

I'm packaging some Java packages for guix https://www.gnu.org/software/guix/, a functional package manager (much like nix).

I would appreciate some assistance for understanding how to leverage Xmvn in this case.

Guix installs each package into a prefix of it's own, e.g.:

/gnu/store/...-plexus-io/share/java/plexus/io.jar /gnu/store/...-dom4j-1.6.1/share/java/dom4j/dom4j.jar

Thus Xmvn shall pick up artifacts and meta-data from all prefixes belonging to the current profile/environment. Each prefix could contain a .../xmvn/configuration.xml and $XDG_DATA_DIRS could be used to get a list of these.

So each package installs its own xmvn configuration.xml file?

I tried this and it worked different then expected.

I tried to use the "prefixes" (according the the Xmvn configuration reference [1]) as shown below. But the Xmvn does not even try to access these prefixes. Can somebody explain why, please?

<configuration> <resolverSettings> <prefixes> <prefix>/gnu/store/...-plexus-io</prefix> </prefixes> </resolverSettings> </configuration>

I learned that I need to define <metadataRepositories>, which worked. But I'm wondering what are the <prefixes> then used for and how to test whether my set-up is correct.

I've always specified the <prefixes/> section along side the <metadataRepositories/> section when I work on SCLs (Software Collections) where I have many filesystem install roots from which I wish to resolve packages. For example:

<metadataRepositories> <repository>/opt/my_scl/root/usr/share/maven-metadata</repository> <repository>/opt/your_scl/root/usr/share/maven-metadata</repository> </metadataRepositories> <prefixes> <prefix>/opt/my_scl/root</prefix> <prefix>/opt/your_scl/root</prefix> </prefixes>

With corresponding <repository/> configurations, then when I try to resolve an artifact, for example doing: $ xmvn-resolve commons-io:commons-io

Then the artifact may be found in "/opt/my_scl/root/usr/share/java" or "/opt/your_scl/root/usr/share/java" depending on which SCL is delivering that artifact.

I guess the term "prefix" may be overloaded here because these prefixes are prepended to the usual installation prefix of /usr. (Double prefix!) It looks like guix is simply changing the install prefix from /usr to something unique per-package? So you may not need to specify these SCL-style prefixes at all.

Can you correctly resolve artifacts using the xmvn-resolve tool?

Thanks in advance for any answer.

Please note: I'm using Xmvn 2.5.0 since this is what my distribution currently ships .

[1] https://fedora-java.github.io/xmvn/config.html

-- Regards Hartmut Goebel

| Hartmut Goebel | h.goebel@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |

---

java-devel mailing list -- java-devel@lists.fedoraproject.org To unsubscribe send an email to java-devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/java-devel@lists.fedoraproject...

Hi,

On Wed, Jan 30, 2019 at 10:16 PM Hartmut Goebel h.goebel@crazy-compilers.com wrote:

I tried to use the "prefixes" (according the the Xmvn configuration reference [1]) as shown below. But the Xmvn does not even try to access these prefixes. Can somebody explain why, please?

[...]

I learned that I need to define <metadataRepositories>, which worked. But I'm wondering what are the <prefixes> then used for and how to test whether my set-up is correct.

Prefixes and metadataRepositories are used for locating metadata in different formats. The former ones are for the old format (JPackage "depmaps") while the latter are for "new metadata" that is specific to XMvn. Current versions of XMvn don't support depmaps any longer, so prefixes are not used. In configuration file format I kept prefixes for backwards-compatibility, so that trying to parse some old config files wouldn't lead to parse errors. But I think now it's time to remove prefixes altogether.

-- Mikolaj Izdebski