Re: HOCON support (was Re: Question - JDK Minimum of future Apache Maven 4.0.0)

[Benjamin Marwell]

Big +1 for an alternative format, but not sure HOCON is the best of all
those out there.
It surely is one of the better ones, though.

Big plus is easiness to humans, no deps, external docs.

However, TOML gained some popularity.  I'd say Maven should ship no more
than one alternative to XML. And while HOCON is a great candidate, so is
TOML. TOML is much easier to parse.

But HOCON is good for me, too. I just hope completion support / markup /
schema is a thing. Otherwise maintaining the pom documents could be a
little cumbersome.

All in all, +1 to what Romain said.

Am Mi., 7. Juni 2023 um 18:02 Uhr schrieb Guillaume Nodet :

> 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
>  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  > .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
> > >  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  a
> > > écrit
> > > > :
> > > >
> > > 

Re: HOCON support (was Re: Question - JDK Minimum of future Apache Maven 4.0.0)

[Romain Manni-Bucau]

Fully got it Hunter...but this has the same yaml pitfall: designed for
human, not embraced as much as planned (thanks k8s to showed it)...you
would also note that all that is doable in xml so question remains: how
much do we want to break our ecosystem?
Personally I'd love the main core descriptor to not break much at least for
deps (i care less about plugins but idea does since it parses the conf).

What about a hvn which would be a graalvm launcher rewriting the pom and
delegating to contextual mvn? Sounds like a way to make everyone happy and
cache the core entrypoint (pom.xml) without having to enable untested code
in our descriptor (what yaml/hocon does).

Le mer. 7 juin 2023 à 19:47, Hunter C Payne
 a écrit :

>  I can answer the question about why HOCON.  1) it has nice syntax, 2) you
> can use values in any part, in any other part which means you don't have to
> write the plugin name's 3 or 4 times unnecessarily (which you can do only
> with properties currently) and 3) because you can include external
> documents which can by updated by plugin providers upstream.  Think
> archetypes but dynamically updated.  This means users typically include a
> HOCON file from the plugin provider and set a couple of properties instead
> of writing plugin elements in XML.
>
> If we think of the existing POM DOM built by the XML parser as the
> interface, you can parse any (tree config) format into that POM DOM (that's
> fun to say).  If that doesn't work, instead you can translate other formats
> into XML.  Either works and if necessary you can work around plugins that
> reparse XML.
> Finally, for users to use a new format, they have to know it exists.  I
> doubt too many folks knew about the polyglot feature.  Someone on this list
> had to tell the rest of us about it and I imagine the folks on this list
> know more about Maven than anyone else.  For this to matter, it has to be
> part of the Maven 4 release PR.  Then it creates discussion in the wider
> community and hopefully that should help bring in younger users and devs.
> That's the ultimate goal.  At the very least, it gets rid of the negative
> reaction younger devs have to XML from Maven.
>
> Hunter
> On Wednesday, June 7, 2023 at 10:23:12 AM PDT, Romain Manni-Bucau <
> rmannibu...@gmail.com> wrote:
>
>  Dead by its usage by end users, was abandonned years ago by its dzv, then
> reudated then re etc.didnt say nobody uses it, just it is not sane for
> us probably to absorb such project.
>
> Issue with conversion the one mentionned: you need to run anything before
> loading it, -1 if an ide or any tool cant parse the descriptor straight.
>
> Also means such solution is a side project and not maven built in feature
> (like a launcher wrapper like gm).
>
> Last: why hocon, it is good but has its own pitfall and first one being a
> low adoption compared to others and user requests.
>
> Do overall Im interested in such a feature but should likely be made
> outside maven as a bridge tool to keep everytool happy, we must not assume
> everybody starts using a mvn project with mvn cli, it is likely not that
> accurate IMHO.
>
> Le mer. 7 juin 2023 à 18:24, Christoph Läubrich  a
> écrit :
>
> > 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
> > > 

