Jason van Zyl wrote: > On Thu, 2004-04-15 at 14:38, Mark Langley wrote: >> If you use XML entities to define your version numbers rather than hard >> coding them in the project.xml files, the process of switching between >> snapshot and release versions becomes much easier. >> >> See http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities >> for more details. > > Do a lot of people actually use this mechanism? > > Is it simply because maven1 doesn't support recursive inheritance? > > Maven2 support recursive inheritance well so would anyone still really > need to use entities like this. Ultimately I suppose it doesn't matter > how the POM comes together but I would like support to come from Maven > itself and not the use of entities which I would consider a workaround.
Yes and no, but entities have their pros and cons. Inheritance is not anything and it depends on the element. E.g. in a multiproject you might have specific developers for the subprojects, but you would like to have them collected in the main project. Also I would not like to inherit always all dependencies from a dependent project, because some dependencies there might only be used to build the package or some are only used for test. E.g. commons-configuration has a dependency for dom4j although I can use the package (well, parts) without. Additionally I would not like to have the test dependencies of it inherited (simple-jndi, hsqldb, commons-db, dbunit, ...). While this component is normally an "external" artifact, I have similar situations in my projects. Using entities you can also create a company-wide repository. The "locator" might point to a webserver. Unfortunately such a "entity repository" makes your POMs quite unmoveable ... Regards, Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
