J�rg Schaible wrote: ><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> ></dependencies> > > I think we'd be more likely to allow something like: <version>${project.getDependency("mx4j").version}</version>
... though I'm still hesitant to suggest that is a good idea. Again, transitive dependencies means most of these won't be specified anyway, and the above is going to dramatically complicate, if not make impossible future, more advanced, dependency mediation (eg when you specify a range of versions). Not to mention being an eye sore (I'm referring to both examples :) >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. > > We intend to do similar things as the management for the dependencies, however referencing an external database/file of developers, so that you only have to edit it in one place if you change your email address, for example. - Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
