I'm probably dumb (again...) but: my current understanding is that when installing a typical fedora java package it installs /usr/share/maven-metadata/app.xml and other things including a jar file typically like /usr/share/java/app/app.jar.
Now, if I need to make some local development I need to install this app.jar file into my local maven repository using something like
mvn install:install-file -DgroupId=... -DartifactId=... -Dfile=...
All this metadata (groupId, artifactId, etc.) is available in the /usr/share/maven-metadata/app.xml file. So, my question: is there any tool which parses app.xml and installs the jar file to the local maven repository?
Or have I just got it wrong, and there is another much more elegant way to make system jar files available to the local maven?
cheers!
--alec
Hi Alec,
On 04/08/2015 09:22 AM, Alec Leamas wrote:
I'm probably dumb (again...) but: my current understanding is that when installing a typical fedora java package it installs /usr/share/maven-metadata/app.xml and other things including a jar file typically like /usr/share/java/app/app.jar.
Now, if I need to make some local development I need to install this app.jar file into my local maven repository using something like
mvn install:install-file -DgroupId=... -DartifactId=... -Dfile=...
All this metadata (groupId, artifactId, etc.) is available in the /usr/share/maven-metadata/app.xml file. So, my question: is there any tool which parses app.xml and installs the jar file to the local maven repository?
Or have I just got it wrong, and there is another much more elegant way to make system jar files available to the local maven?
You can call "xmvn" instead of "mvn" and it will first try to use system jars. Only artifacts not available on your system will be downloaded from Maven Central. It's important to note that "xmvn" ignores artifact versions. It will first try to find exact version, but if it's not available, it will look for any other version of given artifact.
As you can see, development against system jars can be a bit problematic. That's because "system" jars are not really meant to be used for development (IMO). We usually package jars into RPMs, because some Java application needs them at runtime/compile time.
Michal
cheers!
--alec
java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
On 08/04/15 10:17, Michal Srb wrote:
Hi Alec,
Hi! Thanks for taking time to reply.
On 04/08/2015 09:22 AM, Alec Leamas wrote:
All this metadata (groupId, artifactId, etc.) is available in the /usr/share/maven-metadata/app.xml file. So, my question: is there any tool which parses app.xml and installs the jar file to the local maven repository?
Or have I just got it wrong, and there is another much more elegant way to make system jar files available to the local maven?
You can call "xmvn" instead of "mvn" and it will first try to use system jars.
I take this answer as "No, there is no such tool" (?)
Only artifacts not available on your system will be downloaded from Maven Central. It's important to note that "xmvn" ignores artifact versions. It will first try to find exact version, but if it's not available, it will look for any other version of given artifact.
Which IMHO makes perfect sense when working downstream (i. e., packaging) but isn't really sane while doing upstream developing which requires exact version matching.
As you can see, development against system jars can be a bit problematic. That's because "system" jars are not really meant to be used for development (IMO). We usually package jars into RPMs, because some Java application needs them at runtime/compile time.
Still, I have some jars which are available in fedora packages but not in maven central. Which means that the reasonable way is to install (fedora-wise) the package and then maven-install the packaged jar into the maven repository to make them available as dependencies. Or?
Cheers!
--alec
On 8 April 2015 at 10:04, Alec Leamas leamas.alec@gmail.com wrote:
On 08/04/15 10:17, Michal Srb wrote:
Hi Alec,
Hi! Thanks for taking time to reply.
On 04/08/2015 09:22 AM, Alec Leamas wrote:
All this metadata (groupId, artifactId, etc.) is available in the
/usr/share/maven-metadata/app.xml file. So, my question: is there any tool which parses app.xml and installs the jar file to the local maven repository?
Or have I just got it wrong, and there is another much more elegant way to make system jar files available to the local maven?
You can call "xmvn" instead of "mvn" and it will first try to use system jars.
I take this answer as "No, there is no such tool" (?)
To get this tool, you can:
# yum install xmvn
Only artifacts not available on your system will be downloaded
from Maven Central. It's important to note that "xmvn" ignores artifact versions. It will first try to find exact version, but if it's not available, it will look for any other version of given artifact.
Which IMHO makes perfect sense when working downstream (i. e., packaging) but isn't really sane while doing upstream developing which requires exact version matching.
As you can see, development against system jars can be a bit
problematic. That's because "system" jars are not really meant to be used for development (IMO). We usually package jars into RPMs, because some Java application needs them at runtime/compile time.
Still, I have some jars which are available in fedora packages but not in maven central. Which means that the reasonable way is to install (fedora-wise) the package and then maven-install the packaged jar into the maven repository to make them available as dependencies. Or?
Cheers!
--alec
java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
On 08/04/15 11:08, Mat Booth wrote:
On 8 April 2015 at 10:04, Alec Leamas <leamas.alec@gmail.com mailto:leamas.alec@gmail.com> wrote:
You can call "xmvn" instead of "mvn" and it will first try to use system jars. I take this answer as "No, there is no such tool" (?)To get this tool, you can:
# yum install xmvn
Sure :)
Sorry for not being clear enough. What I mean is "There is no tool which parses the /usr/share/maven-metadata/foo.xml and maven-installs the jar(s) listed therein according to the metadata"
xmvn doesn't really fit the bill for reasons explained in my previous message.
Cheers!
--alec
Only artifacts not available on your system will be downloaded from Maven Central. It's important to note that "xmvn" ignores artifact versions. It will first try to find exact version, but if it's not available, it will look for any other version of given artifact.
Which IMHO makes perfect sense when working downstream (i. e., packaging) but isn't really sane while doing upstream developing which requires exact version matching.
As you can see, development against system jars can be a bit problematic. That's because "system" jars are not really meant to be used for development (IMO). We usually package jars into RPMs, because some Java application needs them at runtime/compile time.
Still, I have some jars which are available in fedora packages but not in maven central. Which means that the reasonable way is to install (fedora-wise) the package and then maven-install the packaged jar into the maven repository to make them available as dependencies. Or?
From what I remember, the resolution order of dependencies by maven is
reactor, workspace (entry point for XMvn), local repository, remote repository. However XMvn is configured by default to resolve the local repo, and then the system one (/usr/share/xmvn/configuration.xml). I wonder if it would be possible for Alec to change this so that XMvn resolves remote maven repos prior to resolving the system repo although I would guess there isn't support for this kind of configuration yet ('resolve-local', 'resolve-system' key words exist but probably nothing for 'resolve-remote').
I guess for now the only other solution would be to manually install the artifacts into your local maven repository.
Cheers,
On 04/08/2015 04:21 PM, Roland Grunberg wrote:
From what I remember, the resolution order of dependencies by maven is reactor, workspace (entry point for XMvn), local repository, remote repository. However XMvn is configured by default to resolve the local repo, and then the system one (/usr/share/xmvn/configuration.xml). I wonder if it would be possible for Alec to change this so that XMvn resolves remote maven repos prior to resolving the system repo although I would guess there isn't support for this kind of configuration yet ('resolve-local', 'resolve-system' key words exist but probably nothing for 'resolve-remote').
I guess for now the only other solution would be to manually install the artifacts into your local maven repository.
Correct. Currently there is no way to try remote repositories before falling back XMvn workspace resolver.
On 04/08/2015 11:04 AM, Alec Leamas wrote:
On 08/04/15 10:17, Michal Srb wrote:
Hi Alec,
Hi! Thanks for taking time to reply.
On 04/08/2015 09:22 AM, Alec Leamas wrote:
All this metadata (groupId, artifactId, etc.) is available in the /usr/share/maven-metadata/app.xml file. So, my question: is there any tool which parses app.xml and installs the jar file to the local maven repository?
Or have I just got it wrong, and there is another much more elegant way to make system jar files available to the local maven?
You can call "xmvn" instead of "mvn" and it will first try to use system jars.
I take this answer as "No, there is no such tool" (?)
I've just wrote a simple POC script which you can use to copy system artifacts to Maven repo. The script is available here: https://gist.github.com/mizdebsk/2e022dd00f21b349ce4a
If you find this script useful I can rewrite it properly and include in javapackages-tools RPM, making it easily available in the system.
There is also climbing-namesis tool, but AFAIR it only creates Ivy repos: https://github.com/willb/climbing-nemesis/
java-devel@lists.fedoraproject.org
-
Alec Leamas -
Mat Booth -
Michal Srb -
Mikolaj Izdebski -
Roland Grunberg