Heh, you would read it that way...well, I guess we do have a few crazy POMs with pages and pages of Ant tags. If you love swimming in XML, we have a small ocean over here :)
Don On 2/12/08, Brett Porter <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
