Json has jsonschema and completion support but it does not solve the verbosity issue.
Most plugins solved it by using "g:a:v" syntax for dependencies. We can enhance our parser/xsd to be polymorph IMO hoping IDE support follows, would solve verbosity issue, looks like a quick win to me. Le sam. 12 déc. 2020 à 12:55, John Patrick <nhoj.patr...@gmail.com> a écrit : > I'm with you on that, yes xml is considered old, and legacy, and > verbose. But it's got a decent validation framework, people understand > an xsd and so write a valid xml file based upon the xsd. > > With json i'm unaware of any standard validation framework and schema > definition standard. > > > On Sat, 12 Dec 2020 at 11:46, Michael Osipov <micha...@apache.org> wrote: > > > > Am 2020-12-12 um 11:04 schrieb Markus KARG: > > > Wouldn't it be a more modern and even more effective approach to add > JSON support for POMs? We could keep POM.xml for legacy reasons but add > support for POM.json files. > > > > NOOOOOO, please! JSON is horribly to write by hand and does not have > > comments. It is a decent serialization format, but a horrible one for > > humans. I would rather prefer YAML for this. > > > > > -----Ursprüngliche Nachricht----- > > > Von: Will Iverson [mailto:wiver...@gmail.com] > > > Gesendet: Freitag, 11. Dezember 2020 23:40 > > > An: dev@maven.apache.org > > > Betreff: [DISCUSS] Allow attributes shorthand in pom.xml > > > > > > 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 > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
