Ha, looking at the source code for polyglot-xml it's using Modello to do something very similar to what I'm proposing- it's tweaking Modello code gen to allow dependencies and plugins to be defined via attributes. It also is generating a new XSD and a new pom.xml41 which uses that XSD. The proposal above could be as simple as porting some of the polyglot-xml changes directly in Maven/Modello itself, albeit without generating a new XSD.
I know there are some issues with polyglot and the way pom.xml files are read off disk. My understanding is that some of that is due to be addressed by Build vs Consumer POM, but not sure about the status beyond [ https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM]. Essentially, my proposal boils down to something very similar to Build/Consumer insofar as the "build" pom.xml would support attributes but all generated pom.xml would remain the same. Thanks for the link. On Fri, Dec 11, 2020 at 2:46 PM Manfred Moser <manf...@simpligility.com> wrote: > > > 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 > >