Re: HOCON support (was Re: Question - JDK Minimum of future Apache Maven 4.0.0)

[Hunter C Payne]

 I can answer the question about why HOCON.  1) it has nice syntax, 2) you can 
use values in any part, in any other part which means you don't have to write 
the plugin name's 3 or 4 times unnecessarily (which you can do only with 
properties currently) and 3) because you can include external documents which 
can by updated by plugin providers upstream.  Think archetypes but dynamically 
updated.  This means users typically include a HOCON file from the plugin 
provider and set a couple of properties instead of writing plugin elements in 
XML.

If we think of the existing POM DOM built by the XML parser as the interface, 
you can parse any (tree config) format into that POM DOM (that's fun to say).  
If that doesn't work, instead you can translate other formats into XML.  Either 
works and if necessary you can work around plugins that reparse XML.
Finally, for users to use a new format, they have to know it exists.  I doubt 
too many folks knew about the polyglot feature.  Someone on this list had to 
tell the rest of us about it and I imagine the folks on this list know more 
about Maven than anyone else.  For this to matter, it has to be part of the 
Maven 4 release PR.  Then it creates discussion in the wider community and 
hopefully that should help bring in younger users and devs.  That's the 
ultimate goal.  At the very least, it gets rid of the negative reaction younger 
devs have to XML from Maven.

Hunter
On Wednesday, June 7, 2023 at 10:23:12 AM PDT, Romain Manni-Bucau 
 wrote:  
 
 Dead by its usage by end users, was abandonned years ago by its dzv, then
reudated then re etc.didnt say nobody uses it, just it is not sane for
us probably to absorb such project.

Issue with conversion the one mentionned: you need to run anything before
loading it, -1 if an ide or any tool cant parse the descriptor straight.

Also means such solution is a side project and not maven built in feature
(like a launcher wrapper like gm).

Last: why hocon, it is good but has its own pitfall and first one being a
low adoption compared to others and user requests.

Do overall Im interested in such a feature but should likely be made
outside maven as a bridge tool to keep everytool happy, we must not assume
everybody starts using a mvn project with mvn cli, it is likely not that
accurate IMHO.

Le mer. 7 juin 2023 à 18:24, Christoph Läubrich  a
écrit :

> 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  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mer. 7 juin 2023 à 18:02, Guillaume Nodet  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 

Re: HOCON support (was Re: Question - JDK Minimum of future Apache Maven 4.0.0)

[Romain Manni-Bucau]

Le mer. 7 juin 2023 à 19:24, Guillaume Nodet  a écrit :

> Mmh ,thé XML has not been really modified since maven 3.0, so I think it's
> quite stable now :-)
>

Im happy with that Guillaume but would mean we dont add all the
attributes/tags you want - this is the part I'd like to stabilize, how we
can release a new version with each mvn release without breaking the world.
We have the pipeline but didnt test it much but Im confident your work will
make it validated within 3-4 releases.



> Le mer. 7 juin 2023, 18:06, Romain Manni-Bucau  a
> écrit :
>
> > 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  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mer. 7 juin 2023 à 18:02, Guillaume Nodet  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
> > >  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  > > > .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 

Re: HOCON support (was Re: Question - JDK Minimum of future Apache Maven 4.0.0)

[Guillaume Nodet]

Mmh ,thé XML has not been really modified since maven 3.0, so I think it's
quite stable now :-)

Le mer. 7 juin 2023, 18:06, Romain Manni-Bucau  a
écrit :

> 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  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 7 juin 2023 à 18:02, Guillaume Nodet  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
> >  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  > > .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.
> > > >
> > > 

Re: HOCON support (was Re: Question - JDK Minimum of future Apache Maven 4.0.0)

[Romain Manni-Bucau]

Dead by its usage by end users, was abandonned years ago by its dzv, then
reudated then re etc.didnt say nobody uses it, just it is not sane for
us probably to absorb such project.

