Atlassian is hiring ... :) On 2/12/08, Jason Dillon <[EMAIL PROTECTED]> wrote: > 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] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
