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 <
garydgreg...@gmail.com> wrote:
On Sat, Dec 12, 2020 at 6:53 AM Robert Scholte <rfscho...@apache.org>
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 <mar...@headcrashing.eu> wrote:
Wouldn't it be a more modern and even more effective approach to add JSON
support for POMs? We could keep POM.xml for legacy reasons but add
support
for POM.json files.
-Markus
-----Ursprüngliche Nachricht-----
Von: Will Iverson [mailto:wiver...@gmail.com]
Gesendet: Freitag, 11. Dezember 2020 23:40
An: dev@maven.apache.org
Betreff: [DISCUSS] Allow attributes shorthand in pom.xml
One of the biggest complaints about Maven has long been the verbosity of
the XML format. The verbosity is due in large part to the exclusive
reliance on XML elements in Maven.
Proposal: Allow Maven pom.xml to treat attributes as a short-hand for
declaring configuration elements.
Example: One of the most verbose sections of the pom for most projects is
dependencies. A typical example:
commons-io
commons-io
2.8.0
Here is the same declaration expressed with attribute shortcuts:
That's an 80% reduction in LoC, and would make Maven comparable with
other
popular build tools (e.g. compare and contrast with other build tools at
https://mvnrepository.com/artifact/commons-io/commons-io/2.8.0)
REQUEST: Feedback on if this is something to pursue. I've done some
research, happy to submit patches, but don't want to pursue if there is
either a) technical reason[s] not to proceed I'm not aware of or b) a
lack
of enthusiasm for the entire idea from the community.
Basically, I'm looking for some feedback along the lines of a) love it -
please submit patches so we can check it out, b) huh, maybe, willing to
look at it, or c) this is a terrible idea, because X. Effectively, a
totally non-binding vote on if this is worth exploring.
I've discussed this with others online and done some research, so are a
few
answers to objections/Qs as I currently understand. I may be
wrong/uninformed about certain aspects, which would be very helpful
feedback.
Q: Won't this require a new Maven XSD to be generated?
A: No. The current Maven XSD declares many elements, but is not actually
involved in validation. While the current XSD is valuable for tools and
documentation, it does not actually perform validation.
Q: Wait, so what actually does the validation?
A: It's all done in Java code generated by Modello. The maven-model
project
(https://github.com/apache/maven/tree/maven-3.6.3/maven-model) relies on
the Modello Maven Plugin (
http://codehaus-plexus.github.io/modello/modello-maven-plugin/) which in
turn relies on Modello core (http://codehaus-plexus.github.io/modello/)
to
generate the Java code that processes the pom.xml
The proposal is to submit a patch for Modello that would allow the
generated source to accept an attribute as an alias for input. If it's a
valid element per the Maven maven.mdo file (
https://github.com/apache/maven/blob/maven-3.6.3/maven-model/src/main/mdo/maven.mdo
)
it will now accept an attribute as a shortcut.
Q: Wouldn't this break, like, everything?
A: It would only affect pom.xml files that are read at runtime. All
emitted
pom.xml files would remain exactly the same.
Q: Does this involve changing or rewriting the user's pom.xml? Isn't that
the thing that's making it hard to support alternative formats for
pom.xml
like polyglot poms, etc?
A: Nope, the pom.xml on disk is still the pom.xml. A
X.X.X would be the only flag
recommended to declare that a pom.xml uses attributes for shorthand.
Q: How much work is this to actually implement?
A: It starts with a few lines added to the Modello code generation to
allow
for attribute aliasing with a feature flag. Testing those changes through
the rest of the dependency chain. Adding test cases throughout.
Documentation. although as "now you can use attributes" is conceptually
simple it's not too bad. Tools in the Maven ecosystem would be able to
indicate they have been updated to support this by referring to the
simple
term, "attribute shortcuts". Because nothing else changes, the only real
documentation change would be "things that were elements can also be
declared as attributes." The trickiest part is probably sorting out how
to
manage the feature flag across the various 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.
