On Wed, 30 Jan 2019 at 21:15, Hartmut Goebel <h.goebel(a)crazy-compilers.com>
I'm packaging some Java packages for guix
, a functional package manager (much
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.:
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
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 ) 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.
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:
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
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
currently ships .
| Hartmut Goebel | h.goebel(a)crazy-compilers.com |
| compilers which you thought are impossible |
java-devel mailing list -- java-devel(a)lists.fedoraproject.org
To unsubscribe send an email to java-devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines