IMO we should strive to make the pom even more verbose... So all us maven folk can keep our jobbies :-P
--jason -----Original Message----- From: Brett Porter <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 16:35:35 To:"Maven Developers List" <dev@maven.apache.org> Subject: Re: An Attribute Based POM Yes, I happen to agree with the theory Shane and Jason outlined and is why I accepted the status quo for 5 years :) But I always thought the Maven dependencies tag in Ant looked better and was easier to read. I think the expanded format makes more sense for machine-generated and - read documents. Perhaps XML isn't the right choice in the first place - but it is well tooled and familiar to Java weenies. Maybe one day IDE support will be ubiquitously used and it won't matter, but for now a lot of people look at POMs and edit them in vim and would like them to be simpler. The more important thing is remaining consistent throughout the change IMO. - Brett On 12/02/2008, at 4:22 PM, Don Brown wrote: > Whether an attribute-based design is "proper" is a less important > question than what makes Maven more usable. Form should follow > function. What users care about is more readable POMs, less typing, > and less clutter. I've been really impressed with the Maven team > adopting a more programmatic approach to Maven recently, and this > change will go a long way to making Maven more usable and less > curse-worthy. > > Don > > On 2/12/08, Shane Isbell <[EMAIL PROTECTED]> wrote: >> 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] > -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
