[
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:
> <dependency>
> <groupId>commons-cli</groupId>
> <artifactId>commons-cli</artifactId>
> <version>1.4</version>
> </dependency>
> ...to...
> <dependency groupId="commons-cli" artifactId="commons-cli" version="1.4" />
> 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)
