Hi Brett,
Brett Porter wrote on Tuesday, April 12, 2005 11:20 PM:
> J�rg Schaible wrote:
>
>> if I interpret these correct, you'll define for a company wide POM
>> with the dependencyManagement tag any used dependency in all
>> project? Due to multiple inheritance a parent POM of a
>> multiproject can override the versions of specific dependencies?
>
> I wouldn't call it multiple inheritence, because you can only
> inherit one at a time
You're right. Maybe we should have another term for this like "cascaded
inheritance" :)
>, but yes, this would work. And
> individual projects could override that.
Great.
>>> In addition, transitive dependencies will greatly reduce the number
>>> of these you need to define...
>>
>> This arises new questions. How do we handle "virtual" artifacts i.e.
>> classes that could be provided by different artifacts?
>>
> This has been referred to as a specification dependency in
> the past (typically the XML parser is used as an example, as
> you've said). I wouldn't imagine doing this until Maven 2.1.
>
>> BTW: It would be nice to define artifact groups, e.g.:
>>
>>
> I'm not really in favour of anything that lets you specify
> dependencies you don't really need easily. Bear in mind that
> you probably don't need most of these due to transitive dependencies.
No, you got that wrong. The group element is just used to define shared
elements. Maybe the term "group" and the notation is misleading. Look at the
following snipped, that makes the intension hopefully more clear:
<dependencies>
<definition id="mx4j">
<groupId>mx4j</groupId>
<version>2.1.1</version>
<url>http://mx4j.sf.net</url>
</definition>
<dependency>
<artifactId>mx4j-jmx</artifactId>
<ref id="mx4j" />
</dependency>
<dependency>
<artifactId>mx4j-impl</artifactId>
<ref id="mx4j" />
</dependency>
<dependency>
<artifactId>mx4j-remote-jmx</artifactId>
<ref id="mx4j" />
</dependency>
<dependency>
<artifactId>mx4j-remote-impl</artifactId>
<ref id="mx4j" />
</dependency>
</dependencies>
Purpose it to have one place to set common elements (and especially the
version). Look at your own sample for the Geronimo stuff. This mechanism could
be used in more situation. E.g. the developers of a company share normally a
lot elements of the developer elements.
- J�rg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
