Please note that Tycho uses polyglot very extensively (and develop it
actively), so please don't assume it is "dead" just because you are not
aware of its usages!
For me using XML or JSON or ... for THE SAME THING does not add much
value, but Tycho extends polyglot to the extend of deriving maven model
form existing meta-data files, ther fore you can use maven to build your
eclipse/osgi projects WITHOUT any form of POM (aka pomless build).
Example of "one configurator pom":
https://tycho.eclipseprojects.io/doc/master/StructuredBuild.html
Example of "completely pomless" (only requires an .mvn/extension.xml in
project root):
https://tycho.eclipseprojects.io/doc/master/BndBuild.html
Given that the only "maintain" in polyglot is to adapt to maven
(internal) changes if maven would just support out-of-the-box what today
is "polyglot-common" that would be great and everyone could then also
write the pom in whatever today-hype-text-encoding... and support even
more sophisticated cases like Tycho with little to no maintaining.
Am 07.06.23 um 18:05 schrieb Romain Manni-Bucau:
Maybe let's stabilize XML and ensure we can make it evolving properly in
time before supporting any other format which will impact negatively the
ecosystem IMHO since a lot of descriptor parsers are not org.apache.maven
(which is a very good thing IMHO, means we have a portable enough format to
be adopted).
Once we will tackle that support question I think the main point is which
formats do we want to maintain (support is not a big deal, maintaining is).
While I can envision xml and maybe json are no drama, any other one will
probably end as polyglot, kind of abandonned they restarted then
re-abandonned so from my window I don't see it as great for the community
("good bad idea" we sometimes say).
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 7 juin 2023 à 18:02, Guillaume Nodet <gno...@apache.org> a écrit :
A very rough cut at supporting HOCON is available at
https://github.com/gnodet/maven-hocon-extension. It currently requires
https://github.com/gnodet/maven/tree/polyglot (mainly to add the maven
model as an attached artifact during the build so that it can be consumed
by the hocon parser generator). The generated parser does not handle the
whole model yet, so it's very experimental (and an important part of it is
the plugin configuration which is... xml). A very simple parseable POM is
available at
https://github.com/gnodet/maven-hocon-extension/blob/main/src/it/simple/pom.conf
. If people are actually interested in that, we may be able to move it as
an official maven extension.
Note that takari-polyglot is broken with maven 4 and the above parser is
only for maven 4...
Anyway, I'm all for moving maven forward !
Guillaume
Le mer. 7 juin 2023 à 02:31, Hunter C Payne
<hunterpayne2...@yahoo.com.invalid> a écrit :
I completely agree that JSON is just reinventing the wheel. But that
seems irrelevant from a marketing perspective. And HOCON is actually
better than either JSON or XML. If your potential customers first
reaction
to Maven is 'ick XML' then it doesn't really matter if XML is better.
Just
my experience and opinion.
Hunter
On Tuesday, June 6, 2023 at 05:24:59 PM PDT, Gary Gregory <
garydgreg...@gmail.com> wrote:
Playing a bit of devil's advocate here: while I've not used it, there
is a
maven polyglot plugin that IIRC let's you author your POM in other
formats.
But yeah, XML can be a pain but XML Schema is super handy in tooling and
editors. In the meantime, JSON is just reinventing the wheel...
Gary
On Tue, Jun 6, 2023, 20:02 Hunter C Payne <hunterpayne2...@yahoo.com
.invalid>
wrote:
Sorry to be glib. I apologize. But I did have a point. The attitude
that Guillaume has about my emacs (which has been updated more recently
than either the JVM or your IDE) is exactly the same attitude I face
when I
try to get new users to use Maven. In the case of Maven, it is use of
XML
for the pom, in the case of emacs its all the weird key bindings (which
you
actually already know because of bash). I hope this actually helps.
Hunter
On Tuesday, June 6, 2023 at 04:42:10 PM PDT, Hunter C Payne <
hunterpayne2...@yahoo.com.invalid> wrote:
Ok, sonny...go back to using software I wrote to do your development.
Hunter
On Tuesday, June 6, 2023 at 03:47:56 PM PDT, Guillaume Nodet <
gno...@apache.org> wrote:
Sounds like the only really plausible answer ! So if they can stay
on a
runtime which is 10 years old, an editor which has been released nearly
38
years ago (well, not the latest version of course, but still...), why
can't
they stay on maven 3.9 which is a few months old ?
My proposal was to support critical bug fixes (i.e. security or no
work-around, but that can always be discussed) on the latest branches
supporting LTS JDK for some time..., so 3.x for JDK 8, 4.x for JDK 17
and
maybe 5.x for JDK 21 or 24 or whatever the LTS jdk would be at that
time.
That would be a change from what has been done for the past 15 years,
as
looking at history, I think 2.0.11 was the only micro version ever
released
after the next minor version.
Guillaume
Le mar. 6 juin 2023 à 23:05, Hunter C Payne
<hunterpayne2...@yahoo.com.invalid> a écrit :
emacs
Hunter
On Tuesday, June 6, 2023 at 11:19:43 AM PDT, Guillaume Nodet <
gno...@apache.org> wrote:
One question for people that want JDK 8 support. What IDE do they
use
to
develop ? Because none of the actual IDE is running JDK 8, though
they
can
be used by JDK 8, just like maven with toolchains.
So really, the argument does not really stand, but for the very
minority
of
devs still using emacs/vim.
It really comes down to ease of use (i.e. not having to use --release
flag
or to setup a toolchain) vs staying on JDK for 10 more years.
Le mar. 6 juin 2023 à 18:32, Michael Osipov <micha...@apache.org> a
écrit
:
Am 2023-06-06 um 07:42 schrieb Hervé Boutemy:
it's not about *one not wanting* to upgrade (anybody can use JDK
17
if
they want currently)
it's about *one forcing everybody else* to upgrade (and enter the
toolchain setup question)
EXACTLY!
--
------------------------
Guillaume Nodet
--
------------------------
Guillaume Nodet
--
------------------------
Guillaume Nodet
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
