[DISCUSS] Allow attributes shorthand in pom.xml

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] Allow attributes shorthand in pom.xml

Will Iverson
One of the biggest complaints about Maven has long been the verbosity of
the XML format. The verbosity is due in large part to the exclusive
reliance on XML elements in Maven.

Proposal: Allow Maven pom.xml to treat attributes as a short-hand for
declaring configuration elements.

Example: One of the most verbose sections of the pom for most projects is
dependencies. A typical example:

<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>2.8.0</version>
</dependency>

Here is the same declaration expressed with attribute shortcuts:

<dependency groupId="commons-io" artifactId="commons-io" version="2.8.0" />
That's an 80% reduction in LoC, and would make Maven comparable with other
popular build tools (e.g. compare and contrast with other build tools at
https://mvnrepository.com/artifact/commons-io/commons-io/2.8.0)

REQUEST: Feedback on if this is something to pursue. I've done some
research, happy to submit patches, but don't want to pursue if there is
either a) technical reason[s] not to proceed I'm not aware of or b) a lack
of enthusiasm for the entire idea from the community.

Basically, I'm looking for some feedback along the lines of a) love it -
please submit patches so we can check it out, b) huh, maybe, willing to
look at it, or c) this is a terrible idea, because X. Effectively, a
totally non-binding vote on if this is worth exploring.

I've discussed this with others online and done some research, so are a few
answers to objections/Qs as I currently understand. I may be
wrong/uninformed about certain aspects, which would be very helpful
feedback.

Q: Won't this require a new Maven XSD to be generated?
A: No. The current Maven XSD declares many elements, but is not actually
involved in validation. While the current XSD is valuable for tools and
documentation, it does not actually perform validation.

