Hehe. Nooooooo I was just being sarcastic in my traditional form. I'd like to see some verbosity related changes to simplify the pom's structure eventually... Cause IMO if we can describe the same data with less chars that is going to be easier for folks to consume and manage.... Of course its gotta be consistent, cause inconsistency in format (between attr and elem) is more harmful than bloat from attr-only configuration. But you guys r smart and know that already na?
But when it comes down to it I don't care too much about attr vs elem. What I think is much more useful is to allow dependency (and dependency-like elements) to be grouped, so that similar elements (like groupId and version) can be shared be a number of children. This is IMO a much bigger step towords pom simplification and a debate over attr vs elem. Basically I don't care it its an attr or elem, just let me reuse as mush information as possible. If I end up with a pom containing more than 3 duplicates of the same config... Something is broke and could use some love. Cheers, --jason -----Original Message----- From: Brett Porter <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 16:51:07 To:"Maven Developers List" <dev@maven.apache.org> Subject: Re: An Attribute Based POM Are you saying that if you are looking forward to dealing with more verbosity, you should interview at Atlassian? :) On 12/02/2008, at 4:47 PM, Don Brown wrote: > 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] > -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
