Re: [VOTE] Release Maven Shade Plugin 3.6.0
+1, thanks (small request: can the title "Drop plugin cruft" be rewritten to describe the issue in the changelog on jira?) 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 mar. 28 mai 2024 à 17:21, Tamás Cservenák a écrit : > Howdy, > > We solved 7 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12354611 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/projects/MSHADE/issues > > Staging repo: > https://repository.apache.org/content/repositories/maven-2134/ > > Source release checksum(s) SHA-512 : > > b0a31f02918329c466abd9c7b0c01bc7baeb0fbf8ef084212800c24b937d01495614fde43771689daec9160ef43bcd93c2d87a12dfe9d4e0fd926e190f28f797 > > Staging site: > https://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 >
Re: Maven 3.9.7 fails to activate profile?
you ask but you know it is gradle right ([1])? ;) It is the risk to drive the build descriptors by code, you can get conflicts using conventions not validating themselves in the build script. [1] https://github.com/openjdk/jfx/blob/master/build.gradle#L1674 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 mar. 28 mai 2024 à 16:53, Tamás Cservenák a écrit : > Howdy, > > well, after a quite long investigation we came to several conclusions: > * 3.9.6 and before worked really "by chance", as > * the POM is invalid > > https://repo.maven.apache.org/maven2/org/openjfx/javafx/21.0.3/javafx-21.0.3.pom > > It uses _same profile IDs for conflicting profies_ (as one can expect, > fields having "ID" in their name are supposed to be, well, "identifiers"). > > In fact, am unsure what produced this POM, as Maven cannot even grasp it > (refuses to load it even): > https://gist.github.com/cstamas/27b948306cddabd00105f747e744e2cd > > Thanks > T > > > On Mon, May 27, 2024 at 11:43 PM John Neffenger wrote: > > > Thank you for the quick response, Tamás. > > > > On 5/27/24 11:51 AM, Tamás Cservenák wrote: > > > Can you create a small reproducer, ideally shared on github or similar > > > service? > > > > This "Hello World" JavaFX project illustrates the problem for me: > > > >Hello JavaFX! > >https://github.com/jgneff/hello-javafx > > > > Just clone and build with: > > > >$ git clone https://github.com/jgneff/hello-javafx.git > >$ cd hello-javafx > >$ mvn clean package > > > > Thanks, > > John > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
Re: [VOTE] Release Apache Maven 3.9.7
Agree with Tamas, these are new minor features for the tool so a patch version is ok. That said, strictly speaking maven versioning is arbitrary.arbitrary.(last+1) so we respect our contract ;). Using semantic versioning would require use to have been in at least 6.x or 7.x due to the aggregation nature of maven so think we are good like that and it is saner to enable this kind of update than requiring them to create a ton of version branches which will never be maintained so it is a good trade off IMHO. 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. 22 mai 2024 à 23:32, Tamás Cservenák a écrit : > Hej Gary > > I agree, and TBH i moved MNG-8030 to "new feature", originally it was > improvement (and now would move it back). > > The -itr OTOH is "new feature" as in it makes really simple to ignore > "remote repositories introduced by transitive POMs" but you could achieve > similar effect with already existing features as well (but not so simple). > This, combined with RRF (remote repo filtering) is a killer feature. We > just wanted it out in the wild. > > My 5 cents > T > > On Wed, May 22, 2024, 22:50 Gary D. Gregory wrote: > > > Hi All: > > > > As a user, I don't expect 2 new features in a maintenance release. > > It would be nice to use semantic versioning to manage expectations. > > > > 2c & TY! > > Gary > > > > On 2024/05/22 10:09:20 Tamás Cservenák wrote: > > > Howdy, > > > > > > We solved 21 issues: > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12353964 > > > > > > There are still a couple of issues left in JIRA: > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved > > > > > > Staging repo: > > > https://repository.apache.org/content/repositories/maven-2125/ > > > > > > Dev dist directory (binary bundles updated): > > > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.7/ > > > > > > Source release checksums: > > > apache-maven-3.9.7-src.tar.gz.sha512 > > > > > > a3c211ce683afbde9c4becf8b32397d14d3e7d8e8261094da037dcf27a697a93134440e055e7a9e7e26af2db543d4d9c4e7b0296560f5193df7ba90b9a68d1d1 > > > > > > apache-maven-3.9.7-src.zip.sha512 > > > > > > cdd8249807e251d07c613a65120058993e47a4cbf7f6dbda8599c7ca7ab4ed3fedc727e651f43cba0e9b0d604055c1106c1243be64a1d52c5ddf72dbec5e65dc > > > > > > Staged site: > > > https://maven.apache.org/ref/3-LATEST/ > > > > > > Draft for release notes: > > > https://github.com/apache/maven-site/pull/521 > > > > > > Guide to testing staged releases: > > > http://maven.apache.org/guides/development/guide-testing-releases.html > > > > > > Vote open for 72h > > > > > > [ ] +1 > > > [ ] +0 > > > [ ] -1 > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
Re: [VOTE] Release Apache Maven 4.0.0-beta-3
For me we have the current "catch up" process == delete and rerun, nobody will have pulled it in a blocking fashion anyway and worse case it is flagged as beta/alpha so not as impacting as finals which are consumed from sources very quickly. Long term process is likely to push the tag on a personal (pmc) github fork and only after the vote push it upstream to be able to drop it without any impact for rerolls. +1 for this one (no regression on tested projects) but hope it is the last "burn" 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. 22 mai 2024 à 21:07, Guillaume Nodet a écrit : > The main (only ?) reason is that I always forget to create a branch before > releasing. > So master contains beta-2. Or should I rewrite history and force push ? Or > we’d end up with two commits for beta-1 (but a single tag obviously). > If we agree on a mechanism, we should update the release process > accordingly, as I’m blindly following it (hence I forget to create a > branch). > > Guillaume > > > Le mer. 22 mai 2024 à 20:32, Romain Manni-Bucau a > écrit : > > > Hi Guillaume, > > > > Why isnt it beta1 - I know but we shouldn't burn version even in > > alpha/beta, every time it makes noise we can't justify technically :(? > > > > 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. 22 mai 2024 à 17:12, Guillaume Nodet a > écrit : > > > > > This is a vote to release Apache Maven 4.0.0-beta-3, as I've cut > another > > > release to fix blocking issues found in beta-2. > > > > > > > > > We solved 25 issues: > > > > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12354634 > > > > > > There are still some issues in JIRA: > > > https://issues.apache.org/jira/projects/MNG/issues > > > > > > Release candidates: > > > https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-beta-3/ > > > > > > Staging repository: > > > https://repository.apache.org/content/repositories/maven-2126/ > > > > > > Source release SHA512: > > > - apache-maven-4.0.0-beta-3-src.zip > > > > > > > > > 4125acba32218e341b34c1bbe7700f5aa71947fd1a6a5d418825822099800e3b798a5300eaf711e0709866b7e5fc6fee323515af18d8ab25d7eaac034d72b1c6 > > > - apache-maven-4.0.0-beta-3-src.tar.gz > > > > > > > > > 8ca063a72fdacbcbe4afc33fc46e6c8920327092d11f3d8a77723ce995c3e24d1e8413cce3d5bc59a47657316834bfb9d4706d8bdffa5da5e147bcb404381808 > > > > > > Staging site: > > > https://maven.apache.org/ref/4-LATEST/ > > > > > > Guide to testing staged releases: > > > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > > > The vote is open for at least 72 hours. > > > > > > [ ] +1 > > > [ ] +0 > > > [ ] -1 > > > > > > -- > > > Guillaume Nodet > > > > > >
Re: [VOTE] Release Apache Maven 4.0.0-beta-3
Hi Guillaume, Why isnt it beta1 - I know but we shouldn't burn version even in alpha/beta, every time it makes noise we can't justify technically :(? 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. 22 mai 2024 à 17:12, Guillaume Nodet a écrit : > This is a vote to release Apache Maven 4.0.0-beta-3, as I've cut another > release to fix blocking issues found in beta-2. > > > We solved 25 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12354634 > > There are still some issues in JIRA: > https://issues.apache.org/jira/projects/MNG/issues > > Release candidates: > https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-beta-3/ > > Staging repository: > https://repository.apache.org/content/repositories/maven-2126/ > > Source release SHA512: > - apache-maven-4.0.0-beta-3-src.zip > > 4125acba32218e341b34c1bbe7700f5aa71947fd1a6a5d418825822099800e3b798a5300eaf711e0709866b7e5fc6fee323515af18d8ab25d7eaac034d72b1c6 > - apache-maven-4.0.0-beta-3-src.tar.gz > > 8ca063a72fdacbcbe4afc33fc46e6c8920327092d11f3d8a77723ce995c3e24d1e8413cce3d5bc59a47657316834bfb9d4706d8bdffa5da5e147bcb404381808 > > Staging site: > https://maven.apache.org/ref/4-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > The vote is open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -- > Guillaume Nodet >
Re: [VOTE] Release Apache Maven 3.9.7
+1 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. 22 mai 2024 à 17:38, dev a écrit : > tested on sevral projects, looks nice to me :) Good job. > > +1 (nb) > > Tony > > Le mer. 22 mai 2024 à 12:09:20 +0200, Tamás Cservenák > a écrit : > > Howdy, > > > > We solved 21 issues: > > < > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12353964 > > > > > > There are still a couple of issues left in JIRA: > > < > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved > > > > > > Staging repo: > > <https://repository.apache.org/content/repositories/maven-2125/> > > > > Dev dist directory (binary bundles updated): > > <https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.7/> > > > > Source release checksums: > > apache-maven-3.9.7-src.tar.gz.sha512 > > > a3c211ce683afbde9c4becf8b32397d14d3e7d8e8261094da037dcf27a697a93134440e055e7a9e7e26af2db543d4d9c4e7b0296560f5193df7ba90b9a68d1d1 > > > > apache-maven-3.9.7-src.zip.sha512 > > > cdd8249807e251d07c613a65120058993e47a4cbf7f6dbda8599c7ca7ab4ed3fedc727e651f43cba0e9b0d604055c1106c1243be64a1d52c5ddf72dbec5e65dc > > > > Staged site: > > <https://maven.apache.org/ref/3-LATEST/> > > > > Draft for release notes: > > <https://github.com/apache/maven-site/pull/521> > > > > Guide to testing staged releases: > > <http://maven.apache.org/guides/development/guide-testing-releases.html> > > > > Vote open for 72h > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > >
Re: [VOTE] Release Apache Maven Wrapper 3.3.2
+1 Le mar. 21 mai 2024 à 19:40, Manfred Moser a écrit : > Looks good! > > +1 > > On 2024-05-21 8:17 a.m., Tamás Cservenák wrote: > > Howdy, > > > > We solved 6 issues: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721=12354608 > > > > There are still a couple of issues left in JIRA: > > https://issues.apache.org/jira/projects/MWRAPPER/issues > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-2124/ > > > > Source release checksum SHA512: > > > 620d6945ad3a18cc80da52ad81af452524cf427b24adcff1a83ad77a0d0e72dd18825e2c5e4405e43babe8e6fd52e83cef58b10d39b55fa8a4bba9a7801d66a5 > > > > Staging site: > > https://maven.apache.org/wrapper-archives/wrapper-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for at least 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Apache Maven Build cache extension 1.2.0
+1, tested on a few projects (mvn 4 + java 17) 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 jeu. 9 mai 2024 à 02:43, Olivier Lamy a écrit : > Hi, > Vote for release of Apache Maven Build cache extension 1.2.0 > We fixed 9 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12324820=12353957 > > Staging repo: > https://repository.apache.org/content/repositories/maven-2114/ > Staged sources dist: > > https://repository.apache.org/content/repositories/maven-2114/org/apache/maven/extensions/maven-build-cache-extension/1.2.0/maven-build-cache-extension-1.2.0-source-release.zip > > sha512: > bc1a4b84c4f21a73964d8f65c3d37e372dfa8fc6d64e13db3f2d7ff2111485b41eb6bd24872626597070fd28cdcb55e0702cf9a2f106bedc7ec1483fbcd2aeb2 > > Staged website: > > https://maven.apache.org/extensions-archives/maven-build-cache-extension-LATEST/ > > Vote open for 72h > [+1] > [0] > [-1] > > Cheers > Olivier > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Road forward for: New flag to verify the status
1 or 2 (there are iso from an user perspective imho even if help plugins looks natural) Rather not 3 for me by design and to keep it light Maybe 5: external self contained tool (always better to check a soft cause if tool cant run your tool is useless: here if mvn doesnt run you cant check anything and if maven runs help plugin is 100% designed for such additional checks). Le jeu. 9 mai 2024 à 15:53, Maarten Mulders a écrit : > On 26/04/2024 15:11, Juul Hobert wrote: > > Hi, > > > > > > It's been a while since changes have been made to MNG-6869. It adds > helpful > > functionality that is particularly useful when you're on a company > network > > and want to do some basic checks to verify if Maven is working. This will > > be helpful for a large group of users and helps in solving basic issues > and > > therefore could reduce false issues being reported about "Maven not > > working". The pull request unsatisfyingly ended up in a discussion where > > three flavors came across: implement it in core, in a plugin or in an > > extension. > > > > > > In summary the following arguments apply to the three different flavors: > > > > > > Move it to a plugin > > > > + Does not introduce extra complexity in core > > > > - Needs additional downloads and could fail before the basic checks occur > > > > > > Move it to an extension > > > > + Does not introduce extra complexity in core > > > > - Requires additional installation steps before it can be used (we could > > consider to ship the extension with Maven to circumvent that) > > > > > > Put it in core > > > > + Works without requiring additional downloads / installation steps > > > > + Can do all basic checks > > > > > > > > I like to know how the community thinks about this, so please reply > briefly > > with the following if you have a opinion about it: > > > > - "1" for plugin > > > > - "2" for extension > > > > - "3" for core > > > > - "4" drop the idea, close the ticket > > > > > > > > I'm planning to work on it on the 10th of May and would like to continue > > working on it then. I would appreciate it if replies are given before > this > > date. > > > > > > > > Cheers > > > > > > Juul Hobert, > > > > also on behalf of Giovanni van der Schelde > > > > Hi, > > I think that having more troubleshooting capabilities for non-working > Maven installations would be very useful. So "4" is not an option for me. > > Given this purpose I feel that anything that doesn't ship with Maven by > default would defeat that goal. That drops "1" for me, and also "2" if > it had to be installed manually. > > So I would vote for "3", or for "2" iff that extension would be included > in the official Maven distribution. > > Thanks for your efforts, Juul & Giovanni! > > > Maarten > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [DISCUSS] MDK, a Maven Plugin SPI example
Well not sure what you didn't get from my mails but 1. I agree current solution does not need anything new if it was ambiguous 2. the mail you reference was for jreleaser outside maven so out of topic there IMHO If MDK does not need an external SPI I agree with you there is no new concept nor need of any maven thread since we don't change anything ;) 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 lun. 6 mai 2024 à 21:02, Tamás Cservenák a écrit : > > > > > > Well, for *existing* core component I don't see an issue to add a toggle > to > > say "deploy at end". > > What can be an issue there is only to make it global for the session and > > not per artifact + how to define "end" - agree onSessionClose can be too > > late but sure we can find a good "phase" (plain english not maven > phases). > > > > Which *existing* core component deploys today in Maven? > "At Maven Session end" (and no errors happened) is pretty good plain > english for me. > > > > > > I understand you only talk about artifact but makes years it is no more > > what maven trigger as deployment and we don't have much issue with > current > > solution but we have with combined ones and making it using a different > > lifecycle will make it even harder to handle, in particular with shared > > components where lifecycle is no more what is in the pom and therefore > you > > don't control it properly anymore from the pom. > > Feels like regressing 10 years ago in terms of solution covering for me. > > > > Nobody mentioned a different lifecycle, only you. > MDK is totally the opposite of what you write... > Current m-deploy-p solution (the one you consider "good") is unchanged > since Maven 2.x, so unsure what regressing you talk about. > To be precise, is unchanged since 18 years, so 10 years sounds quite good, > no? (a joke) > > > > I have no idea what you target with your block about sonatype, users are > > covered by sonatype (both solutions btw at the cost of some jvm.config > and > > deps for the oldest). > > > > Does not sound to me like what you say stands: > https://lists.apache.org/thread/6t95xpkgjpxooljf613xf1853qrfv7yq > > I don't feel "covered", sorry. Also, remember that (old) nx-staging-m-p > already broke once in Maven 3.9.x span. > > > > To be honest, today - and I never said it will not change ;), I don't > care > > much of MDK but more about adding a concept we don't need and which will > > create new issues in maven so let's try to use one of the existing > > solutions maybe before moving to building a new maven - or discuss > > rebuilding maven from scratch if that is the ultimate intent, if we break > > the compat rule a lot of things can change and concepts can be > > simplified+refined but AFAIK we are not in this mood, are we? > > > > > You do it again: which "new concept" is added exactly by MDK? > (as everything else works based on existing and proven patterns). > > T >
Re: [DISCUSS] MDK, a Maven Plugin SPI example
Well, for *existing* core component I don't see an issue to add a toggle to say "deploy at end". What can be an issue there is only to make it global for the session and not per artifact + how to define "end" - agree onSessionClose can be too late but sure we can find a good "phase" (plain english not maven phases). I understand you only talk about artifact but makes years it is no more what maven trigger as deployment and we don't have much issue with current solution but we have with combined ones and making it using a different lifecycle will make it even harder to handle, in particular with shared components where lifecycle is no more what is in the pom and therefore you don't control it properly anymore from the pom. Feels like regressing 10 years ago in terms of solution covering for me. I have no idea what you target with your block about sonatype, users are covered by sonatype (both solutions btw at the cost of some jvm.config and deps for the oldest). To be honest, today - and I never said it will not change ;), I don't care much of MDK but more about adding a concept we don't need and which will create new issues in maven so let's try to use one of the existing solutions maybe before moving to building a new maven - or discuss rebuilding maven from scratch if that is the ultimate intent, if we break the compat rule a lot of things can change and concepts can be simplified+refined but AFAIK we are not in this mood, are we? 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 lun. 6 mai 2024 à 20:41, Tamás Cservenák a écrit : > And few more things: > - my intent is to target BOTH, Maven3 and Maven4, as when Sonatype > deprecates OSS/S01 in favor of Central Portal, Maven3 (and currently also > Maven4) users are doomed to "roll their own" solutions for Central > publishing. While Sonatype Nx2 (running on Sonatype OSS/S01 and ASF repo) > can work to a certain degree with m-deploy-p (at the "cost" of logging in > to the UI, and pressing Close button on auto-created staging repository), > the new Central Portal will not work with it (as it seems from doco). IMHO, > we cannot leave Maven3 users behind, we cannot afford to leave Maven3 users > without any solution. > - MDK like solution could also provide support in cases like this (my next > task on radar): > https://lists.apache.org/thread/j3r4hvoonx6ftl8vlgs0fo4f2z9pmll5 > - and finally, nothing forces you to use MDK, obviously. If you publish OCI > images or beam up little green people with Maven, you do not have to use > it! Solution is opt-in, that IS one of the key points of MDK :) > > But to have ANY progress on ANY of this: > - the plugin SPIs needs to be created/released > - we need to use SPIs in plugins > - and only then we can provide seamless experience to our users > > > T > > > On Mon, May 6, 2024 at 8:24 PM Tamás Cservenák > wrote: > > > > >> If you don't need to create a new module nor any new interface in maven > >> core or a shared module I'm all for the change, otherwise it is a new > >> shared thing whatever you present it. > >> > > > > So, if we don't change anything, you accept the "change"? :) > > > > In short: MDK is just a "tech demo", but the "real stuff" is: > > * introduce SPIs for targeted o.a.m.p plugins (the proposed ones are > > deploy and gpg plugins) > > * modify o.a.m.p plugins to use SPI pattern (again, m-deploy-p and > m-gpg-p) > > * and from that moment on, we have an "open for all" game in play, as MDK > > becomes really 'just one' solution. > > In fact, IMHO it is the Maven project itself that should be the home of > > something like MDK. > > Again, MDK is "just a tech demo". > > > > > >> I understand what you mean but it is the case of the "current" solution. > >> We don't need a new module nor anything outside plugins scope. > >> The "do at end" on maven built-in components is even a pretty bad > example > >> cause it would be saner for the goal you describe to add a parameter on > >> maven components methods more than a new concept IMHO - concretely > enable > >> this feature in repositorySystem directly which is already shared by > >> design. > >> > > > > This is the case where I'd like to _improve the current solution_ (as > > opposed to "this is wh
Re: [DISCUSS] MDK, a Maven Plugin SPI example
Le lun. 6 mai 2024 à 19:40, Tamás Cservenák a écrit : > Howdy, > > inline. > > > Exactly...this is what will always happen with plugins and extensions. > > Indeed you can add a phase after plugins then you moved the issue to one > > more step but the issue is still *exactly* the same but in a new concept > > and layer, so literally no gain there. > > > > This is not a new concept at all, one of the main reasons a lifecycle > participant was added was exactly this, > and the Takari lifecycle did leverage it for years. Unsure why this is a > "new concept" for you. > If you don't need to create a new module nor any new interface in maven core or a shared module I'm all for the change, otherwise it is a new shared thing whatever you present it. > > > > > No issue there, you still control the reactor and therefore control the > > last module built after all others if you want - I use that for the > > documentation module of a 100+ modules project, so not an issue, you can > > always have your last module have m-d-p. > > > > > But that's the point! I don't want to author an Ant-like Maven build! > I don't want to fiddle with each nit. I don't want to "fit carefully" > sticks, tricks and hacks, build a house of cards or Jenga-build. > I don't want to modify my build to "make it work". I don't want to adapt > extra hoops and loops in my build "make it happen". > I don't want "smart" and "intelligent" solutions. I don't want to check out > a Maven project and spend time figuring out "how it works". > > I want simple wooden-wedge level solutions. I am in a "Dead Simple Maven > Builds" camp. > I understand what you mean but it is the case of the "current" solution. We don't need a new module nor anything outside plugins scope. The "do at end" on maven built-in components is even a pretty bad example cause it would be saner for the goal you describe to add a parameter on maven components methods more than a new concept IMHO - concretely enable this feature in repositorySystem directly which is already shared by design. As soon as you make a plugin "living" more than its execution you are no more "dead simple" and have a ton of edge cases as the one you mentionned which is a simple one where both cases can make sense (don't deploy if the test fail or let it be deployed - depends if you release or dev, close to "fail test at end"). If you take the deploy jar + oci container case, the recover case is not trivial, the "deploy at end" is just a broken concept by design and requires something different to recover. What I mean is that we cover way enough cases without adding a new thing in core and that moving just one step further is not sufficient in most cases so the solution will be complex for a poor concrete gain so we should probably look for something else - but I agree covering it completely is quite more challenging cause either you can embrace reproducible builds and upsert/get-and-update or you have to burn a version (snapshot or not) if you can't recover manually. > > > > > Not sure what you meant there but I don't see any mutilation: > > > > * you want to control more your lifecycle -> you can, indeed it requires > > some configuration since it breaks the default setup but it is doable and > > main case is still smooth (convention over config) > > * you want to plug a custom impl in a plugin -> you can (Guillaume even > did > > the work for extensions) > > * you want to make plugins working altogether sharing a coupled or > loosely > > coupled state? -> you can (using an extension to hold it or a generic > > JVM/Maven type in the session data) > > > > So there is not yet any describe use case requiring a new concept in > maven > > AFAIK. > > > > Explained above what I mean by "mutilation". > > But you can enumerate all the things you want, but still miss the point :) > Again, this is not a "new tech" or anything, not a "revolutionary solution" > for anything. > This is IMHO "deployment done right" (and more to come). > No what you look at is "only artifacts deployment done my way", but it breaks all the cases maven deploys something else - and once again it is not rare today. > > Oh yes, and this thread is about MDK. > hehe, if so nothing to discuss ;) > > Thanks > T >
Re: [DISCUSS] MDK, a Maven Plugin SPI example
Le lun. 6 mai 2024 à 18:55, Tamás Cservenák a écrit : > Romain, > > I have more and more the feeling that you are not reading what has been > written down, at least not carefully enough. > > Otherwise, you';d know that is it NOT "already doable", as explained in MDK > doco (but also in previous thread): > Just one example: the current "deploy at end" feature of m-deploy-p does > NOT deploy "at (build) end", but at "last module using m-deploy-p plugin". > Hence, you can end up with deployment done, and afterwards a build failure. > Exactly...this is what will always happen with plugins and extensions. Indeed you can add a phase after plugins then you moved the issue to one more step but the issue is still *exactly* the same but in a new concept and layer, so literally no gain there. > For example some latter module running tests that use non-standard > packaging and not using m-deploy-p on purpose. > No issue there, you still control the reactor and therefore control the last module built after all others if you want - I use that for the documentation module of a 100+ modules project, so not an issue, you can always have your last module have m-d-p. > > Second, again as explained, the point is to NOT mutilate your build with > hoops and loops, adapt to chosen build service, > as if you choose (or you are forced) to move to another service, you would > need to rinse-repeat, but this time for the other publishing service. > Not sure what you meant there but I don't see any mutilation: * you want to control more your lifecycle -> you can, indeed it requires some configuration since it breaks the default setup but it is doable and main case is still smooth (convention over config) * you want to plug a custom impl in a plugin -> you can (Guillaume even did the work for extensions) * you want to make plugins working altogether sharing a coupled or loosely coupled state? -> you can (using an extension to hold it or a generic JVM/Maven type in the session data) So there is not yet any describe use case requiring a new concept in maven AFAIK. > > > Thanks > T > > > > On Mon, May 6, 2024 at 5:56 PM Romain Manni-Bucau > wrote: > > > Hi Tamas > > > > So it is just a spi consommable from a plugin using an extension to > share a > > state accross mojo execution...so nothing we already do. > > > > My understanding of your request is to bring to maven 4 api this concept > > for common needs (delayed tasks I'd say more than anything specific to > > deployment). > > > > But presented as in the wiki value stays quite low cause it is already > > doable either with or without an extension - using the session and a > plugin > > running at the end of the build. > > > > Le lun. 6 mai 2024 à 18:37, Tamás Cservenák a > écrit > > : > > > > > Howdy, > > > > > > Please take a peek at (and maybe try out) latest Maveniverse project, > > MDK: > > > > > > https://github.com/maveniverse/mdk > > > > > > This is like "proof of concept" or "demo" of what the Plugin SPI > pattern > > > would be able to do. > > > > > > The idea is to broaden the support, and provide services even like > > > "overlaid staging", when staging would receive deployments from > multiple > > > different sources (like for example OS native binaries). > > > > > > MDK is not yet, but will be integrated with Toolbox, to use it's sink > > > abstraction: > > > https://github.com/maveniverse/toolbox > > > > > > Have fun > > > T > > > > > >
Re: [DISCUSS] MDK, a Maven Plugin SPI example
Hi Tamas So it is just a spi consommable from a plugin using an extension to share a state accross mojo execution...so nothing we already do. My understanding of your request is to bring to maven 4 api this concept for common needs (delayed tasks I'd say more than anything specific to deployment). But presented as in the wiki value stays quite low cause it is already doable either with or without an extension - using the session and a plugin running at the end of the build. Le lun. 6 mai 2024 à 18:37, Tamás Cservenák a écrit : > Howdy, > > Please take a peek at (and maybe try out) latest Maveniverse project, MDK: > > https://github.com/maveniverse/mdk > > This is like "proof of concept" or "demo" of what the Plugin SPI pattern > would be able to do. > > The idea is to broaden the support, and provide services even like > "overlaid staging", when staging would receive deployments from multiple > different sources (like for example OS native binaries). > > MDK is not yet, but will be integrated with Toolbox, to use it's sink > abstraction: > https://github.com/maveniverse/toolbox > > Have fun > T >
Re: [DISCUSS] Maven Plugin SPI
Hi Tamas If the proposed options dont implement a SPI the your solution neither since there are equivalent, you are just more verbose and require more work so still not following you. Le lun. 6 mai 2024 à 18:45, Gary Gregory a écrit : > Please don't use the version in the GAV as marketing, this will be > crazy-making for users IMO, especially if I have to look inside a jar to > figure out what my expectations should be regarding semantic versioning. > > My view is that the user visible jar file name containing the version > should set expectation for compatibility and how "risky" a plug-in update > is, for example 2.3.4 to 2.3.5 should be 0-risk. > > Gary > > On Mon, May 6, 2024, 9:20 AM Guillaume Nodet wrote: > > > I wonder if we should use proper package versioning (using > > Specification-Title and Specification-Version manifest attributes, or any > > other better mechanism) and consider the artifact version as a marketing > > version which should not carry any real semantics. > > > > Guillaume > > > > Le lun. 6 mai 2024 à 15:04, Tamás Cservenák a > écrit > > : > > > > > Sure, > > > > > > Again, I am fine with having SPI artifact next to plugin consumer > > artifact. > > > All I wanted to prevent is having tens or more versions of SPI artifact > > > released, while in fact they are "same thing". > > > > > > T > > > > > > On Mon, May 6, 2024 at 3:03 PM Guillaume Nodet > > wrote: > > > > > > > Le lun. 6 mai 2024 à 14:38, Tamás Cservenák a > > > écrit > > > > : > > > > > > > > > lapsus: as in maven-core and maven-model SHOULD NOT share the same > > > > release > > > > > lifecycle. They DO currently. > > > > > Which implies that we have as many maven-model artifacts released > so > > > far > > > > as > > > > > many maven, but many of them are binary equivalent to each other. > > > > > > > > > > > > > What's the drawback with that ? It's much easier to handle for both > the > > > > developper side > > > > and for the consumer side (they only have to upgrade a single version > > > > instead of two). > > > > > > > > I'm quite on the opposite side, and I'd much rather simplify our > > release > > > > cycles rather > > > > than going with one repo per jar... > > > > > > > > > > > > > That's all I wanted to prevent. Am fine with having SPI next to the > > > > plugin > > > > > as well... > > > > > > > > > > T > > > > > > > > > > On Mon, May 6, 2024 at 2:36 PM Tamás Cservenák < > ta...@cservenak.net> > > > > > wrote: > > > > > > > > > > > Pretty much the same story as Maven models vs Maven "core" > > > (maven-core > > > > in > > > > > > 3.x or api-imple in 4) they don't share the same release > > > lifecycle. > > > > > > > > > > > > SPI is not to be changed often, while we do patch releases of the > > > > > plugins. > > > > > > Am not saying we cannot keep SPI along with Plugins, I am just > > saying > > > > > that > > > > > > it's pointless: we will have many releases of the same thing. > > > > > > > > > > > > On Mon, May 6, 2024 at 2:31 PM Guillaume Nodet < > gno...@apache.org> > > > > > wrote: > > > > > > > > > > > >> Le lun. 6 mai 2024 à 14:29, Tamás Cservenák < > ta...@cservenak.net> > > a > > > > > >> écrit : > > > > > >> > > > > > >> > Howdy, > > > > > >> > > > > > > >> > IIUC you have a problem with designated G? > > > > > >> > As if so, that is really irrelevant. Point is that SPI cannot > > > reside > > > > > >> with > > > > > >> > Plugin, as they share totally different release cycles. > > > > > >> > > > > > > >> > > > > > >> Why ? > > > > > >> > > > > > >> > > > > > >> > > > > > > >> > Second, you mention a plugin dep, that is hence available in > the > > > > same > >
Re: [DISCUSS] Maven Plugin SPI
Le lun. 6 mai 2024 à 16:00, Tamás Cservenák a écrit : > Romain, > > for start, you are referring to a solution to "mangle the model after it > was read up". This is what nexus-staging-m-p does and I consider it wrong > and possibly illegal (despite the fact that I wrote that plugin). > I disagree, this was our choice and this is a great and powerful option. Moreover I think it is way more wrong to redo a solution which is already done cause of the mess in the code but also the comm it creates. > This is not a future proof way to do it. To be precise, nx-staging-m-p > injects m-deploy-p config (to become skipped), and also injects itself > (deploy) goal to become "Caliph instead of Caliph" (to deploy instead of > m-deploy-p) (ref https://en.wikipedia.org/wiki/Iznogoud) > Rightwhich is great. We do the same in junit-platform plugin for goods. > > Other than that, I see no way how you could "alter" m-deploy-p behaviour > using this technique, as: > - here you can rewrite the POM > - rewrite plugin config > - but you cannot add/replace components from the plugin itself > - you CAN do what nx-staging does (remote/disable it, and inject yourself, > but again, I find this bad practice) > > Last bullet is a hack, I hope we both agree on this. > Right but you spoke about creating spi so explicitly enabling the N-1 point (injecting a component in configuration)so we are covered for all cases already. If you want an auto-discovered case you don't cover the case you describe, ie enable/disable deployAtEnd so I still don't see any issue for now. > > T > > T > > On Mon, May 6, 2024 at 3:52 PM Romain Manni-Bucau > wrote: > > > > > > https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/AbstractMavenLifecycleParticipant.java#L44 > > afterProjectsRead sorry > > > > So long story short you have a clean way to handle SPI from plugins with > > explicit configuration from the pom or transversally from an extension. > > I don't see a case in between since user is not able to consume it. > > > > 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 lun. 6 mai 2024 à 15:48, Tamás Cservenák a > écrit > > : > > > > > Romain, > > > > > > could you elaborate what you mean by this: > > > "At startup it does not need to be there, so there is no issue there > > while > > > you resolve the plugin dependency you inject from the extension in > > > afterModelRead normally." > > > > > > What is "afterModelRead"? > > > > > > T > > > > > > > > > On Mon, May 6, 2024 at 3:40 PM Romain Manni-Bucau < > rmannibu...@gmail.com > > > > > > wrote: > > > > > > > Tamas, the extension can inject the configuration which is > instantiated > > > > when the mojo will be executed. > > > > At startup it does not need to be there, so there is no issue there > > while > > > > you resolve the plugin dependency you inject from the extension in > > > > afterModelRead normally. > > > > > > > > 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 lun. 6 mai 2024 à 15:36, Tamás Cservenák a > > > écrit > > > > : > > > > > > > > > Laeubi, > > > > > > > > > > How does tycho use plugin-spi? Can you show me some Tycho > plugin-spi > > > > > examples? > > > > > > > > > > As in case of Maven (proper, so "vanilla"), core extension is > loaded > > > > first > > > > > (early), that would like to define SPI imp
Re: [DISCUSS] Maven Plugin SPI
https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/AbstractMavenLifecycleParticipant.java#L44 afterProjectsRead sorry So long story short you have a clean way to handle SPI from plugins with explicit configuration from the pom or transversally from an extension. I don't see a case in between since user is not able to consume it. 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 lun. 6 mai 2024 à 15:48, Tamás Cservenák a écrit : > Romain, > > could you elaborate what you mean by this: > "At startup it does not need to be there, so there is no issue there while > you resolve the plugin dependency you inject from the extension in > afterModelRead normally." > > What is "afterModelRead"? > > T > > > On Mon, May 6, 2024 at 3:40 PM Romain Manni-Bucau > wrote: > > > Tamas, the extension can inject the configuration which is instantiated > > when the mojo will be executed. > > At startup it does not need to be there, so there is no issue there while > > you resolve the plugin dependency you inject from the extension in > > afterModelRead normally. > > > > 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 lun. 6 mai 2024 à 15:36, Tamás Cservenák a > écrit > > : > > > > > Laeubi, > > > > > > How does tycho use plugin-spi? Can you show me some Tycho plugin-spi > > > examples? > > > > > > As in case of Maven (proper, so "vanilla"), core extension is loaded > > first > > > (early), that would like to define SPI implementations, but the plugin > > that > > > would carry SPI interfaces, if SPI would be within plugin as proposed, > is > > > "yet to be seen", will be loaded by mvn core on first encounter in > > > lifecycle. Or, if both load SPI interfaces, they will end up in two > > > classloaders, again defunct. > > > > > > And yes, this solution would enable -- depending on SPI -- to extend > > > existing SPI enabled-plugin in various ways, without touching the > > > build/POMs itself. > > > > > > > > > T > > > > > > > > > On Mon, May 6, 2024 at 2:46 PM Christoph Läubrich > > > > wrote: > > > > > > > Hi Tamas, > > > > > > > > I'm specifically asking because Tycho has already a plugin-spi > support > > > > we use to a great extent, so if there would be a general usable > > solution > > > > that would be great I even asked many times for it but always got > "use > > > > an extension" so I wonder what changed the mind of maven-devs or if > it > > > > will be just another thing exclusive to "maven-core-plugins" or can > > > > other reuse that (how?). And if others can reuse it, why have a > > > > dedicated repository and not use the repository of the plugin that > > > > offers the spi? > > > > > > > > Am 06.05.24 um 14:08 schrieb Tamás Cservenák: > > > > > Howdy, > > > > > > > > > > I'd like to create a new ASF Maven git repo "maven-plugin-spi". > > > > > > > > > > This repository would hold SPIs as explained here > > > > > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI > > > > > > > > > > Designated G: "org.apache.maven.maven-plugin-spi" > > > > > > > > > > For now, we have two candidates to apply SPI pattern: > > > > > * maven-deploy-plugin (yet to be added) > > > > > * maven-gpg-plugin (already have it, but in unusable form, as it > does > > > not > > > > > follow pattern from wiki) > > > > > > > > > > Example GAs: > > > > > org.apache.maven.maven-plugin-spi:maven-deploy-spi > > > > > org.apache.maven.maven-plugin-spi:maven-gpg-spi > > > > > > > > > > Thanks > > > > > T > > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > >
Re: [DISCUSS] Maven Plugin SPI
Tamas, the extension can inject the configuration which is instantiated when the mojo will be executed. At startup it does not need to be there, so there is no issue there while you resolve the plugin dependency you inject from the extension in afterModelRead normally. 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 lun. 6 mai 2024 à 15:36, Tamás Cservenák a écrit : > Laeubi, > > How does tycho use plugin-spi? Can you show me some Tycho plugin-spi > examples? > > As in case of Maven (proper, so "vanilla"), core extension is loaded first > (early), that would like to define SPI implementations, but the plugin that > would carry SPI interfaces, if SPI would be within plugin as proposed, is > "yet to be seen", will be loaded by mvn core on first encounter in > lifecycle. Or, if both load SPI interfaces, they will end up in two > classloaders, again defunct. > > And yes, this solution would enable -- depending on SPI -- to extend > existing SPI enabled-plugin in various ways, without touching the > build/POMs itself. > > > T > > > On Mon, May 6, 2024 at 2:46 PM Christoph Läubrich > wrote: > > > Hi Tamas, > > > > I'm specifically asking because Tycho has already a plugin-spi support > > we use to a great extent, so if there would be a general usable solution > > that would be great I even asked many times for it but always got "use > > an extension" so I wonder what changed the mind of maven-devs or if it > > will be just another thing exclusive to "maven-core-plugins" or can > > other reuse that (how?). And if others can reuse it, why have a > > dedicated repository and not use the repository of the plugin that > > offers the spi? > > > > Am 06.05.24 um 14:08 schrieb Tamás Cservenák: > > > Howdy, > > > > > > I'd like to create a new ASF Maven git repo "maven-plugin-spi". > > > > > > This repository would hold SPIs as explained here > > > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI > > > > > > Designated G: "org.apache.maven.maven-plugin-spi" > > > > > > For now, we have two candidates to apply SPI pattern: > > > * maven-deploy-plugin (yet to be added) > > > * maven-gpg-plugin (already have it, but in unusable form, as it does > not > > > follow pattern from wiki) > > > > > > Example GAs: > > > org.apache.maven.maven-plugin-spi:maven-deploy-spi > > > org.apache.maven.maven-plugin-spi:maven-gpg-spi > > > > > > Thanks > > > T > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
Re: [DISCUSS] Maven Plugin SPI
Think there is something miscommunicated there. here is my vision: 1. "user" maven spi -> https://github.com/apache/maven/tree/master/api/maven-api-spi 2. plugin spi -> belongs by design to plugin (= the plugin chooses its SPI) so belongs to plugin project to keep thing simples - having one repo by plugin is good but already challenging so x2 the number of repo for spi is likely the promise of a mess and a ton of pointless compatibility matrixes. Side note here being we solved it and it works well for dev and consumers. 3. shared plugin spi -> put it in shared module (but even if the lifecycle can look shared the details of the plugin will not IMHO so think we'll always be in 2 or we'll move all plugins SPI in a shared module which is worse IMHO) 4. anything else stays in extension and it would be bad for us - makes it complex for us but also mojo writers and end users - to redo an extension concurrent for other needs than the previous one So ultimately I think this is not an issue we need to address even if any use case can get multiple solutions, a single one is often the best compromise for everyone. 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 lun. 6 mai 2024 à 15:20, Guillaume Nodet a écrit : > I wonder if we should use proper package versioning (using > Specification-Title and Specification-Version manifest attributes, or any > other better mechanism) and consider the artifact version as a marketing > version which should not carry any real semantics. > > Guillaume > > Le lun. 6 mai 2024 à 15:04, Tamás Cservenák a écrit > : > > > Sure, > > > > Again, I am fine with having SPI artifact next to plugin consumer > artifact. > > All I wanted to prevent is having tens or more versions of SPI artifact > > released, while in fact they are "same thing". > > > > T > > > > On Mon, May 6, 2024 at 3:03 PM Guillaume Nodet > wrote: > > > > > Le lun. 6 mai 2024 à 14:38, Tamás Cservenák a > > écrit > > > : > > > > > > > lapsus: as in maven-core and maven-model SHOULD NOT share the same > > > release > > > > lifecycle. They DO currently. > > > > Which implies that we have as many maven-model artifacts released so > > far > > > as > > > > many maven, but many of them are binary equivalent to each other. > > > > > > > > > > What's the drawback with that ? It's much easier to handle for both the > > > developper side > > > and for the consumer side (they only have to upgrade a single version > > > instead of two). > > > > > > I'm quite on the opposite side, and I'd much rather simplify our > release > > > cycles rather > > > than going with one repo per jar... > > > > > > > > > > That's all I wanted to prevent. Am fine with having SPI next to the > > > plugin > > > > as well... > > > > > > > > T > > > > > > > > On Mon, May 6, 2024 at 2:36 PM Tamás Cservenák > > > > wrote: > > > > > > > > > Pretty much the same story as Maven models vs Maven "core" > > (maven-core > > > in > > > > > 3.x or api-imple in 4) they don't share the same release > > lifecycle. > > > > > > > > > > SPI is not to be changed often, while we do patch releases of the > > > > plugins. > > > > > Am not saying we cannot keep SPI along with Plugins, I am just > saying > > > > that > > > > > it's pointless: we will have many releases of the same thing. > > > > > > > > > > On Mon, May 6, 2024 at 2:31 PM Guillaume Nodet > > > > wrote: > > > > > > > > > >> Le lun. 6 mai 2024 à 14:29, Tamás Cservenák > a > > > > >> écrit : > > > > >> > > > > >> > Howdy, > > > > >> > > > > > >> > IIUC you have a problem with designated G? > > > > >> > As if so, that is really irrelevant. Point is that SPI cannot > > reside > > > > >> with > > > > >> > Plugin, as they share totally different release cycles. > > > > >> > > > > > >> > > > > >> Why ? > &g
Re: [DISCUSS] Maven Plugin SPI
Hi Tamas, I kind of fail to see why org.apache.maven.maven-plugin-spi makes sense instead of org.apache.maven.plugins.$pluginArtifact-spi ? My understanding is that we already have that since any plugin can define a specific SPI in its code and get it injected from a plugin dep using its block - exactly like shade plugin references its transformers to be concrete. So for me nothing to create nor modify to get an old feature. 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 lun. 6 mai 2024 à 14:08, Tamás Cservenák a écrit : > Howdy, > > I'd like to create a new ASF Maven git repo "maven-plugin-spi". > > This repository would hold SPIs as explained here > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Plugin+SPI > > Designated G: "org.apache.maven.maven-plugin-spi" > > For now, we have two candidates to apply SPI pattern: > * maven-deploy-plugin (yet to be added) > * maven-gpg-plugin (already have it, but in unusable form, as it does not > follow pattern from wiki) > > Example GAs: > org.apache.maven.maven-plugin-spi:maven-deploy-spi > org.apache.maven.maven-plugin-spi:maven-gpg-spi > > Thanks > T >
Re: [DISCUSS] Maven3 and Maven4 support split
Hi Tamas, If the impact is to prevent to build a maven 3 (original setup version or CI version for ex) with maven 4 (local version for ex) then I think it violates the contract we had for maven 4 and I'd really like it to not happen. If it is the opposite (a maven 4 based/native project can't be ran with maven 3) then +1. What I'd really don't want to see is to have to maintain 2 branches for all plugins for the coming ~5 years. If *really* an issue I'd prefer we write a migration project (openrewrite like - probably without openrewrite technically) to just write the maven 4 project and make it maven 3 friendly automatically (can be a x-maven-plugin downloading x-v3 or x-v4 subartifact for the runtime, not sexy internally but very smooth in terms of usage). Best, 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 lun. 6 mai 2024 à 12:14, Tamás Cservenák a écrit : > Howdy, > > my pain point was plugin-testing-harness 3.3.0 that is really ancient, > while master of it was mixing maven3 and maven4 support... so I went to > split things. > > IMO we need to split (like maven-3.x and master branch) for maven 3 and > maven 4 support, as there is really no need to support "both", as in case > of plugins, they are "this or that", they cannot be maven3 and maven4 at > the same time. > > Hence, I started with maven-plugin-testing: > https://github.com/apache/maven-plugin-testing/tree/maven-3.x > > Please eyeball and would like to prepare a 3.4.0 release of it soon. > > By the way, same should be done in maven-plugin-plugin (no need to support > creation of maven3 and maven4 plugins at the same time)... and maybe same > pattern (using branches maven-3.x and master for 3 and 4) should be applied > to all plugins? > > Thanks > T >
Re: [VOTE] Release Apache Maven Script Interpreter version 1.6
+1 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 mar. 30 avr. 2024 à 14:03, Sylwester Lachiewicz a écrit : > +1 > > wt., 30 kwi 2024, 12:44 użytkownik Slawomir Jaranowski < > s.jaranow...@gmail.com> napisał: > > > +1 > > > > pon., 29 kwi 2024 o 23:51 Slawomir Jaranowski > > napisał(a): > > > > > Hi, > > > > > > We solved 4 issues: > > > > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12354488 > > > > > > There are no more issues left in JIRA: > > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-script-interpreter > > > > > > Staging repo: > > > https://repository.apache.org/content/repositories/maven-2105/ > > > > > > > > > https://repository.apache.org/content/repositories/maven-2105/org/apache/maven/shared/maven-script-interpreter/1.6/maven-script-interpreter-1.6-source-release.zip > > > > > > Source release checksum(s): > > > maven-script-interpreter-1.6-source-release.zip - SHA-512 : > > > > > > 328a0a033952e6cecb264bf02198808c08e04b05165a72dd3bd168415055703bae1a6732c41ab61638b6e70991ff400c0f03e17d91c287c053e38a15b06c071a > > > > > > Staging site: > > > > > > https://maven.apache.org/shared-archives/maven-script-interpreter-LATEST/ > > > > > > Guide to testing staged releases: > > > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > > > Vote open for at least 72 hours. > > > > > > [ ] +1 > > > [ ] +0 > > > [ ] -1 > > > > > > -- > > > Sławomir Jaranowski > > > > > > > > > -- > > Sławomir Jaranowski > > >
Re: Publish Via the Central Portal
Hi, Nexus plugin works well with maven 4 but has a limitation with java version ootb if you dont force plugin dependency version. >From my side the main issue is it got abandonned - fix was there but no release (at least after months and before I moved back to deploy or a tuned gitflow plugins). Guess we should be able to support it in deploy plugin if protocol requires changes to ensure some continuity and maintenance in time? Le jeu. 2 mai 2024 à 01:29, Slawomir Jaranowski a écrit : > Thanks Brian for responding. > > From the time when nexus-staging-plugin was introduced we have done many > improvements in standard deploy plugin - like deploy at the end, uploading > artifacts in parallel. > > We are also working on Maven 4, so today the plugin should be possible to > use with the next Maven major version. > As I remember nexus-staging-plugin can not be used with Maven 4. > Can a new plugin be used with Maven 4? > > > śr., 1 maj 2024 o 17:50 Brian Fox napisał(a): > > > Hey all. Thanks Romain for pointing out the thread for me. > > > > One issue is that Central publishers is a much larger set of folks than > the > > Maven Dev group. Obviously there's lots of overlap, but as Romain said, > > creating a plugin is a thing that can be done independently. > > > > As we've been working towards refreshing the infra used to publish to > > Central, we have reached out collaboratively to other known tools that > > required support. Specifically Gradle and also Andres / JReleaser to > ensure > > that there is broad tooling support for the new apis. Since we created a > > Maven plugin ourselves, and it is largely based on the long standing > Nexus > > staging plugin, it wasn't apparent that any conversation was needed here. > > > > We will need to dig in other Maven Compat and opening the source however > so > > good call outs. > > > > On Tue, Apr 30, 2024 at 6:11 AM Andres Almiray > wrote: > > > > > Hello everyone, > > > > > > In the meantime JReleaser offers support for both publishing to the > > Portal > > > and handling build poms > > > > > > https://github.com/jreleaser/jreleaser/issues/1612 > > > https://github.com/jreleaser/jreleaser/issues/1632 > > > > > > FWIW the Portal API is publicly available at > > > https://central.sonatype.org/publish/publish-portal-api/ > > > Sonatype's plugin may not offer source code but JReleaser does. > However, > > > it's implementation relies on Feign. You may study and adapt the code > if > > > you feel like it, after all it's licensed under ASL v2 > > > > > > > > > > > > https://github.com/jreleaser/jreleaser/tree/main/sdks/jreleaser-mavencentral-java-sdk > > > > > > Cheers, > > > Andres > > > > > > --- > > > Java Champion; Groovy Enthusiast > > > https://andresalmiray.com > > > https://www.linkedin.com/in/aalmiray > > > -- > > > What goes up, must come down. Ask any system administrator. > > > There are 10 types of people in the world: Those who understand binary, > > and > > > those who don't. > > > To understand recursion, we must first understand recursion. > > > > > > > > > On Tue, Apr 30, 2024 at 12:05 PM Romain Manni-Bucau < > > rmannibu...@gmail.com > > > > > > > wrote: > > > > > > > Hi, > > > > > > > > AFAIK and if I got right the info from Brian, this is not yet > promoted > > > and > > > > the primary solution but will become soon. > > > > > > > > Personally I'm not that shocked we were not consulted - we build > plugin > > > API > > > > for that exact purpose, let people do what they need to do. > > > > > > > > About maven-compat it i mainly about us making it obvious it will > fail > > > but > > > > I think it will be fixed for the final GA release. > > > > > > > > So from my small window there is no concern even if most of us using > > > > central outside the asf will be impacted sometime next year probably. > > > > > > > > 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/rmannib
Re: Publish Via the Central Portal
Hi, AFAIK and if I got right the info from Brian, this is not yet promoted and the primary solution but will become soon. Personally I'm not that shocked we were not consulted - we build plugin API for that exact purpose, let people do what they need to do. About maven-compat it i mainly about us making it obvious it will fail but I think it will be fixed for the final GA release. So from my small window there is no concern even if most of us using central outside the asf will be impacted sometime next year probably. 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 mar. 30 avr. 2024 à 10:32, Slawomir Jaranowski a écrit : > Hi, > > Does anyone try the new Sonatype Central Portal? > https://central.sonatype.org/publish-ea/publish-ea-guide/ > > There is a new (*) Maven plugin provided by Sonatype for deployments: > https://central.sonatype.org/publish/publish-portal-maven/ > > But I am afraid that this plugin will be similar > to nexus-staging-maven-plugin and still use maven-compat ... > Probably it will have a problem with Maven 4 ... > Also Sonatype did not publish a source code for it ... > > https://central.sonatype.com/artifact/org.sonatype.central/central-publishing-maven-plugin > > Also Sonatype did not publish a source code for it ... > > It also looks as standard Maven deployment will not work with the new > Central Portal API. > > I'm surprised that Sonatype did not consult or even announce such a new way > with the Maven community. > > -- > Sławomir Jaranowski >
Re: [VOTE] Release Apache Maven Shade Plugin version 3.5.3
+1 Le lun. 22 avr. 2024 à 05:30, Olivier Lamy a écrit : > +1 > > On Sun, 21 Apr 2024 at 01:54, Hervé Boutemy wrote: > > > > Hi, > > > > We solved 3 issues: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12354342=Text > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-2096/ > > > https://repository.apache.org/content/repositories/maven-2096/org/apache/maven/plugins/maven-shade-plugin/3.5.3/maven-shade-plugin-3.5.3-source-release.zip > > > > Source release checksum(s): > > maven-shade-plugin-3.5.3-source-release.zip sha512: > a97d291f66f7f4a96af936c27061305e3856cb1e32ee5130cbf9b2f9a31d2ac7c1551ab17cd41e75887ac2345b815fad248fb381f437bf1376467a4fcdf24544 > > > > Staging site: > > https://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for at least 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Release Apache Maven JAR Plugin version 3.4.1
+1 Le mer. 17 avr. 2024 à 12:28, Tamás Cservenák a écrit : > +1 > > [INFO] Reference build java.version: 21 (from MANIFEST.MF Build-Jdk-Spec) > [INFO] Reference build os.name: Unix (from pom.properties newline) > [INFO] Minimal buildinfo generated from downloaded artifacts: > > /home/cstamas/Worx/apache-maven/maven-jar-plugin/target/reference/maven-jar-plugin-3.4.1.buildinfo > [INFO] Reproducible Build output summary: 7 files ok > > T > > On Tue, Apr 16, 2024 at 11:13 PM Slawomir Jaranowski < > s.jaranow...@gmail.com> > wrote: > > > Hi, > > > > We solved 2 issues: > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317526=12354551 > > > > There are still a couple of issues left in JIRA: > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MJAR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-2092/ > > > > > https://repository.apache.org/content/repositories/maven-2092/org/apache/maven/plugins/maven-jar-plugin/3.4.1/maven-jar-plugin-3.4.1-source-release.zip > > > > Source release checksum(s): > > maven-jar-plugin-3.4.1-source-release.zip - SHA-512 : > > > > > 7a55772e85af9ce8268ab0d5792197a2341f4c49c1deeba7f8ba98c2b8d56ec3f1d6b34d79b4c4d92dee1df3e3a9e69a5b9ef8974086fa6c3785db5c6fe14e6f > > > > Staging site: > > https://maven.apache.org/plugins-archives/maven-jar-plugin-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for at least 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > -- > > Sławomir Jaranowski > > >
Re: [VOTE] Release Maven Resolver 2.0.0-alpha-10
+1 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 mar. 2 avr. 2024 à 08:35, Guillaume Nodet a écrit : > +1 > > Le ven. 29 mars 2024 à 13:22, Tamás Cservenák a > écrit : > > > > Howdy, > > > > Note: This is an eighth (alpha-4 and alpha-9 was scrubbed) preview > release > > of Resolver 2.0.0, that would allow any downstream consumers to try it > out > > and adapt. The supplier is aligned with Maven 4.0.0-alpha-13. This > resolver > > now implements "dynamic scopes" using newly introduced ScopeManager (as > > opposed to Resolver 1.x "cemented/wired in scopes"), making Resolver > truly > > "scope agnostic" (as it is from now on just a matter of scope manager > > configuration). Also, a bug fix is there that restores backward binary > > compatibility. > > > > For configuration changes, see > > > https://maven.apache.org/resolver-archives/resolver-LATEST/configuration.html > > > > IF the vote is successful, the staging site will NOT be moved to > > https://maven.apache.org/resolver/ but instead will be made reachable > from > > https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-10/ > only. > > > > The 1.9.18 is still the "latest stable" release of Maven Resolver. > > > > === > > > > We solved 11 issues: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12354447 > > > > There are still some issues in JIRA: > > https://issues.apache.org/jira/projects/MRESOLVER/issues > > > > Staging repository: > > https://repository.apache.org/content/repositories/maven-2080/ > > > > Source release SHA512: > > > ba52c431d11adcfbbd2aac088c4ba0bb9c4f864f084047d45ed64fa806ee0625fadd6447cce6f39f05abd493c6f54cc2b6d70740efa6bc994ce694936f6c9e0d > > > > Staging site: > > https://maven.apache.org/resolver-archives/resolver-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > -- > > Guillaume Nodet > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Reproducible builds: a maven thing or not?
Hi all, We've got a lot of work around reproducible builds - whatever we think about it since there are good reasons to say it is pointless and some to say it is useful so I don't want to enter into the debate - but the notion is 100% hosted in plugins today. It has a few pitfalls for me: 1. plugins assume the (output) timestamp is static for a build and rebuild 2. projects often need a build timestamp related to last modifications (frontends, jar.lastModifiedTime usage, ...) Both statements don't go well with a hardcoded value - manually maintainedso not maintained and broken IRL. A workaround used by some projects is to wire the git last commit time - or equivalent - to this value but then a plugin injects the value which means another plugin can read another value or no value and corrupt the reproducibility of the build. Related to that, the work around the PR #30 on maven-artifact-plugin shows that if using a dynamic value the artifact plugin fails or at least emits a warning - which is not acceptable for a valid case IMHO. Originally I just thought about relaxing this warning but Hervé thinks it is wrong and due to the limitations mentionned earlier I think he is right too but this means we can't let a plugin handle the "output timestamp" so I wonder if we should move it to the new maven 4 service layer. The only difficulty is to let it have some pluggability, default would be a hardcoded value in properties but we should be able to use git last commit time - likely reading pack without jgit dependency - or another strategy potentially (ideally, as pointed out by Hervé, a different value per module would be highly relevant and could need some configuration, the common example being: "use the last modified time from git of files in src", ie ignore pom modifications since it does not end in the output for example). So my question is the following one: do we add output timestamp to maven 4 API and let maven 3 like that or do we consider reproducible builds are not a key thing for maven and we let it in plugins (~=outside and artifact plugin is considered not a core plugin - not sure of the status today)? I'm happy both ways but I'm way less happy with a broken setup if we consider it is supported by maven. 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>
Re: release of maven-source-plugin
Hi, I think it is fixed for v4 serie. Main issue comes from the default v3 pom ( https://github.com/apache/maven/blob/maven-3.9.2/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml#L113) which is no more a thing in v4 so the merge of the plugin executions does not happen the same and the issue disappeared. The easiest is likely to either let the default be merged and not use "jar" (implicit jar-no-fork instead) or just not use the default id (attach-sources) and skip the default one. So there is no source plugin issue (as the plugin will never fix it by "bug design") so no reason to hold a release IMHO. Guess it silently overrided the already built artifact for years - until we just fail cause it is a broken design - after this change of goal https://issues.apache.org/jira/browse/MNG-5940. So long story short: we are on track and release can be done I think. 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 dim. 24 mars 2024 à 18:44, Gary Gregory a écrit : > Hi All, > > As long as https://issues.apache.org/jira/browse/MSOURCES-143 is in > play, Commons will stay on a pre-3.3.0 version. > > I re-read the comments, I still don't know what we can do in Commons > to address this as this feels like some deep Maven Magic. > > Gary > > On Sun, Mar 24, 2024 at 11:48 AM Hervé Boutemy > wrote: > > > > I'd like to release maven-source-plugin 3.3.1 to drop the umask > sensitivity > > during Reproducible Builds :)1 > > > > but there are a few issues open > > https://issues.apache.org/jira/projects/MSOURCES/versions/12353471 > > > > they are related to https://issues.apache.org/jira/browse/MSOURCES-121: > I > > don't get what conditions made the build fail previously, but > MSOURCES-121 > > make it fail now always. > > Should we just change the ERROR into WARNING? > > Should we do something smarter, for example not re-add if it's the same > file? > > Or warn only if the second file addition is different from the first? > Then > > replace instead of add? > > > > Please help clarifying and fixing this issue that seems ignored for a > long time > > > > Regards, > > > > Hervé > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [DISCUSS] Maven Dependency Plugin
Hi For me it is: * Tree: human work on transitivity * List: pre-resolve for the runtime (dump jar list in a file) * Resolve: CI init phase Le jeu. 21 mars 2024 à 17:54, Christian Stein a écrit : > I use the "resolve" goal like this: > > mvn --batch-mode --no-transfer-progress -DoutputFile=resolved.txt > org.apache.maven.plugins:maven-dependency-plugin:3.6.1:resolve > > ...and parse the output for Java module names and whether they are > "automatic". > > > https://github.com/sormuras/maven-starter-projects/blob/c7839302f3552caa4de42bc97aa151ddabf7bc78/src/GenerateReadme.java#L74 > > On Thu, Mar 21, 2024 at 5:06 PM Tamás Cservenák > wrote: > > > Howdy, > > > > I'd would be interested in how users and devs are using > > maven-dependency-plugin: > > https://maven.apache.org/plugins/maven-dependency-plugin/ > > > > I collected some basic questions I'd like to have answered (but feel free > > to add more info!): > > - which goals are "must have" for you > > - which goals are "I never touched" for you (or, "I really don't need" or > > "never used" or "shrug") > > - what is missing? > > > > Thanks > > T > > >
Re: Notes on maven-compiler-plugin work
Hi Martin, Since we'll go v4 and really change the impl I guess we can drop all the compiler args from properties and the not relevant options. Ultimately the only options would be: * fork options * compiler args * log/outputs options Anything else brings confusion and prevents us to validate properly the command before it is executed (as of today). +1 to not "preparePaths" and just let the compilation be native. 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 lun. 18 mars 2024 à 00:31, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Hello all > > I'm not yet ready to submit a pull request for the reworked > maven-compiler-plugin, but I would like to report some details about > changes that would come, if accepted. This work is for Maven 4 only, the > plugin for Maven 3 will stay unaffected. > > As proposed on GitHub comment [1], I'm modifying the implementation for > using the standard javax.tools.JavaCompiler interface instead of the > Plexus compiler. That interface is part of standard JDK since Java 6. It > seems that the Eclipse compiler provides also an implementation of that > interface, so compiler independence should be preserved. Forked > compilation is handled by a custom implementation of that interface. The > javax.tools.JavaCompiler interface has some methods needed for Java > modules, for which I saw no direct equivalence in Plexus API. The gap > may grow larger if future Java versions bring more evolution to the > compiler API. The standard interface also has a cache mechanism that may > bring performance improvements (to be verified) when compiling more than > one set of sources, e.g. for multi-versions. It also opens the door for > handling source and classes that are not files, for example by doing > everything in memory (I have no plan to use this features now, but it > become a possibility for the future). > > The way to handle compiler options has been modified. Previously, the > Maven plugin validated some options before to pass them to the compiler. > For example, if the value contains anything else than > "lines", "vars" or "source", the plugin raised an error. The intend was > to provide more informative message. But in the javax.tools.JavaCompiler > interface, there is an API telling us whether an option is supported. > Therefor, the new plugin version first asks to the compiler whether the > option is supported, and only if the compiler said "no", the validation > is performed for producing the error message. Consequently, if the > compiler claims to support the "-g:foo" option, then the plugin will no > longer block the use of the "foo" value in even if the > plugin does not know that value. > > The set of plugin parameters is the same as before: no addition and no > removal, but there is some deprecation. Of course, what to deprecate or > not is open to discussion. In the current state of work, the following > parameters are deprecated but are still working: > > * (a single String): already replaced by > (a list of Strings) since Maven 3.1. > * : replaced by ordinary dependencies with > proc, a new artifact type introduced in Maven 4-alpha13. > > The following parameters are marked as deprecated for removal in the > current state of work. They all became no-op in the new plugin: > > * : the documentation is not really explicit, > but it seems to be about forcing the use of java.lang.Compiler > instead of javax.tools.JavaCompiler (it does not seem to be about > the javac command). The java.lang.Compiler class was deprecated > since Java 9 and no longer exists in Java 21. > * : bundling many class files into a single file can > be considered as the task of separated plugins, for example the JAR > plugin. Furthermore, this parameter does not fit well in the context > of Module Source Hierarchy, because the output is not a single JAR. > * : the way that the javax.tools.JavaCompiler > API is designed, this parameter does not seem relevant to instances > of that interface. The parameter may be partially relevant to some > objects used by JavaCompiler, but not fully (e.g. the "reuseSame" > parameter value stay inapplicable). I suggest to let those decisions > as plugin implementation details. > * : deprecated as a consequence of > deprecation. > > The following parameters ha
Re: [DISCUSS] Maven Core Plugins versioning
Hi Hervé, Think we can try to just move forward the v4 effort and if there are enough requests on v3 we would maintain it as a best effort but as it had been mentionned there is no more any real reason to do both as soon as maven v4 is officially out - ie final - IMHO. 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 mar. 12 mars 2024 à 08:49, Herve Boutemy a écrit : > using 4.x scheme looks simple and working: ok there is an exception with > site, as there are always exceptions > > what is important is system prerequisites history: remember for JDK > requirement? same for Maven version requirement > just need to finish work on MPLUGIN-511 and we'll get the documentation > automated > > I hope we also have good error messages at runtime both in Maven 3 and 4 > > what makes me fear future headache is to decide if we maintain 2 branches > (3.x and 4.x) in parallel of our ~50 plugins or if we just stop 3.x branch, > or if we in general don't yet publish the 4.x branch unless there is a very > good reason > or... any other idea that permits reasonable maintenance effort for us and > reasonable service to our users community > > Regards, > > Hervé > > On 2024/03/06 13:58:01 Tamás Cservenák wrote: > > Howdy, > > > > We have several topics that need to be discussed. > > > > I. Core Plugin Versioning > > > > History: When Maven2 was born, and started using plugins "as we know them > > today" (Maven 1 was a very different beast), the Core Plugin versions > were > > started as 2.0 on purpose. Just check the Maven Central for historical > > versions, some examples: > > * clean > > > https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/ > > * compiler > > > https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/ > > * jar > > > https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/ > > * surefire > > > https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/ > > * dependency > > > https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/ > > > > So, Maven2 "as a fresh release" got all new shiny 2.0 plugins at the > > beginning. Later on, when Maven3 came to existence, it was able to use > > Maven2 plugins, the plugins were slowly migrated to become "Maven 3 > > plugins" (Maven2 could not use them anymore). This was denoted by the > "3.x" > > major plugin version jump. > > > > So far, we have no 4.x plugin release of anything (M releases do not > > count). But my question is the following: > > > > How should we distinguish similar changes for Maven4? > > > > Explanation: when a plugin is migrated to Maven4 API, it will mean Maven3 > > will NOT be able to use anymore (will be incompatible). Similarly as > > before, Maven4 CAN run the "Maven 3" plugins, and will retain this > > capability for some time. But other ways it does not work, nor never > worked > > (Maven3 will not be able to run Maven4 plugin, just like Maven2 never ran > > Maven3 plugin). > > > > For me, the logical answer to this question is the use of major version > > 4.x. So just like it happened with Maven 2 to Maven 3 transition, a > plugin > > version 2.x meant "Maven2 plugin", version 3.x of plugin meant "Maven3 > > plugin" (Maven2 incompatible). > > > > As otherwise, if we start releasing Core plugins 4.x or 5.x, we will > > confuse the hell out of our users. At least that is what I think. > > > > II. Consequence: How to interpret Core plugin versions > > > > As can be seen above, so far the major version of the plugin was kinda > > showing "which Maven API level" is the plugin. > > > > So, it begs the question: HOW to interpret the Maven Core Plugin version? > > > > My interpretation was always: "shift it once left", meaning: Core plugin > > version "3.2.1" MEANS: > > - Maven API version: 3 > > - Core Plugin version 2.1(.0) > > > > III. Consequence: How to express Core plugin "breaking change"? > > > > Today, everyone expects a "major version jump" to express breaking > changes. > > BUT, as explained above, that would be totally misleading here, and would > > break the "customary law" that Major expresses Maven lineage. > > > > Ideas and opinions welcome. > > > > T > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Release Apache Maven Assembly Plugin version 3.7.0
+1 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 dim. 10 mars 2024 à 00:57, Sylwester Lachiewicz a écrit : > +1 > > sob., 9 mar 2024, 09:37 użytkownik Karl Heinz Marbaise > napisał: > > > Hi, > > > > +1 from me > > > > Kind regards > > Karl Heinz Marbaise > > On 07.03.24 19:27, Slawomir Jaranowski wrote: > > > Hi, > > > > > > We solved 25 issues: > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317220=12353243 > > > > > > There are still a couple of issues left in JIRA: > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MASSEMBLY%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC > > > > > > Staging repo: > > > https://repository.apache.org/content/repositories/maven-2069/ > > > > > > https://repository.apache.org/content/repositories/maven-2069/org/apache/maven/plugins/maven-assembly-plugin/3.7.0/maven-assembly-plugin-3.7.0-source-release.zip > > > > > > Source release checksum(s): > > > maven-assembly-plugin-3.7.0-source-release.zip - SHA-512 : > > > > > > fd25b79c126cf728fddc04f9f0cb56cbd5434d4f67001f88947ca677086a5d34e843154c6fe9dfb47ac85889ddd656a5df0ba3e1f6486e1a9d887fedf6d1200e > > > > > > > > > Staging site: > > > > https://maven.apache.org/plugins-archives/maven-assembly-plugin-LATEST/ > > > > > > Guide to testing staged releases: > > > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > > > Vote open for at least 72 hours. > > > > > > [ ] +1 > > > [ ] +0 > > > [ ] -1 > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
Re: [DISCUSS] Maven Core Plugins versioning
Think site got slowly replaced by other alternatives - even to document mojos! - so today it is mainly about us and I also dont think limiting doxia 2 to maven 4 has much issues, there is no real request from outside for it AFAIK. >From a versioning standpoint I see really no reason to make a transitive dep surfacing in a mojo, here it just highlights the site plugin is not selfcontained as it should maybe be so maybe mvn4 could revisit it and try to make our site integration back usbale by some users. So I really see no reason to shout ourself in the foot for a single case which is ultimately promished to more real redesign if we want to keep it on the long run. So let's start simple and if some users want it we'll sort it out as we already did in some plugins which were multi versions friendly...but had a single version if you follow ;). Le ven. 8 mars 2024 à 21:18, Michael Osipov a écrit : > I plan to publish an announcement *before* I update anything or bump > reporting plugins to the (now) next minor version. People will always > complain -- regardless of what you do -- if they are unhappy. > I don't expect you to waste to time for site, just skip it mentally. I > will take care. > > Am 2024-03-08 um 21:10 schrieb Tamás Cservenák: > > Michael, > > > > I understand, but then all that remains is +10 or +100 in versions, > > trickeries, or whatever... > > > > Be prepared for "this works with that but does not with that other" types > > of JIRA... > > And my guess is that the few who still use the site function of Maven > will > > simply drop it. > > A big confusion is ahead, but I'd really not waste any (my at least) > energy > > on "what works with that in site" type of thing. > > > > This reminds me of Smylex, from Batman (1984). > > > > T > > > > > > On Fri, Mar 8, 2024 at 9:01 PM Michael Osipov > wrote: > > > >> Am 2024-03-08 um 20:56 schrieb Tamás Cservenák: > >>> I agree with Gary, > >>> > >>> really really the simplest would be to NOT use Doxia 2 for Maven 3, as > >>> basically that IS the "plugin breakage" we are soon facing. > >> > >> This is unacceptable for me because that breaks two years of ongoing > >> effort. I cannot expect people to move off Maven 3 because of site > >> generation. This is not a core issue since reporting has been removed > >> from Maven Core in Maven 3 for good. Please DO NOT conflate what has > >> been untangled 10+ years ago. I can/will use a minor release with a > >> special section in the release notes since next major is unvailable. > >> > >> M > >> > > > >
Re: [DISCUSS] Maven Core Plugins versioning
+1 without any strong opinion on doxia 2 for maven 3 in the future (no blocker IMHO but not the baseline too) 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 ven. 8 mars 2024 à 13:00, Tamás Cservenák a écrit : > So, can we agree on following (maybe even vote if needed)? > > I. Core Plugin Versioning > Maven3 plugins carry 3.x as the major version number, and Maven4 plugins > will carry 4.x major versions? > > II. Consequence: How to interpret Core plugin versions > See above. In short: the first element is "maven API level", rest could be > "shifted left" and interpreted like that. > > III. Consequence: How to express Core plugin "breaking change"? > Ideally, we should NOT have them. But, in case we must: > - use minor bump and .0 patch to clearly show this is a "bigger" change > (hence, 3.1.0 -> 3.2.0 should be interpreted by users like "I need to sift > thru release notes before just blindly update") > - clearly document the breakage in plugin release notes, plugin announce > and plugin site > > (new) IV. Doxia should be handled similar to Resolver > - Doxia 1.x is Maven 3 (as today, m-site-p 3.x is Maven3 plugin and uses > Doxia 1.x stack) > - Doxia 2.x is Maven 4 (in future, m-site-p 4.x will be Maven4 plugin and > will use Doxia 2.x stack) > As this then solves all the problems Michael brought up rightfully. > > T > > > > On Fri, Mar 8, 2024 at 12:27 PM Tamás Cservenák > wrote: > > > And a short addendum: > > > > Given, today there are still no Maven 4.x plugins nor Doxia 2.x reports > > out there (released), what if, we follow Michael intent BUT with a slight > > "bend": > > - the new Maven Site plugin that uses Doxia 2.0.0 and would carry version > > 4.0.0 (to be released) **should be Maven4 plugin** > > - this implies that all reports stuff that will Doxia 2.0.0 MUST BE > Maven4 > > plugins as well > > - basically, leave Doxia 1.x for Maven3 as is, and use Doxia 2.x for > Maven4 > > > > T > > > > On Fri, Mar 8, 2024 at 12:20 PM Tamás Cservenák > > wrote: > > > >> Just to clarify, explain myself but also FTR on thread: > >> > >> in case of report-plugins we basically have TWO requirements (or deps): > >> - maven API level > >> - doxia API level (that with 2.0.0 contains breaking changes) > >> > >> Basically, Maven4 supports 4.x plugins (that use new API) but also > >> supports running 3,x plugins (in "compat" mode, just like today, as > there > >> are still no 4.x plugins out there). > >> But Doxia introduces hard breakage, as far as I understand (correct me > >> here if I am wrong), there is no "Doxia 2.x backward compat support for > >> Doxia 1.x clients"? > >> > >> Given Doxia 1.x is being phased out, and unlike for Maven API (where we > >> do want and will maintain 3.x and 4.x plugin versions in parallel), > this is > >> not happening with reports/doxia. > >> We do not want any Doxia 1.x report to be released, right? > >> > >> This also implies that a build that does use reports, cannot "gradually" > >> migrate to Doxia 2.0.0, no? > >> It is all or nothing, no? So either a new site plugin with Doxia 2.x or > >> an old site plugin with Doxia 1.x? > >> > >> T > >> > >> On Fri, Mar 8, 2024 at 11:50 AM Tamás Cservenák > >> wrote: > >> > >>> Howdy, > >>> > >>> First, 4.0 is not out yet (check my remark in the initial mail "M > >>> releases do not count"). > >>> > >>> Second, is there a plugin out there that also includes a report? > >>> (or in other words, you remember I was insisting to SPLIT OUT all the > >>> report stuff out of plugins) > >>> > >>> As if there is no such plugin, we deal with them just like explained > >>> above in case of "breaking changes": > >>> basically report-plugins will have breaking changes and will require > new > >>> site stuff... > >>> > >>> If there is a plugin that includes report as well, report MUST be > >>> split out as the first step. > >>> > >>> T > >&
Re: [DISCUSS] Maven Core Plugins versioning
Hi Michael, Site 4.0.0 does not exist, there are only milestones (so no guarantee given in such a release) so not a big deal IMHO, we can align on Tamas proposal and just do a 3.(n+1) if we want to propose the changes to maven 3 (no big opinion on this one). So proposal sounds good to me: $maven.$pluginMajor.$minor. 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 ven. 8 mars 2024 à 11:51, Tamás Cservenák a écrit : > Howdy, > > First, 4.0 is not out yet (check my remark in the initial mail "M releases > do not count"). > > Second, is there a plugin out there that also includes a report? > (or in other words, you remember I was insisting to SPLIT OUT all the > report stuff out of plugins) > > As if there is no such plugin, we deal with them just like explained above > in case of "breaking changes": > basically report-plugins will have breaking changes and will require new > site stuff... > > If there is a plugin that includes report as well, report MUST be split out > as the first step. > > T > > On Fri, Mar 8, 2024 at 11:29 AM Michael Osipov > wrote: > > > Am 2024-03-08 um 11:19 schrieb Tamás Cservenák: > > > So, can we agree on following (maybe even vote if needed)? > > > > > > I. Core Plugin Versioning > > > Maven3 plugins carry 3.x as the major version number, and Maven4 > plugins > > > will carry 4.x major versions? > > > > See Maven Site Plugin 4.0, contains fundemantal changes in the > > background, cannot keep 3.x. Same will apply to almost all of our > > reporting plugins which is caused by Doxia 2.0.0. Totally unrelated to > > Maven 4. How do deal with that? > > > > M > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > >
Re: [VOTE] Release Apache Maven 4.0.0-alpha-13
+1 (side note for future releases: we can move to milestone versioning more than alpha since we are not alpha at all it seems, are we?) 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 jeu. 7 mars 2024 à 00:08, Karl Heinz Marbaise a écrit : > Hi, > > I see the following with 4.0.0-alpha-13 with a test project (spring > boot based 3.3.0-M2): > > [INFO] Unable to find the root directory. Create a .mvn directory in the > root directory or add the root="true" attribute on the root project's > model to identify it. > [INFO] Scanning for projects... > [WARNING] > [WARNING] Some problems were encountered while building the effective > model for 'com.soebes.spring.example:employee:jar:0.0.1-SNAPSHOT' > [WARNING] Ignored POM import for: > org.apache.maven.plugin-tools:maven-plugin-annotations:jar:3.7.0@compile > as already imported > org.apache.maven.plugin-tools:maven-plugin-annotations:jar:3.10.2@compile. > Add a the conflicting managed dependency directly to the > dependencyManagement section of the POM. @ > org.springframework.boot:spring-boot-dependencies:3.3.0-M2, > > /Users/khm/.m2/repository/org/springframework/boot/spring-boot-dependencies/3.3.0-M2/spring-boot-dependencies-3.3.0-M2.pom > [WARNING] > [WARNING] It is highly recommended to fix these problems because they > threaten the stability of your build. > [WARNING] > [WARNING] For this reason, future Maven versions might no longer support > building such malformed projects. > [WARNING] > > The given bom file contains also a pluginManagement section with a > number of plugins defined in > > > The interesting part is that 4.0.0-alpha-12 does not produce such > warning at all: > > [INFO] Unable to find the root directory. Create a .mvn directory in the > root directory or add the root="true" attribute on the root project's > model to identify it. > [INFO] Scanning for projects... > [INFO] > [INFO] --< > com.soebes.spring.example:employee > >-- > [INFO] Building Employee Demo Application 0.0.1-SNAPSHOT > [INFO] from pom.xml > [INFO] -[ jar > ]-- > [INFO] > [INFO] --- clean:3.3.2:clean (default-clean) @ employee --- > [INFO] Deleting > /Users/khm/ws-git-soebes/examples/spring-boot-plus-spring-data/target > [INFO] > > Any ideas what happens? > > > Kind regards > Karl Heinz Marbaise > > On 06.03.24 21:42, Tamás Cservenák wrote: > > Howdy, > > > > This is a vote to release Apache Maven 4.0.0-alpha-13. > > > > We solved 32 issues: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12354062 > > > > There are still some issues in JIRA: > > https://issues.apache.org/jira/projects/MNG/issues > > > > Release candidates: > > https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-alpha-13/ > > > > Staging repository: > > https://repository.apache.org/content/repositories/maven-2068/ > > > > Source release SHA512: > > - apache-maven-4.0.0-alpha-13-src.zip > > > 5e997e382ad7e5021009b74a6a80b9c9076282a3a71260636efc99c28ffad2c4d093d896364e705d853015f6c7d949523fc78c4ebb6aa55edeb43e383f084e3d > > - apache-maven-4.0.0-alpha-13-src.tar.gz > > > 59cc1b312b240e93e9f51ab9549c69385e12ccf5453b8e6238470437fce8ca802bda0eddc66ca94c5d6d05c02e44c0f78d0d7d2038998559a61df6e5c599da10 > > > > Staging site: > > https://maven.apache.org/ref/4-LATEST/ > > Note: site publishing (execution time of `mvn scm-publish:publish-scm`) > now > > takes 32 minutes! We need to do something about this... > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [DISCUSS] Maven Core Plugins versioning
Ok, I'd just use semver prefixing the plugin with the intended maven version (unspecified what happens if not aligned). It is always how it got perceived and I think it is good enough. About the naming I agree the plugin suffix is quite pointless as the maven prefix since we have the groupId, adding code would be dropping an useless part to add yet another useless part, core is just our way to say org.apache.maven.plugins and it is obvious enough for any maven user that a groupId is owned by a project IMHO so either status quo on this one or drop prefix/suffix would be my 2 cts. 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. 6 mars 2024 à 15:16, Tamás Cservenák a écrit : > +1 to that definition > > On Wed, Mar 6, 2024 at 3:14 PM Konrad Windszus wrote: > > > Maven Core plugins are listed in https://maven.apache.org/plugins/. > > But I would say that this versioning policy applies to all plugins in > > groupId org.apache.maven.plugins….. > > > > Konrad > > > > > On 6. Mar 2024, at 15:06, Gary Gregory wrote: > > > > > > One issue from a non-Maven dev (me) is that I have no idea what is a > > > Maven "core" plugin vs. not. I would make that obvious for users, and > > > no, the "maven-" prefix does not make it obvious: > > > > > > maven-clean-plugin -> maven-core-clean-plugin or > maven4-core-clean-plugin > > > > > > I'm also not sure the "plugin" suffix is needed: > > > > > > maven-clean-plugin -> maven-core-clean or maven4-core-clean > > > > > > My preference is "maven4-core-clean" > > > > > > Gary > > > > > > On Wed, Mar 6, 2024 at 8:59 AM Tamás Cservenák > > wrote: > > >> > > >> Howdy, > > >> > > >> We have several topics that need to be discussed. > > >> > > >> I. Core Plugin Versioning > > >> > > >> History: When Maven2 was born, and started using plugins "as we know > > them > > >> today" (Maven 1 was a very different beast), the Core Plugin versions > > were > > >> started as 2.0 on purpose. Just check the Maven Central for historical > > >> versions, some examples: > > >> * clean > > >> > > > https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/ > > >> * compiler > > >> > > > https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/ > > >> * jar > > >> > > > https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/ > > >> * surefire > > >> > > > https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/ > > >> * dependency > > >> > > > https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/ > > >> > > >> So, Maven2 "as a fresh release" got all new shiny 2.0 plugins at the > > >> beginning. Later on, when Maven3 came to existence, it was able to use > > >> Maven2 plugins, the plugins were slowly migrated to become "Maven 3 > > >> plugins" (Maven2 could not use them anymore). This was denoted by the > > "3.x" > > >> major plugin version jump. > > >> > > >> So far, we have no 4.x plugin release of anything (M releases do not > > >> count). But my question is the following: > > >> > > >> How should we distinguish similar changes for Maven4? > > >> > > >> Explanation: when a plugin is migrated to Maven4 API, it will mean > > Maven3 > > >> will NOT be able to use anymore (will be incompatible). Similarly as > > >> before, Maven4 CAN run the "Maven 3" plugins, and will retain this > > >> capability for some time. But other ways it does not work, nor never > > worked > > >> (Maven3 will not be able to run Maven4 plugin, just like Maven2 never > > ran > > >> Maven3 plugin). > > >> > > >> For me, the logical answer to this question is the use of major > version > > >> 4.x. So just like it happened with Maven 2 to Maven 3 transition, a > >
Re: [DISCUSS] Maven Core Plugins versioning
Hi Tamas, Not sure I really got the issue, is it to do a breaking change without a maven-core bump? I tend to agree with you, ie the versioning is $mavenCoreMajor.$pluginMajor.$pluginMinor and no patch digit and guess it works good enough even for users, no? Best, 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. 6 mars 2024 à 14:59, Tamás Cservenák a écrit : > Howdy, > > We have several topics that need to be discussed. > > I. Core Plugin Versioning > > History: When Maven2 was born, and started using plugins "as we know them > today" (Maven 1 was a very different beast), the Core Plugin versions were > started as 2.0 on purpose. Just check the Maven Central for historical > versions, some examples: > * clean > > https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/ > * compiler > > https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/ > * jar > > https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/ > * surefire > > https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/ > * dependency > > https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/ > > So, Maven2 "as a fresh release" got all new shiny 2.0 plugins at the > beginning. Later on, when Maven3 came to existence, it was able to use > Maven2 plugins, the plugins were slowly migrated to become "Maven 3 > plugins" (Maven2 could not use them anymore). This was denoted by the "3.x" > major plugin version jump. > > So far, we have no 4.x plugin release of anything (M releases do not > count). But my question is the following: > > How should we distinguish similar changes for Maven4? > > Explanation: when a plugin is migrated to Maven4 API, it will mean Maven3 > will NOT be able to use anymore (will be incompatible). Similarly as > before, Maven4 CAN run the "Maven 3" plugins, and will retain this > capability for some time. But other ways it does not work, nor never worked > (Maven3 will not be able to run Maven4 plugin, just like Maven2 never ran > Maven3 plugin). > > For me, the logical answer to this question is the use of major version > 4.x. So just like it happened with Maven 2 to Maven 3 transition, a plugin > version 2.x meant "Maven2 plugin", version 3.x of plugin meant "Maven3 > plugin" (Maven2 incompatible). > > As otherwise, if we start releasing Core plugins 4.x or 5.x, we will > confuse the hell out of our users. At least that is what I think. > > II. Consequence: How to interpret Core plugin versions > > As can be seen above, so far the major version of the plugin was kinda > showing "which Maven API level" is the plugin. > > So, it begs the question: HOW to interpret the Maven Core Plugin version? > > My interpretation was always: "shift it once left", meaning: Core plugin > version "3.2.1" MEANS: > - Maven API version: 3 > - Core Plugin version 2.1(.0) > > III. Consequence: How to express Core plugin "breaking change"? > > Today, everyone expects a "major version jump" to express breaking changes. > BUT, as explained above, that would be totally misleading here, and would > break the "customary law" that Major expresses Maven lineage. > > Ideas and opinions welcome. > > T >
Re: Logging in Maven 4
Le lun. 4 mars 2024 à 10:49, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Note: this logging issue is not very important. If there is such > resistance against it, I will not insist. > > > Le 2024-03-04 à 08 h 35, Romain Manni-Bucau a écrit : > > > Please read > > > https://docs.oracle.com/javase%2F9%2Fdocs%2Fapi%2F%2F/java/lang/System.LoggerFinder.html > I have already read that. The idea that System.Logger instance MUST be > obtained thought a LoggerFinder is your own interpretation not backed by > any statement in the Javadoc. For me, it is as valid as saying that > Java.nio.file.Path instances MUST be obtained by calls to Path.of(...), > that java.io.PrintStream instances MUST be System.out or System.err, > etc. If I'm wrong, please point us to the exact sentence in the contract. > As any interface you can also change it - and trust me I'm one of those who did it a lot ;) - but it is also always misleading to end user to get an instance which does not come from the expected factory if this one has a standard and here it is the finder. So technically feasible but I'm not convinced it would be sane for end user and, again, the point is that it does not help on the topic. > > > > "But System.Logger is the same compromise and is as suitable as Log." > > this is nonsense to me since it is strictly equivalent in terms of API > > but not in terms of maven guarantee and stability for plugin writers" > Please elaborate: why a Maven interface would provide more stability > guarantees than a standard Java interface in which all methods are > equivalent? A reason other than claiming that using a System.Logger > instance not provided by LoggerFinder would break applications, unless > you can demonstrate that. > > > > "However, there is nothing in System.Logger, System.getLogger() or > > System.LoggerFinder javadoc saying that we should not use it." - cause > > you don't care about the issue maven api solves for now. > What are the issues that Maven API solves that an equivalent standard > interface does not solve? "Stability" is vague. Can you give an example? > Being maven owned and abstracted from a standard which moves. We can make log contextual whereas if we implement the standard we need to...implement it, any method, any version. This just does not work, the famous slf4j standard beat us already and JVM makes its API evolving so it can break us any time, check out Stream usage in CDI (Instance) for an example. So we need a maven owned abstraction. > > > > Also "Maven, which need more than println but not as much as a real > > logging framework" is wrong, this is only the local case for a subset > > of plugins, anything else needs a real logging system and mvnd too. > Okay. But it can be a two steps process. First use the standard > interface when it fits the exact same purpose than the Maven interface, > and later separate "logging" from "console output". > Hmm, I don't see much issue there, for me whatever we do we'll end up in current state more or less cause it is the need even if not as neat as we all would like and splitting would be worse cause mix the API and make it even more complicated for consumers so not sure I'm keen to have 2 API. Maybe a stream redirector to the logging API in a shared module can help but will end in the same layers IMHO. > > > > @Pavel: exactly cause the API is only a part of the solution, the > > lifecycle is another one and there System.Logger fills another gap the > > JVM had and was using System.out before as explained in the first > > responses. > The fact that System.Logger fills a gap does not mean that it is not > intended to be used for any other purpose. The LoggerFinder javadoc > mentions "Libraries and classes that only need loggers". The fact that > the interface was added in `java.lang` package suggests that it is > intended to be used. E.g., it is a way for libraries to keep the > "java.logging" module optional. > Yes and not, it is literally a design constraint of the JVM from my window cause it must be used for low level/bootstrap log so no real choice than putting it in lang and opening it. When it popped out a lot of backend tried to use it primarly but today it is a dead topic, not sure there was a lot of pitfall except the fact it is an api without backend but the main blocker for me would be the lifecycle and fact we loose the guarantee of instrumentation kind of forcing people to await for next release to upgrade which is something we don't impose as of today and I think it is good to be able to adopt new jvm releases faster, even if it sometimes needs some hack in dependencies, rather than awaiting. Indeed just my o
Re: Logging in Maven 4
Martin Please read https://docs.oracle.com/javase%2F9%2Fdocs%2Fapi%2F%2F/java/lang/System.LoggerFinder.html And "For the third time" we already have it Also please stop this kind of statement "But System.Logger is the same compromise and is as suitable as Log." this is nonsense to me since it is strictly equivalent in terms of API but not in terms of maven guarantee and stability for plugin writers which is the only point to have our log API and not reuse JUL. Similarly "However, there is nothing in System.Logger, System.getLogger() or System.LoggerFinder javadoc saying that we should not use it." - cause you don't care about the issue maven api solves for now. So there is no real way we do it, as I repeated 3 times, cause the key is not the API. Also "Maven, which need more than println but not as much as a real logging framework" is wrong, this is only the local case for a subset of plugins, anything else needs a real logging system and mvnd too. Think you generalized too much compiler work you did but it is not the maven generic case. @Pavel: exactly cause the API is only a part of the solution, the lifecycle is another one and there System.Logger fills another gap the JVM had and was using System.out before as explained in the first responses. 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 lun. 4 mars 2024 à 01:13, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2024-03-04 à 00 h 31, Pavel Horal a écrit : > > > > isn't System.Logger mainly for JDK internals? I always thought that > > using it is in a similar ballpark as using java.util.Optional in > > method arguments (i.e. „please don’t“). > > > System.Logger was needed by JDK internal, e.g. because of bootstrapping > issues. Another reason is that java.logging is a separated JPMS module, > so the java.base module cannot depend on it. However, there is nothing > in System.Logger, System.getLogger() or System.LoggerFinder javadoc > saying that we should not use it. If it was the case, I think that > Oracle would not have placed those interfaces in public API, and > certainly not in the java.lang package which is implicitly imported by > everyone. > > System.Logger can be used by applications that want to keep the > java.logging module optional. It is also a good fit for applications, > like Maven, which need more than println but not as much as a real > logging framework. > > Martin > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Logging in Maven 4
Le dim. 3 mars 2024 à 22:28, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2024-03-03 à 20 h 38, Romain Manni-Bucau a écrit : > > > the idea of maven-api was to abstract anything from the implementation > > to be able to change > A standard Java interface is as good as a Maven interface for that > purpose if they define equivalent methods, which is the case of > System.Logger versus Maven Log. > > > > if you use System.Logger you can't until you don't respect the > > contract which implies LoggerFinder is used which would be a > > misbehavior of the JVM for any user - and as overriding JUL it is used. > I'm not aware of any contract saying that System.Logger must be obtained > by System.getLogger(). The Javadoc only said "are typically obtained > from the System class". Users are not supposed to expect a particular > implementation. If the logger is provided by IOC (as it is in Maven), > users are not supposed to expect that the instance was fetched in any > particular way. > It is expected to use System so the logger finder. if it is not the case you broke the contract of this API. Indeed it works but the setup will be misbehaving: as an user you switch the backend and it is not used. > > > > So you mean reusing existing impl? this would be handled by maven > > bridge so not an issue to me, same as today there. > As said above, the purpose of an interface is to allow implementation to > change. I provided an example where switching to the standard > implementation would be useful for debugging purposes. The standards > implementations need to be invoked directly (not through a custom Log > interface) for providing useful "source class" and "source method" > information. That is the issue. I'm not sure what a "Maven bridge" is, > but if it is some kind of wrappers, this is an extra complexity which > need to be justified by extra features. In the current Maven Log > interface, there is no such extra features except slightly more compact > method calls (logging levels as method names instead of a method > parameter). > As a matter of fact it is current state so not sure what you want to enable. The extra complexity is justified by owning the implementation and ensuring its stability and behavior accross JDK and versions. It is the same rational than creating maven-api to not restate the 10 years of discussion leading to that. Using the JDK would have been an option, JUL had been proposed multiple times and just needs a thin layer - like tomcat one for ex to enable logging config per classrealm - but core committers always had been opposed to that and System.Logger has some limitations and would need the same glue anyway so guess Log will stay and we'll keep delegating until an user backend which supports or not these features (not saying I find our solution good but we were close to worse using slf4j directly which is out of our control, proven not stable enough and conflicts with mojo to make it even more explicit). > > > > I'm not sure what you plan to do but it is the same amount of work > > (normalized by the capacity of the API, indeed JUL has more API than > > current System.Logger). > I have no plan yet, only making a proposal based on what I saw in the > Maven compiler plugin. I agree that java.util.logging has more > capabilities and I would generally be in favour of switching to it (this > is what I use myself in my projects). However, in the particular case of > Maven, the situation is a little bit different because Maven uses the > Log interface sometime for logging, and sometime for console output. For > example, the Maven compiler plugin produces some messages saying "Using > XYZ" (this is logging), then a block of text representing the Mojo > execution result (success or failure) for the person who launched Maven > (this is console output). So in the way that it is used by Maven, Log is > not really a logger interface but rather a "println" facade which can > also, in some occasions, be a real logger. > Guess the mixture here is the one any plugin doing an exec (or similar like ToolProvider) has: how to forward the stdout/stderr to the logging system, often it is per line (and it makes sense to not hang and log everything at once) but has the pitfall to use the logger as a println. But it is a particular consumer usage, this is not what Log defines, it defines a real logger and some plugin use it as println cause it is what they need from my understanding. > > The proposal to use System.Logger is just that: continue to use it as a > "println" facade as Maven currently does, but with the added capability > to switch to a useful logger when needed (e.g. for debugging). > Ok,
Re: Logging in Maven 4
Le dim. 3 mars 2024 à 19:18, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2024-03-03 à 18 h 48, Romain Manni-Bucau a écrit : > > >> (snip) Nothing force us to use System.getLogger() for getting an > >> instance of that interface. (snip) > >> > > Yes but you make something well specified misbehaving so while > > technically true I think it would deserve us on the long run. > > > I do not understand this argument. The proposal is to replace a custom > interface by a standard one doing the same thing. How to get an instance > of that interface does not need to change. This is currently done that > way in Maven Mojos: > > @Inject > protected Log logger > > It would stay as before, except that Log would become System.Logger. > Where do you see a misbehaviour? > Ok, then the idea of maven-api was to abstract anything from the implementation to be able to change, as you can see if you use System.Logger you can't until you don't respect the contract which implies LoggerFinder is used which would be a misbehavior of the JVM for any user - and as overriding JUL it is used. > > > >> I did not talked about performance, but about misleading information > >> filled in log record (snip). > > > > For me it means a bug in the implementation > > > It is not a bug. When a logger uses stackwalker for determining who is > logging, it stops at the first stack frame which is not a method > internal to the logger implementation. It has no way to know that it > should continue a few more frames further. There is no API for saying > "please ignore stack frames that are inside the Maven Log class". > So you mean reusing existing impl? this would be handled by maven bridge so not an issue to me, same as today there. > > When using java.util.logging, we can override the automatic detection by > our own. But this is more work, e.g. we have to replace all calls to a > Logger.log(…) method by a call to our custom method which will override > the LogRecord default values. However 1) we cannot do that with > System.Logger, and 2) we don't need this complication at all if we just > use the logger directly, without passing through a Maven custom interface. > I'm not sure what you plan to do but it is the same amount of work (normalized by the capacity of the API, indeed JUL has more API than current System.Logger). Long story short it is a matter of using https://github.com/apache/cxf/blob/main/core/src/main/java/org/apache/cxf/common/logging/AbstractDelegatingLogger.java . > > > > So overall I'm not sure the goal, > > > For example when Maven is run with the --debug flag, it could use the > logger provided by System.getLogger() instead of the Maven default > "println-like" logger. We may lost coloration, but each log message > would be preceded by a line telling which method in which class emitted > that log. This is very useful when there is no exception stack trace but > we still want to look in the code what is going on. > Hmm, I see so you mean if we change everything we could get the same than what we have today? You can already switch slf4j binding - I use JUL for ex but logback is another common one - and get these info. So if it is your goal I guess we can work on the documentation only? > > Martin > >
Re: Logging in Maven 4
Le dim. 3 mars 2024 à 17:50, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Hello Romain > > Le 2024-03-03 à 17 h 02, Romain Manni-Bucau a écrit : > > > SystemLogger has the ServiceLoader "pick random first" implementation > > which is not what we want > > > You are describing the behavior of the System.getLogger() method. I was > talking about the use of the System.Logger interface. Nothing force us > to use System.getLogger() for getting an instance of that interface. The > flexibility is the same as before, except that it become possible to use > System.getLogger() if desired. > Yes but you make something well specified misbehaving so while technically true I think it would deserve us on the long run. > > > > If we want to drop Log we would rather go to JUL, which stays more > > powerful in terms of API, usable in terms of implementation and still > > as pluggable as SystemLogger for a runtime like maven. > > > Yes, I also prefer java.util.logging. I proposed System.Logger because > it has a one-to-one match with the current Maven Log (except in the way > to specify the logging level). It is also less work for creating a > custom implementation, which is apparently what Maven wants (it > basically uses logger as a "println" functionality). > JUL is quite easy - very easy now we have stackwalker ;) - so I don't think it would have been a blocker by itself. > > > > The point about performance is kind of behind now we are java 17 we > > have stackwalker so an integration thing but no more the old new > > Throwable().getStackTrace() blocker. > > > I did not talked about performance, but about misleading information > filled in log record. No matter if using stackwalker of exception trace, > is System.Logger or java.util.logging are not used directly in the code, > by default the source class name and source method name reported in the > log record will be the class name / method name of the wrapper (for > example Maven Log class) instead of the name of the place where the log > occurred. We can fix that with java.util.logging at the cost of some > effort, but not with System.Logger (as far as I know). > For me it means a bug in the implementation so no more an issue than doing a logger.severe instead of info in mavenLog.info. So maybe not a blocker? > > > > I tend to agree with your point about N records (N>1) vs 1 record but > > this is independent of all log API you mentionned. > > > I did not said that we need to change the log API for doing that, but > that the fact that the use of System.Logger is more tedious (because of > the way to specify logging level) may not be a bad thing, because it can > be an incentive to fix that. > Ok but this is not linked to a specific logger AFAIK. So overall I'm not sure the goal, replace slf4j? (if so i would support you ;)) > > Martin > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Logging in Maven 4
Hi,
I'm not sure I got what we would gain but here is my view on this topic:
* SystemLogger has the ServiceLoader "pick random first" implementation
which is not what we want I think and the API stays low level,
* If we want to drop Log we would rather go to JUL, which stays more
powerful in terms of API, usable in terms of implementation and stillas
pluggable as SystemLogger for a runtime like maven,
* The point about performance is kind of behind now we are java 17 we have
stackwalker so an integration thing but no more the old new
Throwable().getStackTrace() blocker,
* I tend to agree with your point about N records (N>1) vs 1 record but
this is independent of all log API you mentionned, we can fix it with maven
old log api, the new one, java or anything, it is a caller thing - but more
than agree we should stop logging lines but think records.
Guess I got your mail right and didn't interpret the multiple points I
understood.
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 dim. 3 mars 2024 à 15:59, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Maven 4 defines a new interface, `org.apache.maven.api.plugin.Log`, with
> the usual debug(…), info(…), warn(…) and error(…) methods in it. Should
> we replace that by `java.lang.System.Logger`? (now possible with Java
> 17) The latter is also an interface, so we have the same flexibility for
> customization. The only drawback I could see is that codes such as
> `logger.info("something")` would become
> `logger.log(System.Logger.Level.INFO, "something")`, which is more
> tedious to write. However, this inconvenience may actually be a good
> thing (see below).
>
> We could keep the Maven `Log` interface as a wrapper around
> `System.Logger` for convenience. However, some logging implementations
> such as `java.util.logging` use Java reflection for detecting the caller
> class and method. If we keep the Maven `Log` as a convenience instead of
> direct use of `System.Logger`, I suspect that some logging systems will
> think that all logs always come from `org.apache.maven.api.plugin.Log`.
> This automatic detection is the reason why I propose a complete
> replacement.
>
> The current logger is used by Maven like below:
>
>
> getLog().info("-");
> getLog().error("COMPILATION ERROR : ");
>
> getLog().info("-");
> getLog().info(something);
>
> getLog().info("-");
>
> For most logging systems, the above is 5 log records, while actually
> there is only 1 log record and the rest is formatting. The fact that
> System.Logger is more verbose to use may encourage a better pattern like
> below, which results in a single log record:
>
> getLog().log(System.Logger.Level.ERROR,
> """
> -
> COMPILATION ERROR :
> -
> """
> + something +
> """
> -
> """);
>
> The previous code snippet was mixing info(…) and error(…) maybe for
> coloration. But I see that Maven 4 has a MessageBuilder interface for
> this task, so the log record could be rewritten again like below:
>
> MessageBuilder mb = messageBuilderFactory.builder()
>
>
> .info("-").newLine()
> .error("COMPILATION ERROR : ").newLine()
>
>
> .info("-").newLine()
> .info(something).newLine()
>
>
> .info("-").newLine();
> getLog().log(System.Logger.Level.ERROR, md.build());
>
> Any opinion?
>
> Martin
>
>
Re: [VOTE] Require Java 17 for Maven 4
+1 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. 28 févr. 2024 à 08:35, Stephane Nicoll a écrit : > +1 (non binding) > > On Wed, Feb 28, 2024 at 8:31 AM Benjamin Marwell > wrote: > > > Hi Maven Devs/Users/Committers and PMC members! > > > > After several discussions on the mailing lists, I would like to > > start a vote in favour of setting the minimal Java bytecode target > > of Maven-Core 4 to 17 and hence require Java 17 for Maven 4. > > > > This is a procedural majority vote [1*]: > > You can also vote with fractions and negative votes are not vetoes. > > > > Please also notice: > > * Maven 3 will stay at Java 8 no matter what. > > * We may raise Maven 4 to JDK 21 later if we feel like it (depending > > on the release date). > > This is not part of this vote. > > * The linked PR is not part of this vote (this is not a code vote). > > But you may take a look at it to understand the intended change. > > > > PR: https://github.com/apache/maven/pull/1430 > > > > Maven-Parent will not be raised with this vote, the other PR is not > > part of this vote. > > > > Please refrain from starting discussions in this thread, but do > > include a reasoning on downvotes and feel free to start a new > > discussion on the mailing list, or comment on the existing ones. > > > > --- > > > > Vote open for 72 hours: > > > > [ ] +1 (set JDK17 min version for Maven 4.x) > > [ ] +0 > > [ ] -1 (please include reasoning) > > > > --- > > > > - Ben > > > > [1*]: https://www.apache.org/foundation/voting.html > > >
Re: [DISCUSS] Java version for Maven
Hi Hervé Im not sure why there is this belief toolchain improvement is needed, this is NOT needed and CI already bypass it so for me this is not an enabler, more a blocker IRL. Let's improve plugins if they dont enable executable/env config but toolchain is just a part of the execution of so troublesome to maintain that I cant see it as a solution to any problem. Le mer. 28 févr. 2024 à 08:03, Hervé Boutemy a écrit : > Le mardi 27 février 2024, 13:32:36 CET Elliotte Rusty Harold a écrit : > > Toolchains support using JDK 8 to compile even though JDK 17 is > > executing Maven, which does handle this. Unfortunately toolchains are > > poorly designed, badly documented, and not widely understood within > > the community. I'm trying to improve some of the docs for toolchains, > > but that only goes so far. There's a fundamental problem that > > toolchains are incompatible with a hermetic, one click build. > > +1 (taking apart the "poorly designed" aspect) > > that's why toolchain improvement is one necessary enabler > > another one is plugins prerequisites history > > in the whole discussion, I did not find any other enabler: please chime in > if > you saw one > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [DISCUSS] Java version for Maven
Plain standard asf votes - or under the vote manager rules as allowed by asf if it is agreed but means another discussion. I dont care much the details but keeping energy for this thread starts to be more negative on the community than anything positive IMHO so hope we close it with a decision then move on. Not everybody will be happy but we'll stop cycles hopefully and unhappy people will be able to work on solutions after anyway. Le mar. 27 févr. 2024 à 20:02, Aleksandar Kurtakov a écrit : > On Tue, Feb 27, 2024 at 8:16 PM Xeno Amess wrote: > > > whose vote would count and what be the majority:) > > for example should my vote count? or not? > > or just some committers? but why just committers(or not)(as some of them > > might have less contributions even than non-committers)? > > or just pmc? > > or everyone share 1 vote(wow I don't think it shall work this way) > > > > This is something that should be defined by Apache Foundation and/or Maven > PMC. I don't plan to neither dive into the discussion more nor to try > imposing our rules on another project. > If the project believes that continuing such discussion in circles brings > anything good - so be it. > > > > > > > > > Aleksandar Kurtakov 于2024年2月28日周三 01:15写道： > > > > > On Tue, Feb 27, 2024 at 6:13 PM Romain Manni-Bucau < > > rmannibu...@gmail.com> > > > wrote: > > > > > > > Not sure we'll converge guys but shouldnt we make a vote? Seems we > all > > > > understand the impacts technically so maybe time to decide else we'll > > > still > > > > be there in a year. > > > > > > > > > > This is exactly what I try in the Eclipse community - vote, majority > wins > > > and move on. > > > If there is one thing I'm 100% sure now is that no one from one camp > will > > > convince someone from the other camp so all the endless discussions > bring > > > only extra stress. > > > > > > > > > > > > > > Le mar. 27 févr. 2024 à 16:41, John Neffenger a > > > écrit : > > > > > > > > > On 2/26/24 11:42 AM, Basil Crow wrote: > > > > > > We had a similar conversation in the Jenkins community, and I > wrote > > > up > > > > > > our conclusions here: > > > > > > > > > > We also had a similar conversation in the NetBeans community, with > > the > > > > > final vote to drop JDK 8 (vote result: 20 to 1.5). See here: > > > > > > > > > > [VOTE][RESULT] Minimum JDK build and run policy (dropping JDK 8) > > > > > https://lists.apache.org/thread/oq8bof3owctq0ot6xwk03n3w45d09zcc > > > > > > > > > > In particular, see the comments from James Gosling: > > > > > > > > > > Re: Lets talk about JDK 8 (new year edition) > > > > > https://lists.apache.org/thread/sspm6fy1xq0jn2k8lfprn47v69g88jvh > > > > > > > > > >"So…. In my opinion, JDK8 must die." > > > > >"Stop the unholy contortions to coexist. Kill it. Nail its > > coffin > > > > > closed. Do not look back." > > > > > > > > > > I couldn't agree more. :-) > > > > > > > > > > John > > > > > > > > > > > - > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > > > > > > > -- > > > Aleksandar Kurtakov > > > Red Hat Eclipse Team > > > > > > > > -- > Aleksandar Kurtakov > Red Hat Eclipse Team >
Re: [DISCUSS] Java version for Maven
Not sure we'll converge guys but shouldnt we make a vote? Seems we all understand the impacts technically so maybe time to decide else we'll still be there in a year. Le mar. 27 févr. 2024 à 16:41, John Neffenger a écrit : > On 2/26/24 11:42 AM, Basil Crow wrote: > > We had a similar conversation in the Jenkins community, and I wrote up > > our conclusions here: > > We also had a similar conversation in the NetBeans community, with the > final vote to drop JDK 8 (vote result: 20 to 1.5). See here: > > [VOTE][RESULT] Minimum JDK build and run policy (dropping JDK 8) > https://lists.apache.org/thread/oq8bof3owctq0ot6xwk03n3w45d09zcc > > In particular, see the comments from James Gosling: > > Re: Lets talk about JDK 8 (new year edition) > https://lists.apache.org/thread/sspm6fy1xq0jn2k8lfprn47v69g88jvh > >"So…. In my opinion, JDK8 must die." >"Stop the unholy contortions to coexist. Kill it. Nail its coffin > closed. Do not look back." > > I couldn't agree more. :-) > > John > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [DISCUSS] Java version for Maven
>From my experience people hating var will also hate completionstage and at some point streams (or they willfully embrace them just using forEach which is a counter usage IMHO). Every time I digged it was 100% a knowledge+(IT) culture thing. But once again, I'm not sure it is about us - if so I would say I don't care much - but how attracting we can be since our community is not crazy active outside. This is for an an opportunity we should take IMHO. Now if we just want to speak about style and lib usage I guess we have enough threads showing we all diverge so not sure there is a way to converge anytime - nor the need to be honest. 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 ven. 23 févr. 2024 à 15:10, Tamás Cservenák a écrit : > Make love not var! > > T > > On Fri, Feb 23, 2024 at 3:09 PM Xeno Amess wrote: > > > I hate var. > > > > From: Tamás Cservenák > > Sent: Friday, February 23, 2024 9:52:08 PM > > To: Maven Developers List > > Subject: Re: [DISCUSS] Java version for Maven > > > > Howdy, > > > > Some more stats based on 2nd package from Brian > > > > https://gist.github.com/cstamas/8207f8d70882090a1c63cdedc256ec56 > > > > On Fri, Feb 23, 2024 at 2:08 PM Elliotte Rusty Harold < > elh...@ibiblio.org> > > wrote: > > > > > Yes, with var you still get type checks, unlike in Python. But I have > > > wasted so much time debugging Python code simply because the type of a > > > local variable wasn't right there in the declaration that I remain > > > unconvinced var was ever a good idea. I have been convinced by > > > experience that implicitly typed local variables dramatically reduce > > > debugging speed. This isn't something I believed two years ago. Back > > > then I mostly didn't think about it. But since then I have worked a > > > lot with implicit typing, and it is painful. > > > > > > IDEs are not a full solution. They're better in Java than Python, I > > > admit, but I spend more time reading code in tools like Github and > > > Critique than in IDEs. > > > > > > I don't think banning var goes against the community in any way. It's > > > simply another style choice for improved readability and > > > maintainability, like everything spotless and checkstyle currently do. > > > > > > > > > On Fri, Feb 23, 2024 at 12:58 PM Romain Manni-Bucau > > > wrote: > > > > > > > > Le ven. 23 févr. 2024 à 13:44, Elliotte Rusty Harold < > > elh...@ibiblio.org> > > > a > > > > écrit : > > > > > > > > > On Fri, Feb 23, 2024 at 12:23 PM Romain Manni-Bucau > > > > > wrote: > > > > > > > > > > > > @Elliotte while you are pretty right in terms of *compile* > features > > > but > > > > > it > > > > > > ignores the biggest criteria for any ASF project : the community. > > > Even if > > > > > > silly, attracting people with Java 8 is born dead today (to > > > illustrate it > > > > > > just ask somebody to no more use "var" to do a PR for ex, he will > > > start > > > > > to > > > > > > "pf" ;)). > > > > > > > > > > Going off on a tangent but I would reject any PR that showed up in > my > > > > > code review queue that used "var", regardless of JDK version. It's > an > > > > > abomination that should never have been added to Java. It > prioritizes > > > > > a trivial speed up in writing code at the cost of a significant > slow > > > > > down in reading and debugging code. Working in Python for the last > > > > > couple of years has thoroughly convinced me that strong, explicit > > > > > compile time types are the right way to go. I've seen what happens > > > > > when you don't have them, and it's not fun. > > > > > > > > > > > > > I assume you never used it to write that cause you don't loose > compile > > > > checks, you are not slower to read nor debug but generally faster > cause > > > > readability is increased and if you miss
Re: [DISCUSS] Java version for Maven
Le ven. 23 févr. 2024 à 13:44, Elliotte Rusty Harold a écrit : > On Fri, Feb 23, 2024 at 12:23 PM Romain Manni-Bucau > wrote: > > > > @Elliotte while you are pretty right in terms of *compile* features but > it > > ignores the biggest criteria for any ASF project : the community. Even if > > silly, attracting people with Java 8 is born dead today (to illustrate it > > just ask somebody to no more use "var" to do a PR for ex, he will start > to > > "pf" ;)). > > Going off on a tangent but I would reject any PR that showed up in my > code review queue that used "var", regardless of JDK version. It's an > abomination that should never have been added to Java. It prioritizes > a trivial speed up in writing code at the cost of a significant slow > down in reading and debugging code. Working in Python for the last > couple of years has thoroughly convinced me that strong, explicit > compile time types are the right way to go. I've seen what happens > when you don't have them, and it's not fun. > I assume you never used it to write that cause you don't loose compile checks, you are not slower to read nor debug but generally faster cause readability is increased and if you miss the 35 char long type your preferred IDE will compensate that easily. It is literally similar to streams or even plain old java, it depends the habit of the coder but if we consider that we would also prevent foreach usage. You can also reverse it and write the exact same sentence on "not using var", how slow it is to read such a code where half of the chars don't bring any useful data or encourage palantir formatting to break on multiple lines a single statement. So IMHO this is not something right to think nor even consider. Ultimately the point is not "do we think it is good or not", it is literally that if we go against the move then we go against the community - keep in mind we should probably not be the primary citizens there - and therefore I'm not sure the point to be at Apache if we don't care about our community. I'm clearly to stay there and enable people to join rather than staying alone 10 years ago (happy anniversary java 8 ;)). > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [DISCUSS] Java version for Maven
@Elliotte while you are pretty right in terms of *compile* features but it ignores the biggest criteria for any ASF project : the community. Even if silly, attracting people with Java 8 is born dead today (to illustrate it just ask somebody to no more use "var" to do a PR for ex, he will start to "pf" ;)). So most of the challenge here is to stay an active community and not a dying one and using recent enough JDK is a good way to encourage it IMHO. 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 ven. 23 févr. 2024 à 13:15, Elliotte Rusty Harold a écrit : > On Fri, Feb 23, 2024 at 12:20 AM Robert Dean wrote: > > > That being said, if retiring Java 8 and lower output support allows > > Maven to shed technical debt and deliver improvements faster, I'd get > > over my disappointment. :) > > Given the amount of tech debt still in Maven from Maven 2 and earlier, > I don't think shifting the JDK version is likely to have any positive > impact or let improvements arise any faster. In fact, the opposite is > likely true. This is a variant of the xkcd 927 problem. > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [DISCUSS] Java version for Maven
Guess we interleave too much topics. Do we agree on the starting point which is we must comply to the "default" JDK users will get by design, ie the --release one? If so then we should just cover +65% of the targetted JDK and use the minimum as min requirement for end users, period. If not then we should refine the prerequisites to run maven. Side note: this let us free to use java ea if we want on our CI and for releases, we just have to ensure we run on the minimum supported versions tests - without compilation to have some harnessing. 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 jeu. 22 févr. 2024 à 12:51, Tamás Cservenák a écrit : > Exactly! > > When it all started, the "hurdle" to jump 8 > 11 was smaller, but > whoever jumped, was literally free after. > Today, as 11 is dead, the "hurdle" has been raised to 8 > 17, so whoever is > still waiting, is just piling up problems and more work for themselves. > > T > > On Thu, Feb 22, 2024 at 12:49 PM Mateusz Gajewski < > mateusz.gajew...@starburstdata.com> wrote: > > > Actually as Trino solves a federation problem, we pull in a lot of > > dependencies (over 800) and we spent a significant amount of time > patching > > and fixing upstream dependencies like Hadoop, Hive, Parquet etc to > migrate > > to JDK 17 when it was released, and lately to 21. Migration from 11 to 17 > > was painful due to "strong encapsulation by default". From 17 to 21 was > > pretty painless - just a bunch of libraries that needed ASM upgrade and > > some deprecated encryption schemes. To my surprise, different OSS > > communities are now much more aware of the new JDK versions so testing > and > > fixing happens in advance. > > > > On the "big companies stays legacy" topic, we sell the enterprise edition > > of Trino (called Starburst Enterprise) which is on-premise, COTS software > > to the largest (and probably oldest) companies in the world (from a > > variety of sectors). When we plan to transition to a new JDK we inform > our > > customers several months in advance that this will happen. With JDK 17 we > > saw some pushback and we delayed the transition for a couple of months, > but > > with JDK 21 the situation was totally different - we announced that this > > would happen in advance too but this time the feedback was "oh, we've > > already allowed JDK 21 usage in our infrastructure, go ahead". Which was > > both surprising and encouraging. > > > > Times are changing. > > > > On Thu, Feb 22, 2024 at 11:22 AM Romain Manni-Bucau < > rmannibu...@gmail.com> > > wrote: > > > >> @Tamás Cservenák if you read carefully I never > >> wrote > >> "all Java 21 projects are toy projects" ;). Eclipse is also not a topic, > >> it > >> comes as a distro. Quarkus is still 17+21, trinodb is not something > >> primarly embedding code, it is more a standalone so more counter > examples > >> from my understanding of what Maven stands for. > >> And yes, a lot of java 21 code will be thrown away today, I never said > 50% > >> (even less 100% as you meant) but likely > 25%, sure. Same happent for > >> java > >> 8, 11, 17 so not sure why 21 would be different. > >> Does not say 21 is not adopted - I literally wrote the opposite, just > >> meant > >> we should always interpret figures for what they are and identify their > >> bias instead of biasing them more. > >> > >> Please note that --release does NOT solve anything, think to maven as an > >> ecosystem - plugins - and we still want to run with the contextual java > >> version I guess - if this hypothesis is wrong please close this thread > and > >> start a new about this minimalistic feature, if we want to drop that we > go > >> in the distro erea, drop plugins support but decision is not taken on > the > >> same points at all - we woud likely dont care of the java version we > would > >> go that path. > >> > >> Romain Manni-Bucau > >> @rmannibucau <https://twitter.com/rmannibucau> | Blog > >> <https://rmannibucau.metawerx.net/> | Old Blog > >> <http://rmannibucau.wordpress.com> | Github < > >> https://github.com/rmannibucau&
Re: [DISCUSS] Java version for Maven
@Tamás Cservenák if you read carefully I never wrote "all Java 21 projects are toy projects" ;). Eclipse is also not a topic, it comes as a distro. Quarkus is still 17+21, trinodb is not something primarly embedding code, it is more a standalone so more counter examples from my understanding of what Maven stands for. And yes, a lot of java 21 code will be thrown away today, I never said 50% (even less 100% as you meant) but likely > 25%, sure. Same happent for java 8, 11, 17 so not sure why 21 would be different. Does not say 21 is not adopted - I literally wrote the opposite, just meant we should always interpret figures for what they are and identify their bias instead of biasing them more. Please note that --release does NOT solve anything, think to maven as an ecosystem - plugins - and we still want to run with the contextual java version I guess - if this hypothesis is wrong please close this thread and start a new about this minimalistic feature, if we want to drop that we go in the distro erea, drop plugins support but decision is not taken on the same points at all - we woud likely dont care of the java version we would go that path. 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 jeu. 22 févr. 2024 à 11:06, Tamás Cservenák a écrit : > And one more remark regarding "toy projects": > You seriously mean that these numbers could be skewed by "toy projects"? > IMHO toy projects, while most probably represented here, are "lost, like > tears in the rain". > > T > > On Thu, Feb 22, 2024 at 10:39 AM Tamás Cservenák > wrote: > > > >> lot of java 21 tody is still PoC or toy projects > > > > Quarkus, TrinoDB or Eclipse are not toy projects. So they fact there ARE > > "toy projects", you should not derive that "all Java 21 projects are toy > > projects". > > > > T > > > > On Thu, Feb 22, 2024 at 10:32 AM Romain Manni-Bucau < > rmannibu...@gmail.com> > > wrote: > > > >> [joke]this last diagram looks like you are looking for piece[/] > >> > >> I'm not sure the weight can be linear like that, it is not because you > are > >> old that you will die - lot of java 21 tody is still PoC or toy projects > >> so > >> should be in the weight somehow if we go this way. > >> > >> Ultimately your user agent idea was really better than java stat alone > >> since it is really a cross matrix/time unit we should check. > >> > >> Sadly all these stats miss, for my understanding, the dynamic behind > (like > >> seeing a random point in a exponential vs linear graph, alone you don't > >> know where you are going to). > >> > >> From memory, trying to use the last years figures it seems the dynamic > is > >> to follow the LTS with some lateness, ie current is 21 but people are > >> around 11-17. Like a sliding window. > >> Indeed the public polls I use - the ones you get on twitter from > intellij > >> or friends - for that conclusion are biased cause they hit more "geeks" > >> than standard work people but I don't have anything better right now in > >> terms of time serie. > >> Anyone has more comparative data about that? > >> > >> My proposal/thought was really to align on that dynamic - from the > latest > >> to a limit to cover ~>=65% of people - more than fixing some version in > >> stone. > >> > >> 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 jeu. 22 févr. 2024 à 10:17, Tamás Cservenák a > >> écrit : > >> > >> > For start I "normalized" the Java strings to a form like "Java 8" or > >> "Java > >> > 17". This resulted in pretty much similar results as Romain PDF (Azul > >> > report). > >> > > >> > But then realized, we should cons
Re: [DISCUSS] Java version for Maven
[joke]this last diagram looks like you are looking for piece[/] I'm not sure the weight can be linear like that, it is not because you are old that you will die - lot of java 21 tody is still PoC or toy projects so should be in the weight somehow if we go this way. Ultimately your user agent idea was really better than java stat alone since it is really a cross matrix/time unit we should check. Sadly all these stats miss, for my understanding, the dynamic behind (like seeing a random point in a exponential vs linear graph, alone you don't know where you are going to). >From memory, trying to use the last years figures it seems the dynamic is to follow the LTS with some lateness, ie current is 21 but people are around 11-17. Like a sliding window. Indeed the public polls I use - the ones you get on twitter from intellij or friends - for that conclusion are biased cause they hit more "geeks" than standard work people but I don't have anything better right now in terms of time serie. Anyone has more comparative data about that? My proposal/thought was really to align on that dynamic - from the latest to a limit to cover ~>=65% of people - more than fixing some version in stone. 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 jeu. 22 févr. 2024 à 10:17, Tamás Cservenák a écrit : > For start I "normalized" the Java strings to a form like "Java 8" or "Java > 17". This resulted in pretty much similar results as Romain PDF (Azul > report). > > But then realized, we should consider this: Not every LTS existed at the > same time span (and we discuss the future here, not the past). Here is some > history I collected: > > - Java 8: Covers strings like "Java 1.8.0-25" (2014) to "Java 1.8.0-401" > (2024), that is 10 year span. > - Java 11: Covers strings like "Java 11-ea" (2018) to "Java 11.0.22" > (2024), that is a 6 year span. > - Java 17: Covers strings like "Java 17-ea" (2021) to "Java 17.0.10" > (2024), that is a 3 year span. > - Java 21: Covers strings like "Java 21-ea" (2023) to "Java 21.0.2" (2024), > that is 1 year span. > > So, "normalized" and "weighted" (by lifespan) results are these: > https://gist.github.com/cstamas/d2e5560f24ebe6a667834aa1f44d6fc1 > > Weighted pie immediately shows which Java versions are "dead" (are present, > but are "sliding out") and which ones are "alive and kicking" (and adoption > is quite high). > > --- > > Refs: > - https://www.java.com/releases/ > - https://openjdk.org/projects/jdk/11/ > - https://openjdk.org/projects/jdk/17/ > - https://openjdk.org/projects/jdk/21/ > > On Thu, Feb 22, 2024 at 8:50 AM Tamás Cservenák > wrote: > > > Howdy, > > > > Maven UA is created like this: > > > > > https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L555 > > > > I was hoping also for a list of "Apache Maven ..." lines with occurrence > > count. > > > > Now am unsure, for example if any other tool would use "Java X" string in > > its own UA, is that collected here? > > > > But let's cook with what we have :) > > > > T > > > > > > On Thu, Feb 22, 2024, 08:03 Mateusz Gajewski < > > mateusz.gajew...@starburstdata.com> wrote: > > > >> Do you have maven version and java version at the same time report? I > >> wonder if old maven is used with old JDK :) > >> > >> On Wed, Feb 21, 2024 at 23:23 Brian Fox wrote: > >> > >> > Hi everyone. I haven't caught up on this thread but Tamas pinged me to > >> get > >> > some usage data from Central. Attached are the Maven versions and JDK > >> > Version counts as reported by User Agent by distinct IP for the last > 30 > >> > days: > >> > > >> > > >> > > >> > > >> > > >> > On Wed, Feb 21, 2024 at 4:15 PM Hunter C Payne > >> > wrote: > >> > > >> >> I also want to stress that we care about what maven supports far > more > >> >> than what it requires to build. If it needs JDK 17 to build but the > >> jars > >> >> are compliant with Java 8, that's f
Re: [DISCUSS] Java version for Maven
Hmm, not sure im ready for a 200M vanilla build tool even if it would have been ok legally... Le mer. 21 févr. 2024 à 21:41, Hunter C Payne a écrit : > I might be wrong but I understood that shipping the JRE/JVM required a > license and this is why most people don't ship with a JVM bundled. But > perhaps that has changed since the Oracle v Google/Alphabet trial. > Hunter > > On Wednesday, February 21, 2024 at 12:00:54 PM PST, Benjamin Marwell < > bmarw...@apache.org> wrote: > > FWIW, bazel changed its runtime requirement to Java 21. > But they are shipping their own Java Runtime, so their users won't notice. > [1] > > I think they are the first build tool to do that. > > I say this as a FYI fact only, not implying anything. > Make of it what you want. > > - Ben > > Am Di., 20. Feb. 2024 um 21:50 Uhr schrieb Tamás Cservenák > : > > > > Howdy, > > > > I intentionally used "Maven" here, and not "Maven 4" as I am sure the > > majority of Maven users do not run Maven on the same Java version they > > target with their build. We do not do that either. > > > > Some snippets from Herve (who is the ONLY one doing reproducible checks, > > kudos for that) votes: > > > > Sun, Feb 18, 2024, 9:38 AM > > [VOTE] Release Apache Maven Shade Plugin version 3.5.2 > > Reproducible Build ok: reference build done with JDK 11 on *nix > > > > Wed, Jan 31, 2024, 5:06 AM > > [VOTE] Release Apache Maven JLink Plugin version 3.2.0 > > Reproducible Builds ok: reference build done on *nix with JDK 21 and > umask > > 022 > > > > Mon, Jan 8, 2024, 8:29 AM > > [VOTE] Release Maven Plugin Tools version 3.11.0 > > Reproducible Builds ok: reference build done with JDK 8 on Windows with > > umask > > > > Mon, Dec 18, 2023, 8:59 AM > > [VOTE] Release Apache Maven Compiler Plugin version 3.12.0 > > Reproducible Builds ok: reference build done on *nix with JDK 21 and > umask > > 022 > > > > Mon, Dec 18, 2023, 8:59 AM > > [VOTE] Release Apache Maven Compiler Plugin version 3.12.0 > > Reproducible Builds ok: reference build done on *nix with JDK 21 and > umask > > 022 > > > > Wed, Nov 29, 2023, 8:16 AM > > [VOTE] Apache Maven Build Cache Extension 1.1.0 > > Reproducible Build ok: reference build done on *nix with JDK 11 > > > > Sun, Nov 19, 2023, 5:17 PM > > [VOTE] Release Maven Resolver 1.9.17 > > Reproducible Build ok: reference build done with JDK 21 on *nix with > umask > > 022 > > > > Sat, Oct 21, 2023, 4:34 PM > > VOTE] Apache Maven 4.0.0-alpha-8 release > > Reproducible Build ok: reference build done with JDK 21 on *nix with > umask > > 022 > > > > Mon, Oct 2, 2023, 9:11 AM > > [VOTE] Release Apache Maven 3.9.5 > > Reproducible not fully ok: reference build done with JDK 17 on *nix and > > umask 022 > > > > > > > > This CLEARLY shows the tendency: > > - Michael does releases on Java 8 (on windows!), he is a known "aligner" > > and windows person :) > > - Olivier used the "minimum" required Java version (for build cache). > > - Unsure why Herve used Java 11 for the Shade plugin... I mean, he could > > use 21 but also 8, but he shot for 11 that was EOL at the moment of > release. > > - The rest is 21. > > > > > > > > So, the question for those refusing anything other than Java 8 to _run_ > > Maven (or to revert: for those refusing to run Maven on "latest LTS", > that > > is currently 21): > > WHY? > > > > > > Thanks > > T > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [DISCUSS] Java version for Maven
Le mer. 21 févr. 2024 à 10:40, Xeno Amess a écrit :
> Hi.
> I use toolchain for multi-release-jars
> please don't drop it or provide another way for building multi release jars
>
I assume you mean compiler plugin, good news is that it is built-in and
named executable:
https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#executable
.
> ____
> From: Romain Manni-Bucau
> Sent: Wednesday, February 21, 2024 3:48:43 PM
> To: Maven Developers List
> Subject: Re: [DISCUSS] Java version for Maven
>
> Hi Hervé,
>
> +1000 on the philosophy!
>
> On the toolchain support I still fail to see why maven has toolchain
> anywhere in its code.
> Look it how it is used:
> * Tools are generally setup with env variables (JAVA_HOME, JAVA17_HOME,
> JAVAEA_HOME or alike)
> * Most plugins able to switch the JDK can switch the executable in their
> config and use by default ${env.JAVAxx_HOME} or whatever is desired which
> is the same indirection than toolchain but without the downside to setup a
> toolchain.xml. Then plugins can just use the binary (optionally PathExt on
> windows to get the extension) and be it, works really well.
>
> So overall I think we could drop toolchain which ultimately still misses a
> few parts to be complete in terms of env setup and make a shared-executable
> stronger - likely the future base of exec plugin even if not required.
>
> 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. 21 févr. 2024 à 08:39, Hervé Boutemy a
> écrit :
>
> > for sure, given the JDK almanach https://javaalmanac.io/jdk/ , we'll
> have
> > to update our plans
> > https://maven.apache.org/developers/compatibility-plan.html
> >
> > the approach I'd love to promote is "what do we require to not hurt our
> > diversity of users when upgrading minimum prerequisites" (and I'm doing
> it
> > on my free time because I do care about the diversity of our community)
> > => let's work on the enablers
> >
> > Java prerequisite for Maven core is something, but everything will start
> > from plugins: that's why we started the plugins "requirement history"
> > see for example
> > https://maven.apache.org/plugins/maven-shade-plugin/plugin-info.html
> >
> > for a summary on our own plugins, see last column of
> >
> >
> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html
> >
> > As you can see, not many plugins are not covered yet: who wants to work
> on
> > this?
> >
> >
> > Another good item cited is improving decoupling JDK of Maven from JDK to
> > compile and run tests.
> > IIRC, Guillaume prepared something about auto-importing available JDKs
> > from sdkman, which is a great idea: I don't know if this was closed done,
> > but I suppose other JDK switcher tools should be supported, I'm
> > particularly interested on knowing what Windows users need
> > One aspect that I know is not well done is that the MANIFEST in jar
> > describes JDK release from Maven core, not target: we should probably do
> > something
> > Another aspect is that toolchains support has to be enabled in pom.xml:
> it
> > would be useful for it to work from just CLI also.
> >
> > I'm sure there are other features that would be useful on this: who wants
> > to work on this?
> >
> >
> > The 2 previous enablers look sufficient to me: any other enabler someone
> > thinks about?
> >
> > And more importantly: who wants to work on it? plan, track progress,
> > document, explain?
> > we need community's help to prepare a smooth change: updating our plans
> > will be a consequence of this preparation
> >
> > Regards,
> >
> > Hervé
> >
> > Le mardi 20 février 2024, 21:49:03 CET Tamás Cservenák a écrit :
> > > Howdy,
> > >
> > > I intentionally used "Maven" here, and not "Maven 4" as I am sure the
> > > majority of Maven users do not run Maven on the same Java version they
> > > target with their build. We do not do that either.
> > >
> > > Some snippets from Herve (who is the ONLY one doing reproducible
> checks,
> > > kudos for that) votes:
> > >
&
Re: [DISCUSS] Java version for Maven
Le mer. 21 févr. 2024 à 09:07, Hervé Boutemy a
écrit :
> ok, you want to contribute on decoupling JDK of Maven vs JDK of compiler
> and
> tests: perhaps we'll need to open a separate discussion to avoid hijacking
> the
> global plan, but let's have one roundtrip
>
Just to clarify: I don't want but for the rare cases you want to do it you
can already.
>
> scenario is: I use JDK 21 to run Maven, but I need JDK 8 to run my unit
> and
> integration tests
> of course, i have both JDKs on my machine
>
Assuming you have JAVA8_HOME setup you set
${env.JAVA8_HOME}/bin/java in surefire and be it.
>
> I see how I can manually configure toolchain.xml, modify pom.xml etc... to
> do
> that: it works, it's cumbersome
>
> How does "dropping toolchains" help?
>
Does not help, read it the opposite way, "toolchain does not help".
>
> Defining a common plan will probably require a dedicated discussion,
> perhaps
> some wiki pages, perhaps some meeting between people interested to have
> more
> live ideation before sharing proposal on the ML (which is necessary for
> wider
> community discussion)
>
Sure, my point was not to create a debate on that now, just that we should
probably not see toolchain as a solution cause it hurts more it helps.
>
> Le mercredi 21 février 2024, 08:48:43 CET Romain Manni-Bucau a écrit :
> > Hi Hervé,
> >
> > +1000 on the philosophy!
> >
> > On the toolchain support I still fail to see why maven has toolchain
> > anywhere in its code.
> > Look it how it is used:
> > * Tools are generally setup with env variables (JAVA_HOME, JAVA17_HOME,
> > JAVAEA_HOME or alike)
> > * Most plugins able to switch the JDK can switch the executable in their
> > config and use by default ${env.JAVAxx_HOME} or whatever is desired which
> > is the same indirection than toolchain but without the downside to setup
> a
> > toolchain.xml. Then plugins can just use the binary (optionally PathExt
> on
> > windows to get the extension) and be it, works really well.
> >
> > So overall I think we could drop toolchain which ultimately still misses
> a
> > few parts to be complete in terms of env setup and make a
> shared-executable
> > stronger - likely the future base of exec plugin even if not required.
> >
> > 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. 21 févr. 2024 à 08:39, Hervé Boutemy a
> >
> > écrit :
> > > for sure, given the JDK almanach https://javaalmanac.io/jdk/ , we'll
> have
> > > to update our plans
> > > https://maven.apache.org/developers/compatibility-plan.html
> > >
> > > the approach I'd love to promote is "what do we require to not hurt our
> > > diversity of users when upgrading minimum prerequisites" (and I'm
> doing it
> > > on my free time because I do care about the diversity of our community)
> > > => let's work on the enablers
> > >
> > > Java prerequisite for Maven core is something, but everything will
> start
> > > from plugins: that's why we started the plugins "requirement history"
> > > see for example
> > > https://maven.apache.org/plugins/maven-shade-plugin/plugin-info.html
> > >
> > > for a summary on our own plugins, see last column of
> > >
> > >
> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/jo
> > > b/master/site/dist-tool-prerequisites.html
> > >
> > > As you can see, not many plugins are not covered yet: who wants to
> work on
> > > this?
> > >
> > >
> > > Another good item cited is improving decoupling JDK of Maven from JDK
> to
> > > compile and run tests.
> > > IIRC, Guillaume prepared something about auto-importing available JDKs
> > > from sdkman, which is a great idea: I don't know if this was closed
> done,
> > > but I suppose other JDK switcher tools should be supported, I'm
> > > particularly interested on knowing what Windows users need
> > > One aspect that I know is not well done is that the MANIFEST in jar
> > > describes JDK release from Maven core, not target: we should probably
> do
> > > something
> > > A
Re: [DISCUSS] Java version for Maven
Hi Hervé,
+1000 on the philosophy!
On the toolchain support I still fail to see why maven has toolchain
anywhere in its code.
Look it how it is used:
* Tools are generally setup with env variables (JAVA_HOME, JAVA17_HOME,
JAVAEA_HOME or alike)
* Most plugins able to switch the JDK can switch the executable in their
config and use by default ${env.JAVAxx_HOME} or whatever is desired which
is the same indirection than toolchain but without the downside to setup a
toolchain.xml. Then plugins can just use the binary (optionally PathExt on
windows to get the extension) and be it, works really well.
So overall I think we could drop toolchain which ultimately still misses a
few parts to be complete in terms of env setup and make a shared-executable
stronger - likely the future base of exec plugin even if not required.
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. 21 févr. 2024 à 08:39, Hervé Boutemy a
écrit :
> for sure, given the JDK almanach https://javaalmanac.io/jdk/ , we'll have
> to update our plans
> https://maven.apache.org/developers/compatibility-plan.html
>
> the approach I'd love to promote is "what do we require to not hurt our
> diversity of users when upgrading minimum prerequisites" (and I'm doing it
> on my free time because I do care about the diversity of our community)
> => let's work on the enablers
>
> Java prerequisite for Maven core is something, but everything will start
> from plugins: that's why we started the plugins "requirement history"
> see for example
> https://maven.apache.org/plugins/maven-shade-plugin/plugin-info.html
>
> for a summary on our own plugins, see last column of
>
> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html
>
> As you can see, not many plugins are not covered yet: who wants to work on
> this?
>
>
> Another good item cited is improving decoupling JDK of Maven from JDK to
> compile and run tests.
> IIRC, Guillaume prepared something about auto-importing available JDKs
> from sdkman, which is a great idea: I don't know if this was closed done,
> but I suppose other JDK switcher tools should be supported, I'm
> particularly interested on knowing what Windows users need
> One aspect that I know is not well done is that the MANIFEST in jar
> describes JDK release from Maven core, not target: we should probably do
> something
> Another aspect is that toolchains support has to be enabled in pom.xml: it
> would be useful for it to work from just CLI also.
>
> I'm sure there are other features that would be useful on this: who wants
> to work on this?
>
>
> The 2 previous enablers look sufficient to me: any other enabler someone
> thinks about?
>
> And more importantly: who wants to work on it? plan, track progress,
> document, explain?
> we need community's help to prepare a smooth change: updating our plans
> will be a consequence of this preparation
>
> Regards,
>
> Hervé
>
> Le mardi 20 février 2024, 21:49:03 CET Tamás Cservenák a écrit :
> > Howdy,
> >
> > I intentionally used "Maven" here, and not "Maven 4" as I am sure the
> > majority of Maven users do not run Maven on the same Java version they
> > target with their build. We do not do that either.
> >
> > Some snippets from Herve (who is the ONLY one doing reproducible checks,
> > kudos for that) votes:
> >
> > Sun, Feb 18, 2024, 9:38 AM
> > [VOTE] Release Apache Maven Shade Plugin version 3.5.2
> > Reproducible Build ok: reference build done with JDK 11 on *nix
> >
> > Wed, Jan 31, 2024, 5:06 AM
> > [VOTE] Release Apache Maven JLink Plugin version 3.2.0
> > Reproducible Builds ok: reference build done on *nix with JDK 21 and
> umask
> > 022
> >
> > Mon, Jan 8, 2024, 8:29 AM
> > [VOTE] Release Maven Plugin Tools version 3.11.0
> > Reproducible Builds ok: reference build done with JDK 8 on Windows with
> > umask
> >
> > Mon, Dec 18, 2023, 8:59 AM
> > [VOTE] Release Apache Maven Compiler Plugin version 3.12.0
> > Reproducible Builds ok: reference build done on *nix with JDK 21 and
> umask
> > 022
> >
> > Mon, Dec 18, 2023, 8:59 AM
> > [VOTE] Release Apache Maven Compiler Plugin version 3.12.0
> > Reproducible Builds ok: reference build done on *nix with JDK 21 and
> umask
> > 022
> >
> > Wed, Nov 29, 2
Re: [DISCUSS] Java version for Maven
> So it IS about us, the volunteers. > Is not about THEM, downstream users. Not for me, for me and anything ASF is 100% about users and 0% about doers. Anything not aligned on that should stay a personal github project for me. > if they are stuck (due whatever policy or who knows what), they can just > stay with 3.9, 3.8 or whatever suits them. > Why align with the "stuck" ones? Don't get me wrong, I don't think we should stick to java 8 but we should embrace our users and ensure they can embrace what we deliver. If you release maven 4 in 2025 and nobody can use it except a few then it will stay a niche project compared to today where it is the main java build tool. Add the fact you will need ~2 years for maven 4 to be usable by people, then you just killed the project and its community IMHO. This is why I think we should stick to something in between, use not something outdated - as we all saw, java 21 warns about java 8 - but not the ultimate latest. That where my LTS-1 comes - but not today it means Java 21 with the projection we can do of a final release. If your point was about the "then" the reasoning is similar. See how alpha and beta are just dead releases except for people able to build a snapshot, if you release something with a too high minimum java version, it will be the same. Keep in mind a tool to be adapted must work, be efficient etc...but should also respect the 5mn setup. For a java person assuming you have a correct java is ok and then it must stay curl $maven && unzip && bin/mvn, please never any toolchain nor more advanced setup. It works theorically but there is likely no way people adopt it IMHO. Also please just consider the polls - even if they are all biased, the figures are significative enough - about java usage, https://www.azul.com/wp-content/uploads/final-2023-state-of-java-report.pdf for example. 2 LTS is generally always covering most people and hopefully it will go a bit faster in some years but as of today you really need 2 LTS if you want to be mainstream. Even JakartaEE just pushed back from 21 to 17 as a requirement due to the pressure from the communityand at ASF we don't really care about code at the end ;). 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. 21 févr. 2024 à 07:00, Christoph Läubrich a écrit : > I think I mentioned it elsewhere but the fact that maven requires Java > to run is actually a (sometimes annoying) implementation detail, so if > maven would simply ship with a (stripped) JVM, being a native binary or > actually would probably resolve some problems in the area of java > discussions. > > That the java compiler (and surefire) reuses the JVM maven runs on might > have been convenient in the past decades but if one really cares should > actually be configured to use a dedicated JVM anyways. > > > Am 20.02.24 um 21:49 schrieb Tamás Cservenák: > > Howdy, > > > > I intentionally used "Maven" here, and not "Maven 4" as I am sure the > > majority of Maven users do not run Maven on the same Java version they > > target with their build. We do not do that either. > > > > Some snippets from Herve (who is the ONLY one doing reproducible checks, > > kudos for that) votes: > > > > Sun, Feb 18, 2024, 9:38 AM > > [VOTE] Release Apache Maven Shade Plugin version 3.5.2 > > Reproducible Build ok: reference build done with JDK 11 on *nix > > > > Wed, Jan 31, 2024, 5:06 AM > > [VOTE] Release Apache Maven JLink Plugin version 3.2.0 > > Reproducible Builds ok: reference build done on *nix with JDK 21 and > umask > > 022 > > > > Mon, Jan 8, 2024, 8:29 AM > > [VOTE] Release Maven Plugin Tools version 3.11.0 > > Reproducible Builds ok: reference build done with JDK 8 on Windows with > > umask > > > > Mon, Dec 18, 2023, 8:59 AM > > [VOTE] Release Apache Maven Compiler Plugin version 3.12.0 > > Reproducible Builds ok: reference build done on *nix with JDK 21 and > umask > > 022 > > > > Mon, Dec 18, 2023, 8:59 AM > > [VOTE] Release Apache Maven Compiler Plugin version 3.12.0 > > Reproducible Builds ok: reference build done on *nix with JDK 21 and > umask > > 022 > > > > Wed, Nov 29, 2023, 8:16 AM > > [VOTE] Apache Maven Build Cache Extension 1.1.0 > > Reproducible Build ok: reference build done on *nix with JDK 11 > > > > Sun, Nov 19, 2023, 5:17 PM > > [VOTE] Release Maven Resolver 1.
Re: [DISCUSS] Java version for Maven
> I am sure the majority of Maven users do not run Maven on the same Java version they target with their build. Do you use that and the following figures to do a biased conclusion? "If people don't use the same version then we can higher the version"? I think we need to consider two things: * We are OSS dev so not representative of the majority - in a company you most of the time use the same version you target and want to run that, just either laziness, policy or quality (building with different versions can lead to surprises and falsy passing tests = broken prod), sadly it is hard to find data there but I'm pretty sure it is a common experience * Guess there is a "use the first matching version I have" in the stats you mention, so if you target 11 and have 17 you would use 17 but does not mean you are ok to run 21 (random numbers, move them a bit to be a counter example on whatever digit you want for maven 4) * Guess very few people want to have >= 1 JDK So clearly the question is not the latest LTS which would be for me just a moving version we can't support and would be bad for our end users IMHO but only the version we pick to start at 4.0.0. Choices stay: * Latest LTS at that moment to start fresh and not inherit from a legacy at day 0 * Latest LTS - 1 - which would enable to cover more projects and get more adoptions * Something older but I don't find any valid reason since people skipping 2 LTS will likely never reach maven 4 before we discuss to move our baseline again. The other question we should probably anticipate is when do we move our support version range. Since java is not more predictable in terms of releases I think it can make sense to target for "new" releases only 2 (maybe 3 but really unsure?) LTS - indeed with best effort on later versions but no guarantee upfront. With such a policy calendar can be communicated and people can follow or not without surprises. So today, since we don't have yet a final I think 21 can make sense but not cause it is the current latest, cause it will likely be the ~N-1 at 4.0.0 time. 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 mar. 20 févr. 2024 à 21:50, Tamás Cservenák a écrit : > Howdy, > > I intentionally used "Maven" here, and not "Maven 4" as I am sure the > majority of Maven users do not run Maven on the same Java version they > target with their build. We do not do that either. > > Some snippets from Herve (who is the ONLY one doing reproducible checks, > kudos for that) votes: > > Sun, Feb 18, 2024, 9:38 AM > [VOTE] Release Apache Maven Shade Plugin version 3.5.2 > Reproducible Build ok: reference build done with JDK 11 on *nix > > Wed, Jan 31, 2024, 5:06 AM > [VOTE] Release Apache Maven JLink Plugin version 3.2.0 > Reproducible Builds ok: reference build done on *nix with JDK 21 and umask > 022 > > Mon, Jan 8, 2024, 8:29 AM > [VOTE] Release Maven Plugin Tools version 3.11.0 > Reproducible Builds ok: reference build done with JDK 8 on Windows with > umask > > Mon, Dec 18, 2023, 8:59 AM > [VOTE] Release Apache Maven Compiler Plugin version 3.12.0 > Reproducible Builds ok: reference build done on *nix with JDK 21 and umask > 022 > > Mon, Dec 18, 2023, 8:59 AM > [VOTE] Release Apache Maven Compiler Plugin version 3.12.0 > Reproducible Builds ok: reference build done on *nix with JDK 21 and umask > 022 > > Wed, Nov 29, 2023, 8:16 AM > [VOTE] Apache Maven Build Cache Extension 1.1.0 > Reproducible Build ok: reference build done on *nix with JDK 11 > > Sun, Nov 19, 2023, 5:17 PM > [VOTE] Release Maven Resolver 1.9.17 > Reproducible Build ok: reference build done with JDK 21 on *nix with umask > 022 > > Sat, Oct 21, 2023, 4:34 PM > VOTE] Apache Maven 4.0.0-alpha-8 release > Reproducible Build ok: reference build done with JDK 21 on *nix with umask > 022 > > Mon, Oct 2, 2023, 9:11 AM > [VOTE] Release Apache Maven 3.9.5 > Reproducible not fully ok: reference build done with JDK 17 on *nix and > umask 022 > > > > This CLEARLY shows the tendency: > - Michael does releases on Java 8 (on windows!), he is a known "aligner" > and windows person :) > - Olivier used the "minimum" required Java version (for build cache). > - Unsure why Herve used Java 11 for the Shade plugin... I mean, he could > use 21 but also 8, but he shot for 11 that was EOL at the moment of > release. > - The rest is 21. > > > > So, the question for those refusing anything other than Java 8 to _run_ > Maven (or to revert: for those refusing to run Maven on "latest LTS", that > is currently 21): > WHY? > > > Thanks > T >
Re: [VOTE] Release Apache Maven Shade Plugin version 3.5.2
Hi Eliotte, Is the -1 only motivated by the fact there is a PR opened? If so please consider two things: * it is always the case for most releases (maven, asf, living projects ;)) so not sure when it became a hard criteria but if so we should probably think to be more open if we want to release a day * If you take time to review the PR you mention you will also see it just revert a fix and that the final code should be more complex if it lands in shade plugin a day - there are always workarounds there - so don't think we can make it in the week so can await another round and way more time to make it right (long story sort shade has an old bug where it mixes the same config for different kind of rewritten sources, while it often works and stays simple, it also makes it insanely hard to be right since you don't know what you rewrite - a variable, a package, a class name, ...) 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 dim. 18 févr. 2024 à 14:30, Elliotte Rusty Harold a écrit : > -1 > > https://github.com/apache/maven-shade-plugin/pull/193 from an external > contributor is open and unreviewed, although it seems to meet the > criteria for merging if it's correct. It's helpful to triage open PRs > and issues before cutting a release. > > On Sat, Feb 17, 2024 at 1:01 PM Hervé Boutemy > wrote: > > > > Hi, > > > > We solved 6 issues: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12352505=Text > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-2065/ > > > https://repository.apache.org/content/repositories/maven-2065/org/apache/maven/plugins/maven-shade-plugin/3.5.2/maven-shade-plugin-3.5.2-source-release.zip > > > > Source release checksum(s): > > maven-shade-plugin-3.5.2-source-release.zip sha512: > 23fcd21e6b915114efa133b1c4e46fa0b3d77874ff9d974e4bdb24940ea0ed9b7ffaf7f3d1e8a8549837cfe1de7ff2fc8ae7fc68bfc0477ea7a4b8b53e42f6f7% > > > > Staging site: > > https://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for at least 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Release Apache Maven Shade Plugin version 3.5.2
+1, project ok, downstream projects ok, tested on mvn 3.9.2 & java 11 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 dim. 18 févr. 2024 à 09:38, Hervé Boutemy a écrit : > +1 > > Reproducible Build ok: reference build done with JDK 11 on *nix > > see > https://github.com/jvm-repo-rebuild/reproducible-apache/blob/master/wip/maven-shade-plugin-3.5.2.buildspec > > anybody should be able to rebuild locally with > ./rebuild.sh wip/maven-shade-plugin-3.5.2.buildspec > > Regards, > > Hervé > > Le samedi 17 février 2024, 19:00:47 CET Hervé Boutemy a écrit : > > Hi, > > > > We solved 6 issues: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921 > > rsion=12352505=Text > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-2065/ > > > https://repository.apache.org/content/repositories/maven-2065/org/apache/mav > > > en/plugins/maven-shade-plugin/3.5.2/maven-shade-plugin-3.5.2-source-release. > > zip > > > > Source release checksum(s): > > maven-shade-plugin-3.5.2-source-release.zip sha512: > > > 23fcd21e6b915114efa133b1c4e46fa0b3d77874ff9d974e4bdb24940ea0ed9b7ffaf7f3d1e > > 8a8549837cfe1de7ff2fc8ae7fc68bfc0477ea7a4b8b53e42f6f7% > > > > Staging site: > > https://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for at least 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Use of jspecify in Maven
Rather -0 on my side by experience cause this kind of tool is often abused, in particular using an IoC or a codebase with indirections like maven. One prerequisite being all the stack uses it - plexus, sisu, commons etc - Im not sure we can get the benefits without the downsides. That said you can test it in a branch and see what's the status, only big constraint is to not deliver it in the distro but this is easy to do. Le lun. 12 févr. 2024 à 02:43, Elliotte Rusty Harold a écrit : > I'd prefer not. Every additional dependency we add is a liability. > It's not clear we need something like this and even if we do, JSpecify > is only a few months old. This is only the latest of many efforts to > establish a standard for nullness annotations. I don't see why > JSpecify will be the one ring to rule them all. XKCD 927 applies: > > https://xkcd.com/927/ > > Really what needs to happen here is someone needs to reboot the JSR > 305 work in the JCP. I'm not sure why it failed the first time, but > perhaps it can be fixed. > > On Sun, Feb 11, 2024 at 9:28 PM Benjamin Marwell > wrote: > > > > Hello devs and plugin maintainers! > > > > Since JSR 305 (Nullable annotations etc.) did not get implemented > > officially, and Maven allows `null` in a lot of locations, I wanted to > > ask about your opinions about using jspecify: https://jspecify.dev/ > > > > JSpecify was created by the Java community (i.e. Java decs but also > > larger corporations like Google, if I am not mistaken. It was seen as > > needed since JSR 305 never materialized and probably never will. > > Google hat a Guava Situation [1] and decided to do something about it. > > > > JSpecify says it is safe to adopt it [2]. Although the current version > > is 0.3, it is more like 0.9. > > > > I honestly think that Maven would benefit from those annotations, as > > many recent libraries try to avoid `null` as best as they can. Younger > > developers may not be used to seeing nullable parameters, and even > > some of us don't know which parameters can be nulled (or not). > > > > Let me know what you think about this idea. > > > > My personal opinion: I am pretty confident jspecify will displace > > checker-qual as the "top dog" of nullness annotations in the future. I > > also want to give plugin authors a way to use null in their plugins, > > too, although we could make it an optional dependency (just > > annotations...). > > > > Looking forward to reading your opinions! > > > > - Ben > > > > 1: https://github.com/google/guava/issues/2960 > > 2: https://github.com/jspecify/jspecify/wiki/adoption > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Java version for Maven 4?
Le mar. 6 févr. 2024 à 16:12, Hunter C Payne a écrit : > There are also license differences between Java 8 and Java 9+. And the > improvements beyond 8 are not things the market seems to want. Nobody > wants Jigsaw and the API improvements aren't enough to get people to > upgrade. Those that really want new language features use Scala or Kotlin > and those both run best on Java 8. Just to add some other reasons why Java > 9+ isn't really something the market wants. > While I agree with the JPMS - and I was agreeing until 3-4 years ago on the rest - I kind of disagree with the rest which is no more true since java 17+ IMO. Also Scala is slowly dying while Kotlin does not get much more traction every year now so world changed and our old habits must probably too IMHO ;). > Hunter > > On Tuesday, February 6, 2024 at 06:01:07 AM PST, Elliotte Rusty Harold > wrote: > > On Mon, Feb 5, 2024 at 8:46 PM Benjamin Marwell > wrote: > > > > > Besides that, most big (tech) companies do not allow unmaintained or > > unsupported software. > > How I wish that were true. Unmaintained and unsupported software is > all over the place, in big tech, little tech, enterprise, and my > mother's MacBook. I doubt you can install a Linux distro that doesn't > depend critically on some unmaintained library no one is paying > attention to. > > What big tech mono-repo companies do differently that most other > companies don't is build everything from source themselves, kernel and > build tools included, so that when some critical bug surfaces they can > dig into the code and fix it. They are mostly not dependent on > binaries shipped by third parties. It's a feasible option for > companies in the hundreds of billions of dollars range. For the rest > of us, not so much. > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Java version for Maven 4?
While I don't think google-http-java-client is something we can rely on to decide anything for us for the 10 coming years, similarly not sure that mono-repo in big companies is actually a thing we should consider as a first citizen, in particular after the drawbacks big companies got trying to align on nodejs style on CI/CD and the reverts we saw in the ecosystem some years ago, I however see that there is a good hidden point in that off topic: github actions (I think it is a big consumer part of maven) almost never references the maven version used to build which is quite shocking and broken by design but is the current state of the art. However even google-http-java-client moved to java 21 so your example kind of confirms the coming outcome of this thread IMHO rather than trying to oppose to it so I'm not sure what's the point is. 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 mar. 6 févr. 2024 à 15:00, Elliotte Rusty Harold a écrit : > On Mon, Feb 5, 2024 at 8:46 PM Benjamin Marwell > wrote: > > > > > Besides that, most big (tech) companies do not allow unmaintained or > > unsupported software. > > How I wish that were true. Unmaintained and unsupported software is > all over the place, in big tech, little tech, enterprise, and my > mother's MacBook. I doubt you can install a Linux distro that doesn't > depend critically on some unmaintained library no one is paying > attention to. > > What big tech mono-repo companies do differently that most other > companies don't is build everything from source themselves, kernel and > build tools included, so that when some critical bug surfaces they can > dig into the code and fix it. They are mostly not dependent on > binaries shipped by third parties. It's a feasible option for > companies in the hundreds of billions of dollars range. For the rest > of us, not so much. > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Java version for Maven 4?
Hi Elliotte, While I share the wish 1 repo = 1 JDK, I have a hard time to see how any company - including the ones you cite - can seriously bet on Java 11 today for the future (not saying it wasnt hard to reach Java 11 today but we are discussing on what we'll do tomorrow) and why it would pushback the constraint to all the related tools. Java 11 support is already EOL for most vendor until you go "premium" flavor which will likely be very few people and most of them will be able to pay somebody to backport the needed stuff in custom distro of their work if needed anyday so not sure we should consider it. On the other side most libraries tend to move forward faster and if you like big ones, i'll take Spring or JakartaEE as an example - big user base rather than big company$ ;) - and they don't even support Java 11 anymore. So we go with Java 11 with our Maven 4 we'll likely be off most of our users, increase potential contributors work (think PR and needed builds to pass) without any actual gain for the project overall except maybe a few big vendors with part of them already migrated out of maven or even building their own build system. I'm not sure I see it as a very weighty in the balance from my window. So in terms of schedule - I know, the thread about EOL and maintenance got quite closed so it will never be a thing at Maven - I think we should embrace the future and ensure we follow main practises rather than looking a few people cause we are about community more than companies. 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 lun. 5 févr. 2024 à 19:56, Elliotte Rusty Harold a écrit : > On Mon, Feb 5, 2024 at 12:01 PM Benjamin Marwell > wrote: > > > Why 17? 11 is often earlier EOL'd than 8 and 17, so I see absolutely > > no advantage of going to 11: > > > > The advantage of going with 11 instead of 17 is that at least 2 really > big tech companies I could name (and who you can probably guess from > my linked in) have only recently completed their own migration to Java > 11. At least one of those two companies might still employ a PMC > member (though I haven't checked post-layoffs), maybe more than one. > Both have actively supported Maven development over the years, though > that support ebbs and flows depending on corporate priorities. > > I get the impression that folks who haven't worked in such large > mono-repos aren't aware of just how big a multi-year effort it is to > move a repo like that onto a new JDK version. And that's just the VM, > even before you allow devs to change the language level and start > using the new features and libraries. That's just the two really big > mono-repos I have personally worked in. I'm willing to bet that some > other big Java shops are in similar positions. > > Switching back and forth between JDKs for open source development is > doable but an unnecessary hassle. I've done it before, but even > switching from JDK 8 to 11 is an extra paper cut. It kills time every > time spotless fails simply because I'm using Java 8 instead of 11. > > Most importantly, it will be even harder to sell management on the > benefit of spending developer time on Maven 4 development, if it isn't > suitable for that company's own open source projects which, last I > checked, were still on Java 8. (OK, I just spot checked and the first > one I looked at is in fact still compiling for Java *1.7*, probably > because that's where their customers are). > > I'm thinking back to the projects I had to justify to management a few > years and one company back, and it definitely would have been harder > then if I had to tell them what we were contributing would only work > on Java 11 or later. Maybe today I could sell them on Java 11 (or > maybe not, if they aren't paying attention to Maven at all any more) > but Java 17 would be a non-starter. They might prefer to spend their > resources on a build tool they own, or maybe just not spend the dev > hours at all. > > tldr: every uptick in version requirements bleeds that many more > contributors out of the pool. > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Java version for Maven 4?
Side note: dont think toolchain enhancements is a requirement at all, lot of users keep rejecting this additional work (and to be honest I can agree 1nd it does not help more things than using properties to switch the env/executable in plugins) so only question for me is the baseline and minimum requirement when 4 will be final. It is probably wise to start fresh since it will be frozen for years so the lts at that moment does not sound crazy to not cumulate debts before starting. Le sam. 3 févr. 2024 à 16:43, Tamás Cservenák a écrit : > Similarly, this topic (to me at least) somewhat correlates with another > "wrong reflex" (that somehow get roots in project): > - compile against maven-core 3.2.5 > - compile with Java 8+ "as we support Maven on Java 8" > Funnily, both are from 2014, just 10 years old. > > IMHO, > We SHOULD compile against the latest, to pick up the latest deprecations, > and not be "detached", but follow changes in core (and resolver). > We SHOULD compile with latest to benefit from latest improvements (how many > of us said just one thing: is FASTer to build on 21.0.2 than 8.xxx). > Javadoc is the third (important) thing, and more will just come... > > And so on... > > T > > On Sat, Feb 3, 2024 at 4:36 PM Tamás Cservenák > wrote: > > > The non problems: > > - members building project with ancient java versions and calling -1 on > > release votes (as turns out,by mistake) > > - javadoc inconsistencies: what is allowed and what not > > - being stuck in a 20 year tech stack > > ... > > > > Again, _build time requirement_ has nothing to do with _runtime > > requirement_. > > > > Or in other words, a bit of rephrasing: > > For example, desktop app devs who develop apps "certified to work on > older > > OS-es (than current)" _develop those apps on "lower end" of supported > OSes > > version_? > > So, if a macOS app CAN work on macOS 12 (current is 14), it MUST be > > developed on macOS 12? > > > > > > > > > > On Sat, Feb 3, 2024, 16:25 Michael Osipov wrote: > > > >> Am 2024-02-03 um 15:16 schrieb Martin Desruisseaux: > >> > Hello > >> > > >> > From the replies in this thread, it seems to me that there is a > >> > consensus for moving Maven 4 to some Java version after 8. I see: > >> > > >> > * 0 in favour of Java 11 > >> > * 1.5 in favour of Java 17 (the .5 is because I split a vote between > >> > Java 17 and 21) > >> > * 2.5 in favour of Java 21 > >> > * 4 seem neutral (including myself) > >> > > >> > Do we take that as an agreement to require Java 21 for building Maven > 4? > >> > > >> > On a related question, what should be the minimal Java version for > >> > *running* Maven 4? Keeping in mind that if Java 21 (for example) was > >> > required, users would still be able to compile for an older Java > >> version > >> > using the --release option. > >> > >> I still don't understand what non-problem you are trying to solve here?! > >> I think that your time and our time would be better invested in solving > >> real problems, just look into JIRA how many issues have piled up. > >> > >> M > >> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > > >
Re: [VOTE] Release Apache Maven JLink Plugin version 3.2.0
+1 Le lun. 29 janv. 2024 à 23:41, Sylwester Lachiewicz a écrit : > +1 > > pon., 29 sty 2024 o 20:37 Benjamin Marwell > napisał(a): > > > Hi, > > > > We solved 6 issues: > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321432=12349496 > > > > There are still two issues left in JIRA: > > https://issues.apache.org/jira/projects/MJLINK/issues > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-2064 > > > > > https://repository.apache.org/service/local/repositories/maven-2064/content/org/apache/maven/plugins/maven-jlink-plugin/3.2.0/maven-jlink-plugin-3.2.0-source-release.zip > > > > Source release checksum(s): > > maven-jlink-plugin-3.2.0-source-release.zip sha512: > > > > > 0cedc1a75b2ed7c085017ad65f18a10b2da4d06217dcb0eb6a1e6e22a8dadab2df4986b020392d15c7215e0b594f25e47d7341ed4e157a6b7e60be63158d008b% > > > > Staging site: > > https://maven.apache.org/plugins-archives/maven-jlink-plugin-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for at least 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
Re: [VOTE] Release Maven Resolver 2.0.0-alpha-7
+1 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 dim. 28 janv. 2024 à 23:33, Slawomir Jaranowski a écrit : > +1 > > czw., 25 sty 2024, 19:58 użytkownik Tamás Cservenák > napisał: > > > Howdy, > > > > Note: This is a sixth (alpha-4 was scrubbed) preview release of Resolver > > 2.0.0, that would allow any downstream consumers to try it out and adapt. > > The supplier is aligned with Maven 4.0.0-alpha-12. Delivered features are > > mostly smaller improvements, bug fixes and dependency updates. One > notable > > change is that this release makes "file locking" enabled by default. This > > alpha contains pretty much every major feature we planned for 2.0.0. Of > > course, we do NOT exclude more issues to be added (most likely bugs) down > > the road, but the final 2.0.0 release is getting near. > > > > For configuration changes, see > > > > > https://maven.apache.org/resolver-archives/resolver-LATEST/configuration.html > > > > IF the vote is successful, the staging site will NOT be moved to > > https://maven.apache.org/resolver/ but instead will be made reachable > from > > https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-7/ only. > > > > The 1.9.18 is still the "latest stable" release of Maven Resolver. > > > > === > > > > We solved 20 issues: > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12354065 > > > > There are still some issues in JIRA: > > https://issues.apache.org/jira/projects/MRESOLVER/issues > > > > Staging repository: > > https://repository.apache.org/content/repositories/maven-2063 > > > > Source release SHA512: > > > > > af765437edad19adb5cca208841c431bafc983288f5fd6ea09f6446a8ad30bcb27e2c0b81e4652ab4a95ecc8ca95a03cbeb20e3283a3ff1ced40caf6c3dbcf1b > > > > Staging site: > > https://maven.apache.org/resolver-archives/resolver-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > >
Re: Nexus returns 400 Bad Request
Hi tison, As mentionned it depends the "impl" you use but for jdk (mvn4) it will be https://github.com/apache/maven-resolver/blob/master/maven-resolver-transport-jdk-parent/maven-resolver-transport-jdk-11/src/main/java/org/eclipse/aether/transport/jdk/JdkTransporter.java#L347 (also check out the other sibling modules since there are multiple transport impl and as mentionned maven 3 uses another one but it is similar) and be rethrown brutally there https://github.com/apache/maven/blob/f2595c83d9cf9e3d30c4d808dcf4623f320c6182/maven-core/src/main/java/org/apache/maven/internal/impl/DefaultTransport.java#L122 . An idea can be to type better the http exception, propagate the status and a Supplier for te body maybe and compute the error message from maven with the data propagated from the resolver? Side note: all is not nexus so this logic should not fail on the failure handling ;). Best, 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 jeu. 25 janv. 2024 à 04:16, tison a écrit : > Thanks for your reply! > > > Maybe that is a bug in Nexus itself. > > I ever thought of it. But according to Romain's comment, it seems the > MavenSession has the information but not printed out. > > > if you feel motivated to send a pr it would be welcomed I guess. > > I'd like to spend some time to see if I can write one. Could you show > me some related code locations that I can start with? Maven has a lot > of repos and I don't know which components are related to this logic. > > Best, > tison. > > Hervé Boutemy 于2024年1月6日周六 16:05写道： > > > > interesting details > > > > IMHO, we're back to the HTTP wire protocol between Maven CLI and > repositories > > not being precisely defined on edge cases > > = what to put as HTTP return code, what to put as reason phrase > (deprecated in > > HTTP/1.1, removed in HTTP/2), and what to get from HTTP body > > > > idea has been shared some time ago about using RFC 7807, but nothing has > been > > really done > > see https://issues.apache.org/jira/browse/MNG-6795 , marked as > candidate for > > Maven 4, but did not get much traction for now > > > > Regards, > > > > Hervé > > > > Le vendredi 5 janvier 2024, 19:11:57 CET Romain Manni-Bucau a écrit : > > > Hi, > > > > > > This is a valid error but if you want to see it you need to enable HTTP > > > frames. > > > > > > For the record the error returns a HTML response with this content: > > > *Cannot find a matching staging profile*. > > > > > > If you want to check them out it depends a bit of your maven version > but > > > for 3.9 you just comment the two last lines > > > of $MAVEN_HOME/conf/logging/simplelogger.properties > > > (org.slf4j.simpleLogger.log.org.apache.http) and run in debug mode (for > > > maven 4 you can use the JVM httpclient system properties IIRC). > > > > > > But agree our client could be more precise on the error instead of just > > > throwing a 400 without any message, if you feel motivated to send a pr > it > > > would be welcomed I guess. > > > > > > 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 ven. 5 janv. 2024 à 18:46, Michael Osipov a > écrit : > > > > On 2024/01/04 14:00:08 tison wrote: > > > > > Hi, > > > > > > > > > > When deploying artifacts to Nexus repository, 400 Bad Request can > be > > > > > one of the most confusing error code. See [1] as an example. > > > > > > > > > > Sonatype has a page to document some common causes of 400 Bad > Request > > > > > [2]. But I wonder if we can return an error message (diagnostic) > along > > > > > with the error code, so that users can get what conditions broken > > > > > exactly. > > > > > > > > > > I suppose it has been discussed before. Is there any reference >
Re: Java version for Maven 4?
Le lun. 22 janv. 2024 à 13:34, Benjamin Marwell a écrit : > To add some more information, I have seen some extreme reduction in > build times after switching from Java 11 to 17 or even 21 (just for > build, not the runtime). > We can still verify it runs on 11/17 by using the integration tests, > but having the (possibly parallel) unit- and integration tests > compile, run and package on 21 is an *extreme* improvement in build > time. > > As always, YMMV. But why waste time... > > Since with Semeru and Temurin all major vendors have published their > JDK21 at last, > I see no reason to use a lower Java version to build maven with. > It is easily available for everyone who wants to contribute. > > If I read the thread correctly, there were no objections to raising > the build time requirements. > > It will also remove a lot of unneeded profiles (Java 8 Javadoc fix, > possibly build chains and module-info profiles), > in case any of those are present. > Not sure since you will replace it by the same amount (more actually) of toolchain setups so guess the only real point (some of the perf enhancement are backported by some vendors so not justified alone) is to enable more things at build time, rest will not change much from my window (but it is already a step forward, just wanted to highlight we complexify elsewhere simplifying there). > > - Ben > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Java version for Maven 4?
Same there while surefire/invoker runs respect supported versions. Le dim. 21 janv. 2024 à 22:04, Guillaume Nodet a écrit : > At build time, I think it's fine to bump to whatever is needed to make > our life manageable. If 17 is required, so be it. > > Guillaume > > Le sam. 20 janv. 2024 à 19:18, Martin Desruisseaux > a écrit : > > > > Hello > > > > I would like a little clarification about the Java version for Maven 4. > > I saw debate on this mailing list, but has a decision been reached? I > > got the impression that Maven 4 would require Java 11, but last time I > > checked, the pom.xml file was still declaring Java 8 as the target. If > > Java 11 is the target, updating the pom.xml would unlock some features > > and make some code a little bit simpler. > > > > Related question: even if Maven 4 targets Java 8 or 11, would it be > > acceptable to require Java 17 with `--release 8` or `--release 11` > > option only for Maven 4 compilation (not execution)? I ask because as > > far as I know, we cannot write code buildable with both Java 11 and Java > > 17 if the code uses HTML headings in Javadoc comments and the Javadoc > > checks are enabled. If the project builds on Java 11, then it fails on > > Java 17. Or if it builds on Java 17, then it fails on Java 11. For > > building on both versions, we must either avoid HTML headings, or > > disable Javadoc checks (more details at [1]). Using HTML headings is not > > very important, so they could be removed. But the `--release 11` > > approach would allow a more gradual transition to newest Java versions > > while preserving compatibility for users. > > > > Martin > > > > [1]https://github.com/apache/maven/pull/1378#issuecomment-1902173221 > > > > -- > > Guillaume Nodet > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Release Apache Maven 4.0.0-alpha-12
+1 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 lun. 15 janv. 2024 à 13:22, Guillaume Nodet a écrit : > +1 > > Le ven. 12 janv. 2024 à 11:44, Guillaume Nodet a > écrit : > > > I'm starting a new vote to release this new alpha. > > This release brings the latest Maven Resolver 2.0.0-alpha-6, leveraging > > artifact collection filtering and the new transitive dependency manager. > > JLine has been leveraged to provide better line editing, SLF4j has been > > upgraded to 2.x. Also, projects are not resolved anymore outside the > > reactor to provide better consistency during builds. > > > > Fwiw, a few plugins have already been ported to the new API (clean, > > install, deploy, resources, compiler) and do pass their integration > > tests, i'll update the PR > > https://github.com/apache/maven/pull/1048 > > <https://github.com/apache/maven/pull/1048/files> asap. > > > > 13 issues solved: > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12354059 > > > > Staging repository: > > https://repository.apache.org/content/repositories/maven-2062 > > > > Dev dist directory: > > https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-alpha-12/ > > > > Staged site: > > https://maven.apache.org/ref/4-LATEST/ > > > > Guide to testing staged releases: > > http://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for 72h > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > -- > > > > Guillaume Nodet > > > > > > -- > > Guillaume Nodet >
Re: JMPS support, proposal 3
Afaik the ci is up to date so must pass so likely needs a fix.
Le sam. 13 janv. 2024 à 14:43, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Just saw that the CI build has been successful on Java 17 and 21, but
> failed on Java 11 because of the use of the |{@return ...}| javadoc tag.
> This is a trivial Javadoc issue only. Its resolution depends on Maven
> PMC decision about which Java version to require.
>
> Martin
>
>
Re: [VOTE] Release Apache Maven 4.0.0-alpha-12
Guess for this case a force push is okish since it is pretty sure nobody not able to recover from there would have consumed it. For the future we must not push any tag on apache repo before the release passed - we can use our forks, this way there is no real way to burn any version (this is used by some other ASF projects with success so can be worth a try). 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 ven. 12 janv. 2024 à 12:04, Guillaume Nodet a écrit : > The explanation in this case, is that the BOM's parent has been changed > yesterday, and I just realized after releasing alpha-11 when looking at the > staging repo, that the groupId was wrong, so I did not call for a vote for > it, fixed the groupId and cut alpha-12. > The other would have been to force push a reset on master and recut > alpha-11. > > Le ven. 12 janv. 2024 à 12:00, Guillaume Nodet a > écrit : > > > > > > > Le ven. 12 janv. 2024 à 11:47, Romain Manni-Bucau > > > a écrit : > > > >> Hi Guillaume, > >> > >> Is it possible to not burn versions, it is always misleading for end > users > >> so would be great to get the alpha 11 out maybe? > >> > > > > It seems it is the rule in the Maven project, but I'd be happy to change > > it. I fully agree. > > > > > >> > >> 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 ven. 12 janv. 2024 à 11:44, Guillaume Nodet a > >> écrit : > >> > >> > I'm starting a new vote to release this new alpha. > >> > This release brings the latest Maven Resolver 2.0.0-alpha-6, > leveraging > >> > artifact collection filtering and the new transitive dependency > manager. > >> > JLine has been leveraged to provide better line editing, SLF4j has > been > >> > upgraded to 2.x. Also, projects are not resolved anymore outside the > >> > reactor to provide better consistency during builds. > >> > > >> > Fwiw, a few plugins have already been ported to the new API (clean, > >> > install, deploy, resources, compiler) and do pass their integration > >> > tests, i'll update the PR > >> > https://github.com/apache/maven/pull/1048 > >> > <https://github.com/apache/maven/pull/1048/files> asap. > >> > > >> > 13 issues solved: > >> > > >> > > >> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12354059 > >> > > >> > Staging repository: > >> > https://repository.apache.org/content/repositories/maven-2062 > >> > > >> > Dev dist directory: > >> > https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-alpha-12/ > >> > > >> > Staged site: > >> > https://maven.apache.org/ref/4-LATEST/ > >> > > >> > Guide to testing staged releases: > >> > > http://maven.apache.org/guides/development/guide-testing-releases.html > >> > > >> > Vote open for 72h > >> > > >> > [ ] +1 > >> > [ ] +0 > >> > [ ] -1 > >> > > >> > -- > >> > > >> > Guillaume Nodet > >> > > >> > > > > > > -- > > > > Guillaume Nodet > > > > > > -- > > Guillaume Nodet >
Re: [VOTE] Release Apache Maven 4.0.0-alpha-12
Hi Guillaume, Is it possible to not burn versions, it is always misleading for end users so would be great to get the alpha 11 out maybe? 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 ven. 12 janv. 2024 à 11:44, Guillaume Nodet a écrit : > I'm starting a new vote to release this new alpha. > This release brings the latest Maven Resolver 2.0.0-alpha-6, leveraging > artifact collection filtering and the new transitive dependency manager. > JLine has been leveraged to provide better line editing, SLF4j has been > upgraded to 2.x. Also, projects are not resolved anymore outside the > reactor to provide better consistency during builds. > > Fwiw, a few plugins have already been ported to the new API (clean, > install, deploy, resources, compiler) and do pass their integration > tests, i'll update the PR > https://github.com/apache/maven/pull/1048 > <https://github.com/apache/maven/pull/1048/files> asap. > > 13 issues solved: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12354059 > > Staging repository: > https://repository.apache.org/content/repositories/maven-2062 > > Dev dist directory: > https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-alpha-12/ > > Staged site: > https://maven.apache.org/ref/4-LATEST/ > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72h > > [ ] +1 > [ ] +0 > [ ] -1 > > -- > > Guillaume Nodet >
Re: maven-javadoc-plugin CI is borked
Hi Elliotte, think it was a no luck phenomenon (probably due to the load the matrix put on github OSS runners/infra). That said there is a misconfiguration in the GH Actions yaml about version 21 but this one is less misterious: Error: Could not find satisfied version for SemVer '21'. Best, 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. 10 janv. 2024 à 13:31, Elliotte Rusty Harold a écrit : > If anyone has a minute to take a look. I see various failures on > different dependabot PRs that have nothing to do with their content. > E.g. > > Error: Internal server error occurred while resolving > "actions/checkout@v4". Internal server error occurred while resolving > "actions/setup-java@v4". Internal server error occurred while > resolving "actions/upload-artifact@v4" > > https://github.com/apache/maven-javadoc-plugin/pull/263 > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Release Maven Resolver 2.0.0-alpha-6
(thought I sent my vote yesterday but somehow the thread does not list it so resending, please ignore if a gmail issue) +1 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 mar. 9 janv. 2024 à 18:21, Guillaume Nodet a écrit : > +1 > > Le lun. 8 janv. 2024 à 10:16, Tamás Cservenák a > écrit : > > > Howdy, > > > > Note: This is a fifth (alpha-4 was scrubbed) preview release of Resolver > > 2.0.0, that would allow any downstream consumers to try it out and adapt. > > Supplier is aligned with Maven 4.0.0-alpha-10. Major features are > > dependency management and filtering improvements. This alpha contains > > pretty much everything we planned for 2.0.0. Of course we do exclude more > > issues to be added (most likely bugs) down the road but final 2.0.0 is > > close. > > > > For configuration changes, see > > > > > https://maven.apache.org/resolver-archives/resolver-LATEST/configuration.html > > > > IF the vote is successful, the staging site will NOT be moved to > > https://maven.apache.org/resolver/ but instead will be made reachable > from > > https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-6/ only. > > > > The 1.9.18 is still the "latest stable" release of Maven Resolver. > > > > === > > > > We solved 6 issues: > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12354046 > > > > There are still some issues in JIRA: > > https://issues.apache.org/jira/projects/MRESOLVER/issues > > > > Staging repository: > > https://repository.apache.org/content/repositories/maven-2059 > > > > Source release SHA512: > > > > > acee147df2eeb09f2b5bd34fdcb80d5d9d47c92a430b54c708ee71e6a48aab0b04bd9b2f84344545c9d51658a1a077c3f7f6fc374d7120330994f8ec73bbd2ea > > > > Staging site: > > https://maven.apache.org/resolver-archives/resolver-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > > -- > > Guillaume Nodet >
Re: JMPS support, proposal 3
Hi Martin, Design looks better for me now (at this "type" thing but guess the dependency set idea is not liked too so let's keep it), thanks a lot, very impatient plugins start to embrace this new model (in particular on configuration side)! Side note: we can need to review the new type names before making it live, the legacy ones arelegacy but new ones can need an agreement but that's a very small detail. Best, 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 mar. 9 janv. 2024 à 17:58, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2024-01-09 à 16 h 57, Tamás Cservenák a écrit : > > > > Thanks for your effort, I will take a peek at this soon. > > > Thanks. Note that commit 1 can be ignored (it is only cleanup), and > commit 2 (refactoring of DependencyProperties) could be omitted as well > if PathTypes were provided directly as a Dependency method instead of > being stored in DependencyProperties. > > Martin > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Release Maven Surefire version 3.2.5
Le mar. 9 janv. 2024 à 08:03, Michael Osipov a écrit : > Am 2024-01-08 um 09:14 schrieb Slawomir Jaranowski: > > +1 > > > > We should maintain GitHub releases notes, last is for 3.2.2 > > Now we have outdated info which can be confusing for users. > > So we should be consistent - if we have one we should maintain or drop at > > all. > > In my opinion GitHub release notes are useful for user especially > > Dependabot use it. > > At least we can simply put a link to JIRA release notes which is not easy > > to find by users. > > Honestly, > > this is too much of a process for me. If someone else wants to do, fine, > but I'd rather drop all of them to avoid incomplete releases. > Jira stays our source of truth for issues so let's use jira until we migrate to github completely if it happens anytime in the future. If anyone has some will to write a mojo to do the synchro between jira and github releases (a bit like https://github.com/yupiik/tools-maven-plugin/blob/master/yupiik-tools-maven-plugin/src/main/java/io/yupiik/maven/mojo/SynchronizeReleasesToGithubReleasesMojo.java but with jira as source) we could set it up on the CI but ultimately we must not use gh issues AND jira so ultimately we should disable gh issues today :s. > > Michael > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Release Maven Surefire version 3.2.5
+1 Le dim. 7 janv. 2024 à 18:30, Sylwester Lachiewicz a écrit : > +1 > > niedz., 7 sty 2024, 18:07 użytkownik Tamás Cservenák > napisał: > > > +1 > > > > On Sat, Jan 6, 2024 at 9:05 PM Michael Osipov > wrote: > > > > > Hi, > > > > > > we solved 7 issues: > > > > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12354100 > > > > > > There are still a couple of issues left in JIRA: > > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20resolution%20%3D%20Unresolved > > > > > > Staging repo: > > > https://repository.apache.org/content/repositories/maven-2055/ > > > > > > > > > https://repository.apache.org/content/repositories/maven-2055/org/apache/maven/surefire/surefire/3.2.5/surefire-3.2.5-source-release.zip > > > > > > Source release checksum(s): > > > surefire-3.2.5-source-release.zip > > > sha512: > > > > > > > > > 5c894574b5c13813e5cdfec20f47d92e632f625aa53a135d22477b996998119b0c4fbfcabd0bdd35aed20be2d6fa221310e28ce6be6967411f48a7c19aa52dde > > > > > > Staging site: > > > https://maven.apache.org/surefire-archives/surefire-LATEST/ > > > > > > Guide to testing staged releases: > > > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > > > Vote open for 72 hours. > > > > > > [ ] +1 > > > [ ] +0 > > > [ ] -1 > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > >
Re: Nexus returns 400 Bad Request
Hi, This is a valid error but if you want to see it you need to enable HTTP frames. For the record the error returns a HTML response with this content: *Cannot find a matching staging profile*. If you want to check them out it depends a bit of your maven version but for 3.9 you just comment the two last lines of $MAVEN_HOME/conf/logging/simplelogger.properties (org.slf4j.simpleLogger.log.org.apache.http) and run in debug mode (for maven 4 you can use the JVM httpclient system properties IIRC). But agree our client could be more precise on the error instead of just throwing a 400 without any message, if you feel motivated to send a pr it would be welcomed I guess. 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 ven. 5 janv. 2024 à 18:46, Michael Osipov a écrit : > > On 2024/01/04 14:00:08 tison wrote: > > Hi, > > > > When deploying artifacts to Nexus repository, 400 Bad Request can be > > one of the most confusing error code. See [1] as an example. > > > > Sonatype has a page to document some common causes of 400 Bad Request > > [2]. But I wonder if we can return an error message (diagnostic) along > > with the error code, so that users can get what conditions broken > > exactly. > > > > I suppose it has been discussed before. Is there any reference about > > this? What is the related components / code I can check for potential > > contributions (fixes)? > > > > Best, > > tison. > > > > [1] https://issues.apache.org/jira/browse/INFRA-25344 > > [2] https://central.sonatype.org/faq/400-error/ > > Looking at the INFRA issue it seems that 400 is just wrong. There is not > client issue here, but a permission issue which should give you 403. Maybe > that is a bug in Nexus itself. > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: JPMS support, refactored proposal
...check it out again but you also said "it does not work" so still not, as soon as one lib is not jpms compatible (not by not being a module but by not being consummable even with implciit name as explained in this example) you can't use jpms first but you can always workaround the other way around so from a theorical standpoint classpath has still a wider area - not saying it is better to always start with classpath though, don't overinterpret please. But anyway we can move forward we don't have to agree on that 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 jeu. 4 janv. 2024 à 17:19, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2024-01-04 à 17 h 01, Romain Manni-Bucau a écrit : > > > We didnt speak of that but consuming that in a classpath/module > > friendly project. > > > This part was answered: build as JPMS + workarounds. The > counter-argument was that it should be built as class-path + workarounds > instead, which I tried to demonstrate by test cases that it doesn't > work. JPMS + workaround is the only sane way (to my knowledge) to build > a lib that can be consumed on both the classpath and the module-path. > > Martin > >
Re: JPMS support, refactored proposal
Le jeu. 4 janv. 2024 à 16:21, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2024-01-04 à 15 h 56, Romain Manni-Bucau a écrit : > > > Well it was written that the artifact names were not JPMS compatible, > > you can review https://github.com/apache/geronimo-specs but it was > > just one example. > > > Without link to the specific section, I cannot review if it is related > to our discussion. Compiling with JAR files on the class-path and > expecting Java to handle them as JPMS modules later just doesn't work, > or is tricky and unsafe at best. So Geronimo must be doing something > else, e.g. maybe they choose to not handle the problematic artifact as a > JPMS module (which is allowed by the proposal for Maven 4). Projects do > not need to be 100% modules or 100% class-path, it can be a mix of both. > But whatever they choose must be consistent at compilation, > documentation and execution. > We didnt speak of that but consuming that in a classpath/module friendly project. > > > Don't get me wrong but indeed you can fix all the world to make it > > fully JPMS compatible, this is not what happent since java 9 so I > > don't consider that path as something relevant today. > > > We already had this discussion. I (and at least one other person on this > mailing list) think that this is a chicken and egg problem. But anyway, > even if some peoples think that module-paths are not relevant today, it > is not a reason for blocking peoples who think that it is relevant. > Yep (both ways), this is why nothing is blocked except making it status quo or reverting current paradigm to priviledge the other one. This is why I said you I think everyone can be happy if some careness on core is done - I care less about plugins since it is leaves in release cycle and can be more instable than core must be. > Martin > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: JPMS support, refactored proposal
Well it was written that the artifact names were not JPMS compatible, you can review https://github.com/apache/geronimo-specs but it was just one example. Don't get me wrong but indeed you can fix all the world to make it fully JPMS compatible, this is not what happent since java 9 so I don't consider that path as something relevant today. 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 jeu. 4 janv. 2024 à 14:31, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2024-01-04 à 14 h 24, Romain Manni-Bucau a écrit : > > > > Cause it just works (and was forking for years). Geronimo specs jar > > have this issue for ex and this is not a blocker for lib builders to > > consume them, build with them and produce a JPMS friendly jar. > > > Still no test case for proving that it works? Link to the relevant part > of Geronimo build so we can check what they are doing exactly? > > Martin > >
Re: JPMS support, refactored proposal
Le jeu. 4 janv. 2024 à 13:05, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2024-01-04 à 12 h 49, Romain Manni-Bucau a écrit : > > > Just take the previous example you even explained yourself with an > > invalid JPMS name, this is still a valid case today. > > Module names are like any other symbol names (classes, methods, etc.). > If a module name is invalid, we want the same compilation error as > invalid class name or invalid method name. Why would we want the > compiler to silently ignore errors that are certain to cause runtime > exception? If you are aware of a valid case, please show it with a test > case (an application compiled with invalid module name, and still > executable as JPMS). > Cause it just works (and was forking for years). Geronimo specs jar have this issue for ex and this is not a blocker for lib builders to consume them, build with them and produce a JPMS friendly jar. > > Martin > >
Re: [discuss] extend extensions.xml to lifecycles/packaging and types?
Le jeu. 4 janv. 2024 à 13:17, Christoph Läubrich a écrit : > > Why? extension is global for the project so no copy needed. > > If you want to use it in different project I'm not aware how you can > share extension.xml between them ... but a pom deployed somewhere can be > reused (in pom.xml) also extension/extensions.xml cant contain any > configuration) > s/project/modules/ ;) > > > You can get a phase if it exists, not sure if you make it empty > > - was my point > > I see, well maybe it would better be named "empty-jar" and defines al > phases of the usual jar except that it does not bind any plugins by > default, or maybe thinking more about it maybe one should not use any > name but a simple list e.g. > > > jar >clean,custom,package,install (would default to > lifecycle of packaging if not given) > > > would define an (empty) lifecycle that has the phase > clean,custom,package,install only and now you know the order one can > bind plugins there... > This is more or less the idea except you define the chain in extensions.xml to let be reused by submodules. Inline you will need an aggregator pom and I'm not sure how well it will sit in a packaging=pom pom defining it for children. > > > > > Am 04.01.24 um 11:32 schrieb Romain Manni-Bucau: > > Le jeu. 4 janv. 2024 à 10:37, Christoph Läubrich a > > écrit : > > > >> > Kind of but it requires a lot of abstraction and inheritance abuse > IMHO. > >> > >> Not completely sure, but of course all would need to inherit the same > >> parent, maybe one can allow to "import" pom with plugin configuration as > >> an alternative, but for extension.xml it is the same you need to copy it > >> over to all child projects of course. > >> > > > > Why? extension is global for the project so no copy needed. > > > > > >> > >> > almost, you still need to associate phase(s) to each plugin > >> > >> Plugins can have a default phase that is chosen if not specified, still > >> a lifecycle mapping would require that as well, so lifeycle mapping (as > >> xml component xml) is just a little bit different syntax then? > >> > > > > You can get a phase if it exists, not sure if you make it empty - was my > > point > > > > > >> > >> Am 04.01.24 um 10:32 schrieb Romain Manni-Bucau: > >>> Hi Christoph, > >>> > >>> commented inline > >>> > >>> Le jeu. 4 janv. 2024 à 10:19, Christoph Läubrich > a > >>> écrit : > >>> > >>>> Isn't it already possible to "extend" the lifecycle by simply putting > >>>> plugin + execution into root pom? > >>>> > >>> > >>> Kind of but it requires a lot of abstraction and inheritance abuse > IMHO. > >>> For a single module you are very right but for a 10+ project where 5+ > >>> modules will use the same kind of build it will require a pom in the > >> middle > >>> leading to werid structures like root/services/x/pom.xml > >> root/lib/x/pom.xml > >>> so composition would be better there - but you're right, not a blocker > to > >>> build the final deliverables. > >>> > >>> > >>>> > >>>> Main problem for me is that currently packaging == type == lifecycle, > >>>> otherwise one could simply have an "empty" lifecycle + whatever > >>>> packaging and simply bind anything you want tin pom.xml e.g. > >>>> > >>>> > >>>> > >>>> jar > >>>> empty (would default to packaging if not > >>>> given, where empty is just a lifecycle with no mappings) > >>>> > >>>> > >>>> > >>>> org.apache.maven.plugins > >>>> maven-jar-plugin > >>>> > >>>> > >>>>... define all your custom bindings here ... > >>>> > >>>> > >>> almost, you still need to associate phase(s) to each plugin to be able > to > >>> run "mvn compile" "mvn test" or alike until we have an alias notion in > >>> pom/extensions.xml (= say "mvn foo" means run these plugins but it is > the > >>> lifecycle somehow). > >>> > >>> > >>> > >>>> > >>>> > >>>>
Re: JPMS support, refactored proposal
Le jeu. 4 janv. 2024 à 11:42, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2024-01-04 à 11 h 31, Romain Manni-Bucau a écrit : > > >> No, optional dependencies in JPMS are handled by "static requires". > >> > > As explained in previous post it is not always possible cause JPMS > > enforces constraints which are not always respected. > > > I don't understand what you mean. Test case please. > Just take the previous example you even explained yourself with an invalid JPMS name, this is still a valid case today. > > > > Your vision I guess, mine is the opposite from what I saw in OSS land. > > > It is not a vision, it is a fact. I provided a test case. If I'm wrong, > prove it with a test case please. > > Martin > >
Re: [discuss] extend extensions.xml to lifecycles/packaging and types?
Le jeu. 4 janv. 2024 à 10:37, Christoph Läubrich a écrit : > > Kind of but it requires a lot of abstraction and inheritance abuse IMHO. > > Not completely sure, but of course all would need to inherit the same > parent, maybe one can allow to "import" pom with plugin configuration as > an alternative, but for extension.xml it is the same you need to copy it > over to all child projects of course. > Why? extension is global for the project so no copy needed. > > > almost, you still need to associate phase(s) to each plugin > > Plugins can have a default phase that is chosen if not specified, still > a lifecycle mapping would require that as well, so lifeycle mapping (as > xml component xml) is just a little bit different syntax then? > You can get a phase if it exists, not sure if you make it empty - was my point > > Am 04.01.24 um 10:32 schrieb Romain Manni-Bucau: > > Hi Christoph, > > > > commented inline > > > > Le jeu. 4 janv. 2024 à 10:19, Christoph Läubrich a > > écrit : > > > >> Isn't it already possible to "extend" the lifecycle by simply putting > >> plugin + execution into root pom? > >> > > > > Kind of but it requires a lot of abstraction and inheritance abuse IMHO. > > For a single module you are very right but for a 10+ project where 5+ > > modules will use the same kind of build it will require a pom in the > middle > > leading to werid structures like root/services/x/pom.xml > root/lib/x/pom.xml > > so composition would be better there - but you're right, not a blocker to > > build the final deliverables. > > > > > >> > >> Main problem for me is that currently packaging == type == lifecycle, > >> otherwise one could simply have an "empty" lifecycle + whatever > >> packaging and simply bind anything you want tin pom.xml e.g. > >> > >> > >> > >> jar > >> empty (would default to packaging if not > >> given, where empty is just a lifecycle with no mappings) > >> > >> > >> > >> org.apache.maven.plugins > >> maven-jar-plugin > >> > >> > >> ... define all your custom bindings here ... > >> > >> > > almost, you still need to associate phase(s) to each plugin to be able to > > run "mvn compile" "mvn test" or alike until we have an alias notion in > > pom/extensions.xml (= say "mvn foo" means run these plugins but it is the > > lifecycle somehow). > > > > > > > >> > >> > >> Am 04.01.24 um 09:37 schrieb Romain Manni-Bucau: > >>> Hi all, > >>> > >>> Reviewing and trying to follow Martin's thread about JPMS I thought > about > >>> the old issue that our build pipelines (plugins chain) is very hard to > >>> customize. > >>> Guillaume added the priority case but the clean solution proposed > >>> originally was to define custom lifecycles (to add frontend, docker > >> builds > >>> for ex) - more or less a custom AbstractLifecycleMappingProvider. > >>> > >>> I wonder if we shouldn't extend .mvn/extensions.xml (or root pom > >>> block) to support to define custom lifecycle mappings > there > >>> and potentially explicit new "types" too which would be great for > >> Martin's > >>> work since it would allow to avoid undefined types and implicit jar > >> mapping > >>> in a "strict" mode (to detect typos for ex since it must become open). > >>> > >>> So proposal is to extend extension to get more configuration - and > coded > >>> extensions can indeed plug themselves there. > >>> The main challenge seems to be to re-evaluate the mappings but looks > >> doable. > >>> High level it is more or less "let the pom/.mvn inject maven components > >>> without coding/by declaration". > >>> > >>> Hope it makes sense, let me know if it is worth investigating more or > if > >>> the idea is too particular to my old needs. > >>> > >>> Best, > >>> 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 > >>> > >>> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > >> > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: JPMS support, refactored proposal
Le jeu. 4 janv. 2024 à 10:54, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2024-01-04 à 10 h 27, Romain Manni-Bucau a écrit : > > > You also explained this is not true since you cannot compile part of > > the code linked to optional depswhich go against JPMS > > > No, optional dependencies in JPMS are handled by "static requires". > As explained in previous post it is not always possible cause JPMS enforces constraints which are not always respected. > > > > You will also note the compile time check is a very low check in this > > area compared to any runtime (tests) so this is a sacrifice which is > > generally very acceptable > > > This statement is highly questionable. But anyway, this is an > unnecessary sacrifice as it requires going the hard way (trick Java). > > > > the ecosystem is far to have adopted it and it does not bring much to > > dev, so please don't assume JPMS is the way to go *yet*. > > > I'm not forcing anyone to use JPMS. I'm trying to make it easy for those > who want. > > * Want class-path compatibility only? Compile on class-path. > * Want JPMS compatibility only? Compile on module-path. > * Want JPMS + class-path compatibility? Compile on module-path + > workarounds. There is no sane alternative. > > > > doing anything classpath + workarounds for JPMS works in 90% of cases > > > No, this approach requires tricking Java and is unsafe, for no gain in > the end result compared to the simple and sane way. Furthermore, it does > not work at all (uncompilable) for the common case where the developer > wants to write module-info.java himself. It does not cover 90% of cases, > it is more like 1%. > Your vision I guess, mine is the opposite from what I saw in OSS land so let's not move forward in the discussion while both cases are covered we will be fine. > > Martin > >
Re: [discuss] extend extensions.xml to lifecycles/packaging and types?
Hi Christoph, commented inline Le jeu. 4 janv. 2024 à 10:19, Christoph Läubrich a écrit : > Isn't it already possible to "extend" the lifecycle by simply putting > plugin + execution into root pom? > Kind of but it requires a lot of abstraction and inheritance abuse IMHO. For a single module you are very right but for a 10+ project where 5+ modules will use the same kind of build it will require a pom in the middle leading to werid structures like root/services/x/pom.xml root/lib/x/pom.xml so composition would be better there - but you're right, not a blocker to build the final deliverables. > > Main problem for me is that currently packaging == type == lifecycle, > otherwise one could simply have an "empty" lifecycle + whatever > packaging and simply bind anything you want tin pom.xml e.g. > > > > jar >empty (would default to packaging if not > given, where empty is just a lifecycle with no mappings) > > > >org.apache.maven.plugins >maven-jar-plugin > > > ... define all your custom bindings here ... > > almost, you still need to associate phase(s) to each plugin to be able to run "mvn compile" "mvn test" or alike until we have an alias notion in pom/extensions.xml (= say "mvn foo" means run these plugins but it is the lifecycle somehow). > > > Am 04.01.24 um 09:37 schrieb Romain Manni-Bucau: > > Hi all, > > > > Reviewing and trying to follow Martin's thread about JPMS I thought about > > the old issue that our build pipelines (plugins chain) is very hard to > > customize. > > Guillaume added the priority case but the clean solution proposed > > originally was to define custom lifecycles (to add frontend, docker > builds > > for ex) - more or less a custom AbstractLifecycleMappingProvider. > > > > I wonder if we shouldn't extend .mvn/extensions.xml (or root pom > > block) to support to define custom lifecycle mappings there > > and potentially explicit new "types" too which would be great for > Martin's > > work since it would allow to avoid undefined types and implicit jar > mapping > > in a "strict" mode (to detect typos for ex since it must become open). > > > > So proposal is to extend extension to get more configuration - and coded > > extensions can indeed plug themselves there. > > The main challenge seems to be to re-evaluate the mappings but looks > doable. > > High level it is more or less "let the pom/.mvn inject maven components > > without coding/by declaration". > > > > Hope it makes sense, let me know if it is worth investigating more or if > > the idea is too particular to my old needs. > > > > Best, > > 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 > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: JPMS support, refactored proposal
Le jeu. 4 janv. 2024 à 10:20, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2024-01-04 à 09 h 21, Romain Manni-Bucau a écrit : > > > Please just stip thinking jpms first, think classpath first with jpms > > compat, changes the whole perspective. If i want classpath compat more > > than jpms why would i do everything with module and miss my 80% case? > > > Because doing everything as JPMS + workarounds (e.g. copying service > declarations into META-INF) works in both cases (proof: the Apache SIS > project), while the converse is not true: you cannot compile a JPMS > project with class-path, except by tricking Java (inject module-info > *after* compilation, at the cost of sacrificing compile-time checks in > the whole project). > You also explained this is not true since you cannot compile part of the code linked to optional deps which go against JPMS so status quo there and no single silver bullet. You will also note the compile time check is a very low check in this area compared to any runtime (tests) so this is a sacrifice which is generally very acceptable until you are JPMS first which is still quite rare - I don't want we emphasis JPMS more than its adoption, this is not because tools are not ready that it is not adopted just because the programming model is not nice enough, the ecosystem is far to have adopted it and it does not bring much to dev, so please don't assume JPMS is the way to go *yet* - hopefully it can be enhanced in the future on java platform but it is way outside build scope IMHO. So overall doing anything JPMS + workaround works in 80% of cases, doing anything classpath + workarounds for JPMS works in 90% of cases or something like that so it is literally a dev/community preference IMHO and you can't impose one or the other with technical points (depends how much you use optional deps, the existing code base, the compilation base also, etc...). Let's just make it all working as smoothly both ways. > > Martin > >
[discuss] extend extensions.xml to lifecycles/packaging and types?
Hi all, Reviewing and trying to follow Martin's thread about JPMS I thought about the old issue that our build pipelines (plugins chain) is very hard to customize. Guillaume added the priority case but the clean solution proposed originally was to define custom lifecycles (to add frontend, docker builds for ex) - more or less a custom AbstractLifecycleMappingProvider. I wonder if we shouldn't extend .mvn/extensions.xml (or root pom block) to support to define custom lifecycle mappings there and potentially explicit new "types" too which would be great for Martin's work since it would allow to avoid undefined types and implicit jar mapping in a "strict" mode (to detect typos for ex since it must become open). So proposal is to extend extension to get more configuration - and coded extensions can indeed plug themselves there. The main challenge seems to be to re-evaluate the mappings but looks doable. High level it is more or less "let the pom/.mvn inject maven components without coding/by declaration". Hope it makes sense, let me know if it is worth investigating more or if the idea is too particular to my old needs. Best, 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>
Re: JPMS support, refactored proposal
Le jeu. 4 janv. 2024 à 01:23, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2024-01-03 à 21 h 31, Romain Manni-Bucau a écrit : > > >> Can you compile this test case with the dependency on the class-path, > >> without omitting the module-info in the compilation? > >> > > This is exactly the case, module-info is injected somehow - a common > > case is by generating its bytecode but multiple compiler executions is > > another case. > > > I'm talking about the case where developers write their own code, > including the module-info.java file. You confirm that this test case in > uncompilable with class-path? > Yep > I presume that "multiple compiler executions" means "compiling only a > subset of the project". The situation is the same: module-path works, > class-path does not work unless the module-info.class file is deleted. I > updated the README with step-by-step instructions for anyone to try: > > https://github.com/Geomatys/MavenModulepathBug/tree/modularized-client > > Finally, if some developers want to inject a generated module-info.class > file *after* compilation, then class-path works. But the developers lost > all compile-time safety regarding module encapsulation. Nothing prevent > the developers to accidentally use non-exported packages, in which case > compilation will wrongly succeed but an exception will be thrown at > runtime when the code attempts an unauthorized access. So no, class-path > doesn't work for JPMS projects, except by tricking Java with > module-info.class injection *after* compilation. I would discourage that > trick because: > > * The whole project loses all compiler verification of package > accesses, resulting in potentially unexecutable application because > of code that should not have been allowed to compile. > * Errors in the generated module-info.class itself (e.g. missing > "requires" statements, wrong "provides" statements, etc.) will also > be unnoticed at compile-time. > * Adding a class generation phase is more complicated than handling > module-info like ordinary source code and letting javac do its job > (with the added benefit of letting javac do all the verification). > * Module-info is rich (requires, transitive requires, static requires, > exports, qualified exports, opens, qualified opens, uses, provides, > javadoc, etc.). I don't think that generated code can reflect > developers intend as accurately than hand-written module-info. > This is only true if you are a scala guy (old joke) and compiling is testing. You can easily a compiling but not running case and not all statement are true, just true when biaised from jpms view but look bnd or moditech and most become no more true. > Before to argument on each point, let focus on the first one. There is > no way (to my knowledge) someone can use class-path without scarifying > compile-time checks of package accesses. However, if someone really > wants to do that anyway, it will still be possible. But it is not the > approach that I'm trying to make easy. The approach that I'm trying to > make easy is the sane way, which is module-info (either .java or .class) > available at compile time, which mandates the use of module-path (I'm > talking only of JPMS projects here). The claim that class-path is the > way to go in JPMS projects is demonstratively false, proven by above > test case. Class-path in JPMS project is unsafe at best, or doesn't work > at all otherwise. If I'm wrong, I need to be convinced by test cases. > Not email arguments, test cases. > Please just stip thinking jpms first, think classpath first with jpms compat, changes the whole perspective. If i want classpath compat more than jpms why would i do everything with module and miss my 80% case? > > > Now, enhance your example to consume a jar where implicit module name > > would be invalid for example, how would you compile? > > > If the implicit name is wrong, I want a compilation error. Why would I > want a compilation success followed by a runtime failure? Furthermore, > this counter example is moot, because by the rules explained in previous > emails, that JAR file would be placed on the class-path by default since > it has no module-info and no Automatic-Name manifest attribute. Anyway, > users can also explicitly request to put any dependency on the class-path. > Same there, my lib integrates with a 3rd party, its name is wrong but i still want this optional integration - not exposed using jpms. > > > javadoc:javadoc -> > > > https://github.com/apache/maven-javadoc-plugin/blob/master/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocM
Re: JPMS support, refactored proposal
Le mer. 3 janv. 2024 à 19:25, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2024-01-03 à 17 h 15, Romain Manni-Bucau a écrit : > > > see it as "where classpath is in core comes from the time maven was > > only for java libs" (i'd say maven 2 cause I don't know maven 1). > > > The CLASSPATH_CONSTITUENT property and related isAddedToClasspath() > methods were added in Maven 4. I let you (Maven core developers) choose > where to put those properties/methods. My point is that everywhere there > is non-deprecated class-path, should be module-path too. > I understood but the assumption that what is not deprecated is an example is something I wouldn't risk to bet on so maybe better to be in the mindset "what looks correct" (just my 2 cts). > > > > From what I understood it uses the getpathtype methods of your PR and > > limits the type to CLASSES or MODULE, this is where I'm a bit lost. > > > This is a limitation of the current version of DependencyProperties, > because it uses boolean flags for specifying whether a dependency should > be on the CLASSES set or the MODULES set. So we are limited by the > predefined set of boolean flags. This is why I proposed to replace them > by a single property giving directly the PathType values. This is a > minor change, but maybe I should add a commit for that change now for > clarity. > Ok, so it does not work as this but you explained the proposal in a few iterations, got it now, thanks, was starting to be lost! > > > > A lib consumed both as a class path element or module path element > > (most libs) generally compiles using classpath and renders the javadoc > > with module > > > I'm not sure what you mean. Class-path / module-path apply to the > dependencies, not to the module that we are compiling (unless you are > talking about Module Source Hierarchy, but this is another topic). If > you mean that libs generally compile with their dependencies on the > class-path, this is not true if for JPMS module. To prove my point, I > have created yet another test case: > > https://github.com/Geomatys/MavenModulepathBug/tree/modularized-client > > See instruction in the readme. Can you compile this test case with the > dependency on the class-path, without omitting the module-info in the > compilation? > This is exactly the case, module-info is injected somehow - a common case is by generating its bytecode but multiple compiler executions is another case. Now, enhance your example to consume a jar where implicit module name would be invalid for example, how would you compile? That said it is also true this is not a big deal which dispatching works as before probably and the configuration of dependencies can still be done per plugin (javadoc rendering modules and compilation being done on classpath even with 2 passes). > > > > Today javadoc plugin compensate that by *not* respecting the pom > > configuration (it has yet another "guess" algorithm which works not > > bad) but your wish is to drop that so all the current functional cases > > would be broken or you would have to keep what you don't want in the > > plugin > > > If you are talking about javadoc:aggregate, indeed I would not touch > that part. This particular case lives in its own world. But > javadoc:javadoc would work in the same way as java, javac and all other > standard tools. > javadoc:javadoc -> https://github.com/apache/maven-javadoc-plugin/blob/master/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L4420 > > Martin > >
Re: JPMS support, refactored proposal
Le mer. 3 janv. 2024 à 17:03, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2024-01-03 à 16 h 45, Romain Manni-Bucau a écrit : > > maven4 introduces the notion of "services" (...snip...) So guess all > > is there to do it and core can stay as this for backward compat > > (maven4 must support maven3) but nothing more. > > Current services are class-path aware, with DependencyProperties and > isAddedToClasspath() methods. My argument is that where class-path is > handled, module-path should be handled too, because it is a replacement > for class-path. > No, I don't think this is a valid assumption, see it as "where classpath is in core comes from the time maven was only for java libs" (i'd say maven 2 cause I don't know maven 1). But it is mainly a location issue IMHO, way less important than the concept point for me. > > > > Maybe I misread your PR but I didn't see where dependencies were added > > in dep resolver using the meta > > > I do not touch to this part of Maven. > >From what I understood it uses the getpathtype methods of your PR and limits the type to CLASSES or MODULE, this is where I'm a bit lost. > > > > > use javadoc:javadoc then, intent is to run it with --module-path > > target/classes but compile with --classpath > > > No, if the project is compiled with --module-path, it should be run with > the same --module-path (except for JAR added/removed because of scopes), > and javadoc should be run with the same --module-path as well. No, this is your case which is part of the game only. A lib consumed both as a class path element or module path element (most libs) generally compiles using classpath and renders the javadoc with module to expose all it can (and since the module meta can be ignored by the user more easily if he picks classpath rather than the opposite where the module meta would miss). > I do not > understand why you insist for inconsistent options? Can you please > provide a test case showing your point? We are keep arguing again and > again in circles. Please prove me your point with an "hello world" > compilable, executable and documentable on the command line with > inconsistent options, and showing that those inconsistencies are > required for producing the desired result. > Today javadoc plugin compensate that by *not* respecting the pom configuration (it has yet another "guess" algorithm which works not bad) but your wish is to drop that so all the current functional cases would be broken or you would have to keep what you don't want in the plugin so I don't see where your alignment goes, it stops quite quickly for ~half of the cases? This can be done with types - your current options, just need to drop most of the path code from the pr, let plugin consumers types as path configuration (example for exec plugin: -> ) and it would work. It will just not be very neat and convenient in some builds cause you cant say dummy=foo+bar and use dummy in plugins but guess it is workable, just wonder how long this design will last before we start to work it around which is what makes me a be worried about the future of this design even if it works for your particular case. > > Martin > >
Re: JPMS support, refactored proposal
Le mer. 3 janv. 2024 à 16:11, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2024-01-03 à 15 h 19, Romain Manni-Bucau a écrit : > > > I can agree with that so let's move it in a plugin related code maybe? > > > The call is on core Maven developers. If Tamas (or someone else) moves > everything related to class-path to another location, I will follow. But > I think it would need to be a place shared by all Java plugins. > Not really, maven4 introduces the notion of "services", this is where it sits in maven plugin api probably "findDependenciesByFlag(flag)" or "findDependenciesByFilter(...)" - thinking out loud it can not need anything but just to resolve all deps of the module upfront the module build instead of doing it by phase then it is just a .stream().filter() matter. So guess all is there to do it and core can stay as this for backward compat (maven4 must support maven3) but nothing more. > > > > The SPI registration is different depending you are on the class or > > module path. > > > Yes, but it is different than saying that ServiceLoader does not work > well with modules. Managing those differences is one purpose of better > class-path / module-path control. > > > So how do I resolve a "library-path" lib which is > > org/foo/bar/1.0.0/bar-1.0.0.so for example? > > > In a custom plugin written by Java code? > * Create a new PathType instance, e.g. named NATIVE_LIBRARIES. > * Create a new Type instance, e.g. named "so", which declares that > dependencies of this type are members of the NATIVE_LIBRARIES paths. > Notes: > o As said before, this requires a minor change in > DependencyProperties API. > o This approach may have changed since December 14th, I'm not sure. > * In the plugin code, call the following: > > DependencyResolverResult result = > session.getService(DependencyResolver.class) > .resolve(session, project, ResolutionScope.PROJECT_COMPILE); > List paths = result.getDispatchedPaths().get(NATIVE_LIBRARIES); > > That's all, plugin uses the paths as they want. If there is a need for > custom code specifying what to do when the same dependency belong to 2 > or more PathType, it could be done by adding some methods in > DependencyResolverRequest (not shown in above example). > Maybe I misread your PR but I didn't see where dependencies were added in dep resolver using the meta but if it is the case you are in the case I mentionned in previous comment: you just let to the plugin the filtering so precollecting it makes it a lot of work compared a custom filter (this so example look simple but add dll/dylib cases and you'll see that it is easier with a filter, we had the same issue with path filtering and ended dropping most of the tools plugin shared for that reason). So overall, if this genericity is true it means that the surfacing of the jpms flags can sit in a maven 4 service and be it (and drop it from internal basically). That said I'm not sure how getPathType can return PathType.FOO in current code. > > > > No need to modify it, just run javadoc:aggregate on this example > > > javadoc:aggregate (as opposed to javadoc:javadoc) is a special case, as > it does not process a single Maven module, but all modules together. So > it needs to compute the union of source-directories, class-paths and > module-paths of all Maven modules, which is indeed not a standard Maven > usage. If I remember right an email seen on this list or on JIRA years > ago, they way that javadoc:aggregate does that is a dirty trick even by > Maven 3 standards. But anyway, 1) plugins will still be allowed to do > dirty tricks if they want, and 2) the need for javadoc:aggregate would > be greatly reduced with Module Source Hierarchy (javadoc:javadoc would > do the same work in a cleaner way), but this is another debate that I > would like to avoid for now. > use javadoc:javadoc then, intent is to run it with --module-path target/classes but compile with --classpath in the mentionned example (it is true from deps too) so it stays in the current situation for pom writer IMHO even if you enhanced the plain jpms adopter case. this currently works cause both plugins handle the path differently but it seems your intent is to align both - which is something I can understand for your case. so the issue is still the same for me: you cover one valid use case quite well but we add mess on mess (agree with you that each plugin having got a custom jpms integration was not great even if it has explanation for mvn3). so I still think we should step back, review the concepts we have and identify that some are outdated - cause classpath is no more a single thing for example, you are right - and c
Re: JPMS support, refactored proposal
Le mer. 3 janv. 2024 à 14:45, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2024-01-03 à 12 h 08, Romain Manni-Bucau a écrit : > >> I would like to see a proof in the form of an "hello world" > >> application (…snip…) > > > > Yot got some on github. > > > Can you share the URL? > > > >> defaulting on the classpath is fine only if the library developers > >> applied workarounds (…snip…) > >> > > The opposite got proven too > > > Which opposite do you mean? If it is "defaulting on the module-path", > this is not the proposal. The proposal is: comply to developers > instructions when they are explicit, otherwise check if the dependency > is modularized. > No this part is fine, think I misunderstood the phrasing (thought it was about an uninified enforced path) but if it is what you meant no issue there, sorry about that. > > > > I fail to see why you try to impose a single reduced use case to core. > > > Because currently, class-path is managed in core. If class-path become > managed in a different place, I will move module-path management in that > place too. No matter where class-path is managed, I think that > module-path and patch-modules need to be managed in the same place, > because module-path is (partially or fully) a replacement for > class-path. And I think that this management needs to be the same for > all standard Java tools, at least by default. > I can agree with that so let's move it in a plugin related code maybe? > > > > Workarounds are needed both ways but a lib can't, today and likely for > > some serious years, enforce people to consume it as a module, just > > because most of the runtime environments don't support it well enough > > (service loader is a good one here). > > > Workarounds are needed only if a library needs to be usable on *both* > class-path and module-path. Whether a library developer targets only the > class-path, or only the module-path, or both, is developer's choice. On > Maven side, I believe that our task is only to make all those 3 options > as easy as each other. Nothing more. > True but it is a bit more cause maven is opiniated and I guess this is where we wouldnt converge so hopefully we would find a solution which comply to all 3 smoothly (otherwise current state is already good so hope we don't get at the opposite ;)). My side note is that, from maven standpoint, we should probably consider the default choice is both for 5-6 years (we can revise it later indeed). > > I'm not sure to understand correctly the allusion to service loader, > because the sentence seems to said that java.util.ServiceLoader does not > support modules well, which is not true. Or maybe you identified issues > when a service has some implementations on the class-path and some other > implementations on the module-path? Even if it is the case, the proposal > allows developers to force a dependency to be on the class-path. It is > just that if a dependency is forced on the class-path, then *by default* > it will be there for all tools: java, javac, javadoc, etc. But even that > is overrideable. > The SPI registration is different depending you are on the class or module path. And as a lib you often need to support both (sadly, never said I was happy about that java choice but that's real life). I would still be happy to get an overridable example, maybe more on native lib case which needs the type=extension thing (since jar is the default loosing the extension configuration provided by type is fine) so how do I resolve a "library-path" lib which is org/foo/bar/1.0.0/bar-1.0.0.so for example? > > > > Just give it a try to write a small lib (a "commons" for ex ;)) and > > make it classpath and module friendly using a module aware javadoc and > > mainly a classpath build. Now do a lib consuming this first lib with > > the same constraint (be consumable by anyone since most of libs desire > > that) and you'll see what I mean. > > > I don't see what you mean. I proved my point with a test case which does > what you said: a small lib (called "service") and a lib consuming it > (called "client"). Can you show your point by modifying this test case, > or create a new one please? > > https://github.com/Geomatys/MavenModulepathBug No need to modify it, just run javadoc:aggregate on this example, this should use only module mode whereas build can use classpath (this is the expectation in my example) so javadoc and javac don't share the module/class paths. > > > > > once again it is used today by being explicit, requires a bit more > > work but you can't proove it is not doable > >
Re: JPMS support, refactored proposal
Le mer. 3 janv. 2024 à 11:50, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2024-01-03 à 09 h 08, Romain Manni-Bucau a écrit : > > > (…snip…) just to answer trivially to "But if an artifact is included, > > it should (at least by default) always be placed consistently on the > > class-path or module-path.", it is obvious it is not the case for > > several plugins like surefire (…snip…) > > > I would like to see a proof in the form of an "hello world" application, > compiled and executed on the command-line with inconsistent options, > showing that it works and can only work with the inconsistency. I'm not > talking about dependencies added or removed such as JUnit (this is > handled by scopes). I'm talking about the same dependency being on the > class-path at compile time but the module-path at runtime, or conversely. > Yot got some on github. > > > > (…snip…) where ultimately you want to test both but default on > > classpath is fine in 80% of cases even if a module (…snip…) > > > No, defaulting on the classpath is fine only if the library developers > applied workarounds. This point have been proven by an executable test > case months ago. This is an objective fact, not an opinion. So I'm not > sure why you keep bringing an argument that has been demonstrated to be > technically false. Is it because you think that the Java ecosystem > should be forced to keep class-path compatibility? > The opposite got proven too so I have to admit I fail to see why you try to impose a single reduced use case to core. Workarounds are needed both ways but a lib can't, today and likely for some serious years, enforce people to consume it as a module, just because most of the runtime environments don't support it well enough (service loader is a good one here). Just give it a try to write a small lib (a "commons" for ex ;)) and make it classpath and module friendly using a module aware javadoc and mainly a classpath build. Now do a lib consuming this first lib with the same constraint (be consumable by anyone since most of libs desire that) and you'll see what I mean. Indeed in the case of a single app this does not make much sense since you are "chrooted" in a context. > > > > (…snip…) lib will always priviledge its main consumers - classpaths > > today - and enable others - jpms (…snip…) > > > Libraries can do that if they want, but should not be forced to do so. Agree > > Maven 3 practically forces libraries to be designed for class-path > (again: demonstrated by executable test case). By default I agree but you got the solution to use module path, patch path etc (once again it is used today by being explicit, requires a bit more work but you can't proove it is not doable so we only speak of defaults here and indeed maven default is the classpath- historical and still this convention over config thing). > The proposal for Maven 4 > aims to remove this restriction by making module-path as easy as > class-path. It should be transparent for most users, with enough > configuration power for resolving common problems when necessary. I > believe that the current proposal achieve those goals. If it is not the > case, again let prove that with an executable test case against a > prototype. > Rewind a bit the threads and see that the original topics in that area were not JPMS - some started before JPMS - but processors, agents to cite the most known. You still don't solve that since both of them are obvious path which are not consistent between plugins. > > > > (…snip…) using the classpath will enable to fall in an area you can > > use more reflection (…snip…) > > > Enabling more reflection in a module is the purpose of the --add-opens > option, so we don't need class-path for that. But anyway, if a developer > really wants to force the use of class-path, it is still possible with > the proposal. > This is true as much as wrong. This will work when you control the JVM options but most libs will desire to avoid that and classpath is one of the known solutions which works well. > > > > (…snip…) even plain exec plugin which does not handle modules in java > > mode so will ignore - by design - several of the options you added. > > > Why would the exec plugin wants to ignore the module-path by design? > Cause it does not launch a JVM so several options will not be not available. Indeed, some case be reimplemented - guess module path is the easiest - but several will never be cause it is not the JVM owner (same applies for env vars for ex to enlarge the picture to the constraint). The same kind of constraint is owned by JakartaEE today or several spring runtime envs. > > > > The first concern of my
