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 <hunterpayne2...@yahoo.com.invalid> 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 < > m...@talios.com> 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 <hunterpayne2...@yahoo.com.invalid> > <hunterpayne2...@yahoo.com.invalid> > Reply: Maven Developers List <dev@maven.apache.org> <dev@maven.apache.org> > Date: 14 December 2020 at 10:06:25 AM > To: Maven Developers List <dev@maven.apache.org> <dev@maven.apache.org> > 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.
