You can use polyglot-maven for a compatible approach for your own pom files
right now..
https://github.com/takari/polyglot-maven/tree/master/polyglot-xml
Manfred
Will Iverson wrote on 2020-12-11 14:40 (GMT -08:00):
> One of the biggest complaints about Maven has long been the verbosity of
> the XML format. The verbosity is due in large part to the exclusive
> reliance on XML elements in Maven.
>
> Proposal: Allow Maven pom.xml to treat attributes as a short-hand for
> declaring configuration elements.
>
> Example: One of the most verbose sections of the pom for most projects is
> dependencies. A typical example:
>
> <dependency>
> <groupId>commons-io</groupId>
> <artifactId>commons-io</artifactId>
> <version>2.8.0</version>
> </dependency>
>
> Here is the same declaration expressed with attribute shortcuts:
>
> <dependency groupId="commons-io" artifactId="commons-io" version="2.8.0" />
> That's an 80% reduction in LoC, and would make Maven comparable with other
> popular build tools (e.g. compare and contrast with other build tools at
> https://mvnrepository.com/artifact/commons-io/commons-io/2.8.0)
>
> REQUEST: Feedback on if this is something to pursue. I've done some
> research, happy to submit patches, but don't want to pursue if there is
> either a) technical reason[s] not to proceed I'm not aware of or b) a lack
> of enthusiasm for the entire idea from the community.
>
> Basically, I'm looking for some feedback along the lines of a) love it -
> please submit patches so we can check it out, b) huh, maybe, willing to
> look at it, or c) this is a terrible idea, because X. Effectively, a
> totally non-binding vote on if this is worth exploring.
>
> I've discussed this with others online and done some research, so are a few
> answers to objections/Qs as I currently understand. I may be
> wrong/uninformed about certain aspects, which would be very helpful
> feedback.
>
> Q: Won't this require a new Maven XSD to be generated?
> A: No. The current Maven XSD declares many elements, but is not actually
> involved in validation. While the current XSD is valuable for tools and
> documentation, it does not actually perform validation.
>
> Q: Wait, so what actually does the validation?
> A: It's all done in Java code generated by Modello. The maven-model project
> (https://github.com/apache/maven/tree/maven-3.6.3/maven-model) relies on
> the Modello Maven Plugin (
> http://codehaus-plexus.github.io/modello/modello-maven-plugin/) which in
> turn relies on Modello core (http://codehaus-plexus.github.io/modello/) to
> generate the Java code that processes the pom.xml
>
> The proposal is to submit a patch for Modello that would allow the
> generated source to accept an attribute as an alias for input. If it's a
> valid element per the Maven maven.mdo file (
> https://github.com/apache/maven/blob/maven-3.6.3/maven-model/src/main/mdo/maven.mdo)
> it will now accept an attribute as a shortcut.
>
> Q: Wouldn't this break, like, everything?
> A: It would only affect pom.xml files that are read at runtime. All emitted
> pom.xml files would remain exactly the same.
>
> Q: Does this involve changing or rewriting the user's pom.xml? Isn't that
> the thing that's making it hard to support alternative formats for pom.xml
> like polyglot poms, etc?
> A: Nope, the pom.xml on disk is still the pom.xml. A
> <prerequisites><maven>X.X.X<maven></prerequisites> would be the only flag
> recommended to declare that a pom.xml uses attributes for shorthand.
>
> Q: How much work is this to actually implement?
> A: It starts with a few lines added to the Modello code generation to allow
> for attribute aliasing with a feature flag. Testing those changes through
> the rest of the dependency chain. Adding test cases throughout.
> Documentation. although as "now you can use attributes" is conceptually
> simple it's not too bad. Tools in the Maven ecosystem would be able to
> indicate they have been updated to support this by referring to the simple
> term, "attribute shortcuts". Because nothing else changes, the only real
> documentation change would be "things that were elements can also be
> declared as attributes." The trickiest part is probably sorting out how to
> manage the feature flag across the various components. I'm sure there's
> more with a huge ecosystem like this, but the actual changes to the Modello
> code gen appear to be surprisingly minor.
>
> Q: What about tooling, like IDEs, publishing to Maven Central & Maven
> repositories, etc?
> A: Many IDEs appear to have implemented validation logic on top of Maven
> that currently will flag attributes as errors in a pom.xml. Those IDEs and
> other tools would require updates to this validation logic. Because the
> rendered pom.xml output remains the same publishing tool chains and Maven
> repositories should be completely unaffected.
>
> Q: Any big issues you've identified?
> A: Many sub-elements are not actually processed by Modello or Maven Model,
> but are instead passed along to the plugin. For example, <configuration>
> elements. It would be up to each of these projects to eventually allow for
> attribute aliasing (or not). Maven projects that rely on Modello would have
> the choice to adopt the new version and turn on the feature flag (or not).
> It's possible that this would be confusing for some users - i.e. "why can I
> declare dependencies with attributes but not configuration values"? That
> said, I think it's manageable and would allow the ecosystem to slowly
> update.
> Q: Shouldn't we wait for Maven 5 to tackle this?
> A: There's an issue going back to 2008 about the verbosity of pom.xml -
> https://issues.apache.org/jira/browse/MNG-3397 - so... that's 12 years.
> While writing this email, I just realized I commented on that issue back in
> 2014. Any proposal to dramatically change the pom is going to be a *huge*
> effort and is not at all what I'm proposing. This is literally the simplest
> possible change I can think of that accomplishes the goal (dramatically
> reducing the verbosity of the pom.xml) with the least possible impact to
> the ecosystem. It's been twelve years. Maven 5 is years away.
>
> I know there is a voting system for changes to Maven, and this would be a
> huge userland change. If there is even a soft exploratory "yes" I'm happy
> to submit patches. Even better would be the assistance of an existing Maven
> committer willing to help me navigate Apache requirements. If the feedback
> is generally negative, that's fine too - I'll just go ahead and close the
> issue. What I don't want to do is submit patches and then have everyone
> yell at me. The Internet can be rough, you know. :)
>
> I know this is a long email - thanks for reading, and looking forward to
> feedback.
>
> Thanks,
> -Will
>
> P.S. I've been tracking my research on this approach with this issue
> https://issues.apache.org/jira/browse/MNG-7044, in case you are curious
> about the research/additional links.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
