Simplified developer POMs

[odrotbohm]

One criticism of Maven is the verbosity of the pom.xml which stems from the intensive use of XML elements when attributes might suffice. For example, a current dependency declaration:

<dependency>
  <groupId>some.group.id</groupId>
  <artifactId>some-artifact-id</artifactId>
  <version>1.2.3</version>
  <!-- further elements -->
</dependency>

could be written as:

<dependency groupId="some.group.id" artifactId="some-artifact-id" version="1.2.3" … />

each existing nested textual element flattened into an XML attribute. Or even as a

<dependency coordinate="some.group.id:some-artifact-id:1.2.3" />

that's parsed into the individual model elements of a dependency. This approach could be applied to other elements that solely take text elements as child ones.

AFAIR, there were discussions about this in the context of the polyglot Maven efforts and backwards compatibility was to be achieved by transforming the developer POM into the original format on install and deploy. IIRC such improvements where already discussed on the mailing list under the "consumer poms" tagline.

[ascheman]

Besides the usual GAV coordinates, components may have more attributes like classifier, scope etc. which needs to be covered accordingly.

[khmarbaise]

Could be done like this: <dependency coordinate="some.group.id:some-artifact-id:1.2.3" classifier="xx" scope="" type="xx" />

[odrotbohm]

I didn't want to focus on the specifics of what could be achieved with the dependency elements in particular. I think an element-to-attribute conversion would already reduce the size of the XML documents significantly if applied to dependencies, plugins and repositories.

[rmannibucau]

out of curiosity: why not using polyglot-xml?

So questions for me are:

• what is the atomic core maven model (for now tags=pojo model which is quite good cause easy for anyone)
• how many core model do we want to own and maintain (I'd say 1 to keep the integration with 3rd parties easy)
• Is using attributes (per tag) more readable? (we all think to make it inline but an autoformatter will have to make it per line to have it consistent in the while file so we gain a few chars but not lines which is the biggest issue until you merge attributes in a single string - like pax-url for ex)

[ascheman]

We should also consider tools like jQAssistant which could use a more or less canonical XML parser (except for property expansion). Enabling other formats to specify deps is nice (in particular if they make it better readable for humans), but as a tool maintainer I would not like to support (to) many formats.

In particular I would not like to compute the effective model first before reason about it (like it's necessary with Gradle, though they seem to have a nice Java API for that). Perhaps we would otherwise end up with something like language-server-protocol (LSP) to support arbitrary tools.