Q: Wait, so what actually does the validation?
A: It's all done in Java code generated by Modello. The maven-model project
(https://github.com/apache/maven/tree/maven-3.6.3/maven-model) relies on
the Modello Maven Plugin (
http://codehaus-plexus.github.io/modello/modello-maven-plugin/) which in
turn relies on Modello core (http://codehaus-plexus.github.io/modello/) to
generate the Java code that processes the pom.xml

The proposal is to submit a patch for Modello that would allow the
generated source to accept an attribute as an alias for input. If it's a
valid element per the Maven maven.mdo file (
https://github.com/apache/maven/blob/maven-3.6.3/maven-model/src/main/mdo/maven.mdo)
it will now accept an attribute as a shortcut.

Q: Wouldn't this break, like, everything?
A: It would only affect pom.xml files that are read at runtime. All emitted
pom.xml files would remain exactly the same.

Q: Does this involve changing or rewriting the user's pom.xml? Isn't that
the thing that's making it hard to support alternative formats for pom.xml
like polyglot poms, etc?
A: Nope, the pom.xml on disk is still the pom.xml. A
<prerequisites><maven>X.X.X<maven></prerequisites> would be the only flag
recommended to declare that a pom.xml uses attributes for shorthand.

Q: How much work is this to actually implement?
A: It starts with a few lines added to the Modello code generation to allow
for attribute aliasing with a feature flag. Testing those changes through
the rest of the dependency chain. Adding test cases throughout.
Documentation. although as "now you can use attributes" is conceptually
simple it's not too bad. Tools in the Maven ecosystem would be able to
indicate they have been updated to support this by referring to the simple
term, "attribute shortcuts". Because nothing else changes, the only real
documentation change would be "things that were elements can also be
declared as attributes." The trickiest part is probably sorting out how to
manage the feature flag across the various components. I'm sure there's
more with a huge ecosystem like this, but the actual changes to the Modello
code gen appear to be surprisingly minor.

Q: What about tooling, like IDEs, publishing to Maven Central & Maven
repositories, etc?
A: Many IDEs appear to have implemented validation logic on top of Maven
that currently will flag attributes as errors in a pom.xml. Those IDEs and
other tools would require updates to this validation logic. Because the
rendered pom.xml output remains the same publishing tool chains and Maven
repositories should be completely unaffected.

Q: Any big issues you've identified?
A: Many sub-elements are not actually processed by Modello or Maven Model,
but are instead passed along to the plugin. For example, <configuration>
elements. It would be up to each of these projects to eventually allow for
attribute aliasing (or not). Maven projects that rely on Modello would have
the choice to adopt the new version and turn on the feature flag (or not).
It's possible that this would be confusing for some users - i.e. "why can I
declare dependencies with attributes but not configuration values"? That
said, I think it's manageable and would allow the ecosystem to slowly
update.
Q: Shouldn't we wait for Maven 5 to tackle this?
A: There's an issue going back to 2008 about the verbosity of pom.xml -
https://issues.apache.org/jira/browse/MNG-3397 - so... that's 12 years.
While writing this email, I just realized I commented on that issue back in
2014. Any proposal to dramatically change the pom is going to be a *huge*
effort and is not at all what I'm proposing. This is literally the simplest
possible change I can think of that accomplishes the goal (dramatically
reducing the verbosity of the pom.xml) with the least possible impact to
the ecosystem. It's been twelve years. Maven 5 is years away.

I know there is a voting system for changes to Maven, and this would be a
huge userland change. If there is even a soft exploratory "yes" I'm happy
to submit patches. Even better would be the assistance of an existing Maven
committer willing to help me navigate Apache requirements. If the feedback
is generally negative, that's fine too - I'll just go ahead and close the
issue. What I don't want to do is submit patches and then have everyone
yell at me. The Internet can be rough, you know.  :)

I know this is a long email - thanks for reading, and looking forward to
feedback.

Thanks,
-Will

P.S. I've been tracking my research on this approach with this issue
https://issues.apache.org/jira/browse/MNG-7044, in case you are curious
about the research/additional links.
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Allow attributes shorthand in pom.xml

Will Iverson
Ha, looking at the source code for polyglot-xml it's using Modello to do
something very similar to what I'm proposing- it's tweaking Modello code
gen to allow dependencies and plugins to be defined via attributes.  It
also is generating a new XSD and a new pom.xml41 which uses that XSD. The
proposal above could be as simple as porting some of the polyglot-xml
changes directly in Maven/Modello itself, albeit without generating a
new XSD.

I know there are some issues with polyglot and the way pom.xml files are
read off disk. My understanding is that some of that is due to be addressed
by Build vs Consumer POM, but not sure about the status beyond [
https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM].
Essentially, my proposal boils down to something very similar to
Build/Consumer insofar as the "build" pom.xml would support attributes but
all generated pom.xml would remain the same.

Thanks for the link.


On Fri, Dec 11, 2020 at 2:46 PM Manfred Moser <[hidden email]>
wrote:

>
>
> You can use polyglot-maven for a compatible approach for your own pom
> files right now..
>
> https://github.com/takari/polyglot-maven/tree/master/polyglot-xml
>
> Manfred
>
> Will Iverson wrote on 2020-12-11 14:40 (GMT -08:00):
>
> > One of the biggest complaints about Maven has long been the verbosity of
> > the XML format. The verbosity is due in large part to the exclusive
> > reliance on XML elements in Maven.
> >
> > Proposal: Allow Maven pom.xml to treat attributes as a short-hand for
> > declaring configuration elements.
> >
> > Example: One of the most verbose sections of the pom for most projects is
> > dependencies. A typical example:
> >
> > <dependency>
> > <groupId>commons-io</groupId>
> > <artifactId>commons-io</artifactId>
> > <version>2.8.0</version>
> > </dependency>
> >
> > Here is the same declaration expressed with attribute shortcuts:
> >
> > <dependency groupId="commons-io" artifactId="commons-io" version="2.8.0"
> />
> > That's an 80% reduction in LoC, and would make Maven comparable with
> other
> > popular build tools (e.g. compare and contrast with other build tools at
> > https://mvnrepository.com/artifact/commons-io/commons-io/2.8.0)
> >
> > REQUEST: Feedback on if this is something to pursue. I've done some
> > research, happy to submit patches, but don't want to pursue if there is
> > either a) technical reason[s] not to proceed I'm not aware of or b) a
> lack
> > of enthusiasm for the entire idea from the community.
> >
> > Basically, I'm looking for some feedback along the lines of a) love it -
> > please submit patches so we can check it out, b) huh, maybe, willing to
> > look at it, or c) this is a terrible idea, because X. Effectively, a
> > totally non-binding vote on if this is worth exploring.
> >
> > I've discussed this with others online and done some research, so are a
> few
> > answers to objections/Qs as I currently understand. I may be
> > wrong/uninformed about certain aspects, which would be very helpful
> > feedback.
> >
> > Q: Won't this require a new Maven XSD to be generated?
> > A: No. The current Maven XSD declares many elements, but is not actually
> > involved in validation. While the current XSD is valuable for tools and
> > documentation, it does not actually perform validation.
> >
> > Q: Wait, so what actually does the validation?
> > A: It's all done in Java code generated by Modello. The maven-model
> project
> > (https://github.com/apache/maven/tree/maven-3.6.3/maven-model) relies on
> > the Modello Maven Plugin (
> > http://codehaus-plexus.github.io/modello/modello-maven-plugin/) which in
> > turn relies on Modello core (http://codehaus-plexus.github.io/modello/)
> to
> > generate the Java code that processes the pom.xml
> >
> > The proposal is to submit a patch for Modello that would allow the
> > generated source to accept an attribute as an alias for input. If it's a
> > valid element per the Maven maven.mdo file (
> >
> https://github.com/apache/maven/blob/maven-3.6.3/maven-model/src/main/mdo/maven.mdo
> )
> > it will now accept an attribute as a shortcut.
> >
> > Q: Wouldn't this break, like, everything?
> > A: It would only affect pom.xml files that are read at runtime. All
> emitted
> > pom.xml files would remain exactly the same.
> >
> > Q: Does this involve changing or rewriting the user's pom.xml? Isn't that
> > the thing that's making it hard to support alternative formats for
> pom.xml
> > like polyglot poms, etc?
> > A: Nope, the pom.xml on disk is still the pom.xml. A
> > <prerequisites><maven>X.X.X<maven></prerequisites> would be the only flag
> > recommended to declare that a pom.xml uses attributes for shorthand.
> >
> > Q: How much work is this to actually implement?
> > A: It starts with a few lines added to the Modello code generation to
> allow
> > for attribute aliasing with a feature flag. Testing those changes through
> > the rest of the dependency chain. Adding test cases throughout.
> > Documentation. although as "now you can use attributes" is conceptually
> > simple it's not too bad. Tools in the Maven ecosystem would be able to
> > indicate they have been updated to support this by referring to the
> simple
> > term, "attribute shortcuts". Because nothing else changes, the only real
> > documentation change would be "things that were elements can also be
> > declared as attributes." The trickiest part is probably sorting out how
> to
> > manage the feature flag across the various components. I'm sure there's
> > more with a huge ecosystem like this, but the actual changes to the
> Modello
> > code gen appear to be surprisingly minor.
> >
> > Q: What about tooling, like IDEs, publishing to Maven Central & Maven
> > repositories, etc?
> > A: Many IDEs appear to have implemented validation logic on top of Maven
> > that currently will flag attributes as errors in a pom.xml. Those IDEs
> and
> > other tools would require updates to this validation logic. Because the
> > rendered pom.xml output remains the same publishing tool chains and Maven
> > repositories should be completely unaffected.
> >
> > Q: Any big issues you've identified?
> > A: Many sub-elements are not actually processed by Modello or Maven
> Model,
> > but are instead passed along to the plugin. For example, <configuration>
> > elements. It would be up to each of these projects to eventually allow
> for
> > attribute aliasing (or not). Maven projects that rely on Modello would
> have
> > the choice to adopt the new version and turn on the feature flag (or
> not).
> > It's possible that this would be confusing for some users - i.e. "why
> can I
> > declare dependencies with attributes but not configuration values"? That
> > said, I think it's manageable and would allow the ecosystem to slowly
> > update.
> > Q: Shouldn't we wait for Maven 5 to tackle this?
> > A: There's an issue going back to 2008 about the verbosity of pom.xml -
> > https://issues.apache.org/jira/browse/MNG-3397 - so... that's 12 years.
> > While writing this email, I just realized I commented on that issue back
> in
> > 2014. Any proposal to dramatically change the pom is going to be a *huge*
> > effort and is not at all what I'm proposing. This is literally the
> simplest
> > possible change I can think of that accomplishes the goal (dramatically
> > reducing the verbosity of the pom.xml) with the least possible impact to
> > the ecosystem. It's been twelve years. Maven 5 is years away.
> >
> > I know there is a voting system for changes to Maven, and this would be a
> > huge userland change. If there is even a soft exploratory "yes" I'm happy
> > to submit patches. Even better would be the assistance of an existing
> Maven
> > committer willing to help me navigate Apache requirements. If the
> feedback
> > is generally negative, that's fine too - I'll just go ahead and close the
> > issue. What I don't want to do is submit patches and then have everyone
> > yell at me. The Internet can be rough, you know.  :)
> >
> > I know this is a long email - thanks for reading, and looking forward to
> > feedback.
> >
> > Thanks,
> > -Will
> >
> > P.S. I've been tracking my research on this approach with this issue
> > https://issues.apache.org/jira/browse/MNG-7044, in case you are curious
> > about the research/additional links.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Allow attributes shorthand in pom.xml

Elliotte Rusty Harold
In reply to this post by Will Iverson
Hard no. While this might be a good idea if were we starting for
scratch—I have no opinion about that—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.

On Fri, Dec 11, 2020 at 10:40 PM Will Iverson <[hidden email]> wrote:

>
> One of the biggest complaints about Maven has long been the verbosity of
> the XML format. The verbosity is due in large part to the exclusive
> reliance on XML elements in Maven.
>
> Proposal: Allow Maven pom.xml to treat attributes as a short-hand for
> declaring configuration elements.
>
> Example: One of the most verbose sections of the pom for most projects is
> dependencies. A typical example:
>
> <dependency>
> <groupId>commons-io</groupId>
> <artifactId>commons-io</artifactId>
> <version>2.8.0</version>
> </dependency>
>
> Here is the same declaration expressed with attribute shortcuts:
>
> <dependency groupId="commons-io" artifactId="commons-io" version="2.8.0" />
> That's an 80% reduction in LoC, and would make Maven comparable with other
> popular build tools (e.g. compare and contrast with other build tools at
> https://mvnrepository.com/artifact/commons-io/commons-io/2.8.0)
>
> REQUEST: Feedback on if this is something to pursue. I've done some
> research, happy to submit patches, but don't want to pursue if there is
> either a) technical reason[s] not to proceed I'm not aware of or b) a lack
> of enthusiasm for the entire idea from the community.
>
> Basically, I'm looking for some feedback along the lines of a) love it -
> please submit patches so we can check it out, b) huh, maybe, willing to
> look at it, or c) this is a terrible idea, because X. Effectively, a
> totally non-binding vote on if this is worth exploring.
>
> I've discussed this with others online and done some research, so are a few
> answers to objections/Qs as I currently understand. I may be
> wrong/uninformed about certain aspects, which would be very helpful
> feedback.
>
> Q: Won't this require a new Maven XSD to be generated?
> A: No. The current Maven XSD declares many elements, but is not actually
> involved in validation. While the current XSD is valuable for tools and
> documentation, it does not actually perform validation.
>
> Q: Wait, so what actually does the validation?
> A: It's all done in Java code generated by Modello. The maven-model project
> (https://github.com/apache/maven/tree/maven-3.6.3/maven-model) relies on
> the Modello Maven Plugin (
> http://codehaus-plexus.github.io/modello/modello-maven-plugin/) which in
> turn relies on Modello core (http://codehaus-plexus.github.io/modello/) to
> generate the Java code that processes the pom.xml
>
> The proposal is to submit a patch for Modello that would allow the
> generated source to accept an attribute as an alias for input. If it's a
> valid element per the Maven maven.mdo file (
> https://github.com/apache/maven/blob/maven-3.6.3/maven-model/src/main/mdo/maven.mdo)
> it will now accept an attribute as a shortcut.
>
> Q: Wouldn't this break, like, everything?
> A: It would only affect pom.xml files that are read at runtime. All emitted
> pom.xml files would remain exactly the same.
>
> Q: Does this involve changing or rewriting the user's pom.xml? Isn't that
> the thing that's making it hard to support alternative formats for pom.xml
> like polyglot poms, etc?
> A: Nope, the pom.xml on disk is still the pom.xml. A
> <prerequisites><maven>X.X.X<maven></prerequisites> would be the only flag
> recommended to declare that a pom.xml uses attributes for shorthand.
>
> Q: How much work is this to actually implement?
> A: It starts with a few lines added to the Modello code generation to allow
> for attribute aliasing with a feature flag. Testing those changes through
> the rest of the dependency chain. Adding test cases throughout.
> Documentation. although as "now you can use attributes" is conceptually
> simple it's not too bad. Tools in the Maven ecosystem would be able to
> indicate they have been updated to support this by referring to the simple
> term, "attribute shortcuts". Because nothing else changes, the only real
> documentation change would be "things that were elements can also be
> declared as attributes." The trickiest part is probably sorting out how to
> manage the feature flag across the various components. I'm sure there's
> more with a huge ecosystem like this, but the actual changes to the Modello
> code gen appear to be surprisingly minor.
>
> Q: What about tooling, like IDEs, publishing to Maven Central & Maven
> repositories, etc?
> A: Many IDEs appear to have implemented validation logic on top of Maven
> that currently will flag attributes as errors in a pom.xml. Those IDEs and
> other tools would require updates to this validation logic. Because the
> rendered pom.xml output remains the same publishing tool chains and Maven
> repositories should be completely unaffected.
>
> Q: Any big issues you've identified?
> A: Many sub-elements are not actually processed by Modello or Maven Model,
> but are instead passed along to the plugin. For example, <configuration>
> elements. It would be up to each of these projects to eventually allow for
> attribute aliasing (or not). Maven projects that rely on Modello would have
> the choice to adopt the new version and turn on the feature flag (or not).
> It's possible that this would be confusing for some users - i.e. "why can I
> declare dependencies with attributes but not configuration values"? That
> said, I think it's manageable and would allow the ecosystem to slowly
> update.
> Q: Shouldn't we wait for Maven 5 to tackle this?
> A: There's an issue going back to 2008 about the verbosity of pom.xml -
> https://issues.apache.org/jira/browse/MNG-3397 - so... that's 12 years.
> While writing this email, I just realized I commented on that issue back in
> 2014. Any proposal to dramatically change the pom is going to be a *huge*
> effort and is not at all what I'm proposing. This is literally the simplest
> possible change I can think of that accomplishes the goal (dramatically
> reducing the verbosity of the pom.xml) with the least possible impact to
> the ecosystem. It's been twelve years. Maven 5 is years away.
>
> I know there is a voting system for changes to Maven, and this would be a
> huge userland change. If there is even a soft exploratory "yes" I'm happy
> to submit patches. Even better would be the assistance of an existing Maven
> committer willing to help me navigate Apache requirements. If the feedback
> is generally negative, that's fine too - I'll just go ahead and close the
> issue. What I don't want to do is submit patches and then have everyone
> yell at me. The Internet can be rough, you know.  :)
>
> I know this is a long email - thanks for reading, and looking forward to
> feedback.
>
> Thanks,
> -Will
>
> P.S. I've been tracking my research on this approach with this issue
> https://issues.apache.org/jira/browse/MNG-7044, in case you are curious
> about the research/additional links.



--
Elliotte Rusty Harold
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: AW: [DISCUSS] Allow attributes shorthand in pom.xml

Karl Heinz Marbaise-3
In reply to this post by Will Iverson
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:

<plugin>
   ...
   <configuration>
   ...
   </configuration>
</plugin>

The issue here is the "<configuration>...</configuration>" 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
> <[hidden email]> 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 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 <
>> [hidden email]> wrote:
>>
>>   On Sat, Dec 12, 2020 at 6:53 AM Robert Scholte <[hidden email]>
>> 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 <[hidden email]> 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:[hidden email]]
>>> Gesendet: Freitag, 11. Dezember 2020 23:40
>>> An: [hidden email]
>>> 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 version and turn on the feature flag (or
>> not).
>>> It's possible that this would be confusing for some users - i.e. "why
>> can I
>>> declare dependencies with attributes but not configuration values"? That
>>> said, I think it's manageable and would allow the ecosystem to slowly
>>> update.
>>> Q: Shouldn't we wait for Maven 5 to tackle this?
>>> A: There's an issue going back to 2008 about the verbosity of pom.xml -
>>> https://issues.apache.org/jira/browse/MNG-3397 - so... that's 12 years.
>>> While writing this email, I just realized I commented on that issue back
>> in
>>> 2014. Any proposal to dramatically change the pom is going to be a *huge*
>>> effort and is not at all what I'm proposing. This is literally the
>> simplest
>>> possible change I can think of that accomplishes the goal (dramatically
>>> reducing the verbosity of the pom.xml) with the least possible impact to
>>> the ecosystem. It's been twelve years. Maven 5 is years away.
>>>
>>> I know there is a voting system for changes to Maven, and this would be a
>>> huge userland change. If there is even a soft exploratory "yes" I'm happy
>>> to submit patches. Even better would be the assistance of an existing
>> Maven
>>> committer willing to help me navigate Apache requirements. If the
>> feedback
>>> is generally negative, that's fine too - I'll just go ahead and close the
>>> issue. What I don't want to do is submit patches and then have everyone
>>> yell at me. The Internet can be rough, you know. :)
>>>
>>> I know this is a long email - thanks for reading, and looking forward to
>>> feedback.
>>>
>>> Thanks,
>>> -Will
>>>
>>> P.S. I've been tracking my research on this approach with this issue
>>> https://issues.apache.org/jira/browse/MNG-7044, in case you are curious
>>> about the research/additional links.
>>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Allow attributes shorthand in pom.xml

Bernd Eckenfels
In reply to this post by Will Iverson
Hello,

Having includes in a format might be handy, but it does not fit the philosophy of maven of having a repeatable declarative style. If you need such modularity and imperative style you might be better off using gradle or simple pipeline scripts.

(With derived published POMs and changes like profiles and plugins not fitting into this it might have eroded over time, but coming from ANT I still value convention/declaration over imperative style - so every time I wish maven would be more open I remeber those times and I am reconsider if the task I have is suited for a maven Pom (after all its project model not build script)

BTW i abstain from commenting on your tone since we are all passionate about our experiences, it does trigger me to add this footnote, however.

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: Hunter C Payne <[hidden email]>
Gesendet: Saturday, December 12, 2020 8:02:15 PM
An: Maven Developers List <[hidden email]>
Betreff: 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 <[hidden email]> wrote:

 On Sat, Dec 12, 2020 at 6:53 AM Robert Scholte <[hidden email]> 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 <[hidden email]> 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:[hidden email]]
> Gesendet: Freitag, 11. Dezember 2020 23:40
> An: [hidden email]
> 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 version and turn on the feature flag (or not).
> It's possible that this would be confusing for some users - i.e. "why can I
> declare dependencies with attributes but not configuration values"? That
> said, I think it's manageable and would allow the ecosystem to slowly
> update.
> Q: Shouldn't we wait for Maven 5 to tackle this?
> A: There's an issue going back to 2008 about the verbosity of pom.xml -
> https://issues.apache.org/jira/browse/MNG-3397 - so... that's 12 years.
> While writing this email, I just realized I commented on that issue back in
> 2014. Any proposal to dramatically change the pom is going to be a *huge*
> effort and is not at all what I'm proposing. This is literally the simplest
> possible change I can think of that accomplishes the goal (dramatically
> reducing the verbosity of the pom.xml) with the least possible impact to
> the ecosystem. It's been twelve years. Maven 5 is years away.
>
> I know there is a voting system for changes to Maven, and this would be a
> huge userland change. If there is even a soft exploratory "yes" I'm happy
> to submit patches. Even better would be the assistance of an existing Maven
> committer willing to help me navigate Apache requirements. If the feedback
> is generally negative, that's fine too - I'll just go ahead and close the
> issue. What I don't want to do is submit patches and then have everyone
> yell at me. The Internet can be rough, you know. :)
>
> I know this is a long email - thanks for reading, and looking forward to
> feedback.
>
> Thanks,
> -Will
>
> P.S. I've been tracking my research on this approach with this issue
> https://issues.apache.org/jira/browse/MNG-7044, in case you are curious
> about the research/additional links.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Allow attributes shorthand in pom.xml

Will Iverson
TBH, the notion that the build script (whatever the tool) is just copied
wholesale into a published artifact is a little weird. That's part of what
threw me off - I think that our CI system may have been using
help:effective-pom to add a copy of the rendered pom into the CI reporting,
but I may be misremembering. That was twelve years ago, so...  ::shrug::

Restating the above, with the pom.xml being used for several very different
things, including (but not limited to):

a) a build script
b) artifact descriptor for published libraries, plugins, tools, etc. with
(per mvnrepository.com) 18.5 million artifacts (!)
c) audit tool for builds
d) defacto integration point with IDEs

