cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: pom poms
Date Wed, 01 Aug 2007 00:30:09 GMT
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


Mime
View raw message