-
1. Re: Notion of 'compatible-version'?
heiko.braun Mar 13, 2008 4:27 AM (in response to heiko.braun)ALR wrote:
Most I've seen from this is a wishlist/informal roadmap of sorts:
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
Anyone know about the status of this? -
2. Re: Notion of 'compatible-version'?
starksm64 Mar 13, 2008 6:04 AM (in response to heiko.braun)The http://maven.apache.org/release-notes.html show a number of issues related to version ranges as being fixed. The question is, what happens when you use them?
<dependency> <groupid>org.jboss.x</groupid> <artifactid>x-api</artifactid> <!-- Compatible with all 3.3.* versions --> <version>[3.3.0,3.4.0)</version> </dependency>
-
3. Re: Notion of 'compatible-version'?
jason.greene Mar 13, 2008 9:37 AM (in response to heiko.braun)"scott.stark@jboss.org" wrote:
The http://maven.apache.org/release-notes.html show a number of issues related to version ranges as being fixed. The question is, what happens when you use them?
You pray it works. We already know that our version strings are not interpreted correctly. -
4. Re: Notion of 'compatible-version'?
wolfc Mar 13, 2008 11:16 AM (in response to heiko.braun)Until we know how Maven handles ranges during its release cycle we should not be using that.
Suppose the following:
AS 5.0 depends on EJB3 [1.0,2.0)
Current EJB3 release is 1.0.
Now I release EJB3 1.1.
How reproducable is the AS 5.0 build?
It should also be doing a release cycle itself (which can be as simple as a nightly build) to perform an acceptance test on EJB3 1.1. -
5. Re: Notion of 'compatible-version'?
heiko.braun Mar 13, 2008 12:40 PM (in response to heiko.braun)Acceptance test is one thing, but having to release every dependency because of minor version upgrade (which IMO is supposed to be compatible) is not a way to go either.
If you don't favor ranges you could be explicit with compatible versions instead. -
6. Re: Notion of 'compatible-version'?
heiko.braun Mar 13, 2008 12:41 PM (in response to heiko.braun)
We already know that our version strings are not interpreted correctly.
What are the problems you did encounter? -
7. Re: Notion of 'compatible-version'?
starksm64 Mar 13, 2008 1:05 PM (in response to heiko.braun)"wolfc" wrote:
Until we know how Maven handles ranges during its release cycle we should not be using that.
Suppose the following:
AS 5.0 depends on EJB3 [1.0,2.0)
Current EJB3 release is 1.0.
Now I release EJB3 1.1.
How reproducable is the AS 5.0 build?
The mvn release plugin should be recording the versions used, and that version info committed as part of the tag. The release build should effectively be locked to single versions.
How reproducible the trunk/branch build is remains. -
8. Re: Notion of 'compatible-version'?
starksm64 Mar 13, 2008 1:19 PM (in response to heiko.braun)Clearly the version resolution should be pluggable. The current behavior and issue to make this pluggable is:
http://jira.codehaus.org/browse/MNG-612 -
9. Re: Notion of 'compatible-version'?
wolfc Mar 14, 2008 10:18 AM (in response to heiko.braun)"heiko.braun@jboss.com" wrote:
Acceptance test is one thing, but having to release every dependency because of minor version upgrade (which IMO is supposed to be compatible) is not a way to go either.
If you don't favor ranges you could be explicit with compatible versions instead.
Suppose the following:
AS 5.0 depends on EJB3 [1.0,2.0)
EJB3 1.0 depends on MetaData [1.0,2.0)
Current MetaData is 1.0.
Now I release MetaData 1.1 for AS trunk.scott.startk@jboss.org wrote:
The mvn release plugin should be recording the versions used, and that version info committed as part of the tag. The release build should effectively be locked to single versions.
In the repo it should have been noted as:
AS 5.0-1 -> EJB3 1.0-1
EJB3 1.0-1 -> MetaData 1.0-1
To update the repo an EJB3 1.0 release must be done:
EJB3 1.0-2 -> MetaData 1.1-1.
At which point AS 5.0-1 -> EJB3 1.0-1 -> MetaData 1.0-1 is reproducable.
Followed by AS 5.0 release:
AS 5.0-2 -> EJB3 1.0-2.
Ivy works that way and so should Maven.
But I don't see how it works with Maven and transitive dependencies. -
10. Re: Notion of 'compatible-version'?
pgier Mar 14, 2008 10:39 AM (in response to heiko.braun)"wolfc" wrote:
Ivy works that way and so should Maven.
But I don't see how it works with Maven and transitive dependencies.
There is a feature of the release plugin to generate release poms http://maven.apache.org/plugins/maven-release-plugin/examples/generate-release-poms.html
When I tried using it a while back it wasn't working very well, but there have been a few releases since then so maybe it's improved.
This is also something that release engineering is working on. Their approach is to save the whole environment that was used during the build. This includes everything that was downloaded to the local repository, so only these things would be available when reproducing the build. -
11. Re: Notion of 'compatible-version'?
starksm64 Mar 14, 2008 11:02 AM (in response to heiko.braun)Can we get to a version of maven that supports the pluggable version resolution policy and set it to what we want?
-
12. Re: Notion of 'compatible-version'?
pgier Mar 14, 2008 11:17 AM (in response to heiko.braun)The issue that you mentioned earlier (http://jira.codehaus.org/browse/MNG-612) is assigned for 2.1 which is still a long way down the road. Although the comments say it should be 2.0.x. Also, even if it gets resolved, I'm not sure it would help us if we are not using the standard maven version numbers.
It would be nice to have a real "pluggable" version parser and resolution where we could write our own version rules and list it as a build extension in the pom or something like that. I can bring this up on the maven dev list, but my prospects for having time to actually work on this are not too good for the near future.