...it's not surprising it's hard to change things. Both of the statements
"the build script is too verbose" and "there are 18.5 million artifacts and
we can't break repository tools" are perfectly valid.

Until the build script is decoupled from the publishing artifact (the
purpose of the build/consumer) it appears that updates to pom.xml as a
build script are going to be essentially impossible. Unfortunately, it
looks like there's a lot of work to be done to make that happen, not just
in Maven core but in plugins.

I'm not sure if Maven offers an API for tooling to isolate IDEs from file
format changes. Right now an open bug with Intelli/J that I've run into (
https://youtrack.jetbrains.com/issue/IDEA-246963) appears to be related to
Maven bootstrapping in Intelli/J involving parsing Maven output, which... :/

As a BTW, I've used repeatable builds as a cornerstone of development
everywhere for over a decade now. As long as you have a decent commitment
to SCM (ok, pun intended) and a tool like Maven it's not that hard. Truth
for our builds has always been whatever the command-line and CI builds do,
which as a side-effect also has meant that devs can use whatever IDE they
want as long as they respect CI.

FWIW, when working with devs new to the eco-system I usually explain that
the pom.xml is just an industry standard project file format supported by
all the various IDEs, and that by sticking with that we get both
command-line and IDE support. That usually is enough to make them ok with
it. I used to have a training video I recorded where I would cover the
basics in ~30 minutes. Comparing and contrasting the default lifecycle in
Maven vs the magic of Gradle and how much Maven could do for free. I've
worked with make, Ant, Unity, Gradle, Play SBT, msbuild, and Node.js/npm
(among others), and after all that time Maven is still the most solid IMHO.


