Message-ID: <1235445401.4017.1369418906361.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_4016_1492719665.1369418906361" ------=_Part_4016_1492719665.1369418906361 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Recently, I've been noticing that some people (myself included) are ha= ving a hard time with the verbosity of the POM syntax. It seems we could do= a lot more with the use of XML attributes and some decent ID validators be= hind the scenes. Some of this is as simple as reworking the Modello model t= o use attributes, others may require revisions to the underlying Plexus-bas= ed configuration mechanism. At any rate, I want to open the discussion for = a new syntax here.
Below is a sample of what a just-barely-customized POM might look like= . Note that it only has three dependencies. Also note the extra lines occup= ied by simple list delimiters, and the 'implementation' attribute used to s= pecify a String list element (seems reasonable to assume String can be a de= fault list item type)...
I think we can make use of two things that will dramatically reduce th= e verbosity of the above POM: XML attributes, and good ID validation. The f= irst will make better use of 'container' elements, and the second has the p= otential to define and enforce a sub-syntax for IDs, like dependency IDs fo= r example. Consider the following revision of the above POM:
Here, IDs are using a terse format that looks like groupId:artifactId:= version, where missing information would be expressed through blank values.= For example, the project's groupId is inherited from the parent, so its ID= looks like ":my-artifact:1.0-SNAPSHOT". Also, a plugin section t= hat doesn't want to tie the build to a particular plugin version would look= like "org.apache.maven.plugins:maven-surefire-plugin:".
Also, XML elements used solely to delimit lists of other elements are = eliminated. We can depend on XSD validation for the positioning and groupin= g of list elements. For things like managed dependencies and managed plugin= s, these should probably be grouped under a <managedInformation> sect= ion or something. But list delimiter elements are useless, since the presen= ce of multiple of the same element implies a list.
Finally, the 'implementation' attribute on all configuration list elem= ents has been moved to the list delimiter for that configuration - the only= place where I see it making sense to have a list delimiter XML element. Th= is removes the need to replicate this attribute again and again, and adds t= he benefit of templatizing the list handling for configurations. In other w= ords, it has semantics similar to:
This is just a first stab at revising the POM syntax...possibly other = options could include a maven-handled namspace convention, where plugin con= figuration can be directly embedded in the build section to improve coheren= ce.------=_Part_4016_1492719665.1369418906361--