Issue with conversion the one mentionned: you need to run anything before
loading it, -1 if an ide or any tool cant parse the descriptor straight.

Also means such solution is a side project and not maven built in feature
(like a launcher wrapper like gm).

Last: why hocon, it is good but has its own pitfall and first one being a
low adoption compared to others and user requests.

Do overall Im interested in such a feature but should likely be made
outside maven as a bridge tool to keep everytool happy, we must not assume
everybody starts using a mvn project with mvn cli, it is likely not that
accurate IMHO.

Le mer. 7 juin 2023 à 18:24, Christoph Läubrich  a
écrit :

> 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  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mer. 7 juin 2023 à 18:02, Guillaume Nodet  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
> >>  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 

Re: HOCON support (was Re: Question - JDK Minimum of future Apache Maven 4.0.0)

[Christoph Läubrich]

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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 7 juin 2023 à 18:02, Guillaume Nodet  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
 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 
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, 

Re: HOCON support (was Re: Question - JDK Minimum of future Apache Maven 4.0.0)

[Hunter C Payne]

 So perhaps it is easier to translate other formats to XML instead of adding 
support directly to the main code.  My idea wasn't so much to replace XML, 
rather it was to translate other formats to XML and then use the existing XML 
implementations.  I think that makes the work easier without impacting 
downstream plugins.
Hunter

On Wednesday, June 7, 2023 at 09:05:57 AM PDT, Romain Manni-Bucau 
 wrote:  
 
 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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 7 juin 2023 à 18:02, Guillaume Nodet  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
>  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  > .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.

Re: HOCON support (was Re: Question - JDK Minimum of future Apache Maven 4.0.0)

[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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 7 juin 2023 à 18:02, Guillaume Nodet  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
>  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  > .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
> > >  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, 

HOCON support (was Re: Question - JDK Minimum of future Apache Maven 4.0.0)

[Guillaume Nodet]

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
 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  .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
> >  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  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

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Aleksandar Kurtakov]

On Tue, Jun 6, 2023 at 7:52 PM Romain Manni-Bucau 
wrote:

> So are we in "I see it as somebody forcing me to move forward" vs "I see it
> as the project attraction decreasing and the community misbehaving"?
>
> Any way we find a compromise or should we just vote and be it?
>

With my Eclipse PMC hat on I can only assure you that voting (binding
votes!) is the only thing that works in such cases as whatever people say
these discussions never end up technological but rather
philosophical/ethical/etc. aka anything but technological and it's normal
when we speak about widely used projects as the types of technology they
are used for by different entities quite often have nothing else in common.
The longer such discussions go the more bitterness spreads, getting more
people nervous, insulted etc. At the first sign of these things I just call
a vote to be done with it before the cancer spreads. Asking the most vocal
ones of each camp to write a short paragraph explaining why their option is
best.
I really hope that this experience from another community helps Maven too.



>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mar. 6 juin 2023 à 18:32, Michael Osipov  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!
> >
> >
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hervé Boutemy]

Le mardi 6 juin 2023, 20:19:23 CEST Guillaume Nodet a écrit :
> 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.
good point, thanks for adding that one

> 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.
yes, working on toolchains ease of use is to me a good way to prepare for the 
move

and as I said also plugin prerequisites history is another

I recently saw https://issues.apache.org/jira/browse/MNG-7566 that I 
overlooked: I think that this improvement deserves being backported to Maven 
3.9

everything that will help users not able to upgrade better know how to deal 
with their setup is necessary to have the upgrade for the most up to date not 
kill our old installed base

with the current discussion and the different solutions identified, I may start 
to be convinced the move may become reasonable



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hervé Boutemy]

requirements history column has just been added to dist tool report:
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html

on 52 plugins we maintain, 3 have published prerequisites history to help users 
know what version to use when latest has too modern prerequisites

for people interested in helping us, you can see how to provide us a PR by 
looking at issues linked from https://issues.apache.org/jira/browse/MPLUGIN-400

