[jboss-dev] Why Maven sucks (part 1)

[Carlo de Wolf]

Paul Gier wrote:
> Carlo de Wolf wrote:
>> Paul Gier wrote:
>>> We can do this using maven also.  If you want to tie the build to a 
>>> specific snapshot, just put the full snapshot version in the 
>>> dependency.  So for example, ejb3-interceptors you could put version 
>>> "0.13.0-20080417.210958-18".  And maven will keep using that snapshot 
>>> build until you change the dependency.  The -SNAPSHOT convention is 
>>> just for convenience if you just want to build with the latest until 
>>> a release comes out.
>>
>> It must be automated. Whenever someone does a mvn deploy, the pom.xml 
>> should be replaced by one not containing any snapshots, but only full 
>> versions.
>>
> 
> Just so it's clear what you are asking for, you want dependencies with 
> (-SNAPSHOT) to be replaced with the specific snapshot version 
> (-timstamp-build) during deployment?  I could probably add this as an 
> option to the deploy plugin, but I don't know if this would solve the 
> problem.
> 
> Just as an example, let's say you deploy an ejb3 module that has a 
> dependency on jboss-aop.  You deploy and it resolves to aop snapshot 
> build 9.  The app server has a dependency on the current aop snapshot 
> (2.0-SNAPSHOT) and they both point to build 9 so all is fine.  Then aop 
> deploys a new snapshot (build number 10). The app server depends on aop 
> (-SNAPSHOT) so it gets the new version.  Now the app server wants build 
> 10, but ejb3 wants snapshot version 9.  The app server IMO should win 
> because the direct dependency should take priority over the transitive 
> ejb dependency.  To solve this issue you would still have to change the 
> app server dependency to tie it to the specific snapshot of aop.

You just said how to really solve the issue. :-)

I'm just saying that Maven should by default give an error because of an 
incompatible version conflict. Normally I would have version ranges in 
the dependencies and then the only match wins, not even best match. If 
something falls out of the version range constraints, then we have an 
unstable build and it should fail with a nice and friendly error message.

Carlo