Message-ID: <2129125845.26733.1417112881338.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_26732_489370144.1417112881337" ------=_Part_26732_489370144.1417112881337 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 hav= ing 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 beh= ind the scenes. Some of this is as simple as reworking the Modello model to= use attributes, others may require revisions to the underlying Plexus-base= d configuration mechanism. At any rate, I want to open the discussion for a= new syntax here.=20
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 occupi= ed by simple list delimiters, and the 'implementation' attribute used to sp= ecify a String list element (seems reasonable to assume String can be a def= ault list item type)...=20 =20
I think we can make use of two things that will dramatically reduce the= verbosity of the above POM: XML attributes, and good ID validation. The fi= rst will make better use of 'container' elements, and the second has the po= tential to define and enforce a sub-syntax for IDs, like dependency IDs for= example. Consider the following revision of the above POM:=20 =20
Here, IDs are using a terse format that looks like groupId:artifactId:v= ersion, 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 th= at doesn't want to tie the build to a particular plugin version would look = like "org.apache.maven.plugins:maven-surefire-plugin:".=20
Also, XML elements used solely to delimit lists of other elements are e= liminated. We can depend on XSD validation for the positioning and grouping= of list elements. For things like managed dependencies and managed plugins= , these should probably be grouped under a <managedInformation> secti= on or something. But list delimiter elements are useless, since the presenc= e of multiple of the same element implies a list.=20
Finally, the 'implementation' attribute on all configuration list eleme= nts 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. Thi= s removes the need to replicate this attribute again and again, and adds th= e benefit of templatizing the list handling for configurations. In other wo= rds, it has semantics similar to:=20 =20
This is just a first stab at revising the POM syntax...possibly other o= ptions could include a maven-handled namspace convention, where plugin conf= iguration can be directly embedded in the build section to improve coherenc= e.