PLEASE HELP US

Regards,

Hervé

Le mardi 6 juin 2023, 09:30:39 CEST Romain Manni-Bucau a écrit :
> @Hervé: was not really my point, more than forcing the maven version as
> plugins do also forces the java version so as soon as we decide for maven
> plugins are good. They can be compiled with java 8 and run on maven 3+4
> while API is stable or just maven 4 if not. For external plugins some are
> already compiled with java 11 only so will not run on java 8 builds even if
> 3.9 supports it so think this part is really good technically - agree with
> you in terms of doc we can be better but requires a lot of time and effort
> as you mentionned.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github 
> | LinkedIn  | Book
>  >
> Le mar. 6 juin 2023 à 09:11, Hervé Boutemy  a écrit :
> > you're right that we're currently talking about core, not plugins
> > 
> > but this question will inevitably extend from core to plugins, and there
> > are
> > much more plugin developers than core developers
> > 
> > then I think that getting a large view is useful
> > 
> > and honestly, now that I had the opportunity to do the summary and find
> > dist-
> > tool + DOCCK-38 improvements, I know how to continue to prepare the future
> > of
> > this JDK prerequisite question on plugins
> > 
> > I'll just need that people interested in upgrading JDK prerequisite help
> > doing
> > the hard documentation work required to make that move in a smooth way =
> > avoid
> > the "I only care about users who can use latest JDK" effect
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le mardi 6 juin 2023, 08:29:16 CEST Romain Manni-Bucau a écrit :
> > > Do we really care about plugins Hervé? They are compatible with some
> > 
> > maven
> > 
> > > versions so cover the underlying prerequisites, no?
> > > 
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > 
> > https://github.com/rmannibucau>
> > 
> > > | LinkedIn  | Book
> > > 
> > > <
> > 
> > https://www.packtpub.com/application-development/java-ee-8-high-performanc
> > e
> > 
> > > Le mar. 6 juin 2023 à 08:27, Hervé Boutemy  a
> > 
> > écrit :
> > > > > > notice that this will also impact all plugins: and given the few
> > 
> > work
> > 
> > > > done
> > > > 
> > > > > > on
> > > > > > plugins to clearly show what plugin version remains compatible
> > 
> > with a
> > 
> > > > JDK
> > > > 
> > > > > > release, I feel we're not taking the topic the right way
> > > > > 
> > > > > Can you detail it please? While we keep plugin-api java 8 compat -
> > 
> > which
> > 
> > > > is
> > > > 
> > > > > not under discussion there - there is no more impact than today
> > > > > normally.
> > > > 
> > > > currently, if you are still using JDK 7 or even earlier (not a shame,
> > 
> > just
> > 
> > > > a necessity), it's easy to select latest compatible Maven release:
> > > > https://maven.apache.org/docs/history.html
> > > > 
> > > > What about using latest compatible plugins?
> > > > It's where finding documentation starts to become hard:
> > > > 
> > > > - each plugin has it public documentation showing only the latest JDK
> > > > prerequisite
> > 
> > > > - our consolidated view itself is just known from experts only:
> > https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/jo
> > 
> > > > b/master/site/dist-tool-prerequisites.html
> > > > 
> > > > 
> > > > we added some time ago "System Requirements History" for that purpose
> > > > =
> > > > https://issues.apache.org/jira/browse/MPLUGIN-400
> > 
> > > > for example, once a plugin has documented its history, you get:
> > https://maven.apache.org/maven-release/maven-release-plugin/plugin-info.ht
> > 
> > > > ml#system-requirements
> > > > 
> > > > Every plugin should document its system requirements history
> > > > = we need to organise the work to make sure it's done in our own
> > 
> > plugins:
> > > > I did the job on a few ones, but it has to be generalised and I don't
> > 
> > see
> > 
> > > > anybody interested in doing the work (and I'm tired of doing myself
> > > > the
> > > > documentation cleanup on