Re: AW: [DISCUSS] Allow attributes shorthand in pom.xml
On 12.12.20 21:04, Will Iverson wrote: RE: "It would be massively incompatible with the existing toolchain; not just Maven but Gradle,SBT, static analysis tools, bazel, and everything else that sits on top of the Maven repository system. The cost of introducing this now vastly outweighs any conceivable benefit." As described above, the intent for this would be that the pom.xml published to the repository system would be entirely element-based (as today), so nothing downstream from the user's project would be affected. Absolutely agree that the Maven repository system is highest priority. A change in repository format has already being done in the past (long ago) Maven 1 -> Maven 2 (Horror!) I just did some more testing, and it appears that the pom.xml in the user's project is the same as the pom that gets published (e.g. included in the jar generated by package), which would absolutely lead to breakage. That level of breakage is contrary to the whole point of this proposal (allow a user local pom.xml to use attributes, but keep the pom.xml published to repositories the same as today with elements). I thought that the published pom.xml included in the release was generated/modified, but that's apparently not true It also the point that the pom as for example published in central are signed with gpg key ... and this is done on a file base...which is located in your local git repository (or be more accurate in your local directory). (and clarifies the purpose of the Build vs Consumer POM proposal ( https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM). In the past I could have sworn the final pom published was not the same as the pom.xml in the user directory, but that appears to not be the case (at least for an ordinary project). There are further problems with that related because, ci friendly showed some parts, which where possible and which are not. The pom file which is published must be signed not the file within the local directory ... that's currently a hard thing to solve for those who are working on that part (maven-gpg-plugin is completely file based). It needs to be created a stream based variant to handle that correctly. It's possible that some tooling I was using (e.g. my CI tool) was tweaking the pom during publishing, which is where I got the idea that happened by default. Whatever tool it would be that would have broken the integrity of the pom file (which was signed for releases maybe not within coroporate environments?)... But I've never seen such things... To restate more simply: The pom.xml in the user's directory is the *same* as the pom.xml that is bundled into the JAR produced by package. So, *no* changes can be made to the userland pom.xml without also breaking downstream publishing. Exactly. Or to be very accurate... The pom file in the jar itself is not the problem the one which is delivered to somewhere else... That's a killer for the proposal, at least if/until Build vs Consumer comes along. In the meantime, the only thing I can think of is for Maven core to add a bit more native support for polyglot to make it easier to work with, but that's an entirely different thing. That's what is currently worked on to separate the build pom locally (in the project which contains information on how it's build) and the distributed pom which is only needed for consumption from each other. That is currently undergoing work on current master for Maven 4.0.0+ If that is working over the time the build pom can be changed...but that would result in changes in tooling like IDE's/Code analyzers etc but that's a different story. But most important here is to open the door for such options... Thanks for the feedback - I'll include this information in the bug tracker for the issue for future reference and it can be closed. One kind of weird point of clarification: The XSD declares a ton of optional values and also includes documentation, but doesn't appear to actually enforce validation (that's done by Modello generated Java code). This appears to be a very common misconception about the Maven XSD - that it's involved in the validation process. I was certainly a bit surprised to see everything marked as optional in the XSD when I downloaded it and reviewed it. The real issue with XSD validation is that it can't be done where a plugin come into the game so the part where a plugin defines a configuration like this: ... ... The issue here is the "..." which is dynamically integrated into the pom or used to inject information into the plugin during run time violates that... cause Maven allows to define any kind of plugins and only the author of a plugin defines which kind of entries are in the configuration block... so you can't check the whole XML via XSD ... but Maven itself checks very carefully the whole pom... Cheers, -Will On Sat, Dec 12, 2020 at 11:02 AM Hunter C Payne wrote: So there have been a few comments so far
Re: AW: [DISCUSS] Allow attributes shorthand in pom.xml
RE: "It would be massively incompatible with the existing toolchain; not just Maven but Gradle,SBT, static analysis tools, bazel, and everything else that sits on top of the Maven repository system. The cost of introducing this now vastly outweighs any conceivable benefit." As described above, the intent for this would be that the pom.xml published to the repository system would be entirely element-based (as today), so nothing downstream from the user's project would be affected. Absolutely agree that the Maven repository system is highest priority. I just did some more testing, and it appears that the pom.xml in the user's project is the same as the pom that gets published (e.g. included in the jar generated by package), which would absolutely lead to breakage. That level of breakage is contrary to the whole point of this proposal (allow a user local pom.xml to use attributes, but keep the pom.xml published to repositories the same as today with elements). I thought that the published pom.xml included in the release was generated/modified, but that's apparently not true (and clarifies the purpose of the Build vs Consumer POM proposal ( https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM). In the past I could have sworn the final pom published was not the same as the pom.xml in the user directory, but that appears to not be the case (at least for an ordinary project). It's possible that some tooling I was using (e.g. my CI tool) was tweaking the pom during publishing, which is where I got the idea that happened by default. To restate more simply: The pom.xml in the user's directory is the *same* as the pom.xml that is bundled into the JAR produced by package. So, *no* changes can be made to the userland pom.xml without also breaking downstream publishing. That's a killer for the proposal, at least if/until Build vs Consumer comes along. In the meantime, the only thing I can think of is for Maven core to add a bit more native support for polyglot to make it easier to work with, but that's an entirely different thing. Thanks for the feedback - I'll include this information in the bug tracker for the issue for future reference and it can be closed. One kind of weird point of clarification: The XSD declares a ton of optional values and also includes documentation, but doesn't appear to actually enforce validation (that's done by Modello generated Java code). This appears to be a very common misconception about the Maven XSD - that it's involved in the validation process. I was certainly a bit surprised to see everything marked as optional in the XSD when I downloaded it and reviewed it. Cheers, -Will On Sat, Dec 12, 2020 at 11:02 AM Hunter C Payne wrote: > So there have been a few comments so far (yea) so I'm going to try to > address them here: > 1) choice of formatAny format that specifies a POM should have validation > (which JSON, HOCON and XML do). YAML should be a non-starter as it has no > validation (or types and it depends on invisible characters for > formatting). But Unbound only translates between formats and so you can > still write your 1000s of lines of XML if you want but it allows the rest > of us to have 10 line POM files. > But I've noticed that none of you have mentioned HOCON (which has > comments) so far which leads me to think that none of you know this format > or understand what it enables. Its an extension of JSON so it picks up all > the validation functionality. But it also has an include primitive which > allows abstracting of POMs in a really useful way. I can write a block of > HOCON and host it on a server somewhere in my infrastructure and then every > project in the org can add an include line to use that block of POM. > That's so much nicer than the way we abstract POMs currently. > Multi-project POMs are often a nightmare to do mainly because the > inheritance of POMs is so complex. > HOCON spec: https://github.com/lightbend/config/blob/master/HOCON.md > > 2) why we are doing thisIf you don't have problems getting teammates to > use Maven, then you are the lucky 1%. The rest of us have to work with > folks under the age of 35 and its pretty impossible to get them to use or > learn Maven due to XML. Also, my HOCON POMs are a small fraction as long > as the XML ones but with the same functionality. > > I'm just not understanding the resistance here. I feel like those that > are resisting don't really understand the current developer community. SBT > is a slow and very poor build tool but people use it because they dislike > XML that much more. Not sure why folks on this list don't understand > that. XML is pretty universally hated at this point. Perhaps best to just > accept that instead of talking about features (XSD) that almost nobody ever > used. > > 3) ease of integrationI'm only asking to have Unbound included, not to > change the POM format, or require significant changes in Maven itself. I'm > not sure why you would want
Re: AW: [DISCUSS] Allow attributes shorthand in pom.xml
So there have been a few comments so far (yea) so I'm going to try to address
them here:
1) choice of formatAny format that specifies a POM should have validation
(which JSON, HOCON and XML do). YAML should be a non-starter as it has no
validation (or types and it depends on invisible characters for formatting).
But Unbound only translates between formats and so you can still write your
1000s of lines of XML if you want but it allows the rest of us to have 10 line
POM files.
But I've noticed that none of you have mentioned HOCON (which has comments) so
far which leads me to think that none of you know this format or understand
what it enables. Its an extension of JSON so it picks up all the validation
functionality. But it also has an include primitive which allows abstracting
of POMs in a really useful way. I can write a block of HOCON and host it on a
server somewhere in my infrastructure and then every project in the org can add
an include line to use that block of POM. That's so much nicer than the way we
abstract POMs currently. Multi-project POMs are often a nightmare to do mainly
because the inheritance of POMs is so complex.
HOCON spec: https://github.com/lightbend/config/blob/master/HOCON.md
2) why we are doing thisIf you don't have problems getting teammates to use
Maven, then you are the lucky 1%. The rest of us have to work with folks under
the age of 35 and its pretty impossible to get them to use or learn Maven due
to XML. Also, my HOCON POMs are a small fraction as long as the XML ones but
with the same functionality.
I'm just not understanding the resistance here. I feel like those that are
resisting don't really understand the current developer community. SBT is a
slow and very poor build tool but people use it because they dislike XML that
much more. Not sure why folks on this list don't understand that. XML is
pretty universally hated at this point. Perhaps best to just accept that
instead of talking about features (XSD) that almost nobody ever used.
3) ease of integrationI'm only asking to have Unbound included, not to change
the POM format, or require significant changes in Maven itself. I'm not sure
why you would want this as the tooling should still use XML for reasons of
legacy and practicality. But forcing devs to write POMs in XML by hand is
currently required and pretty undesirable.
4) what is wrong with XMLFor one the way lists and maps are represented are
very verbose and unwieldy. But the bigger thing for me is how inheritance is
done in Maven. Mutli-module projects are way too hard to make work. A simpler
block level inheritance that HOCON enables is far more preferable. Consider
this example:
https://github.com/hunterpayne/maven-unbound/blob/master/examples/rpm.conf
This block of code can be included by adding this to your HOCON POM:
include file("examples/rpm.conf")
And now my pom can build RPMs in a single line. Pretty nifty and so much
better than repeating 80 or so lines of XML.
Hunter
On Saturday, December 12, 2020, 8:20:08 AM PST, Gary Gregory
wrote:
On Sat, Dec 12, 2020 at 6:53 AM Robert Scholte wrote:
> Here's my unpopular response: I'm not going to invest in attribute support
> for Maven.
> If the verbosity of the pom.xml is the first thing people complain about,
> well, then Maven is doing a pretty good job (if the build itself had
> issues, one would complain about that first, right?).
> By having elements only it is much easier to maintain Maven.
> It'll remove discussion as to: what would be an attribute and what should
> be an element? Can it be based on required versus optional? Allowing both
> for the same "fields" is probably a recipe for disaster.
>
That's simple IMO and what we usually do at my day job: XML elements and
attributes are like Types (Classes) and its attributes (instance
variables). It does not need to be more complicated than that. FWIW, I'm
baffled at the suggestion that optional vs. required has anything to do
with this.
Gary
I'll leave it up to tools like polyglot to do some the transformation from
> your favorite language to the XML as expected by Maven.
> This is a clear separation, and it will give the Maven team the
> opportunity to focus on the real issues.
>
> So please join your forces and spend your energy on improving polyglot!
>
> thanks,
> Robert
> On 12-12-2020 11:04:33, Markus KARG wrote:
> 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.
> -Markus
>
> -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
Re: AW: [DISCUSS] Allow attributes shorthand in pom.xml
On Sat, Dec 12, 2020 at 6:53 AM Robert Scholte wrote: > Here's my unpopular response: I'm not going to invest in attribute support > for Maven. > If the verbosity of the pom.xml is the first thing people complain about, > well, then Maven is doing a pretty good job (if the build itself had > issues, one would complain about that first, right?). > By having elements only it is much easier to maintain Maven. > It'll remove discussion as to: what would be an attribute and what should > be an element? Can it be based on required versus optional? Allowing both > for the same "fields" is probably a recipe for disaster. > That's simple IMO and what we usually do at my day job: XML elements and attributes are like Types (Classes) and its attributes (instance variables). It does not need to be more complicated than that. FWIW, I'm baffled at the suggestion that optional vs. required has anything to do with this. Gary I'll leave it up to tools like polyglot to do some the transformation from > your favorite language to the XML as expected by Maven. > This is a clear separation, and it will give the Maven team the > opportunity to focus on the real issues. > > So please join your forces and spend your energy on improving polyglot! > > thanks, > Robert > On 12-12-2020 11:04:33, Markus KARG wrote: > 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. > -Markus > > -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: > > > commons-io > commons-io > 2.8.0 > > > Here is the same declaration expressed with attribute shortcuts: > > > 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 > X.X.X 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
AW: [DISCUSS] Allow attributes shorthand in pom.xml
Okay, seems you got me wrong. The idea is not to force YOU to write JSON, but to allows OTHERS to do that. There are people that like JSON and YAML over XML, so we if would have a separating layer between the information needed by Maven itself, and the data format providing that information, we would have the freedom for people to add ANY config format they like. I cannot see any good reason against THAT. Stay with XML as long as YOU want, but let OTHERS use OTHER formats. -Markus -Ursprüngliche Nachricht- Von: Michael Osipov [mailto:micha...@apache.org] Gesendet: Samstag, 12. Dezember 2020 12:46 An: dev@maven.apache.org Betreff: Re: [DISCUSS] Allow attributes shorthand in pom.xml 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. NOO, 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: > > > commons-io > commons-io > 2.8.0 > > > Here is the same declaration expressed with attribute shortcuts: > > > 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 > X.X.X 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 >
AW: AW: [DISCUSS] Allow attributes shorthand in pom.xml
Well, don't get me wrong, I think the original question was not whether YOU invest time in that, but more whether it makes sense that OTHERS invest in that. In the end, this is a democratic and open project. Not every idea asked is intended as your personal task. ;-) -Markus -Ursprüngliche Nachricht- Von: Robert Scholte [mailto:rfscho...@apache.org] Gesendet: Samstag, 12. Dezember 2020 12:53 An: dev@maven.apache.org Betreff: Re: AW: [DISCUSS] Allow attributes shorthand in pom.xml Here's my unpopular response: I'm not going to invest in attribute support for Maven. If the verbosity of the pom.xml is the first thing people complain about, well, then Maven is doing a pretty good job (if the build itself had issues, one would complain about that first, right?). By having elements only it is much easier to maintain Maven. It'll remove discussion as to: what would be an attribute and what should be an element? Can it be based on required versus optional? Allowing both for the same "fields" is probably a recipe for disaster. I'll leave it up to tools like polyglot to do some the transformation from your favorite language to the XML as expected by Maven. This is a clear separation, and it will give the Maven team the opportunity to focus on the real issues. So please join your forces and spend your energy on improving polyglot! thanks, Robert On 12-12-2020 11:04:33, Markus KARG wrote: 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. -Markus -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: commons-io commons-io 2.8.0 Here is the same declaration expressed with attribute shortcuts: 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 X.X.X 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 cha
Re: AW: [DISCUSS] Allow attributes shorthand in pom.xml
Just a side note: it is about maven 4 where deployed poms will not be dev pom so tooling, static analyzis tools etc will follow since we will anyway - otherwise mvn 4 and all xsd discussions are pointless. Verbosity is a common feedback - with easiness to do in project custom lifecycle so IMHO we must tackle that in mvn 4 or stay on mvn 3. Le sam. 12 déc. 2020 à 14:03, Tamás Cservenák a écrit : > Agree with Robert here: this issue is really about "hard to author/write > POMs as they are chatty". > > Then use polyglot, and let's Maven itself (or Maven + polyglot) sort out > things, but modding POM modello is something not we'd like to do... (as > many others noted, existing tooling etc). > > My 5 cents. > > T > > On Sat, Dec 12, 2020 at 12:53 PM Robert Scholte > wrote: > > > Here's my unpopular response: I'm not going to invest in attribute > support > > for Maven. > > If the verbosity of the pom.xml is the first thing people complain about, > > well, then Maven is doing a pretty good job (if the build itself had > > issues, one would complain about that first, right?). > > By having elements only it is much easier to maintain Maven. > > It'll remove discussion as to: what would be an attribute and what should > > be an element? Can it be based on required versus optional? Allowing both > > for the same "fields" is probably a recipe for disaster. > > > > I'll leave it up to tools like polyglot to do some the transformation > from > > your favorite language to the XML as expected by Maven. > > This is a clear separation, and it will give the Maven team the > > opportunity to focus on the real issues. > > > > So please join your forces and spend your energy on improving polyglot! > > > > thanks, > > Robert > > On 12-12-2020 11:04:33, Markus KARG wrote: > > 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. > > -Markus > > > > -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: > > > > > > commons-io > > commons-io > > 2.8.0 > > > > > > Here is the same declaration expressed with attribute shortcuts: > > > > > > 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
Re: AW: [DISCUSS] Allow attributes shorthand in pom.xml
Agree with Robert here: this issue is really about "hard to author/write POMs as they are chatty". Then use polyglot, and let's Maven itself (or Maven + polyglot) sort out things, but modding POM modello is something not we'd like to do... (as many others noted, existing tooling etc). My 5 cents. T On Sat, Dec 12, 2020 at 12:53 PM Robert Scholte wrote: > Here's my unpopular response: I'm not going to invest in attribute support > for Maven. > If the verbosity of the pom.xml is the first thing people complain about, > well, then Maven is doing a pretty good job (if the build itself had > issues, one would complain about that first, right?). > By having elements only it is much easier to maintain Maven. > It'll remove discussion as to: what would be an attribute and what should > be an element? Can it be based on required versus optional? Allowing both > for the same "fields" is probably a recipe for disaster. > > I'll leave it up to tools like polyglot to do some the transformation from > your favorite language to the XML as expected by Maven. > This is a clear separation, and it will give the Maven team the > opportunity to focus on the real issues. > > So please join your forces and spend your energy on improving polyglot! > > thanks, > Robert > On 12-12-2020 11:04:33, Markus KARG wrote: > 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. > -Markus > > -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: > > > commons-io > commons-io > 2.8.0 > > > Here is the same declaration expressed with attribute shortcuts: > > > 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 > X.X.X 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 >
Re: AW: [DISCUSS] Allow attributes shorthand in pom.xml
Here's my unpopular response: I'm not going to invest in attribute support for Maven. If the verbosity of the pom.xml is the first thing people complain about, well, then Maven is doing a pretty good job (if the build itself had issues, one would complain about that first, right?). By having elements only it is much easier to maintain Maven. It'll remove discussion as to: what would be an attribute and what should be an element? Can it be based on required versus optional? Allowing both for the same "fields" is probably a recipe for disaster. I'll leave it up to tools like polyglot to do some the transformation from your favorite language to the XML as expected by Maven. This is a clear separation, and it will give the Maven team the opportunity to focus on the real issues. So please join your forces and spend your energy on improving polyglot! thanks, Robert On 12-12-2020 11:04:33, Markus KARG wrote: 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. -Markus -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: commons-io commons-io 2.8.0 Here is the same declaration expressed with attribute shortcuts: 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 X.X.X 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
AW: [DISCUSS] Allow attributes shorthand in pom.xml
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. -Markus -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: commons-io commons-io 2.8.0 Here is the same declaration expressed with attribute shortcuts: 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 X.X.X 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, 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