On Sun, Dec 13, 2020 at 8:05 PM Hunter C Payne
<[hidden email]> wrote:

>  I'm very glad you get some use out of reproducible builds.  Especially
> given the amount of work it seems to take (seems like ~1 out of every 3
> emails is about this).  And you are right about my co-workers (pity me).
> But perhaps you are not appreciating the scale of the problem.  Maven is
> losing an entire generation of devs right now for a very silly reason.
> Don't dismiss it as just a grumble when it is so commonly heard.
>
> The issues with XML are more than just attributes.  It is also how lists
> and maps work in XML.  And gaining a simpler abstraction mechanism is just
> a optional bonus (the includes in HOCON).
>
> Who really cares what format the users/devs write the POM in?  It doesn't
> have to effect the Maven devs nearly as much as breaking the venerable POM
> XML format would.  Let the computers translate from one format to another.
> If users want to write their POMs in HOCON or JSON (or even, ick YAML) does
> it really matter as long as Maven can translate the POM into XML or the
> Maven internal POM data structures?  Its not like the internals of Maven
> are dependent upon the POM being written in XML anyway (yea abstraction).
> The IDEs/tools can still use the translated XML POMs.
>
> It is much better than breaking the POM format which is the current
> proposal.  In my opinion the original proposal of using XML attributes is
> putting a band-aid on a broken leg.  Seems like supporting other POM
> formats is less work for more win to me.  Especially since working POM
> conversion implementations already exist.
> > You mention that 12 line SBT build - that’s great, but the moment you
> need to deviate from something normal - it can deviate quite quickly IMHO.
> It doesn't have to.
>
> Hunter
>     On Sunday, December 13, 2020, 5:01:33 PM PST, Mark Derricutt <
> [hidden email]> wrote:
>
>  Spoken just like someone who deals with people from high school in 2005.
>
> I certainly care about reproducible builds - maybe not to the level of
> some, but when working on projects that span multiple years, have multiple
> deployments in different data centres for different customers, with
> different versions deployed - that all need to be able to be maintained.
>
> Being able to check out the version of the project that would deployed 2
> years ago, and rebuild it with the exact same packages and get the same
> build back - makes patching so much easier.
>
> With a project made up on around 90 repos/artifacts ( non multi module - so
> different releasee cadences across the board ), being able to check out
> that old version - build it, reproduce the problem, patch one, maybe two
> modules, and rebuild the platform for distribution with the minimum of
> surface area change possible - for that patch release - and being able to
> do that without major issue, in a short period of time - is a god send.
>
> Sure, it MAY incur some upfront and ongoing costs - but the pay off, when
> needed - is wonderful.
>
> the level of frustration people have with Maven and its enthrallment with
> XML at this point
>
> I see a lot of folk grumble about XML, or mostly - the over use of elements
> vs attributes, however, knowing that *everything* is an element (config
> aside in a few plugins) is also a godsend for both tooling, and
> consistency.
>
> I see far more people grumble about Gradle’s blend of DSL and Groovy
> programming, and the dark majick that obscures where one changes from the
> other ( I believe this is mitigated largely with the Kotlin DSL ).
>
> You won’t have to look far to find someone, even those on the dev team who
> don’t agree that the POM needs to change - but adoption, and usage is now
> far far *beyond* merely just “Apache Maven” itself - so it’s not the
> easiest thing to change.
>
> You mention that 12 line SBT build - that’s great, but the moment you need
> to deviate from something normal - it can deviate quite quickly IMHO.
>
>
>
>
> From: Hunter C Payne <[hidden email]>
> <[hidden email]>
> Reply: Maven Developers List <[hidden email]> <[hidden email]>
> Date: 14 December 2020 at 10:06:25 AM
> To: Maven Developers List <[hidden email]> <[hidden email]>
> Subject:  Re: [DISCUSS] Allow attributes shorthand in pom.xml
>
> Hunter PS I've never even heard someone want a repeatable build.  I have no
> idea why that would even be that desirable.