I like the attribute based POM, but we can reduce more the XML. For example, we'd can group groupId/artifactId/version into one attribute like this:
<dependency artifact="org.apache.maven:maven-project:2.0.8" scope="runtime" classifier="something"/> An other solution would be to group dependencies: <dependencyGroup root="org.apache.maven"> <dependency artifact="maven-project:2.0.8"/> <dependency artifact="continuum:continuum-model:1.1"/> </dependencyGroup> Note that for the continuum-model artifact, I use only "continuum as the groupId and Maven would can merge it with the "root" attribute. Emmanuel > I know that it is not always clear when to use and attribute and when to > use > an element; but typically, attributes are used to attach metadata or > nonessential information about an element, while subelements are essential > parts of the parent element. To me, the groupId, artifactId and version > would be essential parts of a dependency element. > > Shane > > On Feb 10, 2008 10:45 PM, Brett Porter <[EMAIL PROTECTED]> wrote: > >> Hi, >> >> I've always wanted to see an attribute based POM, so based on Nicolas' >> suggestion I killed some time after waking up early this morning to do >> it. >> >> JIRA: http://jira.codehaus.org/browse/MNG-3397 >> >> Here is a build to try: >> http://people.apache.org/~brett/apache-maven-2.0.9-SNAPSHOT-terse-bin.tar.gz >> and svn branch: >> http://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x-terse >> >> Here are two different files for comparison (it halved the size): >> >> http://svn.apache.org/viewvc/maven/archiva/trunk/pom.xml?content-type=text%2Fplain&view=co >> >> http://svn.apache.org/viewvc/maven/archiva/trunk/pom-4.1.0.xml?content-type=text%2Fplain&view=co >> >> What I did is basically convert all the primitive types in the model >> to attributes. I think more could be done (flattening lists, doing the >> same for plugin configuration elements), but this gets a big win at >> least in the dependencies section for minimal work. >> >> It should be completely backwards compatible. It detects v4.0.0 and >> reads it like it used to (then internally converts to the 4.1.0 Java >> model). >> >> Here's some notes on the implementation so far (again, go easy, I just >> whipped this up today and it's not production ready): >> - I see this as a stepping stone to the final solution. I've said this >> before, but I think the POM should separate the build information from >> the project metadata (particularly that stored in the repository). I >> think we need to take baby steps towards that though. >> - this could feasibly be applied to the settings and profile files too. >> - I switched to StAX in the process. This is likely going to introduce >> some small quirks we need to iron out (like the hack I added to parse >> Trygve's name - why did we ever allow that!) I think ideally we'd use >> the Xpp3Reader for 4.0.0 and the StaxReader for 4.1.0 for best >> compatibility. This would also fix the problem in that I've just >> removed the Xpp3Reader and so some plugins may choke. I'm sure the >> release plugin won't be happy, for example. >> - There is probably a slight performance overhead in reading v4 POMs >> since it repopulates the model twice. I haven't measured it but if >> it's an issue we could optimise the reader/converter. It also adds >> about 200k to the maven-model JAR. >> - It is very close to detecting based on namespace so we could enforce >> the use of that instead. >> >> Enjoy! >> >> Cheers, >> Brett >> >> -- >> Brett Porter >> [EMAIL PROTECTED] >> http://blogs.exist.com/bporter/ >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
