I would have thought that maven would complain when provided versions were not compatible with requested versions.
I'm working on maven-ant-tasks which lists:
<dependency> <groupId>org.apache.ant</groupId> <artifactId>ant</artifactId> <version>1.8.0</version> </dependency>
But the build didn't complain at all with ant 1.7.1 installed, until the compile failed because an ant 1.8 feature was used.
I would have thought that maven would complain when provided versions were not compatible with requested versions.
I'm pretty sure Deepak told me that our maven patches to do the mvn-jpp, look in /usr/share/java, etc. make it ignore versions (if you're using mvn-jpp and not just regular mvn).
Andrew
On 08/13/2010 05:50 AM, Andrew Overholt wrote:
I would have thought that maven would complain when provided versions were not compatible with requested versions.
I'm pretty sure Deepak told me that our maven patches to do the mvn-jpp, look in /usr/share/java, etc. make it ignore versions (if you're using mvn-jpp and not just regular mvn).
Andrew
Intentional? Unavoidable? Bug?
* Orion Poplawski orion@cora.nwra.com [2010-08-13 16:49]:
On 08/13/2010 05:50 AM, Andrew Overholt wrote:
I would have thought that maven would complain when provided versions were not compatible with requested versions.
I'm pretty sure Deepak told me that our maven patches to do the mvn-jpp, look in /usr/share/java, etc. make it ignore versions (if you're using mvn-jpp and not just regular mvn).
Andrew
Intentional? Unavoidable? Bug?
Intentional AFAIK. Deepak will be able to speak more authoritatively later in the week when he's around.
Andrew
Excerpts from Andrew Overholt's message of Mon Aug 16 15:33:26 +0200 2010:
- Orion Poplawski orion@cora.nwra.com [2010-08-13 16:49]:
On 08/13/2010 05:50 AM, Andrew Overholt wrote:
I would have thought that maven would complain when provided versions were not compatible with requested versions.
I'm pretty sure Deepak told me that our maven patches to do the mvn-jpp, look in /usr/share/java, etc. make it ignore versions (if you're using mvn-jpp and not just regular mvn).
Andrew
Intentional? Unavoidable? Bug?
Intentional AFAIK. Deepak will be able to speak more authoritatively later in the week when he's around.
I am no Deepak but in the meantime maybe I can shed some light on this (or at least write what I got to know about maven over the course of last few months).
This is indeed intentional and reason is simple. Normally we have only one version of each package installed. So there will probably never be ant-1.7 and ant-1.8 installed simultaneously unless we decide it's necessary to create package ant18 (or something similar).
Therefore version checks are ignored when resolving maven dependencies in jpp mode. Otherwise we would get tons of dependency issues when compiling packages with maven. Most of the time this doesn't cause compilation/runtime problems and if it does we update/backport dependencies so that all Fedora packages are able to use same versions of dependencies. This can sometimes be time-consuming (we have to update packages to use new dependencies) but then we usually offer these updates upstream and we don't have to do it again.
Deepak can probably get more technical or correct my assumtions, but this is my understanding of this situation so far.
* Stanislav Ochotnicky sochotnicky@redhat.com [2010-08-23 07:58]:
Excerpts from Andrew Overholt's message of Mon Aug 16 15:33:26 +0200 2010:
- Orion Poplawski orion@cora.nwra.com [2010-08-13 16:49]:
On 08/13/2010 05:50 AM, Andrew Overholt wrote:
I would have thought that maven would complain when provided versions were not compatible with requested versions.
I'm pretty sure Deepak told me that our maven patches to do the mvn-jpp, look in /usr/share/java, etc. make it ignore versions (if you're using mvn-jpp and not just regular mvn).
Andrew
Intentional? Unavoidable? Bug?
Intentional AFAIK. Deepak will be able to speak more authoritatively later in the week when he's around.
I am no Deepak but in the meantime maybe I can shed some light on this (or at least write what I got to know about maven over the course of last few months).
This is indeed intentional and reason is simple. Normally we have only one version of each package installed. So there will probably never be ant-1.7 and ant-1.8 installed simultaneously unless we decide it's necessary to create package ant18 (or something similar).
Therefore version checks are ignored when resolving maven dependencies in jpp mode. Otherwise we would get tons of dependency issues when compiling packages with maven. Most of the time this doesn't cause compilation/runtime problems and if it does we update/backport dependencies so that all Fedora packages are able to use same versions of dependencies. This can sometimes be time-consuming (we have to update packages to use new dependencies) but then we usually offer these updates upstream and we don't have to do it again.
Deepak can probably get more technical or correct my assumtions, but this is my understanding of this situation so far.
Oops, didn't see this message when I replied to parent.
Yes, you're absolutely correct. There is no technical limitation that required us to ignore versions. It was done on purpose for the reasons above.
Cheers, Deepak
-- Stanislav Ochotnicky sochotnicky@redhat.com Associate Software Engineer - Base Operating Systems Brno
PGP: 71A1677C Red Hat Inc. http://cz.redhat.com
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
* Orion Poplawski orion@cora.nwra.com [2010-08-13 16:49]:
On 08/13/2010 05:50 AM, Andrew Overholt wrote:
I would have thought that maven would complain when provided versions were not compatible with requested versions.
I'm pretty sure Deepak told me that our maven patches to do the mvn-jpp, look in /usr/share/java, etc. make it ignore versions (if you're using mvn-jpp and not just regular mvn).
Andrew
Intentional? Unavoidable? Bug?
Hi,
It was intentional. In Fedora, there is only one version of any given library. Making maven require specific versions would have caused a lot more problems as packagers would have to go around manually patching the pom files.
Cheers, Deepak
-- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
java-devel@lists.fedoraproject.org
-
Andrew Overholt -
Deepak Bhole -
Orion Poplawski -
Stanislav Ochotnicky