I tried to set (as you suggested in TODO) xml.listStyle="flat"
and according to http://modello.codehaus.org/DataModel, this should support: ... </modules> <dependency groupId="easymock" artifactId="easymock" version="1.2_Java1.3" scope="test"/> <dependencyManagement> ... but modello ignores the flat style and generates the same parser as wrapped : <code> else if ( xmlStreamReader.getLocalName().equals( "dependencies" ) ) ... </code> That beeing said, I'm not sure this is a good idea to declare dependencies anywhere in the POM, and not keep them grouped. A better use (IMHO) of flat list format would be for plugins, executions, goals, dependencies as child of dependencyManagement... Nico. 2008/2/11, Brett Porter <[EMAIL PROTECTED]>: > > 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] > >
