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 <hunterpayne2...@yahoo.com.invalid> 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 <m...@laeubi-soft.de> 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 <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 > > > > >
