Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
Got a question about poms... Is there any reason why versions of some
artifacts are hardcoded in some of the poms? Specific examples are [1]:
<dependency>
<groupId>org.apache.cocoon</groupId>
<artifactId>cocoon-spring-configurator</artifactId>
<version>1.0.0</version>
</dependency>
And [2]:
<dependency>
<groupId>org.apache.cocoon</groupId>
<artifactId>cocoon-configuration-api</artifactId>
<version>1.0.0</version>
</dependency>
And there is one more. When trying to build Cocoon [3], this causes
'artifact not found' errors. And as soon as I remove these lines,
everything becomes peachy. Any reason to keep these lines? If yes, why
versions are hardcoded only in these three places?
We should depend on released stuff whereever possible.
I don't think it is, in this case. There is a new element -
configurator:bean-map - which is not part of 1.0 - so 1.0.1 snapshot must be used.
As the
configuration stuff is nearly the only stuff which has a final release,
it just there that we use the version. Now, why it fails, I don't know
as these artifacts should be in public repositories.
(see -o flag, forces complete local build)
Vadim
Using the mvn dep mgmt for dependencies that come out of the same
project is imho bad and doesn't work as soon as every module has
separate release cycles. So while it is general useful to have all third
party versions in the root pom, it doesn't work for artifacts of the
same project. So this is the reason why they are hard-coded in some poms.
HTH
Carsten
