[
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:
> <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)
