[jira] [Commented] (MNG-7044) Allow use of attributes in Maven pom.xml
[ https://issues.apache.org/jira/browse/MNG-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248454#comment-17248454 ] Will Iverson commented on MNG-7044: --- One last comment/link - if you want to experiment with different Maven build formats, check out: https://github.com/takari/polyglot-maven/ > Allow use of attributes in Maven pom.xml > > > Key: MNG-7044 > URL: https://issues.apache.org/jira/browse/MNG-7044 > Project: Maven > Issue Type: New Feature > Components: core, POM >Reporter: Will Iverson >Priority: Minor > Labels: features > > Proposal: The current pom.xml file is very verbose due to the exclusive use > of XML elements. This makes even simple declarations such as dependencies > unnecessarily verbose. > I would propose that a future version of Maven allow for the use of > attributes as an alternative declaration for pom.xml configuration. This > would only affect how Maven ingests project files - for consistency and > backward compatibility all generated pom.xml files would continue to be > element based. > Projects that declared a conflicting/duplicate attribute/element pairing > would be considered to be malformed, and would result in a built break. > By way of example of the benefit of this proposal, this declaration would be > reduced from: > > commons-cli > commons-cli > 1.4 > > ...to... > > This would allow many Maven projects to *dramatically* decrease the total > line count, which is one of the frequent criticisms of Maven compared with > other build tools. > If there is interest, I would be happy to help support this. My > hope/expectation is that the changes required to support this in Maven itself > would be quite minor - simply adding a bit of additional logic to look for > attributes in the XML parse and error reporting in the event of a duplication > (as well as supporting test cases). That said, I don't want to send in > patches for a change like this that would be dead on arrival. > This would, of course, represent a potentially large impact on the user and > tooling space (in particular, IDEs that integrate Maven support). As the > emitted files for resolved pom.xml files (those that are published in repos) > would remain the same, hopefully the overall impacts would be manageable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7044) Allow use of attributes in Maven pom.xml
[ https://issues.apache.org/jira/browse/MNG-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248450#comment-17248450 ] Will Iverson commented on MNG-7044: --- 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. Here is the link to Build/Consumer: https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM Go ahead and close this issue - if possible go ahead and link it to an issue for Build/Consumer if it exists in JIRA. Thanks! -Will > Allow use of attributes in Maven pom.xml > > > Key: MNG-7044 > URL: https://issues.apache.org/jira/browse/MNG-7044 > Project: Maven > Issue Type: New Feature > Components: core, POM >Reporter: Will Iverson >Priority: Minor > Labels: features > > Proposal: The current pom.xml file is very verbose due to the exclusive use > of XML elements. This makes even simple declarations such as dependencies > unnecessarily verbose. > I would propose that a future version of Maven allow for the use of > attributes as an alternative declaration for pom.xml configuration. This > would only affect how Maven ingests project files - for consistency and > backward compatibility all generated pom.xml files would continue to be > element based. > Projects that declared a conflicting/duplicate attribute/element pairing > would be considered to be malformed, and would result in a built break. > By way of example of the benefit of this proposal, this declaration would be > reduced from: > > commons-cli > commons-cli > 1.4 > > ...to... > > This would allow many Maven projects to *dramatically* decrease the total > line count, which is one of the frequent criticisms of Maven compared with > other build tools. > If there is interest, I would be happy to help support this. My > hope/expectation is that the changes required to support this in Maven itself > would be quite minor - simply adding a bit of additional logic to look for > attributes in the XML parse and error reporting in the event of a duplication > (as well as supporting test cases). That said, I don't want to send in > patches for a change like this that would be dead on arrival. > This would, of course, represent a potentially large impact on the user and > tooling space (in particular, IDEs that integrate Maven support). As the > emitted files for resolved pom.xml files (those that are published in repos) > would remain the same, hopefully the overall impacts would be manageable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7044) Allow use of attributes in Maven pom.xml
[ https://issues.apache.org/jira/browse/MNG-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246131#comment-17246131 ] Will Iverson commented on MNG-7044: --- Looks like the change would be to this file: https://github.com/codehaus-plexus/modello/blob/08152b14bb44867c038e52fc957c46ec1906668e/modello-plugins/modello-plugin-xpp3/src/main/java/org/codehaus/modello/plugin/xpp3/Xpp3ReaderGenerator.java It's a ~1600 line code generator. Looks like it doesn't actually have any tests for validating that a given pom.xml can be parsed/validated, just that the files generated by a *.mdo file can successfully compile. The maven-model project at https://github.com/apache/maven/blob/master/maven-model/pom.xml has a dependency on modello-maven-plugin, which in turn uses the above. Trying to time box to ~1hr at time. :) Next step is to try to generate a working test environment linking the above with SNAPSHOTs. My sense that this will all boil down to just a few lines to tweak the Xpp3ReaderGenerator.java is still there. The error message for an invalid pom.xml such as: Malformed POM /Users/wiverson/src/tiny-pom/pom.xml: Unknown attribute 'scope' for tag 'dependency' (position: START_TAG seen ...y groupId="junit" artifactId="junit" version="4.11" scope="test"/>... @22:81) @ /Users/wiverson/src/tiny-pom/pom.xml, line 22, column 81 ...is clearly coming from the Modello generated code, not the XSD. A simple version of the tweak to the code generator would just check to see if the attribute is a known field and allow it to be set if known, while throwing an error (like today) if not. A fancier version would emit an warning for a duplicate attribute/element declaration (just like a duplicate element declaration today. > Allow use of attributes in Maven pom.xml > > > Key: MNG-7044 > URL: https://issues.apache.org/jira/browse/MNG-7044 > Project: Maven > Issue Type: New Feature > Components: core, POM >Reporter: Will Iverson >Priority: Minor > Labels: features > > Proposal: The current pom.xml file is very verbose due to the exclusive use > of XML elements. This makes even simple declarations such as dependencies > unnecessarily verbose. > I would propose that a future version of Maven allow for the use of > attributes as an alternative declaration for pom.xml configuration. This > would only affect how Maven ingests project files - for consistency and > backward compatibility all generated pom.xml files would continue to be > element based. > Projects that declared a conflicting/duplicate attribute/element pairing > would be considered to be malformed, and would result in a built break. > By way of example of the benefit of this proposal, this declaration would be > reduced from: > > commons-cli > commons-cli > 1.4 > > ...to... > > This would allow many Maven projects to *dramatically* decrease the total > line count, which is one of the frequent criticisms of Maven compared with > other build tools. > If there is interest, I would be happy to help support this. My > hope/expectation is that the changes required to support this in Maven itself > would be quite minor - simply adding a bit of additional logic to look for > attributes in the XML parse and error reporting in the event of a duplication > (as well as supporting test cases). That said, I don't want to send in > patches for a change like this that would be dead on arrival. > This would, of course, represent a potentially large impact on the user and > tooling space (in particular, IDEs that integrate Maven support). As the > emitted files for resolved pom.xml files (those that are published in repos) > would remain the same, hopefully the overall impacts would be manageable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7044) Allow use of attributes in Maven pom.xml
[ https://issues.apache.org/jira/browse/MNG-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17244296#comment-17244296 ] Will Iverson commented on MNG-7044: --- https://github.com/codehaus-plexus/modello/issues/81 > Allow use of attributes in Maven pom.xml > > > Key: MNG-7044 > URL: https://issues.apache.org/jira/browse/MNG-7044 > Project: Maven > Issue Type: New Feature > Components: core, POM >Reporter: Will Iverson >Priority: Minor > Labels: features > > Proposal: The current pom.xml file is very verbose due to the exclusive use > of XML elements. This makes even simple declarations such as dependencies > unnecessarily verbose. > I would propose that a future version of Maven allow for the use of > attributes as an alternative declaration for pom.xml configuration. This > would only affect how Maven ingests project files - for consistency and > backward compatibility all generated pom.xml files would continue to be > element based. > Projects that declared a conflicting/duplicate attribute/element pairing > would be considered to be malformed, and would result in a built break. > By way of example of the benefit of this proposal, this declaration would be > reduced from: > > commons-cli > commons-cli > 1.4 > > ...to... > > This would allow many Maven projects to *dramatically* decrease the total > line count, which is one of the frequent criticisms of Maven compared with > other build tools. > If there is interest, I would be happy to help support this. My > hope/expectation is that the changes required to support this in Maven itself > would be quite minor - simply adding a bit of additional logic to look for > attributes in the XML parse and error reporting in the event of a duplication > (as well as supporting test cases). That said, I don't want to send in > patches for a change like this that would be dead on arrival. > This would, of course, represent a potentially large impact on the user and > tooling space (in particular, IDEs that integrate Maven support). As the > emitted files for resolved pom.xml files (those that are published in repos) > would remain the same, hopefully the overall impacts would be manageable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7044) Allow use of attributes in Maven pom.xml
[ https://issues.apache.org/jira/browse/MNG-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17243753#comment-17243753 ] Michael Osipov commented on MNG-7044: - File an issue with Modelo and I will fix the 404. > Allow use of attributes in Maven pom.xml > > > Key: MNG-7044 > URL: https://issues.apache.org/jira/browse/MNG-7044 > Project: Maven > Issue Type: New Feature > Components: core, POM >Reporter: Will Iverson >Priority: Minor > Labels: features > > Proposal: The current pom.xml file is very verbose due to the exclusive use > of XML elements. This makes even simple declarations such as dependencies > unnecessarily verbose. > I would propose that a future version of Maven allow for the use of > attributes as an alternative declaration for pom.xml configuration. This > would only affect how Maven ingests project files - for consistency and > backward compatibility all generated pom.xml files would continue to be > element based. > Projects that declared a conflicting/duplicate attribute/element pairing > would be considered to be malformed, and would result in a built break. > By way of example of the benefit of this proposal, this declaration would be > reduced from: > > commons-cli > commons-cli > 1.4 > > ...to... > > This would allow many Maven projects to *dramatically* decrease the total > line count, which is one of the frequent criticisms of Maven compared with > other build tools. > If there is interest, I would be happy to help support this. My > hope/expectation is that the changes required to support this in Maven itself > would be quite minor - simply adding a bit of additional logic to look for > attributes in the XML parse and error reporting in the event of a duplication > (as well as supporting test cases). That said, I don't want to send in > patches for a change like this that would be dead on arrival. > This would, of course, represent a potentially large impact on the user and > tooling space (in particular, IDEs that integrate Maven support). As the > emitted files for resolved pom.xml files (those that are published in repos) > would remain the same, hopefully the overall impacts would be manageable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7044) Allow use of attributes in Maven pom.xml
[ https://issues.apache.org/jira/browse/MNG-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17243521#comment-17243521 ] Will Iverson commented on MNG-7044: --- On this page: [https://codehaus-plexus.github.io/modello/modello-maven-plugin/faq.html] there's a reference to a Modello wiki at [http://docs.codehaus.org/display/MODELLO/Home] that's dead. Found some of it on wayback, last snapshot in 2015. Looks like some conceptual overview stuff, but all-in-all Modello looks like a fairly conventional static code generator. > Allow use of attributes in Maven pom.xml > > > Key: MNG-7044 > URL: https://issues.apache.org/jira/browse/MNG-7044 > Project: Maven > Issue Type: New Feature > Components: core, POM >Reporter: Will Iverson >Priority: Minor > Labels: features > > Proposal: The current pom.xml file is very verbose due to the exclusive use > of XML elements. This makes even simple declarations such as dependencies > unnecessarily verbose. > I would propose that a future version of Maven allow for the use of > attributes as an alternative declaration for pom.xml configuration. This > would only affect how Maven ingests project files - for consistency and > backward compatibility all generated pom.xml files would continue to be > element based. > Projects that declared a conflicting/duplicate attribute/element pairing > would be considered to be malformed, and would result in a built break. > By way of example of the benefit of this proposal, this declaration would be > reduced from: > > commons-cli > commons-cli > 1.4 > > ...to... > > This would allow many Maven projects to *dramatically* decrease the total > line count, which is one of the frequent criticisms of Maven compared with > other build tools. > If there is interest, I would be happy to help support this. My > hope/expectation is that the changes required to support this in Maven itself > would be quite minor - simply adding a bit of additional logic to look for > attributes in the XML parse and error reporting in the event of a duplication > (as well as supporting test cases). That said, I don't want to send in > patches for a change like this that would be dead on arrival. > This would, of course, represent a potentially large impact on the user and > tooling space (in particular, IDEs that integrate Maven support). As the > emitted files for resolved pom.xml files (those that are published in repos) > would remain the same, hopefully the overall impacts would be manageable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7044) Allow use of attributes in Maven pom.xml
[ https://issues.apache.org/jira/browse/MNG-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17243516#comment-17243516 ] Michael Osipov commented on MNG-7044: - See here: https://codehaus-plexus.github.io/modello/modello.html > Allow use of attributes in Maven pom.xml > > > Key: MNG-7044 > URL: https://issues.apache.org/jira/browse/MNG-7044 > Project: Maven > Issue Type: New Feature > Components: core, POM >Reporter: Will Iverson >Priority: Minor > Labels: features > > Proposal: The current pom.xml file is very verbose due to the exclusive use > of XML elements. This makes even simple declarations such as dependencies > unnecessarily verbose. > I would propose that a future version of Maven allow for the use of > attributes as an alternative declaration for pom.xml configuration. This > would only affect how Maven ingests project files - for consistency and > backward compatibility all generated pom.xml files would continue to be > element based. > Projects that declared a conflicting/duplicate attribute/element pairing > would be considered to be malformed, and would result in a built break. > By way of example of the benefit of this proposal, this declaration would be > reduced from: > > commons-cli > commons-cli > 1.4 > > ...to... > > This would allow many Maven projects to *dramatically* decrease the total > line count, which is one of the frequent criticisms of Maven compared with > other build tools. > If there is interest, I would be happy to help support this. My > hope/expectation is that the changes required to support this in Maven itself > would be quite minor - simply adding a bit of additional logic to look for > attributes in the XML parse and error reporting in the event of a duplication > (as well as supporting test cases). That said, I don't want to send in > patches for a change like this that would be dead on arrival. > This would, of course, represent a potentially large impact on the user and > tooling space (in particular, IDEs that integrate Maven support). As the > emitted files for resolved pom.xml files (those that are published in repos) > would remain the same, hopefully the overall impacts would be manageable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7044) Allow use of attributes in Maven pom.xml
[ https://issues.apache.org/jira/browse/MNG-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17243432#comment-17243432 ] Will Iverson commented on MNG-7044: --- KK, so the validation of the model happens in Java. The actual parsing of the model appears to be from Java code generated by Modello. It appears that the Modello Maven plugin is used to generate Java parsing code from a Modello file. This page has links with the Modello plugin and the Maven Modello file available here: [http://codehaus-plexus.github.io/modello/modello-maven-plugin/faq.html] Interestingly, the existing page for Modello lists other formats besides XML (e.g. YAML). [http://codehaus-plexus.github.io/modello/modello-maven-plugin/index.html] This is the Maven core project that actually generates the Model parsing from Modello: [https://github.com/apache/maven/tree/master/maven-model] That maven-model project is interesting, as there is essentially no code in it at all, just the Modello generation. Checking that code out and running it to generate the Modello XML parsing is quite interesting and (happily) pretty straight-forward. It appears that the theoretical path is to add an option to the Modello Java generator to add attribute processing via a flag. So, then the process is (again, to flog theoretical) submit a patch to add the option to Modello to allow for attribute alias generation (looks like just a few lines), and then submit a patch to turn that option on in the maven-model project (a single line to enable it in the Modello configuration). Unfortunately, the links on the Modello page to documentation appear to be broken due to the codehaus dissolution. Let me know any thoughts/observations. I would guess adding an option to Modello to generate attribute aliasing is, in itself, pretty innocuous/likely to be accepted. Which, in turn, would mean that flipping the option on would be a single line PR for maven-model. Huh. > Allow use of attributes in Maven pom.xml > > > Key: MNG-7044 > URL: https://issues.apache.org/jira/browse/MNG-7044 > Project: Maven > Issue Type: New Feature > Components: core, POM >Reporter: Will Iverson >Priority: Minor > Labels: features > > Proposal: The current pom.xml file is very verbose due to the exclusive use > of XML elements. This makes even simple declarations such as dependencies > unnecessarily verbose. > I would propose that a future version of Maven allow for the use of > attributes as an alternative declaration for pom.xml configuration. This > would only affect how Maven ingests project files - for consistency and > backward compatibility all generated pom.xml files would continue to be > element based. > Projects that declared a conflicting/duplicate attribute/element pairing > would be considered to be malformed, and would result in a built break. > By way of example of the benefit of this proposal, this declaration would be > reduced from: > > commons-cli > commons-cli > 1.4 > > ...to... > > This would allow many Maven projects to *dramatically* decrease the total > line count, which is one of the frequent criticisms of Maven compared with > other build tools. > If there is interest, I would be happy to help support this. My > hope/expectation is that the changes required to support this in Maven itself > would be quite minor - simply adding a bit of additional logic to look for > attributes in the XML parse and error reporting in the event of a duplication > (as well as supporting test cases). That said, I don't want to send in > patches for a change like this that would be dead on arrival. > This would, of course, represent a potentially large impact on the user and > tooling space (in particular, IDEs that integrate Maven support). As the > emitted files for resolved pom.xml files (those that are published in repos) > would remain the same, hopefully the overall impacts would be manageable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7044) Allow use of attributes in Maven pom.xml
[ https://issues.apache.org/jira/browse/MNG-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242707#comment-17242707 ] Michael Osipov commented on MNG-7044: - Yes, the validation happens completely in Java: https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java > Allow use of attributes in Maven pom.xml > > > Key: MNG-7044 > URL: https://issues.apache.org/jira/browse/MNG-7044 > Project: Maven > Issue Type: New Feature > Components: core, POM >Reporter: Will Iverson >Priority: Minor > Labels: features > > Proposal: The current pom.xml file is very verbose due to the exclusive use > of XML elements. This makes even simple declarations such as dependencies > unnecessarily verbose. > I would propose that a future version of Maven allow for the use of > attributes as an alternative declaration for pom.xml configuration. This > would only affect how Maven ingests project files - for consistency and > backward compatibility all generated pom.xml files would continue to be > element based. > Projects that declared a conflicting/duplicate attribute/element pairing > would be considered to be malformed, and would result in a built break. > By way of example of the benefit of this proposal, this declaration would be > reduced from: > > commons-cli > commons-cli > 1.4 > > ...to... > > This would allow many Maven projects to *dramatically* decrease the total > line count, which is one of the frequent criticisms of Maven compared with > other build tools. > If there is interest, I would be happy to help support this. My > hope/expectation is that the changes required to support this in Maven itself > would be quite minor - simply adding a bit of additional logic to look for > attributes in the XML parse and error reporting in the event of a duplication > (as well as supporting test cases). That said, I don't want to send in > patches for a change like this that would be dead on arrival. > This would, of course, represent a potentially large impact on the user and > tooling space (in particular, IDEs that integrate Maven support). As the > emitted files for resolved pom.xml files (those that are published in repos) > would remain the same, hopefully the overall impacts would be manageable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7044) Allow use of attributes in Maven pom.xml
[ https://issues.apache.org/jira/browse/MNG-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241923#comment-17241923 ] Will Iverson commented on MNG-7044: --- Bit more investigation: - Everything in the current Maven xsd is apparently optional. As in, literally every element is flagged as minOccurs="0". So, it appears that technically a Maven pom.xml can have anything in it with whatever attributes anyone wanted to add, and it would still be considered valid insofar as the Maven xsd is concerned. The bulk of the xsd is devoted to documentation - there is essentially no validation expressed in the xsd. - There already exists today an interesting separation between a project pom.xml and the effective pom that's generated both by Maven internally for processing and exported to a repository. Do you happen to know which Maven project is responsible for the actual parsing of the pom.xml itself? > Allow use of attributes in Maven pom.xml > > > Key: MNG-7044 > URL: https://issues.apache.org/jira/browse/MNG-7044 > Project: Maven > Issue Type: New Feature > Components: core, POM >Reporter: Will Iverson >Priority: Minor > Labels: features > > Proposal: The current pom.xml file is very verbose due to the exclusive use > of XML elements. This makes even simple declarations such as dependencies > unnecessarily verbose. > I would propose that a future version of Maven allow for the use of > attributes as an alternative declaration for pom.xml configuration. This > would only affect how Maven ingests project files - for consistency and > backward compatibility all generated pom.xml files would continue to be > element based. > Projects that declared a conflicting/duplicate attribute/element pairing > would be considered to be malformed, and would result in a built break. > By way of example of the benefit of this proposal, this declaration would be > reduced from: > > commons-cli > commons-cli > 1.4 > > ...to... > > This would allow many Maven projects to *dramatically* decrease the total > line count, which is one of the frequent criticisms of Maven compared with > other build tools. > If there is interest, I would be happy to help support this. My > hope/expectation is that the changes required to support this in Maven itself > would be quite minor - simply adding a bit of additional logic to look for > attributes in the XML parse and error reporting in the event of a duplication > (as well as supporting test cases). That said, I don't want to send in > patches for a change like this that would be dead on arrival. > This would, of course, represent a potentially large impact on the user and > tooling space (in particular, IDEs that integrate Maven support). As the > emitted files for resolved pom.xml files (those that are published in repos) > would remain the same, hopefully the overall impacts would be manageable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7044) Allow use of attributes in Maven pom.xml
[ https://issues.apache.org/jira/browse/MNG-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241299#comment-17241299 ] Maarten Mulders commented on MNG-7044: -- I'm sorry for the early closure. Indeed I should've double-checked if it was the same proposal or not. I don't hold a strong opinion in favour of or against this idea, it's just me being too lazy and not checking. Again, please apologise. You can find the Modello model in [Maven Core|https://github.com/apache/maven], under [maven-model/src/main/mdo|https://github.com/apache/maven/tree/master/maven-model/src/main/mdo]. I am not familiar with how it works or how it transforms into Java code, so I'm afraid I won't be of much help in that part. I do know some parts of Maven from my recent work on Maven, just not these parts. As far as I understand, with the new build/consumer feature that will ship in Maven 4, it will be possible to deploy a different POM than the one that is used to build the project. Maybe that would provide the foundation for what you're suggesting - rewriting those attributes into the more verbose element-based structure so all tools that support Model version 4 will be able to understand. But again, I'm not sure about this, we would need to investigate. > Allow use of attributes in Maven pom.xml > > > Key: MNG-7044 > URL: https://issues.apache.org/jira/browse/MNG-7044 > Project: Maven > Issue Type: New Feature > Components: core, POM >Reporter: Will Iverson >Priority: Minor > Labels: features > > Proposal: The current pom.xml file is very verbose due to the exclusive use > of XML elements. This makes even simple declarations such as dependencies > unnecessarily verbose. > I would propose that a future version of Maven allow for the use of > attributes as an alternative declaration for pom.xml configuration. This > would only affect how Maven ingests project files - for consistency and > backward compatibility all generated pom.xml files would continue to be > element based. > Projects that declared a conflicting/duplicate attribute/element pairing > would be considered to be malformed, and would result in a built break. > By way of example of the benefit of this proposal, this declaration would be > reduced from: > > commons-cli > commons-cli > 1.4 > > ...to... > > This would allow many Maven projects to *dramatically* decrease the total > line count, which is one of the frequent criticisms of Maven compared with > other build tools. > If there is interest, I would be happy to help support this. My > hope/expectation is that the changes required to support this in Maven itself > would be quite minor - simply adding a bit of additional logic to look for > attributes in the XML parse and error reporting in the event of a duplication > (as well as supporting test cases). That said, I don't want to send in > patches for a change like this that would be dead on arrival. > This would, of course, represent a potentially large impact on the user and > tooling space (in particular, IDEs that integrate Maven support). As the > emitted files for resolved pom.xml files (those that are published in repos) > would remain the same, hopefully the overall impacts would be manageable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7044) Allow use of attributes in Maven pom.xml
[ https://issues.apache.org/jira/browse/MNG-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241125#comment-17241125 ] Will Iverson commented on MNG-7044: --- RE: [Modello|https://codehaus-plexus.github.io/modello/index.html], ok, so that's a tool that Maven uses to generate the XSD, so (in theory) that should make it easier to update, not harder, right? Otherwise, why use a tool? If the Maven xsd is generated by Modello, where is the source for the xsd coming from? It would be helpful if you could point me to a Git repo for the Modello script that generates the xsd so I can submit an appropriate proposal for a patch. I completely understand that the source code for Maven is scattered everywhere in a ton of different modules - pointers for where to look would be a huge time saver. RE: sitting for many months, sure. I mean, MVN-5653 raising the issue was submitted in 2014 and I've been working with Java since 1995, so I get what I'm dealing with here. Stepping back for a minute - there's the engineering effort to make this happen. That might involve (for example) updating Modello scripts in a repo, updating some set of Maven core logic to add attribute processing, writing a bunch of test cases, and (eventually) posting a new xsd. In theory all of this could be done with patches and experimental forks - that's literally the point of open source software, to allow for that kind of work to be done in the open. The temporary experimental xsd could even be hosted somewhere else. If there are other components to be updated or issues to be tracked, cool, that's software development. Make a list, check it off. If there is interest in pursuing this, the committers with experience in their respective areas could probably knock it out quickly, even as an experimental build. The sense I get is that there is a low level resistance to fixing or even discussing this issue, for reasons I don't really understand. This is (IMHO) a reasonable proposal for solving a huge user land problem with Maven with the smallest possible impact on the ecosystem. This is the functional equivalent of a feature-flag incremental update to Maven - if a user wants to start using a theoretical 4.0.1 xsd for their projects with the option of using attributes, cool, otherwise stick with 4.0.0 - and everything Maven emits continues to be 4.0.0 for maximum compatibility anyways. If there is a strong technical objection, cool, let's get it on the table and talk about it. It would be *super helpful* to have someone, anyone who currently works on Maven help out with this - someone who can answer a few Qs, provide a few pointers. Otherwise, I'm going to be stuck having to parse through repos by hand, but that's no different from any legacy software dev project. I really, really like Maven, and it makes me sad to have to continually explain the (many) advantages Maven has over other build tools only to be met with "but the XML is too verbose." This is eminently fixable. > Allow use of attributes in Maven pom.xml > > > Key: MNG-7044 > URL: https://issues.apache.org/jira/browse/MNG-7044 > Project: Maven > Issue Type: New Feature > Components: core, POM >Reporter: Will Iverson >Priority: Minor > Labels: features > > Proposal: The current pom.xml file is very verbose due to the exclusive use > of XML elements. This makes even simple declarations such as dependencies > unnecessarily verbose. > I would propose that a future version of Maven allow for the use of > attributes as an alternative declaration for pom.xml configuration. This > would only affect how Maven ingests project files - for consistency and > backward compatibility all generated pom.xml files would continue to be > element based. > Projects that declared a conflicting/duplicate attribute/element pairing > would be considered to be malformed, and would result in a built break. > By way of example of the benefit of this proposal, this declaration would be > reduced from: > > commons-cli > commons-cli > 1.4 > > ...to... > > This would allow many Maven projects to *dramatically* decrease the total > line count, which is one of the frequent criticisms of Maven compared with > other build tools. > If there is interest, I would be happy to help support this. My > hope/expectation is that the changes required to support this in Maven itself > would be quite minor - simply adding a bit of additional logic to look for > attributes in the XML parse and error reporting in the event of a duplication > (as well as supporting test cases). That said, I don't want to send in > patches for a change like this that would be dead on arrival. > This would, of course, represent a potentially large impact on the user
[jira] [Commented] (MNG-7044) Allow use of attributes in Maven pom.xml
[ https://issues.apache.org/jira/browse/MNG-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241095#comment-17241095 ] Will Iverson commented on MNG-7044: --- I would just like to also note that MNG-5653 was originally opened in 2014, and it proposed a different syntax from what I'm recommending. This [announcement thread|https://www.reddit.com/r/java/comments/k3rv35/whats_new_in_maven_4_maarten_on_it/] 4.0.0 is an example of the user complaints over the verbosity of Maven. I completely understand the sensitivities around breakage, etc. It's just that this has been a known issue since at least 2014, and there has been zero movement around any kind of resolution. Saying "wait until 5.0" to even start *thinking about it* under the [current release structure|https://maven.apache.org/docs/history.html] appears to be a decade long deferral. > Allow use of attributes in Maven pom.xml > > > Key: MNG-7044 > URL: https://issues.apache.org/jira/browse/MNG-7044 > Project: Maven > Issue Type: New Feature > Components: core, POM >Reporter: Will Iverson >Priority: Minor > Labels: features > > Proposal: The current pom.xml file is very verbose due to the exclusive use > of XML elements. This makes even simple declarations such as dependencies > unnecessarily verbose. > I would propose that a future version of Maven allow for the use of > attributes as an alternative declaration for pom.xml configuration. This > would only affect how Maven ingests project files - for consistency and > backward compatibility all generated pom.xml files would continue to be > element based. > Projects that declared a conflicting/duplicate attribute/element pairing > would be considered to be malformed, and would result in a built break. > By way of example of the benefit of this proposal, this declaration would be > reduced from: > > commons-cli > commons-cli > 1.4 > > ...to... > > This would allow many Maven projects to *dramatically* decrease the total > line count, which is one of the frequent criticisms of Maven compared with > other build tools. > If there is interest, I would be happy to help support this. My > hope/expectation is that the changes required to support this in Maven itself > would be quite minor - simply adding a bit of additional logic to look for > attributes in the XML parse and error reporting in the event of a duplication > (as well as supporting test cases). That said, I don't want to send in > patches for a change like this that would be dead on arrival. > This would, of course, represent a potentially large impact on the user and > tooling space (in particular, IDEs that integrate Maven support). As the > emitted files for resolved pom.xml files (those that are published in repos) > would remain the same, hopefully the overall impacts would be manageable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7044) Allow use of attributes in Maven pom.xml
[ https://issues.apache.org/jira/browse/MNG-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241081#comment-17241081 ] Will Iverson commented on MNG-7044: --- Hi! # This is not a duplicate, it's a different approach. Issue MNG-5653 is proposing a new syntax, which is completely different. # This approach would require adding attribute declarations to the Maven to the Maven XSD to allow for attribute declarations. I have looked at the existing xsd and adding the attribute declarations could be done in a day - I would be happy to do this and would propose it as a transitional Maven .xsd with a 4.0.1 version number. Users would be able to update their existing pom.xml to the 4.0.1 with zero breakage. # This proposal would have Maven continue to emit the existing 4.0.0 pom.xml with adherence to the existing xsd. I appreciate that this seems at first blush to be a big change, but it's also the most incremental way to support the end goal (allowing end users to use a more concise syntax) while maintaining backward compatibility. Please reconsider this closure - this is a very different proposal from MNG-5653, which I will note is already a dead proposal. > Allow use of attributes in Maven pom.xml > > > Key: MNG-7044 > URL: https://issues.apache.org/jira/browse/MNG-7044 > Project: Maven > Issue Type: New Feature > Components: core, POM >Reporter: Will Iverson >Priority: Minor > Labels: features > > Proposal: The current pom.xml file is very verbose due to the exclusive use > of XML elements. This makes even simple declarations such as dependencies > unnecessarily verbose. > I would propose that a future version of Maven allow for the use of > attributes as an alternative declaration for pom.xml configuration. This > would only affect how Maven ingests project files - for consistency and > backward compatibility all generated pom.xml files would continue to be > element based. > Projects that declared a conflicting/duplicate attribute/element pairing > would be considered to be malformed, and would result in a built break. > By way of example of the benefit of this proposal, this declaration would be > reduced from: > > commons-cli > commons-cli > 1.4 > > ...to... > > This would allow many Maven projects to *dramatically* decrease the total > line count, which is one of the frequent criticisms of Maven compared with > other build tools. > If there is interest, I would be happy to help support this. My > hope/expectation is that the changes required to support this in Maven itself > would be quite minor - simply adding a bit of additional logic to look for > attributes in the XML parse and error reporting in the event of a duplication > (as well as supporting test cases). That said, I don't want to send in > patches for a change like this that would be dead on arrival. > This would, of course, represent a potentially large impact on the user and > tooling space (in particular, IDEs that integrate Maven support). As the > emitted files for resolved pom.xml files (those that are published in repos) > would remain the same, hopefully the overall impacts would be manageable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7044) Allow use of attributes in Maven pom.xml
[ https://issues.apache.org/jira/browse/MNG-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241035#comment-17241035 ] Michael Osipov commented on MNG-7044: - This is likely the third or fourth request for this. Please search open issues and close as duplicate. > Allow use of attributes in Maven pom.xml > > > Key: MNG-7044 > URL: https://issues.apache.org/jira/browse/MNG-7044 > Project: Maven > Issue Type: New Feature > Components: core, POM >Reporter: Will Iverson >Priority: Minor > Labels: features > > Proposal: The current pom.xml file is very verbose due to the exclusive use > of XML elements. This makes even simple declarations such as dependencies > unnecessarily verbose. > I would propose that a future version of Maven allow for the use of > attributes as an alternative declaration for pom.xml configuration. This > would only affect how Maven ingests project files - for consistency and > backward compatibility all generated pom.xml files would continue to be > element based. > Projects that declared a conflicting/duplicate attribute/element pairing > would be considered to be malformed, and would result in a built break. > By way of example of the benefit of this proposal, this declaration would be > reduced from: > > commons-cli > commons-cli > 1.4 > > ...to... > > This would allow many Maven projects to *dramatically* decrease the total > line count, which is one of the frequent criticisms of Maven compared with > other build tools. > If there is interest, I would be happy to help support this. My > hope/expectation is that the changes required to support this in Maven itself > would be quite minor - simply adding a bit of additional logic to look for > attributes in the XML parse and error reporting in the event of a duplication > (as well as supporting test cases). That said, I don't want to send in > patches for a change like this that would be dead on arrival. > This would, of course, represent a potentially large impact on the user and > tooling space (in particular, IDEs that integrate Maven support). As the > emitted files for resolved pom.xml files (those that are published in repos) > would remain the same, hopefully the overall impacts would be manageable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
