Re: Access the maven commandline options from a plexus component?
Key code is here: https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L1367-L1431 The CliRequest contains all the original arguments, MavenExecutionRequest transforms these values and can be accessed via MavenSession. I don't see anything related to showVersion. If you have a good argument why you need it later, you can provide a PR where the MavenExecutionRequest is extended with boolean showVersion() thanks, Robert -- Oorspronkelijke bericht -- Van "Christoph Läubrich" Aan "Maven Developers List" Datum 10-11-2022 08:49:03 Onderwerp Access the maven commandline options from a plexus component? Is it possible to access the commandline options I pass to maven in a plexus component? I'm especially interested in the -V option because I want this to trigger printing the version of my core-extension as well - 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: Adding extra "scope" type metadata to dependencies?
Regarding #1 you need to be more precise. The jigsaw-team also thought it would be easy to extend the pom for this. However, in the end I discovered there's no need to do this. The plexus-java library has code which you feed the module descriptor and all jars and it is able to decide if they belong to the modulepath or classpath. Only for testing you might want want to decide where services or static required modules belongs. That's a per-test decision, so can't be done at pom-level. plexus-java[1] has proven itself since Java 9, only edge cases are tricky, but most of the time it is in the details of the specification of the java module system. Robert [1] https://codehaus-plexus.github.io/plexus-languages/plexus-java/usage.html -- Oorspronkelijke bericht -- Van "Ralph Goers" Aan "Maven Developers List" Datum 10-11-2022 06:08:27 Onderwerp Re: Adding extra "scope" type metadata to dependencies? Extending the pom.xml has been discussed for years. Unfortunately, it validates the XSD, so when the pom is extended with new attributes older versions of Maven will fail. This is the main reason why import scope was introduced rather than using a new element. There were many discussions about adding provides/requires concepts to the pom as well as other constructs but they always failed due to this. Ralph On Nov 8, 2022, at 1:36 PM, Mark Raynsford wrote: Hello! I'd like to be able to add extra metadata to dependencies in a POM file. Specifically: 1. I'd like to be able to specify whether a dependency goes on the class or module path rather than have Maven decide for me. 2. I'd like to be able to specify that a dependency _doesn't_ go on either path (possibly because it's going to be added manually elsewhere during deployment as an OSGi bundle, or as part of a dynamically created module layer, or something similar). Ideally, the second point would be handled properly by IDEs such that clicking "Run" wouldn't result in artifacts being added to the classpath/modulepath of the program the IDE runs. I remember reading (possibly over a year ago now) that there might be some possibility of an extension that allows for adding extra information to a element, but I'm now unable to find any evidence this existed. Is there some way to do this today? If not... Will there be some way in Maven 4.0.0+? -- Mark Raynsford | https://www.io7m.com - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MPH-183] effective-pom + verbose should show path to source
This is already a huge improvement as imported boms now hides this information. I do see room for more improvements, though (even though they could be considering as minor as this already solves a critical issue) From another example I picked one of the longest lines: 2.16.1 Suppose you want to use a different version of this zipkin dependency, what should you do? The first thing is to check is if you can upgrade spring-cloud-dependencies. The focus should be on that dependency. Even though io.zipkin.reporter2:zipkin-reporter-bom:2.16.1, line 149 is the most exact location, what's probably more important from a developer perspective is the preferred location to make a change in your pom. That would likely be org.springframework.cloud:spring-cloud-dependencies:2020.0.4. IMO that should be the first part of the line (instead of scrolling to the right). This implies reverting the order, so instead of .. from .. from .., I'd prefer .. to .. to .. Now that we know the org.springframework.cloud:spring-cloud-dependencies dependency needs to be updated, it would be great if it shows the linenumber in the pom. We might run into problems if this was inherited via a parent pom, in which case we should make clear which parent shoould be changed. I'm already very pleased with the current results. If you agree with me you can make separate tasks of it and decide if they should be come part of the same release or not. I consider it finetuning, although adjusting the order later might result in a huge shock as you suddenly need to read it the other way around. great work, Robert -- Oorspronkelijke bericht -- Van "Maarten Mulders" Aan "Maven Developers List" Datum 7-6-2022 17:46:41 Onderwerp [MPH-183] effective-pom + verbose should show path to source Hi all, Over the past months, I have been working on an enhancement [1] for the Maven Help Plugin. The enhancement is about the effective-pom goal. If you pass it the 'verbose' parameter, it will include inline comments saying "this line of the effective pom is caused by this line in a different pom": org.example mng-7344-dep-x 2 This is not so useful when you have a long path of POMs referring to each other. It will only show the last POM of that trail, but not the intermediate POMs. This makes it hard for users to understand how their effective POM was constructed. In the enhanced version, help:effective-pom -Dverbose would show something like this: org.example mng-7344-dep-x 2 (I'm sorry, the output is hard to read in a plain-text email; a formatted version is available in the JIRA ticket [1].) This enhancement requires changes in three projects: 1. Maven Help Plugin 2. Maven Core 3. Modello Now that the proof of concept is there, I'd like to ask: is this an enhancement we want to incorporate into Maven? If so, I'll start by polishing the code a bit, and then open three separate merge requests. We can discuss the implementation there. One particularly important thing to mention is that I did _not yet_ pay attention to backward compatibility of the Maven Help Plugin. I believe we can do this in a decent way - it wasn't the first priority for the proof of concept. I'm looking forward to hearing your thoughts on this. Thanks, Maarten [1] https://issues.apache.org/jira/browse/MPH-183 - 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: JDK 18 Release Candidate builds & JDK 19 Early-Access builds
Hi David, I just noticed that https://wiki.openjdk.java.net/display/quality/Quality+Outreach the Maven status for Java17 should be green. Confirmed via https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/ We used to test for LTS, current and next ea, but it seems the set has been reduced. I'll leave it up to the team if we can restore that. In the past we've already seen that doing that we could early respond to unexpected changes. thanks, Robert -- Oorspronkelijke bericht -- Van "David Delabassee" Aan rfscho...@apache.org CC dev@maven.apache.org Datum 28-2-2022 21:25:11 Onderwerp JDK 18 Release Candidate builds & JDK 19 Early-Access builds Robert, All, The Release Candidates of JDK 18 have been released [1]. At this stage, only P1 issues will be evaluated [2]. And with the JDK 18 General Availability sets for March 22nd, it is now time to shift the focus to JDK 19. I'd like to thank those of you who have already provided feedback on the early Early Builds of JDK 19. Feedback is always extremely useful, even more, when it comes early in the development cycle. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-February/006404.html [2] https://openjdk.java.net/jeps/3 ## JDK 18 Release Candidate The Release Candidate builds of JDK 18 are now available [3], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [4]. [3] https://jdk.java.net/18/ [4] https://jdk.java.net/18/release-notes ## JDK 19 Early-Access builds JDK 19 Early-Access builds 11 are now available [5], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [6]. [5] https://jdk.java.net/19/ [6] https://jdk.java.net/19/release-notes Recent changes that maybe of interest: * JDK-8278067: Make HttpURLConnection default keep alive timeout configurable * JDK-8281000: ClassLoader::registerAsParallelCapable throws NPE if caller is null * JDK-8282279: Interpret case-insensitive string locale independently * JDK-8176706: Support CLDR's Additional (Skeleton) Date-Time Formats * JDK-5041655: (ch) FileLock: negative param and overflow issues * JDK-8255266: Update Public Suffix List to 3c213aa * JDK-8280958: G1/Parallel: Unify marking code structure * JDK-8072070: Improve interpreter stack banging * JDK-8277175: Add a parallel multiply method to BigInteger * JDK-8278947: Support for array constants in constant table * JDK-8281462: Annotation toString output for enum not reusable for source input * JDK-8281175: Add a -providerPath option to jarsigner * JDK-8277795: ldap connection timeout not honoured under contention * JDK-8279842: HTTPS Channel Binding support for Java GSS/Kerberos * JDK-8280744: Allow SuppressWarnings to be used in all declaration contexts * JDK-8272984: javadoc support for reproducible builds * JDK-8272317: jstatd has dependency on Security Manager which needs to be removed ## New Project Loom Early-Access builds Project Loom Early-Access builds19-loom+4-115 (2022/2/13) are available [7] with the related Javadoc [8]. These EA builds are based on JDK 19 (jdk-19+9). In those builds, the APIs for Structured Concurrency and Scope Locals have been moved into the `jdk.incubator.concurrent` incubator module. Note that the module name may change later. To use those APIs, simply use `--add-modules jdk.incubator.concurrent` at compile and runtime. Those EA builds are provided under the GNU General Public License, version 2, with the Classpath Exception and are produced for the purpose of gathering feedback. Use for any other purpose is at your own risk. Proper feedback should be sent to the `loom-dev` mailing list [9]. [7] https://jdk.java.net/loom/ [8] https://download.java.net/java/early_access/loom/docs/api/ [9] https://mail.openjdk.java.net/mailman/listinfo/loom-dev ## Topics of Interest * JDK 18 - Card Table Card Size Shenanigans https://tschatzl.github.io/2022/02/15/card-table-card-size.html * Compiled & Tested Code In Javadoc - Inside Java Newscast #20 https://inside.java/2022/02/10/insidejava-newscast-020/ * New candidate JEP: 423: Region Pinning for G1 https://mail.openjdk.java.net/pipermail/jdk-dev/2022-February/006368.html * Refactoring Java 8 code with Java 17 new features - JEP Café #9 https://inside.java/2022/02/01/jepcafe9/ As always, let us know if you find any issues while testing your projects on the latest JDK Early Access builds. Thanks for your support! --David - 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
Change of Chair
Hi all, as of now, Karl Heinz is the new chairman of the Apache Maven project. I've done it for quite some time with a lot of pleasure. I will also reduce my activities on this project, but will still be involved as PMC member. thanks, Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Welcome Sławomir Jaranowski as Maven Committer
The Maven PMC invited Sławomir to become a committer and he has accepted it. Enjoy improving Apache Maven! thanks, Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: reviewing Maven Wrapper before releasing
Jason, my point is that i DID write integration tests as part of the donation to better understand the code, improve the codebase and its reliability. While writing them I did find several issues, some caused because the scripts didn't get in sync with the Maven core scripts. So it is possible to automate these tests, they are there, somebody just has to ported them to the new project. Also with the change of strategy how the wrapper should work we need integration-tests to confirm it all works. We shouldn't gamble, as almost every release people will only test is _after_ its vote, which is just too late. Robert [1] https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-5937%20wrapper -- Origineel bericht -- Van: "Jason van Zyl" Aan: "Maven Developers List" Verzonden: 12-12-2021 13:54:16 Onderwerp: Re: reviewing Maven Wrapper before releasing Clearly no one here disagrees with the goal of having robust testing for software that is made available to users. As to the timing of that testing being complete for the wrapper, to the satisfaction of those objecting to a release, I will argue. Do we wait four years for adequate testing? I’m not being facetious because we’re rolling up on three years since the initial donation of the wrapper was made. No one can force anyone else to do work here, sometimes things take a while, and there still may be a great deal of time that passes before testing is present that is considered adequate. All else being equal, I think the value of a release to remove the state of limbo the wrapper has been in for years outweighs the current lack of testing. The wrapper has been in use for 8 years, and while more testing is preferred we have reasonable assurances it works as expected. I don’t think we’ll be back to zero if we find issues, they can be fixed and will be accompanied by tests as most things here are. Right now from a user’s perspective the wrapper appears dead at Takari and Apache which is a shame. Would everyone be amenable to an alpha release? And transition to a non-alpha release when everyone agrees the testing is sufficient? jvz On Dec 12, 2021, at 5:14 AM, Maarten Mulders wrote: Chiming in a little late, but here are my 2 cents nevertheless. I would not feel confident releasing something that we cannot test in an automated way. Not having an integration test suite means we don't know for sure if it works. And if we know it works and we change something, we're back to zero. To me, this has nothing to do with a (misplaced) drive for perfection. It is all about making sure we ship something to users that we know to work, and that we can easily prove to still work after we change it. Thanks, Maarten On 11/12/2021 13:43, Robert Scholte wrote: It was marked for Maven 4, and part of the improvements was test automation, which was now possible because it became part of Maven Core. Even thought the code still exists in Maven Core, is has now become useless. There hasn't been a real need for new releases of Maven Wrapper Plugin until a range of Maven 3.8 started. Maven Wrapper would have been another feature to attract developers to Maven 4. And finally, I see that the donated code has been used as base, ignoring all the effort done to improve that codebase done afterwards. Hence my response that reliability is gone that was added after donation. Robert -- Origineel bericht -- Van: "Manfred Moser" Aan: dev@maven.apache.org Verzonden: 10-12-2021 20:58:33 Onderwerp: Re: reviewing Maven Wrapper before releasing I totally agree with finally just shipping this. We got this all donated about two years ago now and there is still nothing shipping. I used to just manually do the testing and thousands of projects are happy. I assume the new project is at least manually testing and works as before or better. Let's not wait nay more and let perfection get into our way. It surely is good enough for a release. The beauty is that if you find an issue.. you just ship again ... no reason to wait. manfred Hervé BOUTEMY wrote on 2021-12-10 04:13 (GMT -08:00): the current 3.1.0-SNAPSHOT works like 0.5.6 as donated: I confess I did not test, I just did not change anything using the general approach "people were happy before, just continue step by step improvements" :) reading the mvnw script (*nix), compiling+running the .java is executed only if neither wget nor curl are available on your machine reading the mvnw.cmd, it seems .java is not supported looking at Git history confirms: https://github.com/apache/maven-wrapper/commit/570bc50afe07bff696a097cd7746d01b00e70337 Don't hesitate to create a Jira issue and corresponding fix to add .java support for Windows: future 3.1.0 will have one more fix over previous 0.5.6 Regards, Hervé Le vendredi 10 décembre 2021, 10:40:41 CET Robe
Re: reviewing Maven Wrapper before releasing
It was marked for Maven 4, and part of the improvements was test automation, which was now possible because it became part of Maven Core. Even thought the code still exists in Maven Core, is has now become useless. There hasn't been a real need for new releases of Maven Wrapper Plugin until a range of Maven 3.8 started. Maven Wrapper would have been another feature to attract developers to Maven 4. And finally, I see that the donated code has been used as base, ignoring all the effort done to improve that codebase done afterwards. Hence my response that reliability is gone that was added after donation. Robert -- Origineel bericht -- Van: "Manfred Moser" Aan: dev@maven.apache.org Verzonden: 10-12-2021 20:58:33 Onderwerp: Re: reviewing Maven Wrapper before releasing I totally agree with finally just shipping this. We got this all donated about two years ago now and there is still nothing shipping. I used to just manually do the testing and thousands of projects are happy. I assume the new project is at least manually testing and works as before or better. Let's not wait nay more and let perfection get into our way. It surely is good enough for a release. The beauty is that if you find an issue.. you just ship again ... no reason to wait. manfred Hervé BOUTEMY wrote on 2021-12-10 04:13 (GMT -08:00): the current 3.1.0-SNAPSHOT works like 0.5.6 as donated: I confess I did not test, I just did not change anything using the general approach "people were happy before, just continue step by step improvements" :) reading the mvnw script (*nix), compiling+running the .java is executed only if neither wget nor curl are available on your machine reading the mvnw.cmd, it seems .java is not supported looking at Git history confirms: https://github.com/apache/maven-wrapper/commit/570bc50afe07bff696a097cd7746d01b00e70337 Don't hesitate to create a Jira issue and corresponding fix to add .java support for Windows: future 3.1.0 will have one more fix over previous 0.5.6 Regards, Hervé Le vendredi 10 décembre 2021, 10:40:41 CET Robert Scholte a écrit : I need more time. e.g. it looks like type=source doesn't use the Java sourcefile to download the wrapper. now that the plugin and wrapper are combined in one project, the ITs are incomplete. They should call both the wrapper-goal and something like 'mvnw --version' to ensure it is working (this used to be done in maven-integration-testing) thanks, Robert -- Origineel bericht -- Van: "Hervé BOUTEMY" Aan: "Maven Developers List" Verzonden: 10-12-2021 08:08:57 Onderwerp: Re: reviewing Maven Wrapper before releasing >thank you to everybody who reviewed, discussed, contributed > >we now have 16 issues fixed, everything seems stable > >if nobody objects, I'll start a release over the week-end > >Regards, > >Hervé > >Le mardi 7 décembre 2021, 00:07:41 CET Hervé BOUTEMY a écrit : >> Hi, >> >> Maven Wrapper has been donated to Apache Maven, imported to >> >>https://github.com/apache/maven-wrapper >> >> Documentation published to https://maven.apache.org/wrapper/ >> >> Here is the list of fixes from previous 0.5.6 release: >>https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721; >>ve>> >> rsion=12350068 >> >> >> Please test and review so we can do a release soon >> >> 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 - 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 - 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: reviewing Maven Wrapper before releasing
To me there's a very important piece missing. For the maven-wrapper-plugin I wrote several ITs to proof that downloading and unpacking works with all kinds of combinations of parameters. With the maven-wrapper code moved to this project, there no coverage at all to the actual wrapper code. Unlike maven-integration-testing there's no proof that mvnw works, because maven-invoker-plugin will keep using mvn. It needs to be improved like done with maven-verifier[1] (which is used by maven-integration-testing) IMO we should not release this maven-wrapper under pressure until this is solved: we should automatically verify that the scripts work now, as with any feature change. At its current state we've dropped in reliability compared to the maven-wrapper module in Maven Core. thanks, Robert [1] https://issues.apache.org/jira/browse/MSHARED-855 -- Origineel bericht -- Van: "Hervé BOUTEMY" Aan: "Maven Developers List" Verzonden: 10-12-2021 13:13:41 Onderwerp: Re: reviewing Maven Wrapper before releasing the current 3.1.0-SNAPSHOT works like 0.5.6 as donated: I confess I did not test, I just did not change anything using the general approach "people were happy before, just continue step by step improvements" :) reading the mvnw script (*nix), compiling+running the .java is executed only if neither wget nor curl are available on your machine reading the mvnw.cmd, it seems .java is not supported looking at Git history confirms: https://github.com/apache/maven-wrapper/commit/570bc50afe07bff696a097cd7746d01b00e70337 Don't hesitate to create a Jira issue and corresponding fix to add .java support for Windows: future 3.1.0 will have one more fix over previous 0.5.6 Regards, Hervé Le vendredi 10 décembre 2021, 10:40:41 CET Robert Scholte a écrit : I need more time. e.g. it looks like type=source doesn't use the Java sourcefile to download the wrapper. now that the plugin and wrapper are combined in one project, the ITs are incomplete. They should call both the wrapper-goal and something like 'mvnw --version' to ensure it is working (this used to be done in maven-integration-testing) thanks, Robert -- Origineel bericht -- Van: "Hervé BOUTEMY" Aan: "Maven Developers List" Verzonden: 10-12-2021 08:08:57 Onderwerp: Re: reviewing Maven Wrapper before releasing >thank you to everybody who reviewed, discussed, contributed > >we now have 16 issues fixed, everything seems stable > >if nobody objects, I'll start a release over the week-end > >Regards, > >Hervé > >Le mardi 7 décembre 2021, 00:07:41 CET Hervé BOUTEMY a écrit : >> Hi, >> >> Maven Wrapper has been donated to Apache Maven, imported to >> >>https://github.com/apache/maven-wrapper >> >> Documentation published to https://maven.apache.org/wrapper/ >> >> Here is the list of fixes from previous 0.5.6 release: >>https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721; >>ve>> >> rsion=12350068 >> >> >> Please test and review so we can do a release soon >> >> 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 - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: reviewing Maven Wrapper before releasing
I need more time. e.g. it looks like type=source doesn't use the Java sourcefile to download the wrapper. now that the plugin and wrapper are combined in one project, the ITs are incomplete. They should call both the wrapper-goal and something like 'mvnw --version' to ensure it is working (this used to be done in maven-integration-testing) thanks, Robert -- Origineel bericht -- Van: "Hervé BOUTEMY" Aan: "Maven Developers List" Verzonden: 10-12-2021 08:08:57 Onderwerp: Re: reviewing Maven Wrapper before releasing thank you to everybody who reviewed, discussed, contributed we now have 16 issues fixed, everything seems stable if nobody objects, I'll start a release over the week-end Regards, Hervé Le mardi 7 décembre 2021, 00:07:41 CET Hervé BOUTEMY a écrit : Hi, Maven Wrapper has been donated to Apache Maven, imported to https://github.com/apache/maven-wrapper Documentation published to https://maven.apache.org/wrapper/ Here is the list of fixes from previous 0.5.6 release: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721 rsion=12350068 Please test and review so we can do a release soon 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: reviewing Maven Wrapper before releasing
With mvn verify -Prun-its all ITs fail on my system. This should work out-of-the-box, so I'll need to investigate the issue. And I'm pretty sure we can remove the cli package: you can't pass System properties to Maven, only arguments. And they should be passed as is to mvn. IT's should confirm that. Robert -- Origineel bericht -- Van: "Jason van Zyl" Aan: "Maven Developers List" Verzonden: 7-12-2021 14:55:32 Onderwerp: Re: reviewing Maven Wrapper before releasing Everything builds and it generates the wrapper for a project in a way will be familiar to existing users. The switch for current users should, hopefully, be painless and transparent. Nice work Robert and Hervé. I put a notice on the GitHub page for the Takari version about the impending release at Apache, and provided pointers to the new Git repository and JIRA project. jvz On Dec 6, 2021, at 6:07 PM, Hervé BOUTEMY wrote: Hi, Maven Wrapper has been donated to Apache Maven, imported to https://github.com/apache/maven-wrapper Documentation published to https://maven.apache.org/wrapper/ Here is the list of fixes from previous 0.5.6 release: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721=12350068 Please test and review so we can do a release soon 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Eat our own dogfood
There's another project that is suffering from this change: https://github.com/quick-perf/maven-test-bench This is a benchmark comparing the performance on a specific commit on Camel (as it is a huge project) It would be great if we could have statistics on a wide range of Maven version. There are a couple of options: - restore the constructor causing the issue (if the removed class is still on the classpath, this would be a easy and valuable change) - select a different commit (and/or project) thanks, Robert -- Origineel bericht -- Van: "Paul Hammant" Aan: "Maven Developers List" ; "Robert Scholte" Verzonden: 10-11-2021 08:43:39 Onderwerp: Re: Eat our own dogfood Apache used to operate Gump for this purpose, back on the days of Ant and Maven 1.x. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Eat our own dogfood
This should be done as part of Mavens own build. Don't rely on uploaded versions, there's always a gap where another job could have uploaded a different version. If things start to fail, it could be hard to reproduce it. It should be the one that has been built and stashed, so you can unstash and unpack it in a new stage. Robert -- Origineel bericht -- Van: "Slawomir Jaranowski" Aan: "Maven Developers List" ; "Maarten Mulders" Verzonden: 9-11-2021 12:56:26 Onderwerp: Re: Eat our own dogfood Hi, Good idea. One of the resolutions can be to use maven wrapper to configure the Maven version to use, and use wrapper to build a project. Such a solution can be easily used in any CI system. Using a wrapper we simply download the latest build and deployed Maven version from the repository, we don't need to build the project twice. I assume that deployment is done after all tests pass so the repository will contain a working version. Task to do before: - Make maven wrapper functional [1] - Support SNAPSHOT versions by wrapper [2] [1] https://issues.apache.org/jira/browse/MWRAPPER-14 [2] https://issues.apache.org/jira/browse/MWRAPPER-15 wt., 9 lis 2021 o 11:52 Maarten Mulders napisał(a): Hi all, In the last year, we've seen multiple situations where a change in Maven core prevented Maven from building itself [1][2]. On the path to stabilising Maven towards Maven 4, I think this isn't helping us. That's why I propose we introduce an additional GitHub action. Let's call it the "eat our own dogfood" check: build Maven Core, then use that build to build Maven Core again. Maybe it's possible to do it on Jenkins, too. I'm less familiar with our Jenkins setup, that's all... What do you think? Thanks, Maarten [1] https://issues.apache.org/jira/browse/MNG-7087 [2] https://issues.apache.org/jira/browse/MNG-7319 -- Sławomir Jaranowski - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JPMS data as first-class citizen of the POM
Keep in mind that the pom.xml is language agnostic, it describes configuration that makes sense for any programming language. Hence, the pom should not be extended with Java specific features. Maven supports extensions, with seems like a better fit. Configuring an extension is not standardized yet, now the extension can pick up System properties of read some file from its preferred location. The closest you can get right now is probable the moditect-maven-plugin[1] thanks, Robert [1] https://github.com/moditect/moditect - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Upcoming Maven 3.8.4
We're in an awkward situation. It looks like that of all the 3.8.x releases, the first (3.8.1) is the most stable one. The subtitle of Maven 3.8.2 was "Fixes and non-invasive backports from Maven 4.0.0-alpha-1." Looking back it looks like the backports weren't that non-invasive, and we have unintended regressions on both 3.8.2 and 3.8.3 compared to 3.6.3 As you might know we do our (plugin) tests with every latest 3.x-release, because most assume that should be the most stable one. Hence we need to have a 3.8.4 with either fixes or reverts before thinking of any other release. thanks, Robert -- Origineel bericht -- Van: "Gary Gregory" Aan: "Maven Developers List" CC: "Rob Tompkins" Verzonden: 24-10-2021 12:03:59 Onderwerp: Re: Upcoming Maven 3.8.4 That's the normal release process for any project AFAIK, if you want to put a release candidate out to on https://dist.apache.org/repos/dist/dev/ that is done via svn, we've automated those steps. Then the actual release goes to https://dist.apache.org/repos/dist/release/, same for Maven https://dist.apache.org/repos/dist/release/maven/ After that, the files are mirrored all over by various servers. Publishing to Maven Central is a separate process but critical since that is what most builds (Maven, Ant Ivy, and so on) expect and use. Gary On Sun, Oct 24, 2021, 05:27 Slawomir Jaranowski wrote: Hi, Very strange release process for common components ... some of the artifacts are published to the Central Repository and some of them are published by svn repository ... I don't see benefit for customizing maven core for one of case of usage but it is discussion for another place, here I only point it sob., 23 paź 2021 o 22:51 Gary Gregory napisał(a): > HI All: > > I discovered a regression this morning that prevents me from creating > a release candidate for Apache Commons CLI: > > https://issues.apache.org/jira/browse/MNG-7316 > https://github.com/apache/maven/pull/601 > > May this be included for 3.8.4 please? > > Gary > > On Sat, Oct 23, 2021 at 3:48 PM Falko Modler wrote: > > > > Hi, > > > > > Given that we had two releases with regressions I tend *not* to merge > > > #578. Give it more time and thought. > > > > As written before on GH, not merging #578 or a backport of #476 will > > bring back MNG-6843. > > This will catch users off guard that were happily benefitting from > > MNG-6843 being fixed in 3.8.2 and 3.8.3. > > > > If you still want to do it this way, then please at least document that > > MNG-6843 is back under "Known Issues" in 3.8.4 "Release Notes". > > Additionally, MNG-6843 should be reopened. > > > > I'd really prefer if we could keep MNG-6843 fixed, by whichever PR > > (doesn't need to be mine). > > > > Cheers, > > > > Falko > > > > Am 23.10.2021 um 21:22 schrieb Michael Osipov: > > > Folks, > > > > > > all important tickets for Maven 3.8.4 have been addressed in > > > maven-3.8.x branch. > > > > > > We have two open PRs: > > > * #578: Alternative to the ThreadLocal approach > > > * #476: As far as I understand a more global approach to the issue and > > > supersedes #576, but requires Java 8. So Maven 3.9+ > > > > > > Given that we had two releases with regressions I tend *not* to merge > > > #578. Give it more time and thought. Maybe go over to #476 directly in > > > 3.9.0 and 4.0.0. > > > > > > Please test and let me know whether you still see errors. If I don't > > > read any objections I will start the new release somewhere around mid > > > next week. > > > > > > Michael > > > > > > - > > > 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 > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Sławomir Jaranowski - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven version 3.8.3
+1 -- Origineel bericht -- Van: "Michael Osipov" Aan: dev@maven.apache.org Verzonden: 29-9-2021 19:01:39 Onderwerp: Re: [VOTE] Release Apache Maven version 3.8.3 Am 2021-09-27 um 21:17 schrieb Michael Osipov: Hi, We solved 18 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12350518 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%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1667/ Dev dist directory: https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.3/ Source release checksums: apache-maven-3.8.3-src.zip sha512: 165c7ce9fbc1b20a0e826950f2acc6638abffbbcd0b2dda869b9b2612984c421c985844ec68b9d4f9d214df3d1531f3051bbe8edd29b22cf97ef4606f15761f7 apache-maven-3.8.3-src.tar.gz sha512: 7d7b6abf8f0407f95e35ccf857412b59c8ebfa0b2eef8cf52badf20d47e4be1e79f2412965d514314240184847b5bf5c20e63c7f4b8d6cce5d2f3bc5bd31d2f2 Binary release checksums: apache-maven-3.8.3-bin.zip sha512: 959de0db3e342ecf1c183b321799a836c3c10738126f3302b623376efa45c6769ccb5cd32a17f9a9a8eb64bb30f13a6a0e4170bf03a7707cfba6d41392107e93 apache-maven-3.8.3-bin.tar.gz sha512: 1c12a5df43421795054874fd54bb8b37d242949133b5bf6052a063a13a93f13a20e6e9dae2b3d85b9c7034ec977bbc2b6e7f66832182b9c863711d78bfe60faa Draft for release notes: https://github.com/apache/maven-site/pull/264 Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open until Sunday. +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 PMD Plugin version 3.15.0
+1 -- Origineel bericht -- Van: "Andreas Dangel" Aan: "Maven Developers List" Verzonden: 6-9-2021 20:56:25 Onderwerp: [VOTE] Release Apache Maven PMD Plugin version 3.15.0 Hi, We solved 14 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12349432=Text=12317621 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPMD%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1663/ https://repository.apache.org/content/repositories/maven-1663/org/apache/maven/plugins/maven-pmd-plugin/3.15.0/maven-pmd-plugin-3.15.0-source-release.zip Source release checksum(s): maven-pmd-plugin-3.15.0-source-release.zip sha512: 8ce5f12e7bbdb69013e122ef525f20c9cb191c1fbaf29708800aa887d2782e4eedc7aab51a663803e4c7d0f6005918836d5eb0a27bff35ffdf483194e32f7dc4 Staging site: https://maven.apache.org/plugins-archives/maven-pmd-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 Regards, Andreas - 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
[ANN] Apache Maven Javadoc Plugin 3.3.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Javadoc Plugin, version 3.3.1 The Javadoc Plugin uses the Javadoc tool to generate javadocs for the specified project. https://maven.apache.org/plugins/maven-javadoc-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-javadoc-plugin 3.3.1 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-javadoc-plugin/download.html Release Notes - Maven Javadoc Plugin - Version 3.3.1 ** Bug * [MJAVADOC-450] - Artifacts with a classifier are ignored when looking for resources in dependencies * [MJAVADOC-618] - Goal javadoc:aggregate fails with submodules packaged as war * [MJAVADOC-677] - Using "requires static transitive" makes javadoc goal fail * [MJAVADOC-678] - avoid unit test creating javadoc-options-javadoc-resources.xml in root directory * [MJAVADOC-679] - "Unable to compute stale date" in a directory with accent characters (charset issue) * [MJAVADOC-680] - JDK 16+: Error fetching link: [...]\target\javadoc-bundle-options. Ignored it. * [MJAVADOC-684] - maven-javadoc and reproducible builds ** Improvement * [MJAVADOC-683] - Reimplement failOnWarning (for Java 17) ** Task * [MJAVADOC-687] - Upgrade Jetty Version to last 9.4.x Enjoy, -The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] [VOTE] Release Apache Maven Javadoc Plugin version 3.3.1
Hi, The vote has passed with the following result: +1 : Hervé BOUTEMY, Robert Scholte, Arnaud Héritier, Karl Heinz Marbaise, Sylwester Lachiewicz PMC quorum: .reached I will promote the artifacts to the central repo. -- Origineel bericht -- Van: "Robert Scholte" Aan: "Maven Developers List" Verzonden: 4-9-2021 10:57:36 Onderwerp: [VOTE] Release Apache Maven Javadoc Plugin version 3.3.1 Hi, We solved 9 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317529=12347807=Text There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317529%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1660 https://repository.apache.org/content/repositories/maven-1660/org/apache/maven/plugins/maven-javadoc-plugin/3.3.1/maven-javadoc-plugin-3.3.1-source-release.zip Source release checksum(s): maven-javadoc-plugin-3.3.1-source-release.zip sha512: b10de64f1389b04b6e4aace3045f77e90515448d91cbb4705a0805779b052bc76df695ad85bad55288f8bc66b9bced86baad11bbb40ef06e441e20700bb31746 Staging site: https://maven.apache.org/plugins-archives/maven-javadoc-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 WAR Plugin version 3.3.2
+1 -- Origineel bericht -- Van: "Hervé BOUTEMY" Aan: "Maven Developers List" Verzonden: 5-9-2021 11:38:24 Onderwerp: [VOTE] Release Apache Maven WAR Plugin version 3.3.2 Hi, We solved 2 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121=12348574=Text Staging repo: https://repository.apache.org/content/repositories/maven-1661/ https://repository.apache.org/content/repositories/maven-1661/org/apache/maven/plugins/maven-war-plugin/3.3.2/maven-war-plugin-3.3.2-source-release.zip Source release checksum(s): maven-war-plugin-3.3.2-source-release.zip sha512: 368d1066d3aa429b3dc26b1e3a502fe56c4232fae13727c74d44015b160eec3753f28ff72e3a0f33f9dfa9d25e9912efb559d45cf41952151ecc88337203fc95 Staging site: https://maven.apache.org/plugins-archives/maven-war-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 Javadoc Plugin version 3.3.1
+1 -- Origineel bericht -- Van: "Robert Scholte" Aan: "Maven Developers List" Verzonden: 4-9-2021 10:57:36 Onderwerp: [VOTE] Release Apache Maven Javadoc Plugin version 3.3.1 Hi, We solved 9 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317529=12347807=Text There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317529%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1660 https://repository.apache.org/content/repositories/maven-1660/org/apache/maven/plugins/maven-javadoc-plugin/3.3.1/maven-javadoc-plugin-3.3.1-source-release.zip Source release checksum(s): maven-javadoc-plugin-3.3.1-source-release.zip sha512: b10de64f1389b04b6e4aace3045f77e90515448d91cbb4705a0805779b052bc76df695ad85bad55288f8bc66b9bced86baad11bbb40ef06e441e20700bb31746 Staging site: https://maven.apache.org/plugins-archives/maven-javadoc-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
[VOTE] Release Apache Maven Javadoc Plugin version 3.3.1
Hi, We solved 9 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317529=12347807=Text There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317529%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1660 https://repository.apache.org/content/repositories/maven-1660/org/apache/maven/plugins/maven-javadoc-plugin/3.3.1/maven-javadoc-plugin-3.3.1-source-release.zip Source release checksum(s): maven-javadoc-plugin-3.3.1-source-release.zip sha512: b10de64f1389b04b6e4aace3045f77e90515448d91cbb4705a0805779b052bc76df695ad85bad55288f8bc66b9bced86baad11bbb40ef06e441e20700bb31746 Staging site: https://maven.apache.org/plugins-archives/maven-javadoc-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: Maven Extension Configuration
Yes it is, Karl Heinz beat me already in 2015! -- Origineel bericht -- Van: "Falko Modler" Aan: dev@maven.apache.org Verzonden: 31-8-2021 23:21:33 Onderwerp: Re: Maven Extension Configuration Hi Robert, this is basically https://issues.apache.org/jira/browse/MNG-5897, no? I left a few thouhts there a while ago. Cheers, Falko Am 31.08.2021 um 22:50 schrieb Robert Scholte: Hi, I see quite some Maven extensions that rely on configuration. There's no convention for this, so they all pick their own format and location. Looking at the build-cache it seems there's again configuration required. I think with Maven 4 we should make it possible to add a configuration-block to an extension, similar to plugins. The difficult part is how to make Components (@Named/@Inject) get access to this configuration. I don't think we can pass if with some method of an API. For that reason probably the Configuration itself should be a Component too and Maven (with Sisu) is responsible for mapping and injecting it. Important benefit is that we'll have type-safe configuration. I hope others like this idea as well. Is it worth investigating or do we already see blockers? In case of enough positive responses I'll prepare a wiki page for the details. thanks, Robert - 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
Maven Extension Configuration
Hi, I see quite some Maven extensions that rely on configuration. There's no convention for this, so they all pick their own format and location. Looking at the build-cache it seems there's again configuration required. I think with Maven 4 we should make it possible to add a configuration-block to an extension, similar to plugins. The difficult part is how to make Components (@Named/@Inject) get access to this configuration. I don't think we can pass if with some method of an API. For that reason probably the Configuration itself should be a Component too and Maven (with Sisu) is responsible for mapping and injecting it. Important benefit is that we'll have type-safe configuration. I hope others like this idea as well. Is it worth investigating or do we already see blockers? In case of enough positive responses I'll prepare a wiki page for the details. thanks, Robert
Re: Request for Enhancement: Dependency Overrides
On Twitter started a similar discussion, they should have joined to have a more complete view on this topic. Here's[1] where it all started: Robert [1] https://twitter.com/JonathanGiles/status/1427748493678956544 -- Origineel bericht -- Van: "Enno Thieleke" Aan: "Maven Developers List" Verzonden: 26-8-2021 11:59:09 Onderwerp: Re: Request for Enhancement: Dependency Overrides Hi Michael, I'll take this as a "go ahead, if it's good we'll accept it". Just a few more questions before I start. For the issue: Would reopening https://issues.apache.org/jira/browse/MNG-4530 suffice or would you like to see a new one? Where do I create the proposal? What should be created first, the issue or the proposal? I'm asking, because in the proposal we'd work out the details and after that's done, that's where the issue becomes relevant (no issue, no code changes). At least that's how I'm used to implementing changes like this. I don't want to have created unnecessary noise in your issue system, if - for some unknown eventuality - the proposal doesn't get your approval. Is it ok to use one issue for changes in both projects, Maven and maven-resolver? Kind regards Enno From: Michael Osipov Sent: Wednesday, August 25, 2021 9:01 PM To: dev@maven.apache.org Subject: Re: Request for Enhancement: Dependency Overrides Am 2021-08-25 um 20:51 schrieb Enno Thieleke: Hello again, some days have passed and I didn't want to distract you people from releasing the new version of Maven, but now that it's done, I'm getting back to this topic. I'm asking for the opinion of the Maven PMC and committers regarding this feature. I'd like to see some sort of dependency override/replacement mechanism. One that's powerful, yet easy to use, which doesn't require boilerplate XML and which leaves the dependency graph virtually untouched (by that I mean the shape of the graph remains the same, unless additional transitive dependencies are brought into play by overrides/replacements). Please let me know what you people think of such a feature. Maybe a vote is in order, but I'm not sure and I wouldn't know how to call for one properly here. Please tell me how to proceed. I'm only willing to commit more time to this, if I have an ok from you that it'll be merged once it meets the quality standards of the Maven project. As I said previously, this perfectly makes sense, but having this in Core means that someone needs to create an issue, proposal and a PR. Consider that no one of us is getting paid on this, so free time only. Unless it comes from the community, I see little chances to have this soon. Michael - 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
(prop) Canonical property storage
FYI: A discussion has started on core-libs-dev mailinglist[1] about extending java.util.Properties with methods to store properties files in a reproducible way. If you have any comments, subscribe to the mailinglist[2] or ask me to drop the comments. thanks, Robert [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-August/080758.html [2] https://mail.openjdk.java.net/mailman/listinfo/core-libs-dev
Re: JDK 17 related plugin releases
Acknowlegded, but ASM 9.1 already supports Java 17, which is our main target. Robert -- Origineel bericht -- Van: "Gary Gregory" Aan: "Maven Developers List" ; mthmuld...@apache.org Verzonden: 18-8-2021 13:34:05 Onderwerp: Re: JDK 17 related plugin releases Note that the current version of ASM is 9.2. Gary On Wed, Aug 18, 2021, 03:49 Maarten Mulders wrote: Well, that was a short ride - the latest release of the maven-plugin-tools is already up-to-date, as it uses ASM 9.1. Same goes for the maven-dependency-plugin; latest release is also on ASM 9.1 From the "Required" list on the aforementioned Wiki page, that leaves us with the maven-shade-plugin. The last release, 3.2.4, uses ASM 8.0 so it definitely needs an upgrade of at least the ASM version. I'm not too familiar with this plugin, so I'm a bit hesitant to start working on it. There are also quite a few pending merge requests there that I would not know what to do with. If it only were about upgrading ASM, I could do that, but I cannot properly assess the open merge requests. Maarten On 18/08/2021 09:16, Maarten Mulders wrote: > I'll take the maven-plugin-plugin for a ride. > > > Maarten > > On 17/08/2021 19:28, Robert Scholte wrote: >> With JDK 17 appearing soon we should at least release those plugins >> that depend on ASM.[1] >> Even though optional, I'll release both the maven-compiler-plugin and >> maven-javadoc-plugin too. >> I could use some help with the other plugins too, including verifying >> if there are PRs worth adding and the doing the releases. >> Please raise your hand so we can divide the work. >> >> thanks, >> Robert >> >> [1] https://cwiki.apache.org/confluence/display/MAVEN/ASM+depending+projects >> >> >> > > - > 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
JDK 17 related plugin releases
With JDK 17 appearing soon we should at least release those plugins that depend on ASM.[1] Even though optional, I'll release both the maven-compiler-plugin and maven-javadoc-plugin too. I could use some help with the other plugins too, including verifying if there are PRs worth adding and the doing the releases. Please raise your hand so we can divide the work. thanks, Robert [1] https://cwiki.apache.org/confluence/display/MAVEN/ASM+depending+projects
Re: Commandline inheritance
Confirmed. Having the definition of central-repo in mind: this one is nominated to be moved from the super-pom to the installation settings.xml. It makes sense to have the ability to always override it using the user settings.xml (if you want to). Next the proposal is still to finally provide the --settings to override the previous result (so not anymore replacing one of the previous files). Based on the responses this seems to be preferred solution for handling this. Robert -- Origineel bericht -- Van: "Tamás Cservenák" Aan: "Maven Developers List" Verzonden: 10-8-2021 22:18:22 Onderwerp: Re: Commandline inheritance A git like behavior sound good for me as well. So install/system-wise < user < project T On Tue, Aug 10, 2021, 08:22 Benjamin Marwell wrote: I read Michaels message the way like option 6: > Since we have only two files: installation and user, I'd expect that first the installation settings are parsed followed by user settings (generic to specific). Installation is more generic (global) than user. Same for git: it will first parse the installation settings (/etc), then any user settings, then any project settings. Or are we mixing up terms here? NPM does the same, too. On Mon, 9 Aug 2021, 16:35 Robert Scholte, wrote: > I'll add it, but it doesn't match the order of GIT[1] as mentioned by > Michael. > Maybe there should be a list of other comparable tools with their order > > > Robert > > > [1] https://git-scm.com/docs/git-config#FILES > On 9-8-2021 15:09:30, Benjamin Marwell wrote: > Hi Robert, > > I would like to propose another solution. > According to the wiki page and to the documentation, we have > > user > > where " > > From what I understand from other build systems, a more common approach > would be > > installation (aka global) > > This would fix the naming issue (global becomes global). > Of course this is a breaking change, but for maven 4, this seems > reasonable to me. > > Am So., 8. Aug. 2021 um 11:48 Uhr schrieb Robert Scholte : > > > > During a discussion with Michael we noticed there's something odd about > the names of some flags and the order of inheritance. > > > > I've tried to explain it on a separate wiki page[1] together with the > first 3 options how we could fix it. > > Please have a look at it and share your thoughts. > > > > thanks, > > Robert > > > > [1] > https://cwiki.apache.org/confluence/display/MAVEN/Commandline+inheritance > > - > 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: maven-shade-plugin question
Looking only at the log, both writers existed before it was promoted from the sandbox in 2007. Counter was introduced by Karl Heinz while refactoring. It could very well be there's a better solution for it right now. I would expect enough coverage by ITs to confirm that. Robert On 9-8-2021 16:35:13, Tamás Cservenák wrote: Howdy, re maven-shade-plugin's Java package org.apache.maven.plugins.shade.pom: 1. What is the goal of this code? As there are 3 classes in here, and Counter is used only by MavenJDOMWriter, while MavenJDOMWriter is used only by PomWriter, while PomWriter is used only by ShadeMojo (to write out dep reduced POM), but 2. ... the xpp3 writer is available as well, as maven-model is pulled in as direct dependency, 3. ... but moreover, the model-writer is there as well (true. as maven-core transitive dep) so, what is the reason these classes exist? Do I miss something? Thanks T
Re: Commandline inheritance
I'll add it, but it doesn't match the order of GIT[1] as mentioned by Michael. Maybe there should be a list of other comparable tools with their order Robert [1] https://git-scm.com/docs/git-config#FILES On 9-8-2021 15:09:30, Benjamin Marwell wrote: Hi Robert, I would like to propose another solution. According to the wiki page and to the documentation, we have user where " >From what I understand from other build systems, a more common approach would >be installation (aka global) This would fix the naming issue (global becomes global). Of course this is a breaking change, but for maven 4, this seems reasonable to me. Am So., 8. Aug. 2021 um 11:48 Uhr schrieb Robert Scholte : > > During a discussion with Michael we noticed there's something odd about the > names of some flags and the order of inheritance. > > I've tried to explain it on a separate wiki page[1] together with the first 3 > options how we could fix it. > Please have a look at it and share your thoughts. > > thanks, > Robert > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Commandline+inheritance - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven version 3.8.2
+1 On 4-8-2021 22:02:18, Michael Osipov wrote: Hi, We solved 68 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12349965 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%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1657/ Dev dist directory: https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.2/ Source release checksums: apache-maven-3.8.2-src.zip sha512: 228ae07dfd89f73cc7d0b10b60708db2730465dbe6022968bde6c5d7f0df9bcd7f460fe1d8012726a29f136486bdb63d1e1ba932e307380fe4c1f4db440407dd apache-maven-3.8.2-src.tar.gz sha512: 617377ad85ced7961f972610ed88535fd3f1ab18e104556d8a3adee7769515ee67ee3cbaff50afcffd74a443b471b806acb1ae92f91a259bc8ccaab56795baf6 Binary release checksums: apache-maven-3.8.2-bin.zip sha512: 59ad2cbd6b7abde34ebedda94ce5631256373718e71b55202035bd1190d0144f071433f78b99e16f1204413b3eb888659e5039009e1ad0106f16332e3c62bced apache-maven-3.8.2-bin.tar.gz sha512: b0bf39460348b2d8eae1c861ced6c3e8a077b6e761fb3d4669be5de09490521a74db294cf031b0775b2dfcd57bd82246e42ce10904063ef8e3806222e686f222 Draft for release notes: https://github.com/apache/maven-site/pull/251 Guide to testing staged releases: http://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
Commandline inheritance
During a discussion with Michael we noticed there's something odd about the names of some flags and the order of inheritance. I've tried to explain it on a separate wiki page[1] together with the first 3 options how we could fix it. Please have a look at it and share your thoughts. thanks, Robert [1] https://cwiki.apache.org/confluence/display/MAVEN/Commandline+inheritance
Re: [Maven 4] Collapsing mvnDebug into mvn
Thinks to keep in mind when trying to log for a specific execution of a plugin:
- loggers use the classname as identifier, so you need to know when to the
execution starts and ends.
- plugins can call Maven Core code, most likely you want this to be logged as
part of the plugin execution.
- multithreading... need I say more?
Most of the time you're only interested in logging of the last failed plugin of
the previous build, but it is very very tricky to implement.
Robert
On 2-8-2021 16:06:06, Romain Manni-Bucau wrote:
Le lun. 2 août 2021 à 16:02, Michael Osipov a écrit :
> Am 2021-08-02 um 09:39 schrieb Romain Manni-Bucau:
> > Le dim. 1 août 2021 à 22:37, Michael Osipov a
> écrit :
> >
> >> A prerequisite PR is ready: https://github.com/apache/maven/pull/519
> >
> >
> > Maybe I'm a bit "off" on this one but shouldn't we just enable to
> configure
> > slf4j from the command line with "shortcuts"? ie --info --debug
> > --org.apache.wagon-debug
> >
> > Once you know all go through a logger it does not make much sense to
> have a
> > verbose toggle anymore IMHO and it is not powerful enough to enable what
> > you need (even the JVM uses system properties to filter the logs you
> wants
> > so can be saner to rely on slf4j for us?)
>
> It is a bit problematic. SLF4J does not log so you need to delegate to
> the actual logging implementation. I would prefer --log-level/-L {level}
> or {logger}:{level}. -L can be provided multiple times.
> There are open tickets requesting this, but no one has provided a
> concept how to solve this for all supported logging bindings.
>
Guess only for the built-in binding is sufficient - if you change the
binding you can want to ensure it is integrated anyway since other things
can not work properly like log4j2/logback bindings require some flushing to
work properly for ex so it is not only a switch.
That said, the point is to not make --debug specific. An interesting
question about it do we need quiet then?
Think, if we break anything (+-0 on that), it is where we should go rather
than renaming anything which means breaking end users for no feature for
them (which is always a bad idea IMHO).
>
> M
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
Re: [Maven 4] Collapsing mvnDebug into mvn
CI can have multiple Maven versions. Mistakes will happen: users might add --debug assuming verbose logging. With an Environment Variable the CI server can globally suppress the option to debug. I'm also fine with a NO_DEBUG option, but I'd like to have a global way to suppress the impact. Robert On 31-7-2021 16:08:36, Michael Osipov wrote: Am 2021-07-31 um 11:22 schrieb Robert Scholte: > Right, it is suspend, I misinterpreted the description of server. > > Can we introduce an environment variable for it, so CI servers can set it to > 0? Let me summarize: If --debug is passed everything will work as before: wait forever If --debug --batch-mode is passed the VM will wait for at most 30 s. This value can be modified by a new environment variable. Question: Why would a CI system set this to 0 if it is not going to debug the process? M > Robert > On 30-7-2021 21:46:46, Michael Osipov wrote: > I guess you mean suspend and not server. > Your idea may work, but still is problematic. If the breakpoint is quite > early you will miss in your IDE and then you need to start over. > I think -B and --debug are special cases and I believe that a timeout is > acceptible since the build is halted, but more importantly will continue > *automatically* after it. Just like waiting for a network resource which > might be slow. > > M > > Am 2021-07-30 um 18:31 schrieb Robert Scholte: >> I wonder if this is a realistic issue. In the cases I know with the >> batch-mode the interactive part is skipped and code falls back to defaults. >> If there are issues, they're more much likely to happen in the interactive >> mode. >> Maybe a more reasonable solution is to use server="n" (default) for batch >> mode, server="y" for interactive mode: no delay in batchmode and still the >> option to attach a remote debugger. >> >> thanks, >> Robert >> >> >> On 30-7-2021 16:56:15, Michael Osipov wrote: >> Am 2021-07-30 um 14:31 schrieb Stephen Connolly: >>> So now I cannot debug Maven issues that happen when running in batch mode? >>> We should document that specific case uses MAVEN_OPTS >> >> Not now, nothing has been committed/merged yet. This is just a PoC. >> Robert and me thought about this. We could add an environment var which >> circumvents the batch mode if you really want to debug in batch mode. An >> alternative would be if you running in batch mode runjdwp would receive >> a timeout value in milliseconds to wait for a debugger to attach. Say 30 >> 000 ms and then the process will continue. In interactive mode, the JVM >> will wait forever. >> See here: >> https://docs.oracle.com/javase/8/docs/technotes/guides/jpda/conninv.html#Invocation >> >> WDYT? >> >>> On Tue 27 Jul 2021 at 16:01, Michael Osipov wrote: >>> >>>> So you say that -B will implicitly disable --debug without any further >>>> notice? >>>> >>>> I logically agree that batch contradicts debug which requires >>>> interaction with the suspended VM. Both does not make sense. >>>> >>>> Note: Colors are easier now. They now work just like people are used >>>> with grep --color... >>>> >>>> Am 2021-07-27 um 16:27 schrieb Robert Scholte: >>>>> batch mode means no interaction, but the debug-flag is an interaction >>>> (java process is waiting for input). >>>>> So it doesn't make sense to have both activated. >>>>> This will prevent CI jobs to hang when using --debug (if they assume >>>> this means logging at debug level) >>>>> batch implies disabling colours, but if you *only* want to disable >>>> colors, you should use -Dstyle.color=never >>>>> >>>>> Robert >>>>> On 27-7-2021 13:56:45, Michael Osipov wrote: >>>>> OK, let me sum up what you are proposing: >>>>> >>>>> Am 2021-07-27 um 12:39 schrieb Robert Scholte: >>>>>> I actually like the idea of renaming --debug/-X to --verbose/-X and >>>> we're actually lucky. >>>>>> When renaming we can add a message that --debug for logging at debug >>>> level has been renamed to --verbose. >>>>> >>>>> A preceding commit will rename --debug to verbose. This PR will reuse >>>>> --debug instead of -dj/--debug-java. I assume that most do -X and not >>>>> --debug, but that's a wild guess. >>>>> >>>>>> Due to the nature of debugging (waiting until remote debugger is >>>> attached) the message will be visib
Re: [Maven 4] Collapsing mvnDebug into mvn
Right, it is suspend, I misinterpreted the description of server. Can we introduce an environment variable for it, so CI servers can set it to 0? Robert On 30-7-2021 21:46:46, Michael Osipov wrote: I guess you mean suspend and not server. Your idea may work, but still is problematic. If the breakpoint is quite early you will miss in your IDE and then you need to start over. I think -B and --debug are special cases and I believe that a timeout is acceptible since the build is halted, but more importantly will continue *automatically* after it. Just like waiting for a network resource which might be slow. M Am 2021-07-30 um 18:31 schrieb Robert Scholte: > I wonder if this is a realistic issue. In the cases I know with the > batch-mode the interactive part is skipped and code falls back to defaults. > If there are issues, they're more much likely to happen in the interactive > mode. > Maybe a more reasonable solution is to use server="n" (default) for batch > mode, server="y" for interactive mode: no delay in batchmode and still the > option to attach a remote debugger. > > thanks, > Robert > > > On 30-7-2021 16:56:15, Michael Osipov wrote: > Am 2021-07-30 um 14:31 schrieb Stephen Connolly: >> So now I cannot debug Maven issues that happen when running in batch mode? >> We should document that specific case uses MAVEN_OPTS > > Not now, nothing has been committed/merged yet. This is just a PoC. > Robert and me thought about this. We could add an environment var which > circumvents the batch mode if you really want to debug in batch mode. An > alternative would be if you running in batch mode runjdwp would receive > a timeout value in milliseconds to wait for a debugger to attach. Say 30 > 000 ms and then the process will continue. In interactive mode, the JVM > will wait forever. > See here: > https://docs.oracle.com/javase/8/docs/technotes/guides/jpda/conninv.html#Invocation > > WDYT? > >> On Tue 27 Jul 2021 at 16:01, Michael Osipov wrote: >> >>> So you say that -B will implicitly disable --debug without any further >>> notice? >>> >>> I logically agree that batch contradicts debug which requires >>> interaction with the suspended VM. Both does not make sense. >>> >>> Note: Colors are easier now. They now work just like people are used >>> with grep --color... >>> >>> Am 2021-07-27 um 16:27 schrieb Robert Scholte: >>>> batch mode means no interaction, but the debug-flag is an interaction >>> (java process is waiting for input). >>>> So it doesn't make sense to have both activated. >>>> This will prevent CI jobs to hang when using --debug (if they assume >>> this means logging at debug level) >>>> batch implies disabling colours, but if you *only* want to disable >>> colors, you should use -Dstyle.color=never >>>> >>>> Robert >>>> On 27-7-2021 13:56:45, Michael Osipov wrote: >>>> OK, let me sum up what you are proposing: >>>> >>>> Am 2021-07-27 um 12:39 schrieb Robert Scholte: >>>>> I actually like the idea of renaming --debug/-X to --verbose/-X and >>> we're actually lucky. >>>>> When renaming we can add a message that --debug for logging at debug >>> level has been renamed to --verbose. >>>> >>>> A preceding commit will rename --debug to verbose. This PR will reuse >>>> --debug instead of -dj/--debug-java. I assume that most do -X and not >>>> --debug, but that's a wild guess. >>>> >>>>> Due to the nature of debugging (waiting until remote debugger is >>> attached) the message will be visible so users can easily kill the running >>> process and restart Maven with the new command. >>>>> In case of batch-mode as done by CI servers I think we can ignore the >>> --debug-flag, so if they were using the --debug flag, they'll just get less >>> logging. >>>> >>>> Here you expect that -B and --debug (new) are mutually exclusive? I >>>> don't know how likely it is, but maybe someone whats to debug w/o >>>> colors, send to file or omit the progress. >>>> Is that what you have in mind? >>>> >>>> M >>>> >>>>> On 26-7-2021 21:00:26, Michael Osipov wrote: >>>>> Hi folks, >>>>> >>>>> I was recently working on MNG-7075 and while the solution is straight >>>>> forward [1], it just feels awkward. For a long time I had the idea that >>>>> the mvnDebug script can be completely collapsed into mvn with a single &
Re: [Maven 4] Collapsing mvnDebug into mvn
The discussion is about using --debug -B (combination of these 2 flags). With Maven 3 this meant batch-mode + debug level logging. The proposal for Maven 4 is to change debug level logging to --verbose/-X and redefine --debug for debugging instead of mvnDebug. So if you're only using -B there's no issue. And if you are using --debug -B you can switch to -X -B which will behave the same for Maven 3 and 4. Robert On 30-7-2021 22:59:09, Clemens Quoss wrote: Hello! I may not understand much of this discussion going on here. But we use the -B option for having the default behaviour of maven-release in literally thousands of our Jenkins build jobs. Even only having to wait on a debug timeout would not be acceptable and would force us to remove this in a customized version of maven- release. Regards Clemens Am 30. Juli 2021 21:46:37 MESZ schrieb Michael Osipov : >I guess you mean suspend and not server. >Your idea may work, but still is problematic. If the breakpoint is quite >early you will miss in your IDE and then you need to start over. >I think -B and --debug are special cases and I believe that a timeout is >acceptible since the build is halted, but more importantly will continue >*automatically* after it. Just like waiting for a network resource which >might be slow. > >M > >Am 2021-07-30 um 18:31 schrieb Robert Scholte: >> I wonder if this is a realistic issue. In the cases I know with the >> batch-mode the interactive part is skipped and code falls back to defaults. >> If there are issues, they're more much likely to happen in the interactive >> mode. >> Maybe a more reasonable solution is to use server="n" (default) for batch >> mode, server="y" for interactive mode: no delay in batchmode and still the >> option to attach a remote debugger. >> >> thanks, >> Robert >> >> >> On 30-7-2021 16:56:15, Michael Osipov wrote: >> Am 2021-07-30 um 14:31 schrieb Stephen Connolly: >>> So now I cannot debug Maven issues that happen when running in batch mode? >>> We should document that specific case uses MAVEN_OPTS >> >> Not now, nothing has been committed/merged yet. This is just a PoC. >> Robert and me thought about this. We could add an environment var which >> circumvents the batch mode if you really want to debug in batch mode. An >> alternative would be if you running in batch mode runjdwp would receive >> a timeout value in milliseconds to wait for a debugger to attach. Say 30 >> 000 ms and then the process will continue. In interactive mode, the JVM >> will wait forever. >> See here: >> https://docs.oracle.com/javase/8/docs/technotes/guides/jpda/conninv.html#Invocation >> >> WDYT? >> >>> On Tue 27 Jul 2021 at 16:01, Michael Osipov wrote: >>> >>>> So you say that -B will implicitly disable --debug without any further >>>> notice? >>>> >>>> I logically agree that batch contradicts debug which requires >>>> interaction with the suspended VM. Both does not make sense. >>>> >>>> Note: Colors are easier now. They now work just like people are used >>>> with grep --color... >>>> >>>> Am 2021-07-27 um 16:27 schrieb Robert Scholte: >>>>> batch mode means no interaction, but the debug-flag is an interaction >>>> (java process is waiting for input). >>>>> So it doesn't make sense to have both activated. >>>>> This will prevent CI jobs to hang when using --debug (if they assume >>>> this means logging at debug level) >>>>> batch implies disabling colours, but if you *only* want to disable >>>> colors, you should use -Dstyle.color=never >>>>> >>>>> Robert >>>>> On 27-7-2021 13:56:45, Michael Osipov wrote: >>>>> OK, let me sum up what you are proposing: >>>>> >>>>> Am 2021-07-27 um 12:39 schrieb Robert Scholte: >>>>>> I actually like the idea of renaming --debug/-X to --verbose/-X and >>>> we're actually lucky. >>>>>> When renaming we can add a message that --debug for logging at debug >>>> level has been renamed to --verbose. >>>>> >>>>> A preceding commit will rename --debug to verbose. This PR will reuse >>>>> --debug instead of -dj/--debug-java. I assume that most do -X and not >>>>> --debug, but that's a wild guess. >>>>> >>>>>> Due to the nature of debugging (waiting until remote debugger is >>>> attached) the message will be visible so users can easily kill the running >>>
Re: [Maven 4] Collapsing mvnDebug into mvn
I wonder if this is a realistic issue. In the cases I know with the batch-mode the interactive part is skipped and code falls back to defaults. If there are issues, they're more much likely to happen in the interactive mode. Maybe a more reasonable solution is to use server="n" (default) for batch mode, server="y" for interactive mode: no delay in batchmode and still the option to attach a remote debugger. thanks, Robert On 30-7-2021 16:56:15, Michael Osipov wrote: Am 2021-07-30 um 14:31 schrieb Stephen Connolly: > So now I cannot debug Maven issues that happen when running in batch mode? > We should document that specific case uses MAVEN_OPTS Not now, nothing has been committed/merged yet. This is just a PoC. Robert and me thought about this. We could add an environment var which circumvents the batch mode if you really want to debug in batch mode. An alternative would be if you running in batch mode runjdwp would receive a timeout value in milliseconds to wait for a debugger to attach. Say 30 000 ms and then the process will continue. In interactive mode, the JVM will wait forever. See here: https://docs.oracle.com/javase/8/docs/technotes/guides/jpda/conninv.html#Invocation WDYT? > On Tue 27 Jul 2021 at 16:01, Michael Osipov wrote: > >> So you say that -B will implicitly disable --debug without any further >> notice? >> >> I logically agree that batch contradicts debug which requires >> interaction with the suspended VM. Both does not make sense. >> >> Note: Colors are easier now. They now work just like people are used >> with grep --color... >> >> Am 2021-07-27 um 16:27 schrieb Robert Scholte: >>> batch mode means no interaction, but the debug-flag is an interaction >> (java process is waiting for input). >>> So it doesn't make sense to have both activated. >>> This will prevent CI jobs to hang when using --debug (if they assume >> this means logging at debug level) >>> batch implies disabling colours, but if you *only* want to disable >> colors, you should use -Dstyle.color=never >>> >>> Robert >>> On 27-7-2021 13:56:45, Michael Osipov wrote: >>> OK, let me sum up what you are proposing: >>> >>> Am 2021-07-27 um 12:39 schrieb Robert Scholte: >>>> I actually like the idea of renaming --debug/-X to --verbose/-X and >> we're actually lucky. >>>> When renaming we can add a message that --debug for logging at debug >> level has been renamed to --verbose. >>> >>> A preceding commit will rename --debug to verbose. This PR will reuse >>> --debug instead of -dj/--debug-java. I assume that most do -X and not >>> --debug, but that's a wild guess. >>> >>>> Due to the nature of debugging (waiting until remote debugger is >> attached) the message will be visible so users can easily kill the running >> process and restart Maven with the new command. >>>> In case of batch-mode as done by CI servers I think we can ignore the >> --debug-flag, so if they were using the --debug flag, they'll just get less >> logging. >>> >>> Here you expect that -B and --debug (new) are mutually exclusive? I >>> don't know how likely it is, but maybe someone whats to debug w/o >>> colors, send to file or omit the progress. >>> Is that what you have in mind? >>> >>> M >>> >>>> On 26-7-2021 21:00:26, Michael Osipov wrote: >>>> Hi folks, >>>> >>>> I was recently working on MNG-7075 and while the solution is straight >>>> forward [1], it just feels awkward. For a long time I had the idea that >>>> the mvnDebug script can be completely collapsed into mvn with a single >>>> switch. >>>> Therefore, I have created a draft PR [2] which works in the Windows >>>> command prompt and the Bourne shell. It completely obsoletes MNG-7075, >>>> mvnDebug and a nice bonus: When mvnDebug is run, output still refers to >>>> 'mvn', e.g., 'mvn -r ' this is inconsistent until now, but will be >>>> consistent in the future. mvnDebug would remain as-is, but would emit a >>>> warning that it is deprecated. >>>> mvnDebug is used ony by Maven developers like us and of course >>>> extension/plugin devs. The majory are just users which don't care. >>>> >>>> Note: I am not happy with -dj, but wasn't able to come up with something >>>> better for the moment. I would prefer --debug to be renamed to --verbose >>>> and --debug to be recycled as Java debug mode, but that is likely >>>> impossible, I guess. >>>> >>&g
[ANN] Apache Maven Enforcer Plugin + Extension 3.0.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven
Enforcer Plugin and Extension, version 3.0.0
The Enforcer plugin is the Loving Iron Fist of Maven and provides goals to
control certain environmental constraints such as Maven version, JDK version
and OS family along with many more built-in rules and user created rules.
https://maven.apache.org/enforcer/maven-enforcer-plugin/
You should specify the version in your project's plugin configuration:
org.apache.maven.plugins
maven-enforcer-plugin
3.0.0
You can download the appropriate sources etc. from the download page:
https://maven.apache.org/enforcer/download.html
Release Notes - Maven Enforcer Plugin - Version 3.0.0
** Bug
* [MENFORCER-168] - In a multi module project "bannedDependencies" rule
tries to resolve project artifacts from external repository
* [MENFORCER-185] - Require Release Dependencies ignorant about aggregator
build
* [MENFORCER-301] - banDuplicatePomDependencyVersions does not check
managementDependencies
* [MENFORCER-336] - Beanshell rule is not thread-safe
* [MENFORCER-346] - RequireSnapshotVersion not compatible with CI Friendly
Versions (${revision})
* [MENFORCER-351] - NPE when using new syntax with
maven-enforcer-plugin
* [MENFORCER-352] - Broken links on Maven Enforcer Plugin site
* [MENFORCER-357] - RequirePluginVersions not recognizing
versions-from-properties
* [MENFORCER-359] - [REGRESSION] RequirePluginVersions fails when versions
are inherited
* [MENFORCER-364] - requireFilesExist rule should be case sensitive
* [MENFORCER-366] - Broken Links on Project Home Page
* [MENFORCER-373] - TestRequireOS uses hamcrest via transitive dependency
* [MENFORCER-374] - plexus-container-default in enforcer-api is very
outdated
* [MENFORCER-381] - classifier not included in output of failed
RequireUpperBoundDeps test
** New Feature
* [MENFORCER-358] - requireUpperBounds deps should have includes
* [MENFORCER-361] - Introduce RequireTextFileChecksum with line separator
normalization
** Improvement
* [MENFORCER-211] - wildcard ignore in requireReleaseDeps
* [MENFORCER-245] - Improve documentation about writing own Enforcer Rule
* [MENFORCER-257] - RequireActiveProfile should respect inherited activated
profiles
* [MENFORCER-277] - Upgrade maven-dependency-tree to 3.x
* [MENFORCER-304] - Improve dependency resolving in multiple modules project
* [MENFORCER-313] - requireUpperBoundDeps: add [] and colors to the
output
* [MENFORCER-329] - Example for writing a custom rule should be upgraded
* [MENFORCER-338] - Along with JavaVersion, allow enforcement of the
JavaVendor
* [MENFORCER-349] - Include Java vendor in display-info output
* [MENFORCER-350] - requireMavenVersion x.y.z is processed as (,x.y.z]
instead of [x.y.z,)
* [MENFORCER-353] - Consistently format artifacts same as dependency:tree
* [MENFORCER-355] - make build Reproducible
* [MENFORCER-376] - Add support for excludes/includes in requireJavaVendor
rule
* [MENFORCER-384] - Introduce Maven Enforcer Extension
* [MENFORCER-388] - Extends RequirePluginVersions with banMavenDefaults
** Task
* [MENFORCER-377] - Remove reference to travis or switch to travis.com
* [MENFORCER-380] - Fix maven assembly links
* [MENFORCER-387] - Require Java 8
** Dependency upgrade
* [MENFORCER-267] - Upgrade to make Maven 3.1+
* [MENFORCER-371] - Require Maven 3.1.1
* [MENFORCER-379] - Update maven-common-artifact-filters to 3.2.0
Note: Thanks to all the individual contributors and OpenValue: they've provided
several PR during an Open Source Contribution Training Day.
Enjoy,
-The Apache Maven team
[RESULT] [VOTE] Release Apache Maven Enforcer Plugin / Extension version 3.0.0
Hi, The vote has passed with the following result: +1 : Hervé BOUTEMY, Michael Osipov, Robert Scholte, Arnaud Héritier PMC quorum: reached I will promote the artifacts to the central repo. On 26-7-2021 23:17:57, Robert Scholte wrote: Hi, We solved 37 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317520=12346527=Text There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317520%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1656 https://repository.apache.org/content/repositories/maven-1656/org/apache/maven/enforcer/enforcer/3.0.0/enforcer-3.0.0-source-release.zip Source release checksum(s): enforcer-3.0.0-source-release.zip sha512: 2916475006ee76223de1d2fc58129b42864275edcfcf14945bef7699fa29fb26e23f35532d54a83413f3ab1bfb84a05885418ce5aa3d6b25dad29299c5957523 Staging site: https://maven.apache.org/enforcer-archives/enforcer-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: [VOTE] Release Apache Maven Enforcer Plugin / Extension version 3.0.0
+1 On 26-7-2021 23:17:57, Robert Scholte wrote: Hi, We solved 37 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317520=12346527=Text There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317520%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1656 https://repository.apache.org/content/repositories/maven-1656/org/apache/maven/enforcer/enforcer/3.0.0/enforcer-3.0.0-source-release.zip Source release checksum(s): enforcer-3.0.0-source-release.zip sha512: 2916475006ee76223de1d2fc58129b42864275edcfcf14945bef7699fa29fb26e23f35532d54a83413f3ab1bfb84a05885418ce5aa3d6b25dad29299c5957523 Staging site: https://maven.apache.org/enforcer-archives/enforcer-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 4] Collapsing mvnDebug into mvn
batch mode means no interaction, but the debug-flag is an interaction (java process is waiting for input). So it doesn't make sense to have both activated. This will prevent CI jobs to hang when using --debug (if they assume this means logging at debug level) batch implies disabling colours, but if you *only* want to disable colors, you should use -Dstyle.color=never Robert On 27-7-2021 13:56:45, Michael Osipov wrote: OK, let me sum up what you are proposing: Am 2021-07-27 um 12:39 schrieb Robert Scholte: > I actually like the idea of renaming --debug/-X to --verbose/-X and we're > actually lucky. > When renaming we can add a message that --debug for logging at debug level > has been renamed to --verbose. A preceding commit will rename --debug to verbose. This PR will reuse --debug instead of -dj/--debug-java. I assume that most do -X and not --debug, but that's a wild guess. > Due to the nature of debugging (waiting until remote debugger is attached) > the message will be visible so users can easily kill the running process and > restart Maven with the new command. > In case of batch-mode as done by CI servers I think we can ignore the > --debug-flag, so if they were using the --debug flag, they'll just get less > logging. Here you expect that -B and --debug (new) are mutually exclusive? I don't know how likely it is, but maybe someone whats to debug w/o colors, send to file or omit the progress. Is that what you have in mind? M > On 26-7-2021 21:00:26, Michael Osipov wrote: > Hi folks, > > I was recently working on MNG-7075 and while the solution is straight > forward [1], it just feels awkward. For a long time I had the idea that > the mvnDebug script can be completely collapsed into mvn with a single > switch. > Therefore, I have created a draft PR [2] which works in the Windows > command prompt and the Bourne shell. It completely obsoletes MNG-7075, > mvnDebug and a nice bonus: When mvnDebug is run, output still refers to > 'mvn', e.g., 'mvn -r ' this is inconsistent until now, but will be > consistent in the future. mvnDebug would remain as-is, but would emit a > warning that it is deprecated. > mvnDebug is used ony by Maven developers like us and of course > extension/plugin devs. The majory are just users which don't care. > > Note: I am not happy with -dj, but wasn't able to come up with something > better for the moment. I would prefer --debug to be renamed to --verbose > and --debug to be recycled as Java debug mode, but that is likely > impossible, I guess. > > WDYT? > > Michael > > [1] https://github.com/apache/maven/pull/515 > [2] https://github.com/apache/maven/pull/517 > > - > 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: [Maven 4] Collapsing mvnDebug into mvn
I actually like the idea of renaming --debug/-X to --verbose/-X and we're actually lucky. When renaming we can add a message that --debug for logging at debug level has been renamed to --verbose. Due to the nature of debugging (waiting until remote debugger is attached) the message will be visible so users can easily kill the running process and restart Maven with the new command. In case of batch-mode as done by CI servers I think we can ignore the --debug-flag, so if they were using the --debug flag, they'll just get less logging. Robert On 26-7-2021 21:00:26, Michael Osipov wrote: Hi folks, I was recently working on MNG-7075 and while the solution is straight forward [1], it just feels awkward. For a long time I had the idea that the mvnDebug script can be completely collapsed into mvn with a single switch. Therefore, I have created a draft PR [2] which works in the Windows command prompt and the Bourne shell. It completely obsoletes MNG-7075, mvnDebug and a nice bonus: When mvnDebug is run, output still refers to 'mvn', e.g., 'mvn -r ' this is inconsistent until now, but will be consistent in the future. mvnDebug would remain as-is, but would emit a warning that it is deprecated. mvnDebug is used ony by Maven developers like us and of course extension/plugin devs. The majory are just users which don't care. Note: I am not happy with -dj, but wasn't able to come up with something better for the moment. I would prefer --debug to be renamed to --verbose and --debug to be recycled as Java debug mode, but that is likely impossible, I guess. WDYT? Michael [1] https://github.com/apache/maven/pull/515 [2] https://github.com/apache/maven/pull/517 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Apache Maven Enforcer Plugin / Extension version 3.0.0
Hi, We solved 37 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317520=12346527=Text There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317520%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1656 https://repository.apache.org/content/repositories/maven-1656/org/apache/maven/enforcer/enforcer/3.0.0/enforcer-3.0.0-source-release.zip Source release checksum(s): enforcer-3.0.0-source-release.zip sha512: 2916475006ee76223de1d2fc58129b42864275edcfcf14945bef7699fa29fb26e23f35532d54a83413f3ab1bfb84a05885418ce5aa3d6b25dad29299c5957523 Staging site: https://maven.apache.org/enforcer-archives/enforcer-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: [External] : Re: JDK 17 is now in Rampdown Phase Two
Hi Dalibor, I think you are right. >"%JAVA_HOME%\bin\javadoc" -J-version java version "11.0.11" 2021-04-20 LTS Java(TM) SE Runtime Environment 18.9 (build 11.0.11+9-LTS-194) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.11+9-LTS-194, mixed mode) >mvn -v Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d) Maven home: d:\apache-maven-3.8.1\bin\.. Java version: 11.0.11, vendor: Oracle Corporation, runtime: D:\jdk-11.0.11 Default locale: nl_NL, platform encoding: Cp1252 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" Is there a better way to get the exact information? thanks, Robert On 19-7-2021 16:20:43, Dalibor Topic wrote: On 16.07.2021 10:55, Robert Scholte wrote: > Hi Rory, > > thanks for the update. > We're having 2 issues related to javadoc, one based on JDK 17-ea+30, the > other one on Oracle OpenJDK 11.0.11 on Windows. Hi Robert, I don't think that we provide an Oracle OpenJDK build of 11.0.11, or at least I can't find it here: https://jdk.java.net/archive/. Did you mean Oracle JDK 11.0.11, by chance? cheers, dalibor topic -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 , Video: dalibor.to...@oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRB 246209 Geschäftsführer: Ralf Herrmann
Re: [External] : Re: JDK 17 is now in Rampdown Phase Two
Hi Rory, I noticed. That means we'll need to adjust our plugin based on the comments from Jonathan. thanks, Robert On 19-7-2021 09:40:16, Rory O'Donnell wrote: Hi Robert, Bug was closed as not an issue, see Jonathan's comments in the bug. Rgsd,Rory On 16/07/2021 12:18, Robert Scholte wrote: > I've created https://bugs.openjdk.java.net/browse/JDK-8270831 for the > JDK 17-ea bug. > > thanks, > Robert >> >> On 16-7-2021 12:51:28, Rory O'Donnell wrote: >> >> Hi Robert, >> >> Can you highlight the priority of the issues for you , would need to be >> P1 or P2 to get fixed in >> >> Rampdown Phase Two. >> >> Rgds,Rory >> >> On 16/07/2021 11:46, Rory O'Donnell wrote: >> > Hi Robert, >> > >> > Can you log a couple of bugs, refer to the closed bugs and send the >> IDs ? >> > >> > Thanks,Rory >> > >> > On 16/07/2021 09:55, Robert Scholte wrote: >> >> Hi Rory, >> >> >> >> thanks for the update. >> >> We're having 2 issues related to javadoc, one based on JDK 17-ea+30, >> >> the other one on Oracle OpenJDK 11.0.11 on Windows. >> >> >> >> The issue with JDK 17 has to do with stdout and errout. >> >> The maven-javadoc-plugin has a flag to fail on warning, which means: >> >> if something is written to the stderr it'll fail the build. >> >> There has been a change that normal output is pushed to the stderr >> >> instead of stdout. >> >> Here's an example to show what has been written to the stderr, which >> >> should have been stdout: >> >> [WARNING] Javadoc Warnings >> >> [WARNING] Loading source file >> >> >> E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\src\main\java\foo\bar\MyClass.java... >> >> [WARNING] Constructing Javadoc information... >> >> [WARNING] Building index for all the packages and classes... >> >> [WARNING] Standard Doclet version 17-ea+30-2618 >> >> [WARNING] Building tree for all the packages and classes... >> >> [WARNING] Generating >> >> >> E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\foo\bar\MyClass.html... >> >> [WARNING] Generating >> >> >> E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\foo\bar\package-summary.html... >> >> [WARNING] Generating >> >> >> E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\foo\bar\package-tree.html... >> >> [WARNING] Generating >> >> >> E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\foo\bar\class-use\MyClass.html... >> >> [WARNING] Generating >> >> >> E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\foo\bar\package-use.html... >> >> [WARNING] Generating >> >> >> E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\overview-tree.html... >> >> [WARNING] Building index for all classes... >> >> [WARNING] Generating >> >> >> E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\allclasses-index.html... >> >> [WARNING] Generating >> >> >> E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\allpackages-index.html... >> >> [WARNING] Generating >> >> >> E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\index-all.html... >> >> [WARNING] Generating >> >> >> E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\index.html... >> >> [WARNING] Generating >> >> >> E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\help-doc.html... >> >> >> >> The first line (Javadoc Warnings) comes from the plugin, the rest of >> >> the lines are captured from the stderr (!). >> >> Most likely related to >> https://bugs.openjdk.java.net/browse/JDK-8268774 >> >> >> >> The other one is weird: >> >> https://bugs.openjdk.java.net/browse/JDK-8220702 h
Re: [JENKINS] - New Maven Controller for the project
This was indeed the issue.
Gavin has configured the plugin and now builds start to turn blue/green again.
I'll try to get trigger all master and get these back to blue[1]
If you see any issues, please reply to this mail.
Robert
[1]
https://ci-maven.apache.org/job/Maven/job/dist-tool-plugin/job/master/site/dist-tool-master-jobs.html
On 16-7-2021 13:38:53, Robert Scholte wrote:
Could this be the issue?
[Jira] No Jira site is configured for this project. This must be a project
configuration error
@Gavin, could you configure this like it was done with ci-builds? Especially
the credentials seem to be an issue for me.
thanks,
Robert
On 16-7-2021 12:49:30, Robert Scholte wrote:
Gavin,
I've been able to install the required plugin.
I think we should be able to fix the rest ourselves.
@Arnaud and others
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-acr-plugin/job/master/
All stages succeed, but in the end the build is marked as failure.
I can't see the cause, so I could use extra help.
thanks,
Robert
On 16-7-2021 11:22:12, Gavin McDonald wrote:
All PMC Members should see an 'Administer' button down the leftside nav
On Fri, Jul 16, 2021 at 10:38 AM Robert Scholte
wrote:
> This would indeed be a good one for Arnaud.
> I don't recognize an option related to this.
> What do you expect me to see, or can you share a link to see if I have
> access?
>
> thanks,
> Robert
>
> On 16-7-2021 10:25:04, Gavin McDonald wrote:
> Hi
>
> I think I have it configured correctly that PMC can manage the controller,
> can someone test by
> trying to install this plugin and let me know?
>
> TIA
>
> On Fri, Jul 16, 2021 at 10:07 AM Arnaud Héritier
> wrote:
>
> > This one:
> > https://plugins.jenkins.io/ws-cleanup/
> >
> > Do we (at least PMCs) have admin privileges on the controller? In such
> > case you can just add it from the plugins management admin panel.
> >
> > You just search the missing keyword on jenkins.io to find the plugin
> > implementing the missing command.
> >
> > We should probably document these needs somewhere.
> >
> > Arnaud
> >
> > Le ven. 16 juil. 2021 à 10:02, Robert Scholte a
> > écrit :
> >
> >> Yes, that fixed the build generating pages like
> >>
> >>
> https://ci-maven.apache.org/job/Maven/job/dist-tool-plugin/job/master/site/dist-tool-master-jobs.html
> >>
> >>
> >> Most masters are broken, most likely all due to this error:"
> >> No such DSL method 'cleanWs'
> >>
> >>
> >> Looks like another plugin is missing.
> >>
> >> Robert
> >> On 16-7-2021 09:52:15, Gavin McDonald wrote:
> >> Thanks Robert,
> >>
> >> I believe those are a result of missing plugins Ansicolor and
> Timestamper.
> >>
> >> Both now installed
> >>
> >> HTH
> >>
> >> On Fri, Jul 16, 2021 at 9:31 AM Robert Scholte wrote:
> >>
> >> > Okay, that makes sense.
> >> > Jobs have been picked up, just required quite some hours to run
> >> everything.
> >> >
> >> > this morning I noticed some failed with the following message:
> >> >
> >> > org.codehaus.groovy.control.MultipleCompilationErrorsException:
> startup
> >> failed:
> >> > WorkflowScript: 54: Invalid option type "timestamps". Valid option
> >> types: [authorizationMatrix, buildDiscarder, catchError,
> >> checkoutToSubdirectory, datadog, disableConcurrentBuilds,
> disableResume,
> >> durabilityHint, newContainerPerStage, overrideIndexTriggers,
> >> parallelsAlwaysFailFast, preserveStashes, quietPeriod, rateLimitBuilds,
> >> retry, script, skipDefaultCheckout, skipStagesAfterUnstable, throttle,
> >> throttleJobProperty, timeout, waitUntil, warnError, withChecks,
> >> withContext, withCredentials, withEnv, wrap, ws] @ line 54, column 9.
> >> > timestamps()
> >> > ^
> >> >
> >> > WorkflowScript: 56: Invalid option type "ansiColor". Valid option
> >> types: [authorizationMatrix, buildDiscarder, catchError,
> >> checkoutToSubdirectory, datadog, disableConcurrentBuilds,
> disableResume,
> >> durabilityHint, newContainerPerStage, overrideIndexTriggers,
> >> parallelsAlwaysFailFast, preserveStashes, quietPeriod, rateLimitBuilds,
> >> retry, script, skipDefaultCheckout, skipStagesAfterUnstable, throttle,
> >> throttleJobProperty, timeout, waitUntil, warnError, withChecks,
> >> withContext, withCredentials, withEnv, wrap, ws] @ line 56, column 9.
> >> > ansiColor('xterm')
> >> &g
Re: Specify toolchains.xml location in pom.xml ?
Hi Lee, next time could you use the maven users list for these kind of questions? The dev-list is meant for Maven committer discussions. To answer your question: no, that is not possible. Toolchain is defined at Maven level, so any maven-plugin or maven-extension can use it. This implies that it is not possible to define the location at plugin level such as the maven-toolchains-plugin. thanks, Robert On 17-7-2021 02:58:00, leerho wrote: On page http://maven.apache.org/guides/mini/guide-using-toolchains.html it states: Starting with Maven 3.3.1 > you can put the > toolchains.xml file wherever you like by using the --global-toolchains > file option Or by specifying --toolchains tools/toolchains.xml for every mvn command. Is it possible to configure the maven-toolchains-plugin with a directory of where to find the *toolchains.xml*? Lee.
Re: Documentation 404 links
Please create a PR for https://github.com/apache/maven-toolchains-plugin/blob/master/src/site/apt/index.apt.vm thanks, Robert On 17-7-2021 02:44:32, leerho wrote: The docs page for the maven-toolchains-plugin has 4 non-working links: user mailing list -> https://maven.apache.org/plugins/maven-toolchains-plugin/mail-lists.html Mail archive -> https://maven.apache.org/plugins/maven-toolchains-plugin/mail-lists.html issue tracker -> https://maven.apache.org/plugins/maven-toolchains-plugin/issue-tracking.html source repository -> https://maven.apache.org/plugins/maven-toolchains-plugin/source-repository.html Please fix :) Lee.
Re: [VOTE] Release Maven Shade Plugin version 3.3.0
+1 On 17-7-2021 09:45:20, Michael Osipov wrote: Am 2021-07-14 um 13:41 schrieb Michael Osipov: > Hi, > > We solved 9 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12348391 > > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHADE%20AND%20resolution%20%3D%20Unresolved > > > Staging repo: > https://repository.apache.org/content/repositories/maven-1655/ > https://repository.apache.org/content/repositories/maven-1655/org/apache/maven/plugins/maven-shade-plugin/3.3.0/maven-shade-plugin-3.3.0-source-release.zip > > > Source release checksum(s): > maven-shade-plugin-3.3.0-source-release.zip > sha512: > eb84e09106febe41388903f7fbc66d7e85888005d78c075f2291a05a19eb22f53c3fd6953ec864d41c44f869dd13706126bac632d5d9511b75bbdc71a63b01ba > > > Staging site: > http://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/ > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. +1 I need more votes to proceed with the release. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [JENKINS] - New Maven Controller for the project
Could this be the issue?
[Jira] No Jira site is configured for this project. This must be a project
configuration error
@Gavin, could you configure this like it was done with ci-builds? Especially
the credentials seem to be an issue for me.
thanks,
Robert
On 16-7-2021 12:49:30, Robert Scholte wrote:
Gavin,
I've been able to install the required plugin.
I think we should be able to fix the rest ourselves.
@Arnaud and others
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-acr-plugin/job/master/
All stages succeed, but in the end the build is marked as failure.
I can't see the cause, so I could use extra help.
thanks,
Robert
On 16-7-2021 11:22:12, Gavin McDonald wrote:
All PMC Members should see an 'Administer' button down the leftside nav
On Fri, Jul 16, 2021 at 10:38 AM Robert Scholte
wrote:
> This would indeed be a good one for Arnaud.
> I don't recognize an option related to this.
> What do you expect me to see, or can you share a link to see if I have
> access?
>
> thanks,
> Robert
>
> On 16-7-2021 10:25:04, Gavin McDonald wrote:
> Hi
>
> I think I have it configured correctly that PMC can manage the controller,
> can someone test by
> trying to install this plugin and let me know?
>
> TIA
>
> On Fri, Jul 16, 2021 at 10:07 AM Arnaud Héritier
> wrote:
>
> > This one:
> > https://plugins.jenkins.io/ws-cleanup/
> >
> > Do we (at least PMCs) have admin privileges on the controller? In such
> > case you can just add it from the plugins management admin panel.
> >
> > You just search the missing keyword on jenkins.io to find the plugin
> > implementing the missing command.
> >
> > We should probably document these needs somewhere.
> >
> > Arnaud
> >
> > Le ven. 16 juil. 2021 à 10:02, Robert Scholte a
> > écrit :
> >
> >> Yes, that fixed the build generating pages like
> >>
> >>
> https://ci-maven.apache.org/job/Maven/job/dist-tool-plugin/job/master/site/dist-tool-master-jobs.html
> >>
> >>
> >> Most masters are broken, most likely all due to this error:"
> >> No such DSL method 'cleanWs'
> >>
> >>
> >> Looks like another plugin is missing.
> >>
> >> Robert
> >> On 16-7-2021 09:52:15, Gavin McDonald wrote:
> >> Thanks Robert,
> >>
> >> I believe those are a result of missing plugins Ansicolor and
> Timestamper.
> >>
> >> Both now installed
> >>
> >> HTH
> >>
> >> On Fri, Jul 16, 2021 at 9:31 AM Robert Scholte wrote:
> >>
> >> > Okay, that makes sense.
> >> > Jobs have been picked up, just required quite some hours to run
> >> everything.
> >> >
> >> > this morning I noticed some failed with the following message:
> >> >
> >> > org.codehaus.groovy.control.MultipleCompilationErrorsException:
> startup
> >> failed:
> >> > WorkflowScript: 54: Invalid option type "timestamps". Valid option
> >> types: [authorizationMatrix, buildDiscarder, catchError,
> >> checkoutToSubdirectory, datadog, disableConcurrentBuilds,
> disableResume,
> >> durabilityHint, newContainerPerStage, overrideIndexTriggers,
> >> parallelsAlwaysFailFast, preserveStashes, quietPeriod, rateLimitBuilds,
> >> retry, script, skipDefaultCheckout, skipStagesAfterUnstable, throttle,
> >> throttleJobProperty, timeout, waitUntil, warnError, withChecks,
> >> withContext, withCredentials, withEnv, wrap, ws] @ line 54, column 9.
> >> > timestamps()
> >> > ^
> >> >
> >> > WorkflowScript: 56: Invalid option type "ansiColor". Valid option
> >> types: [authorizationMatrix, buildDiscarder, catchError,
> >> checkoutToSubdirectory, datadog, disableConcurrentBuilds,
> disableResume,
> >> durabilityHint, newContainerPerStage, overrideIndexTriggers,
> >> parallelsAlwaysFailFast, preserveStashes, quietPeriod, rateLimitBuilds,
> >> retry, script, skipDefaultCheckout, skipStagesAfterUnstable, throttle,
> >> throttleJobProperty, timeout, waitUntil, warnError, withChecks,
> >> withContext, withCredentials, withEnv, wrap, ws] @ line 56, column 9.
> >> > ansiColor('xterm')
> >> > ^
> >> >
> >> > 2 errors
> >> >
> >> > at
> >>
> org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
>
> >> > at
> >>
> org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1085)
>
> >> >
Re: [External] : Re: JDK 17 is now in Rampdown Phase Two
I've created https://bugs.openjdk.java.net/browse/JDK-8270831 for the JDK 17-ea bug. thanks, Robert On 16-7-2021 12:51:28, Rory O'Donnell wrote: Hi Robert, Can you highlight the priority of the issues for you , would need to be P1 or P2 to get fixed in Rampdown Phase Two. Rgds,Rory On 16/07/2021 11:46, Rory O'Donnell wrote: > Hi Robert, > > Can you log a couple of bugs, refer to the closed bugs and send the IDs ? > > Thanks,Rory > > On 16/07/2021 09:55, Robert Scholte wrote: >> Hi Rory, >> >> thanks for the update. >> We're having 2 issues related to javadoc, one based on JDK 17-ea+30, >> the other one on Oracle OpenJDK 11.0.11 on Windows. >> >> The issue with JDK 17 has to do with stdout and errout. >> The maven-javadoc-plugin has a flag to fail on warning, which means: >> if something is written to the stderr it'll fail the build. >> There has been a change that normal output is pushed to the stderr >> instead of stdout. >> Here's an example to show what has been written to the stderr, which >> should have been stdout: >> [WARNING] Javadoc Warnings >> [WARNING] Loading source file >> E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\src\main\java\foo\bar\MyClass.java... >> [WARNING] Constructing Javadoc information... >> [WARNING] Building index for all the packages and classes... >> [WARNING] Standard Doclet version 17-ea+30-2618 >> [WARNING] Building tree for all the packages and classes... >> [WARNING] Generating >> E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\foo\bar\MyClass.html... >> [WARNING] Generating >> E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\foo\bar\package-summary.html... >> [WARNING] Generating >> E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\foo\bar\package-tree.html... >> [WARNING] Generating >> E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\foo\bar\class-use\MyClass.html... >> [WARNING] Generating >> E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\foo\bar\package-use.html... >> [WARNING] Generating >> E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\overview-tree.html... >> [WARNING] Building index for all classes... >> [WARNING] Generating >> E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\allclasses-index.html... >> [WARNING] Generating >> E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\allpackages-index.html... >> [WARNING] Generating >> E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\index-all.html... >> [WARNING] Generating >> E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\index.html... >> [WARNING] Generating >> E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\help-doc.html... >> >> The first line (Javadoc Warnings) comes from the plugin, the rest of >> the lines are captured from the stderr (!). >> Most likely related to https://bugs.openjdk.java.net/browse/JDK-8268774 >> >> The other one is weird: >> https://bugs.openjdk.java.net/browse/JDK-8220702 has been marked as >> fixed for JDK-13. >> However, our matching integrationtest with Oracle OpenJDK 11.0.11 >> succeeds on Linux, but fails on Windows. >> The issue has to do with the Java Platform Modular System, so it >> shouldn't be OS related. >> I thought this one would be backported from 13 to 11, but I can't >> find that reference anymore. >> If it is not yet backported, then IMHO it should. However, the Linux >> distribution doesn't suffer this issue. >> >> So far I hadn't had a response from Jonathan or anyone else working >> on the javadoc tool. >> Maybe you can help us here. >> >> thanks, >> Robert >>> >>> On 15-7-2021 22:07:07, Rory O'Donnell wrote: >>> >>> >>> Hi Robert , * >>> * >>> >>> *Per the JDK 17 schedule , we are in Rampdown Phase Two [1].* >>> >>> *Please advise if you find any issues while testing the latest Early >>> Access builds.* >>> >>> * Sched
Re: JDK 17 is now in Rampdown Phase Two
Hi Rory, thanks for the update. We're having 2 issues related to javadoc, one based on JDK 17-ea+30, the other one on Oracle OpenJDK 11.0.11 on Windows. The issue with JDK 17 has to do with stdout and errout. The maven-javadoc-plugin has a flag to fail on warning, which means: if something is written to the stderr it'll fail the build. There has been a change that normal output is pushed to the stderr instead of stdout. Here's an example to show what has been written to the stderr, which should have been stdout: [WARNING] Javadoc Warnings [WARNING] Loading source file E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\src\main\java\foo\bar\MyClass.java... [WARNING] Constructing Javadoc information... [WARNING] Building index for all the packages and classes... [WARNING] Standard Doclet version 17-ea+30-2618 [WARNING] Building tree for all the packages and classes... [WARNING] Generating E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\foo\bar\MyClass.html... [WARNING] Generating E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\foo\bar\package-summary.html... [WARNING] Generating E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\foo\bar\package-tree.html... [WARNING] Generating E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\foo\bar\class-use\MyClass.html... [WARNING] Generating E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\foo\bar\package-use.html... [WARNING] Generating E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\overview-tree.html... [WARNING] Building index for all classes... [WARNING] Generating E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\allclasses-index.html... [WARNING] Generating E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\allpackages-index.html... [WARNING] Generating E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\index-all.html... [WARNING] Generating E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\index.html... [WARNING] Generating E:\java-workspace\apache-maven-plugins\plugins\maven-javadoc-plugin\target\it\MJAVADOC-538\target\site\apidocs\help-doc.html... The first line (Javadoc Warnings) comes from the plugin, the rest of the lines are captured from the stderr (!). Most likely related to https://bugs.openjdk.java.net/browse/JDK-8268774 The other one is weird: https://bugs.openjdk.java.net/browse/JDK-8220702 has been marked as fixed for JDK-13. However, our matching integrationtest with Oracle OpenJDK 11.0.11 succeeds on Linux, but fails on Windows. The issue has to do with the Java Platform Modular System, so it shouldn't be OS related. I thought this one would be backported from 13 to 11, but I can't find that reference anymore. If it is not yet backported, then IMHO it should. However, the Linux distribution doesn't suffer this issue. So far I hadn't had a response from Jonathan or anyone else working on the javadoc tool. Maybe you can help us here. thanks, Robert On 15-7-2021 22:07:07, Rory O'Donnell wrote: Hi Robert , * * *Per the JDK 17 schedule , we are in Rampdown Phase Two [1].* *Please advise if you find any issues while testing the latest Early Access builds.* * Schedule: o *2021/07/15 Rampdown Phase Two* o 2021/08/05 Initial Release Candidate o 2021/08/19 Final Release Candidate o 2021/09/14 General Availability The overall feature set is frozen. No further JEPs will be targeted to this release. * Features integrated in JDK 17: o JEP 306: Restore Always-Strict Floating-Point Semantics o JEP 356: Enhanced Pseudo-Random Number Generators o JEP 382: New macOS Rendering Pipeline o JEP 391: macOS/AArch64 Port o JEP 398: Deprecate the Applet API for Removal o JEP 403: Strongly Encapsulate JDK Internals o JEP 406: Pattern Matching for switch (Preview) o JEP 407: Remove RMI Activation o JEP 409: Sealed Classes o JEP 410: Remove the Experimental AOT and JIT Compiler o JEP 411: Deprecate the Security Manager for Removal o JEP 412: Foreign Function & Memory API (Incubator) o JEP 414: Vector API (Second Incubator) o JEP 415: Context-Specific Deserialization Filters * * *OpenJDK 17 Early Access build 31 is available at **https://jdk.java.net/17* * These early-access , open-source builds are provided under the o GNU General Public License, version 2, with the Classpath Exception * Release Notes are available at https://jdk.java.net/17/release-notes * * *OpenJDK 18
Re: [JENKINS] - New Maven Controller for the project
This would indeed be a good one for Arnaud.
I don't recognize an option related to this.
What do you expect me to see, or can you share a link to see if I have access?
thanks,
Robert
On 16-7-2021 10:25:04, Gavin McDonald wrote:
Hi
I think I have it configured correctly that PMC can manage the controller,
can someone test by
trying to install this plugin and let me know?
TIA
On Fri, Jul 16, 2021 at 10:07 AM Arnaud Héritier
wrote:
> This one:
> https://plugins.jenkins.io/ws-cleanup/
>
> Do we (at least PMCs) have admin privileges on the controller? In such
> case you can just add it from the plugins management admin panel.
>
> You just search the missing keyword on jenkins.io to find the plugin
> implementing the missing command.
>
> We should probably document these needs somewhere.
>
> Arnaud
>
> Le ven. 16 juil. 2021 à 10:02, Robert Scholte a
> écrit :
>
>> Yes, that fixed the build generating pages like
>>
>> https://ci-maven.apache.org/job/Maven/job/dist-tool-plugin/job/master/site/dist-tool-master-jobs.html
>>
>>
>> Most masters are broken, most likely all due to this error:"
>> No such DSL method 'cleanWs'
>>
>>
>> Looks like another plugin is missing.
>>
>> Robert
>> On 16-7-2021 09:52:15, Gavin McDonald wrote:
>> Thanks Robert,
>>
>> I believe those are a result of missing plugins Ansicolor and Timestamper.
>>
>> Both now installed
>>
>> HTH
>>
>> On Fri, Jul 16, 2021 at 9:31 AM Robert Scholte wrote:
>>
>> > Okay, that makes sense.
>> > Jobs have been picked up, just required quite some hours to run
>> everything.
>> >
>> > this morning I noticed some failed with the following message:
>> >
>> > org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
>> failed:
>> > WorkflowScript: 54: Invalid option type "timestamps". Valid option
>> types: [authorizationMatrix, buildDiscarder, catchError,
>> checkoutToSubdirectory, datadog, disableConcurrentBuilds, disableResume,
>> durabilityHint, newContainerPerStage, overrideIndexTriggers,
>> parallelsAlwaysFailFast, preserveStashes, quietPeriod, rateLimitBuilds,
>> retry, script, skipDefaultCheckout, skipStagesAfterUnstable, throttle,
>> throttleJobProperty, timeout, waitUntil, warnError, withChecks,
>> withContext, withCredentials, withEnv, wrap, ws] @ line 54, column 9.
>> > timestamps()
>> > ^
>> >
>> > WorkflowScript: 56: Invalid option type "ansiColor". Valid option
>> types: [authorizationMatrix, buildDiscarder, catchError,
>> checkoutToSubdirectory, datadog, disableConcurrentBuilds, disableResume,
>> durabilityHint, newContainerPerStage, overrideIndexTriggers,
>> parallelsAlwaysFailFast, preserveStashes, quietPeriod, rateLimitBuilds,
>> retry, script, skipDefaultCheckout, skipStagesAfterUnstable, throttle,
>> throttleJobProperty, timeout, waitUntil, warnError, withChecks,
>> withContext, withCredentials, withEnv, wrap, ws] @ line 56, column 9.
>> > ansiColor('xterm')
>> > ^
>> >
>> > 2 errors
>> >
>> > at
>> org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
>> > at
>> org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1085)
>> > at
>> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603)
>> > at
>> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581)
>> > at
>> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558)
>> > at
>> groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
>> > at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
>> > at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
>> > at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
>> > at
>> org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.doParse(CpsGroovyShell.java:142)
>> > at
>> org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:127)
>> > at
>> org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:571)
>> > at
>> org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:523)
>> > at
>> org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:337)
>> > at hudson.model.ResourceController.execute(ResourceController.java:97)
>> > at hudson.model.Executor.run(Executor.java:429)
>> > Finished: FAILUR
Re: [JENKINS] - New Maven Controller for the project
Yes, that fixed the build generating pages like
https://ci-maven.apache.org/job/Maven/job/dist-tool-plugin/job/master/site/dist-tool-master-jobs.html
Most masters are broken, most likely all due to this error:"
No such DSL method 'cleanWs'
Looks like another plugin is missing.
Robert
On 16-7-2021 09:52:15, Gavin McDonald wrote:
Thanks Robert,
I believe those are a result of missing plugins Ansicolor and Timestamper.
Both now installed
HTH
On Fri, Jul 16, 2021 at 9:31 AM Robert Scholte wrote:
> Okay, that makes sense.
> Jobs have been picked up, just required quite some hours to run everything.
>
> this morning I noticed some failed with the following message:
>
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> WorkflowScript: 54: Invalid option type "timestamps". Valid option types:
> [authorizationMatrix, buildDiscarder, catchError, checkoutToSubdirectory,
> datadog, disableConcurrentBuilds, disableResume, durabilityHint,
> newContainerPerStage, overrideIndexTriggers, parallelsAlwaysFailFast,
> preserveStashes, quietPeriod, rateLimitBuilds, retry, script,
> skipDefaultCheckout, skipStagesAfterUnstable, throttle, throttleJobProperty,
> timeout, waitUntil, warnError, withChecks, withContext, withCredentials,
> withEnv, wrap, ws] @ line 54, column 9.
> timestamps()
> ^
>
> WorkflowScript: 56: Invalid option type "ansiColor". Valid option types:
> [authorizationMatrix, buildDiscarder, catchError, checkoutToSubdirectory,
> datadog, disableConcurrentBuilds, disableResume, durabilityHint,
> newContainerPerStage, overrideIndexTriggers, parallelsAlwaysFailFast,
> preserveStashes, quietPeriod, rateLimitBuilds, retry, script,
> skipDefaultCheckout, skipStagesAfterUnstable, throttle, throttleJobProperty,
> timeout, waitUntil, warnError, withChecks, withContext, withCredentials,
> withEnv, wrap, ws] @ line 56, column 9.
> ansiColor('xterm')
> ^
>
> 2 errors
>
> at
> org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
> at
> org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1085)
> at
> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603)
> at
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558)
> at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
> at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
> at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
> at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
> at
> org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.doParse(CpsGroovyShell.java:142)
> at
> org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:127)
> at
> org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:571)
> at
> org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:523)
> at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:337)
> at hudson.model.ResourceController.execute(ResourceController.java:97)
> at hudson.model.Executor.run(Executor.java:429)
> Finished: FAILURE
>
>
>
> I've looked into our Jenkins scripts and and can't find these options. So
> I assume these are some globally defined scripts that needs to be repaired.
>
> thanks,
> Robert
>
> On 15-7-2021 11:18:34, Gavin McDonald wrote:
> Hi
>
> On Thu, Jul 15, 2021 at 11:08 AM Robert Scholte
> wrote:
>
> > In case you haven't noticed: all Windows nodes are offline.
> >
> >
> Yeah they are 'leased' nodes shared between all ci-* controllers and come
> online
> when in use.
>
>
> Robert
> > On 15-7-2021 10:29:31, Robert Scholte wrote:
> > Our scripts use the labels ubuntu and Windows to distinguish the OS.
> > Is it safe to add ubuntu to the maven nodes?
> >
> > thanks,
> > Robert
> > On 15-7-2021 10:06:37, Gavin McDonald wrote:
> > Thanks All,
> >
> > Jobs have been migrated.
> >
> > Please test and report any issues ASAP to INFRA jira.
> >
> > https://ci-maven.apache.org/
> >
> >
> >
> > On 2021/07/08 21:37:43, Arnaud Héritier wrote:
> > > Hi Gavin
> > >
> > > Let’s go. I cannot test more than the authentication today but I can
> > assist
> > > more later this month after my vacations.
> > >
> > > What is important is to move the shared libraries used by our jobs (I
> do
> > > not remember how they were configured).
> > >
> > > W
Re: [JENKINS] - New Maven Controller for the project
Okay, that makes sense.
Jobs have been picked up, just required quite some hours to run everything.
this morning I noticed some failed with the following message:
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
WorkflowScript: 54: Invalid option type "timestamps". Valid option types:
[authorizationMatrix, buildDiscarder, catchError, checkoutToSubdirectory,
datadog, disableConcurrentBuilds, disableResume, durabilityHint,
newContainerPerStage, overrideIndexTriggers, parallelsAlwaysFailFast,
preserveStashes, quietPeriod, rateLimitBuilds, retry, script,
skipDefaultCheckout, skipStagesAfterUnstable, throttle, throttleJobProperty,
timeout, waitUntil, warnError, withChecks, withContext, withCredentials,
withEnv, wrap, ws] @ line 54, column 9. timestamps() ^ WorkflowScript: 56:
Invalid option type "ansiColor". Valid option types: [authorizationMatrix,
buildDiscarder, catchError, checkoutToSubdirectory, datadog,
disableConcurrentBuilds, disableResume, durabilityHint, newContainerPerStage,
overrideIndexTriggers, parallelsAlwaysFailFast, preserveStashes, quietPeriod,
rateLimitBuilds, retry, script, skipDefaultCheckout, skipStagesAfterUnstable,
throttle, throttleJobProperty, timeout, waitUntil, warnError, withChecks,
withContext, withCredentials, withEnv, wrap, ws] @ line 56, column 9.
ansiColor('xterm') ^ 2 errors at
org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
at
org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1085)
at
org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603)
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581)
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558)
at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298) at
groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268) at
groovy.lang.GroovyShell.parseClass(GroovyShell.java:688) at
groovy.lang.GroovyShell.parse(GroovyShell.java:700) at
org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.doParse(CpsGroovyShell.java:142)
at
org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:127)
at
org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:571)
at
org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:523)
at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:337) at
hudson.model.ResourceController.execute(ResourceController.java:97) at
hudson.model.Executor.run(Executor.java:429) Finished: FAILURE
I've looked into our Jenkins scripts and and can't find these options. So I
assume these are some globally defined scripts that needs to be repaired.
thanks,
Robert
On 15-7-2021 11:18:34, Gavin McDonald wrote:
Hi
On Thu, Jul 15, 2021 at 11:08 AM Robert Scholte
wrote:
> In case you haven't noticed: all Windows nodes are offline.
>
>
Yeah they are 'leased' nodes shared between all ci-* controllers and come
online
when in use.
Robert
> On 15-7-2021 10:29:31, Robert Scholte wrote:
> Our scripts use the labels ubuntu and Windows to distinguish the OS.
> Is it safe to add ubuntu to the maven nodes?
>
> thanks,
> Robert
> On 15-7-2021 10:06:37, Gavin McDonald wrote:
> Thanks All,
>
> Jobs have been migrated.
>
> Please test and report any issues ASAP to INFRA jira.
>
> https://ci-maven.apache.org/
>
>
>
> On 2021/07/08 21:37:43, Arnaud Héritier wrote:
> > Hi Gavin
> >
> > Let’s go. I cannot test more than the authentication today but I can
> assist
> > more later this month after my vacations.
> >
> > What is important is to move the shared libraries used by our jobs (I do
> > not remember how they were configured).
> >
> > We will see if we need / have to find some sponsors to setup some
> > additional build nodes.
> >
> > Thanks for your help.
> >
> > Le jeu. 8 juil. 2021 à 23:06, Enrico Olivelli a
> > écrit :
> >
> > > Il giorno gio 8 lug 2021 alle ore 20:06 Gavin McDonald
> > > gmcdon...@apache.org>
> > > ha scritto:
> > >
> > > > Hi All,
> > > >
> > > > With no more interest in this subject, and no willing testers, I'll
> be
> > > > going ahead tomorrow and move all Maven jobs to ci-maven.apache.org.
> > > >
> > >
> > > I have tested that I am able to login to ci-maven with my LDAP
> credentials
> > >
> > > Thanks
> > > Enrico
> > >
> > >
> > > >
> > > > Feel free to check after the move and create INFRA jira ticket(s) for
> > > > anything that breaks as a result.
> > > >
> &g
Re: [JENKINS] - New Maven Controller for the project
In case you haven't noticed: all Windows nodes are offline. Robert On 15-7-2021 10:29:31, Robert Scholte wrote: Our scripts use the labels ubuntu and Windows to distinguish the OS. Is it safe to add ubuntu to the maven nodes? thanks, Robert On 15-7-2021 10:06:37, Gavin McDonald wrote: Thanks All, Jobs have been migrated. Please test and report any issues ASAP to INFRA jira. https://ci-maven.apache.org/ On 2021/07/08 21:37:43, Arnaud Héritier wrote: > Hi Gavin > > Let’s go. I cannot test more than the authentication today but I can assist > more later this month after my vacations. > > What is important is to move the shared libraries used by our jobs (I do > not remember how they were configured). > > We will see if we need / have to find some sponsors to setup some > additional build nodes. > > Thanks for your help. > > Le jeu. 8 juil. 2021 à 23:06, Enrico Olivelli a > écrit : > > > Il giorno gio 8 lug 2021 alle ore 20:06 Gavin McDonald > > gmcdon...@apache.org> > > ha scritto: > > > > > Hi All, > > > > > > With no more interest in this subject, and no willing testers, I'll be > > > going ahead tomorrow and move all Maven jobs to ci-maven.apache.org. > > > > > > > I have tested that I am able to login to ci-maven with my LDAP credentials > > > > Thanks > > Enrico > > > > > > > > > > Feel free to check after the move and create INFRA jira ticket(s) for > > > anything that breaks as a result. > > > > > > Gav... > > > > > > On 2021/06/30 18:23:54, Gavin McDonald wrote: > > > > Hi Michael, > > > > > > > > On 2021/06/30 18:12:12, Michael Osipov wrote: > > > > > Am 2021-06-30 um 20:03 schrieb Gavin McDonald: > > > > > > Hi Maven folks. > > > > > > > > > > > > Infra has decided to separate off the Maven build jobs from > > > > > > ci-builds.apache.org over to its very own Jenkins Controller and > > > Agents. > > > > > > > > > > > > This means that Maven now has a dedicated Jenkins environment for > > > itself. > > > > > > It > > > > > > also means that no other projects build jobs can build on the Maven > > > nodes; > > > > > > and > > > > > > then Maven jobs will no longer be able to build on the ci-builds > > > jobs. > > > > > > > > > > > > Your new Controller is set up as https://ci-maven.apache.org and > > > all Maven > > > > > > Committers > > > > > > can login via LDAP and create jobs. > > > > > > > > > > > > At the time of writing, there is one node/agent attached but I am > > > building > > > > > > 4 more - all > > > > > > Ubuntu 20.04 and based in our Azure account. > > > > > > > > > > Well, just Ubuntu? We actually need at least three different > > operating > > > > > systems to detect subtile bugs which I have found over time. > > > > > Since this is on an Azure can you rather add at least one Windows and > > > > > FreeBSD node to it? 4x Ubuntu won't really help. > > > > > > > > You are getting exactly as you have been using on ci-builds.a.o (and > > > builds.a.o) before that. > > > > There is no FreeBSD on any of our CI nor has there been for many years, > > > we do not support > > > > it. > > > > > > > > As for Windows nodes, you still have access to the same Windows nodes > > as > > > you always have, they are what are called floating agents available for > > > lease by all Jenkins Controllers, so your access and availability to the > > > Windows nodes will not change. We have 6 Windoes nodes currently and plan > > > to add some more soon. > > > > > > > > If anyone were to donate any nodes to attach to ci-maven then we'd be > > > happy to help add them on, including FreeBSD donated nodes, only > > difference > > > being that Infra would not manage them nor install any software on them, > > > which would be up to the donator(s). > > > > > > > > HTH > > > > > > > > > > > > > > Michael > > > > > > > > > > - > > > > > 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 > > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > -- > Arnaud Héritier > Twitter/Skype : aheritier > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [JENKINS] - New Maven Controller for the project
Our scripts use the labels ubuntu and Windows to distinguish the OS. Is it safe to add ubuntu to the maven nodes? thanks, Robert On 15-7-2021 10:06:37, Gavin McDonald wrote: Thanks All, Jobs have been migrated. Please test and report any issues ASAP to INFRA jira. https://ci-maven.apache.org/ On 2021/07/08 21:37:43, Arnaud Héritier wrote: > Hi Gavin > > Let’s go. I cannot test more than the authentication today but I can assist > more later this month after my vacations. > > What is important is to move the shared libraries used by our jobs (I do > not remember how they were configured). > > We will see if we need / have to find some sponsors to setup some > additional build nodes. > > Thanks for your help. > > Le jeu. 8 juil. 2021 à 23:06, Enrico Olivelli a > écrit : > > > Il giorno gio 8 lug 2021 alle ore 20:06 Gavin McDonald > > gmcdon...@apache.org> > > ha scritto: > > > > > Hi All, > > > > > > With no more interest in this subject, and no willing testers, I'll be > > > going ahead tomorrow and move all Maven jobs to ci-maven.apache.org. > > > > > > > I have tested that I am able to login to ci-maven with my LDAP credentials > > > > Thanks > > Enrico > > > > > > > > > > Feel free to check after the move and create INFRA jira ticket(s) for > > > anything that breaks as a result. > > > > > > Gav... > > > > > > On 2021/06/30 18:23:54, Gavin McDonald wrote: > > > > Hi Michael, > > > > > > > > On 2021/06/30 18:12:12, Michael Osipov wrote: > > > > > Am 2021-06-30 um 20:03 schrieb Gavin McDonald: > > > > > > Hi Maven folks. > > > > > > > > > > > > Infra has decided to separate off the Maven build jobs from > > > > > > ci-builds.apache.org over to its very own Jenkins Controller and > > > Agents. > > > > > > > > > > > > This means that Maven now has a dedicated Jenkins environment for > > > itself. > > > > > > It > > > > > > also means that no other projects build jobs can build on the Maven > > > nodes; > > > > > > and > > > > > > then Maven jobs will no longer be able to build on the ci-builds > > > jobs. > > > > > > > > > > > > Your new Controller is set up as https://ci-maven.apache.org and > > > all Maven > > > > > > Committers > > > > > > can login via LDAP and create jobs. > > > > > > > > > > > > At the time of writing, there is one node/agent attached but I am > > > building > > > > > > 4 more - all > > > > > > Ubuntu 20.04 and based in our Azure account. > > > > > > > > > > Well, just Ubuntu? We actually need at least three different > > operating > > > > > systems to detect subtile bugs which I have found over time. > > > > > Since this is on an Azure can you rather add at least one Windows and > > > > > FreeBSD node to it? 4x Ubuntu won't really help. > > > > > > > > You are getting exactly as you have been using on ci-builds.a.o (and > > > builds.a.o) before that. > > > > There is no FreeBSD on any of our CI nor has there been for many years, > > > we do not support > > > > it. > > > > > > > > As for Windows nodes, you still have access to the same Windows nodes > > as > > > you always have, they are what are called floating agents available for > > > lease by all Jenkins Controllers, so your access and availability to the > > > Windows nodes will not change. We have 6 Windoes nodes currently and plan > > > to add some more soon. > > > > > > > > If anyone were to donate any nodes to attach to ci-maven then we'd be > > > happy to help add them on, including FreeBSD donated nodes, only > > difference > > > being that Infra would not manage them nor install any software on them, > > > which would be up to the donator(s). > > > > > > > > HTH > > > > > > > > > > > > > > Michael > > > > > > > > > > - > > > > > 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 > > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > -- > Arnaud Héritier > Twitter/Skype : aheritier > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Apache Maven Dependency Tree 3.1.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Dependency Tree, version 3.1.0 This library contains a tree-based API for resolution of Maven project dependencies. https://maven.apache.org/shared/maven-dependency-tree/ You should specify the version in your project's plugin configuration: org.apache.maven.shared maven-dependency-tree 3.1.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/shared/maven-dependency-tree/download.html Release Notes - Maven Shared Components - Version maven-dependency-tree-3.1.0 ** Improvement * [MSHARED-339] - DependencyGraphBuilder does not provide verbose tree * [MSHARED-491] - DependencyGraphBuilders shouldn't need reactorProjects for resolving dependencies * [MSHARED-519] - Maven31DependencyGraphBuilder (and others?) should not download dependencies other than the pom * [MSHARED-657] - plexus-component-annotation in line with plexus-component-metadata * [MSHARED-691] - Upgrade parent to 31 * [MSHARED-788] - Add functionality to collect raw dependencies in Maven 3+ * [MSHARED-816] - Annotate DependencyNodes with dependency management metadata * [MSHARED-825] - Require Java 8 * [MSHARED-850] - Upgrade org.eclipse.aether:aether-util dependency in org.apache.maven.shared:maven-dependency-tree * [MSHARED-852] - Add Exclusions to DependencyNode * [MSHARED-853] - make build Reproducible Enjoy, -The Apache Maven team
[RESULT] [VOTE] Release Apache Maven Dependency Tree version 3.1.0
Hi, The vote has passed with the following result: +1 : Elliotte Rusty Harold, Hervé BOUTEMY, Sylwester Lachiewicz, Robert Scholte, Michael Osipov, Tamás Cservenák, Arnaud Héritier PMC quorum: reached I will promote the artifacts to the central repo. On 8-7-2021 14:34:19, Robert Scholte wrote: Hi, We solved 12 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12341375=Text There are no issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20component%20%3D%20maven-dependency-tree%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1654 https://repository.apache.org/content/repositories/maven-1654/org/apache/maven/shared/maven-dependency-tree/3.1.0/maven-dependency-tree-3.1.0-source-release.zip Source release checksum(s): maven-dependency-tree-3.1.0-source-release.zip sha512: a34df4748ed28dcf0224abd1ff7c2ebe228c90e95afa01b0a9590770392a9642c3b716cd09847c30f6a58492b5e08015f2ffa0e498f0351a85a97c6dc089e6c4 Staging site: https://maven.apache.org/shared-archives\maven-dependency-tree-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: [VOTE] Release Apache Maven Dependency Tree version 3.1.0
+1 On 8-7-2021 14:34:19, Robert Scholte wrote: Hi, We solved 12 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12341375=Text There are no issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20component%20%3D%20maven-dependency-tree%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1654 https://repository.apache.org/content/repositories/maven-1654/org/apache/maven/shared/maven-dependency-tree/3.1.0/maven-dependency-tree-3.1.0-source-release.zip Source release checksum(s): maven-dependency-tree-3.1.0-source-release.zip sha512: a34df4748ed28dcf0224abd1ff7c2ebe228c90e95afa01b0a9590770392a9642c3b716cd09847c30f6a58492b5e08015f2ffa0e498f0351a85a97c6dc089e6c4 Staging site: https://maven.apache.org/shared-archives\maven-dependency-tree-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
[VOTE] Release Apache Maven Dependency Tree version 3.1.0
Hi, We solved 12 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12341375=Text There are no issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20component%20%3D%20maven-dependency-tree%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1654 https://repository.apache.org/content/repositories/maven-1654/org/apache/maven/shared/maven-dependency-tree/3.1.0/maven-dependency-tree-3.1.0-source-release.zip Source release checksum(s): maven-dependency-tree-3.1.0-source-release.zip sha512: a34df4748ed28dcf0224abd1ff7c2ebe228c90e95afa01b0a9590770392a9642c3b716cd09847c30f6a58492b5e08015f2ffa0e498f0351a85a97c6dc089e6c4 Staging site: https://maven.apache.org/shared-archives\maven-dependency-tree-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: Apply exclusions later?
Dependency resolution is the heart of Maven and there are only a few that dare
to touch that code.
Answering this is not that easy without good investigation.
I expect that simply removing the exclusions from the cache key will cause
issues.
It might require an extra abstraction layer where GAV are separated from meta
info such as exclusions.
You could try to do a POC and verify it with the integration tests of both
maven-artifact-resolver and Maven (= maven + maven-integration-testing) to see
the impact and share the results.
thanks,
Robert
On 7-7-2021 07:19:33, Wei Cai wrote:
@Team,
Please share your insights for this issue.
On 2021/07/01 09:11:12, wecai wrote:
> We have a large dependency which has 300+ transitive dependencies, let's name
> the dependency as BigDep1.
>
>
> We have large numbers of libraries that depend on BigDep1. We may add
> exclusions when we use these libraries in our project.
>
> com.company...
> Lib1
>
> some_group_id
> some_artifact_id
>
>
>
>
> It took long time and huge memory to buid the project, we saw the BigDep1 is
> resolved thousands of times without hit from memory cache...
>
>
> By checking the code, we can see Maven is trying to load the resolved result
> of BigDep1 from cache, but as debugged it always failed to get the cached
> result.
> We can see the key is determined by GAV, repositories, childSelector,
> childManager, childTraverser, childFilter, this means exclusions is
> considered as part of the key.
> https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L504
> | Object key = |
> | | args.pool.toKey( d.getArtifact(), childRepos, childSelector,
> childManager, childTraverser, childFilter ); |
> | | |
> | | List children = args.pool.getChildren( key ); |
> | | if ( children == null ) => always null. need recalculate and again save
> to cache which takes long time and consumes large memory |
> | | { |
> | | args.pool.putChildren( key, child.getChildren() ); |
> | | |
> | | args.nodes.push( child ); |
> | | |
> | | process( args, results, descriptorResult.getDependencies(), childRepos,
> childSelector, childManager, |
> | | childTraverser, childFilter ); |
> | | |
> | | args.nodes.pop(); |
> | | } |
>
>
> Let me use a simple pattern to describe the problem:
>
>
> Lib1 -> BigDep1
> Lib2 -> Lib3 (has exclusion) -> BigDep1
> Lib4 -> Lib2
> ...
>
>
> Now in our project, we use libraries: Lib1, Lib2 , Lib4 with exclusions.
>
>
> Project -> Lib1
> Project -> Lib2
> Project -> Lib4 (has exclusion)
>
>
> Here is how maven resolve the dependencies:
> maven starts to resolve Lib1, Lib1 -> BigDep1. maven first resolves BigDep1
> and caches BigDep1 in memory
> maven starts to resolve Lib2, Lib2 -> Lib3 (has exclusion) -> BigDep1, as
> Lib3 has exclusion, so maven cannot load BigDep1 from cache and calculate
> BigDep1 again.
> maven starts to resolve Lib4 (has exclusion), Lib4 (has exclusion) -> Lib2
> ->Lib3 -> BigDep1, as Lib4 has exclusion, so maven cannot load Lib2, Lib3,
> BigDep1 from cache, all of them recalculated.
>
>
> I'm thinking if we can use GAV as the cache key and apply the exclusions
> later. maven can resolve the dependencies in this way:
> maven starts to resolve Lib1, maven first resolves BigDep1 and caches BigDep1
> by using BigDep1's GAV as key.
> maven starts to resolve Lib2, Lib2 -> Lib3 (has exclusion) -> BigDep1, maven
> get BigDep1 from cache, then calc Lib3 without applying exclusion and cache
> the result with Lib'3 GAV.
> when maven comes to resolve Lib2, maven starts to apply Lib3's exclusion to
> Lib3, add Lib3 with exclusion as children of Lib2 and then cache Lib2.
> maven starts to resolve Lib4 (has exclusion), Lib4 (has exclusion) -> Lib2
> ->Lib3 -> BigDep1, maven get Lib2 from cache, then calc Lib4 without applying
> the exclusion and then cache Lib4.
> when maven comes to resolve the current project, maven applies Lib4's
> exclusion, add Lib4 with exclusion as children of Project module, and then
> cache Project's resolved result.
>
>
> Does this make sense?
>
>
> This means all libraries' resolved result are cached with its GAV.
> Only the one which depends on it need to load the result from cache and apply
> exclusions if any.
>
>
> Thanks,
> Eric
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Discuss: maven-war-plugin build war archive directly without building exploded war
One thing to keep in mind is filtering/interpolation of ${some-key}
-expressions.
But I think it is possible to do it without temporary folder.
Robert
On 2-7-2021 07:18:14, Cai, Eric wrote:
We have a large web project and there is large numbers of dependencies. When we
run "mvn war:war", it usually takes 40s+ to build a war (~ 600MB) on a windows
10 box and 15s + with a mac book.
By checking the war-plugin code, we know the plugin need first copy files
necessary to a folder under project dir (exploded war), then archive the entire
folder.
Copying the files to a new folder actually take a long time.
My question is:
Does it make sense to modify war-plugin to skip building the exploded war and
directly create archive with original files? I think it can save quite a bit
time.
src/main/webapp -> archive
target/classes -> archive
...
Any impacts if the exploded war is not created?
Thanks,
Eric
Re: Maven 4 performances problems
Should we postpone the alpha-1 release because of this? For me the most important reason for alpha-1 is to get confirmation that builds won't be broken due to build/consumer. But if users simply look at buildtime and due to some slower result don't care for the other changes, then we shouldn't do this release now. Robert On 1-7-2021 11:20:17, Guillaume Nodet wrote: I've been running a few tests to measure performances. This simplistic test looks like running the following command in a loop and measure the execution time. This is done on a quite big project so that a bunch of pom files are actually read. for i in 1 2 3 4 5 6 7 8 9 10 ; do time $MAVEN_HOME/bin/mvn -DskipTests -Dmaven.experimental.buildconsumer=true help:evaluate -Dexpression=java.io.tmpdir -DforceStdout -q ; done The average results are the following: Maven 4 with build/consumer: 28,40s Maven 4 w/out build/consumer: 23,43s Maven 3: 21,54s I find the 20% performance loss of the build/consumer feature quite problematic. I hinted about those possible performance problems when reviewing the original PR, so I'd like to see if I can investigate a different way of achieving the transformation. I think the main performance cost comes from using the following pattern: read file -> parse using JAXP -> transform using TRAX -> write to stream read stream -> parse using XPP3 The first step is performed in a separate thread and the output written to a pipe stream which is used as the input of the usual pom parser. This double parsing step, in addition to using the JAXP / TRAX api, which is not the fastest one, comes at a heavy cost. I see two ways to solve the problem: * refactor the build/consumer feature to use a different API so that the parsing can be done in a single step (this would mean defining an XmlFilter interface to do the filtering and wrapping it inside an XmlPullParser) * get rid of the Xpp3 implementation and use the more common Stax api which already defines filters The second option has some drawbacks though: all the plugin configuration done using Xpp3Dom would not work anymore, so this is a very big and incompatible change. I'm thus willing to investigate the first option and see what can be done. If there's a consensus, I'll start working on a POC about the api / filters and will get back to this list with some more information. -- Guillaume Nodet
Re: Maven 3.8.x
It is probably easier to do a backport of maven-shared-utils with the vulnerability fix. Robert On 27-6-2021 00:48:00, Michael Osipov wrote: Folks, I have now back ported a lot of issues to maven-3.8.x which aren't related to resume, producer/consumer, etc. Many are just an output of Resolver update, no code changes in Maven itself. The following are open now: 1. MNG-7034: waiting for a backport from gnodet@ since my humble try did not work 2. Without MNG-6965 I see MNG-7115 constantly. 3. Jansi/maven-shared-utils upgrade: > https://issues.apache.org/jira/issues/?jql=project%20%3D%2012316922%20AND%20fixVersion%20%3D%2012349448%20%20AND%20(summary%20~%20jansi%20OR%20text%20~%20jansi)%20and%20issuekey%20not%20in%20(MNG-6915%2CMNG-7087%2CMNG-6914)%20ORDER%20BY%20priority%20DESC%2C%20key%20ASC Looks like a lot, but most are fixed by Jansi upgrade. Anyone wants to help out with Jansi? I see no further issues from master worth/possible back porting to maven-3.8.x. It we can resolve those from above, I'd start a release in July. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JPMS, Maven and test jars
>> I would not want it to be log4j-core-tests-3.0.0-SNAPSHOT.jar as that would not be understood to be a test jar. If this artifact is intended for log4j only, consider skipping install/deploy. But then I wonder why there's a need for a module descriptor. If it is intended to be used by users of log4j for testing, this name does make sense to me, similar to spring-test. Robert On 22-6-2021 23:20:11, Ralph Goers wrote: > On Jun 22, 2021, at 11:16 AM, Robert Scholte wrote: > > If I understand correctly you want both log4j-core main classes and test > classes be distributed as modularized jars. > To me with JPMS you should move the modularized test-classes to a separate > Maven module as a first citizen artifact. > That should make it a lot easier. Robert, I have a question on the above. I am generating log4j-core-3.0.0-SNAPSHOT.jar and log4j-core-3.0.0-SNAPSHOT-tests.jar. If the source is left in log4j-core and I create a log4j-core-tests module what would I specify in the pom to get it to create the test jar as log4j-core-3.0.0-SNAPSHOT-tests.jar? I would not want it to be log4j-core-tests-3.0.0-SNAPSHOT.jar as that would not be understood to be a test jar. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3.8.x
MNG-5669 contains lambda and IIRC there was a follow up improvement by Guillaume. MNG-6824 contains method references. I think both are more improvements than bugs. Before MNG-5669 Maven read a dependency that was also part of the reactor again. Result was the same, just spilling time. Before MNG-6824 the way ModelMerger was used one didn't hit the issue, but with build/consumer it did. So I don't consider these as regressions and would prefer not to take the risks of cherrypicking. Robert On 23-6-2021 19:19:44, Hervé BOUTEMY wrote: IIUC, DefaultModelBuilder fundamental change was done on June 22 2020: https://github.com/apache/maven/commit/bdec668de9c600165bb69c95b6ea0625d9f74fb0 before that point in time, there is no issue, isn't it? then I imagine MNG-5669 and MNG-6824 are safe to cherry pick? Regards, Hervé Le mercredi 23 juin 2021, 11:10:18 CEST Robert Scholte a écrit : > I would avoid cherrypicking any commit related to the DefaultModelBuilder, > this is just not the same class anymore. Also don't try to add fixes that > has been done with Java 8 features. > > To make your life easier I would focus on regressions only. > > So I would at least NOT try to include: > - MNG-5669 > - MNG-6160 > - MNG-6824 > > Robert > > > On 23-6-2021 10:02:52, Michael Osipov wrote: > Folks, > > I'd like to proceed with 3.8.x since there are a few issues which users > would like to see addressed. > I went through the issues in 4.0.0-alpha-1 and would like to evaluate > the following to be back ported to 3.8.x branch: > > https://issues.apache.org/jira/browse/MNG-5669 > https://issues.apache.org/jira/browse/MNG-5868 > https://issues.apache.org/jira/browse/MNG-6071 > https://issues.apache.org/jira/browse/MNG-6160 > https://issues.apache.org/jira/browse/MNG-6737 > https://issues.apache.org/jira/browse/MNG-6767 > https://issues.apache.org/jira/browse/MNG-6819 > https://issues.apache.org/jira/browse/MNG-6824 > https://issues.apache.org/jira/browse/MNG-6828 > https://issues.apache.org/jira/browse/MNG-6842 > https://issues.apache.org/jira/browse/MNG-6850 > https://issues.apache.org/jira/browse/MNG-6921 > https://issues.apache.org/jira/browse/MNG-6937 > https://issues.apache.org/jira/browse/MNG-6964 > https://issues.apache.org/jira/browse/MNG-6983 > https://issues.apache.org/jira/browse/MNG-6991 > https://issues.apache.org/jira/browse/MNG-7000 > https://issues.apache.org/jira/browse/MNG-7034 > https://issues.apache.org/jira/browse/MNG-7057 > > Almost all are bugfixes. > Do you see any other issues need to be back ported? Any objects for those? > > Michael > > - > 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: Maven 3.8.x
I would avoid cherrypicking any commit related to the DefaultModelBuilder, this is just not the same class anymore. Also don't try to add fixes that has been done with Java 8 features. To make your life easier I would focus on regressions only. So I would at least NOT try to include: - MNG-5669 - MNG-6160 - MNG-6824 Robert On 23-6-2021 10:02:52, Michael Osipov wrote: Folks, I'd like to proceed with 3.8.x since there are a few issues which users would like to see addressed. I went through the issues in 4.0.0-alpha-1 and would like to evaluate the following to be back ported to 3.8.x branch: https://issues.apache.org/jira/browse/MNG-5669 https://issues.apache.org/jira/browse/MNG-5868 https://issues.apache.org/jira/browse/MNG-6071 https://issues.apache.org/jira/browse/MNG-6160 https://issues.apache.org/jira/browse/MNG-6737 https://issues.apache.org/jira/browse/MNG-6767 https://issues.apache.org/jira/browse/MNG-6819 https://issues.apache.org/jira/browse/MNG-6824 https://issues.apache.org/jira/browse/MNG-6828 https://issues.apache.org/jira/browse/MNG-6842 https://issues.apache.org/jira/browse/MNG-6850 https://issues.apache.org/jira/browse/MNG-6921 https://issues.apache.org/jira/browse/MNG-6937 https://issues.apache.org/jira/browse/MNG-6964 https://issues.apache.org/jira/browse/MNG-6983 https://issues.apache.org/jira/browse/MNG-6991 https://issues.apache.org/jira/browse/MNG-7000 https://issues.apache.org/jira/browse/MNG-7034 https://issues.apache.org/jira/browse/MNG-7057 Almost all are bugfixes. Do you see any other issues need to be back ported? Any objects for those? Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JPMS, Maven and test jars
If I understand correctly you want both log4j-core main classes and test classes be distributed as modularized jars. To me with JPMS you should move the modularized test-classes to a separate Maven module as a first citizen artifact. That should make it a lot easier. It should also make the separation more clear: classes under target/test-classes are there to unittest its main classes. Whereas this new module contains reusable (main) code for testing (which should be tested too ;) ) I understand that this will change the GA(-classifier) for the testing module, but to me for a good reason. Even with your very small reduction of steps to simplify the process, it doesn't fit in the default lifecycle unless you write you introduce a new lifecycle-binding or write a new extension. Robert On 22-6-2021 07:02:59, Ralph Goers wrote: Sorry for posting again. I really need to proof-read better. Please ignore the prior email. I have recently had quite an adventure modifying several of Log4j’s Maven modules to implement JPMS on our master branch. It was an adventure due to a few issues: 1. https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8265826 . This bug has been fixed in Java 17 but Log4j uses Java 11 to build. 2. Log4j-plugins builds an annotation processor, packages it with the annotations and classes necessary to build and run plugins, creates and test jar and runs unit tests. 3. It is not possible to compile an annotation processor with a module-info.java present. The compile will fail because it can’t find the annotation processor “service” when compiling module-info.java. 4. It is very difficult to compile an annotation processor and then use it in the same Maven module. JPMS expects the annotation processor to either be on the classpath or specified with the processorpath option. When a module-info.java is present, Maven automatically moves everything to the module path. Maven only supports using coordinates to specify the processor path, which don’t exist when the processor is in the same module. The only way to solve this is to compile all the classes with proc=only without a module-info.java present. 5. Although number 4 might seem bad, it really doesn’t matter because javac will fail if a module-info.java is present because module-info.java will have a reference to the service class being generated by the annotation processor and for some reason module-info.java is resolved before the annotation processor runs. 6. If the main set of classes are compiled with a module-info.java every other compile in the Maven module must also be modularized. Likewise, if the main module does not contain a module-info.java no other compile can either. 7. JPMS requires that every module have its own package space with no overlap with any other JPMS module. So while generating the log4j-plugins module is quite painful, generating log4j-core isn’t much better. That is actually the primary focus for this list. Log4j-core consists of the main classes packaged in the jar, a test jar that is used by downstream Maven modules, and the unit tests. Prior to JPMS one would just create the main jar and then package all the test classes and unit tests in a test jar. This can no longer be done with JPMS. When a project publishes a test jar along with the main jar, just like any other JPMS module. the test jar cannot use the package space of the main classes. Log4j core uses org.apache.logging.log4j.core so I placed all the test utility classes under org.apache.logging.log4j.core.test. However, the unit tests all need to be packaged in the main package space since its module-info.java “extends” the main module and several unit tests are required to be in the same main package so that they can access package private methods specifically provided for testing. In order to get this to work I had to perform the following steps: • Compile all the main classes except module-info.java with the Plugin annotation processor. • Compile the main module-info.java. • Compile the test classes used by other modules with module-info.java and using the plugin preprocessor. • Package these test classes in a test jar. • Delete the module-info and generated source for the test classes. • Move the main module-info to a temp location. • Compile the unit test classes without module-info.java. • Move the main module-info back to the classes directory. • Compile module-info.java for unit tests. • Run the unit tests. • Create the main jar if the unit tests pass. Were it not for JDK-8265826 I believe this could have been simplified somewhat to: • Compile all the main classes except module-info.java with the Plugin annotation processor. • Compile the main module-info.java. • Compile the test classes used by other modules with its module-info.java and using the plugin preprocessor. • Package these test classes in a test jar. • Delete the module-info and generated source for the test classes. • Compile the unit
Re: [VOTE] Release Maven Resolver version 1.7.1
+1 On 14-6-2021 10:46:34, Michael Osipov wrote: Hi, We solved 6 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12350167 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20Resolver Staging repo: https://repository.apache.org/content/repositories/maven-1651/ https://repository.apache.org/content/repositories/maven-1651/org/apache/maven/resolver/maven-resolver/1.7.1/maven-resolver-1.7.1-source-release.zip Source release checksum(s): maven-resolver-1.7.1-source-release.zip dd577be910894cec235a00ed3ce408ed9dadd2c13c6ded202eca03220e66cceea2f13d33bda3a2864798783952926c145dd2de6547b4abb419e8af5f31f78de5 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Supporting building with incompatible JDK versions on a single project
AFAIK the --add-opens is only useful when using the module path. Maven itself and the plugins use the classpath, so I would like to have an example to better understand your issue. thanks, Robert On 15-6-2021 18:43:35, Guillaume Nodet wrote: Hi everyone ! There are some small incompatibilities between JDK around the supported command line versions. Usually, those do not cause any real problems. However, the "--add-opens" are sometimes necessary and only supported on JDK >= 9, as the JVM exits with an error on JDK 8. Some plugins may require the use of those options when running on JDK >= 9. What would be the way to solve this ? For mvnd, when the client launches the daemon, the JDK_JAVA_OPTIONS environment property is used. But it works because we have control on the client environment. But when you just clone a git repo, asking the user to set a specific environment is problematic imho. The .mvn/maven.config or .mvn/jvm.config can't be used to set up environment variables or to conditionally set up arguments afaik. Any idea ? -- Guillaume Nodet
Re: Issues to be done for Maven Core 4.0.0-alpha-1?
There was a regression issue with JAnsi which has now been fixed. Let's try the latest SNAPSHOT for a week to see if we hit any blockers. If not, I'll do the release next weekend. thanks, Robert On 29-5-2021 14:58:17, Robert Scholte wrote: If there are no objections, I'll do the release next week. Robert On 23-5-2021 11:43:54, Martin Kanters wrote: Hi all, With MNG-6915 [1] being merged yesterday, all Jansi-related PRs are merged. AFAIK there is nothing pressing left for the Maven 4.0.0-alpha-1 release, or am I missing something? Martin [1] https://issues.apache.org/jira/browse/MNG-6915 Op di 4 mei 2021 om 19:56 schreef Martin Kanters : > @Guillaume Great, thanks for updating them! I'm processing them as we > speak. > > Martin > > Op di 4 mei 2021 om 15:13 schreef Michael Osipov : > >> Am 2021-05-03 um 20:35 schrieb Guillaume Nodet: >> > Now that maven-shared-utils has been released, I've rebased my PRs: >> > https://github.com/apache/maven/pulls/gnodet >> >> Darn, I would I could review your quality PRs, still busy with Resolver... >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >>
Re: Build windows-jdk11
I don't understand why INFRA-21954 was closed, the issue is still occurring. I've changed INFRA-21690 to blocker, but still no response. Robert On 7-6-2021 15:32:29, Benjamin Marwell wrote: I also opened https://issues.apache.org/jira/browse/INFRA-21954 #asfinfra on slack On Mon, 7 Jun 2021, 14:52 Michael Osipov, wrote: > Am 2021-06-07 um 14:36 schrieb Elliotte Rusty Harold: > > Build windows-jdk11 has been broken for a week+ now. Anyone want to > > take a look? I couldn't find any useful log output. > > > https://issues.apache.org/jira/browse/INFRA-21690 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Moving away from Modello
Well, where is the need for additional namespaces and how they be handled? The reader has a strict mode, should it fail or ignore unknown tags? I am aware of one request: adding a namespace on plugins configuration (to validate its content), however the configuration-element is part of the maven namespace, so I don't think this will work. thanks, Robert On 7-6-2021 15:37:17, Elliotte Rusty Harold wrote: On Mon, Jun 7, 2021 at 1:21 PM Guillaume Nodet wrote: > > The generated xml readers are used to actually read the pom. That's an > important part :-) > I spent quite some time profiling those and XPP3 is really fast, so I'd > really like to avoid using JAXB for that. > > I agree with not using JAXB. It's a poorly designed API that causes more problems than it solves, though I could say the same for all the other data binding APIs out there. Not just for XML either. JSON and SQL data binding APIs suffer from the same flawed goal of avoiding writing the code necessary to understand the data. It never works and it always ends up costing more in the end. There are current issues in our pom.xml parsing, particularly around namespaces, that aren't going to be resolved until we get rid of or fix Modello, and possibly that's going to require fixing XPP3. I don't know. However the XML parser should be an implementation detail. -- 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: Moving away from Modello
The title suggest it should me moved completely from the Maven codebase, but I think there's no alternative for Maven Core, as we need quite a huge set of features. I don't think there's another tool that can keep the model, reader, writers, mergers, validators and xsd in sync. If you want to replace it, start with Maven core. If you succeed we can have another discussion otherwise we will stick to Modello. We have enough committers that can maintain it. To me consistency is just as important, so it makes sense to have a preferred library for reading/writing XML. As Maven Core already claims Modello, better mark this as the preferred solution. Regarding Eclipse support, most likely Eclipse was the first IDE to support Modello and it still does. If you open the pom you should see there are m2 plugins available, including one for modello. Once installed and restarted, it works as expected (just tested it). Like any IDE, in general you don't get all the options but often pluguins are available. You rarely need to touch the mdo-files, but with the right documentation you should be able to extend it. But that is for any solution we would choose. We shouldn't maintain all Java files and XSDs by hand, but generate it. And any generating tool will require read that famous manual. Robert On 2-6-2021 14:38:43, Gary Gregory wrote: On Wed, Jun 2, 2021 at 8:30 AM Jochen Wiedmann wrote: > > On Wed, Jun 2, 2021 at 1:02 PM Elliotte Rusty Harold wrote: > > > What do folks think about slowly moving away from Modello where > > feasible to simplify the build? Does anyone find Modello a net > > positive, especially in longterm maintenance, not just in initial code > > generation? > > To me, it sounds feasible to replace Modello with a Sax parser > (reading), and a Sax > event generator (writing), that take as input a bean class (either > written manually, > or generated by Modello, and do the serialization/deserialization. > > Would, most likely, not be a drop-in-replacement, but definitely a medium-term > solution. What about JAXB? Gary > > Jochen > > > -- > > Look, that's why there's rules, understand? So that you think before > you break 'em. > > -- (Terry Pratchett, Thief of Time) > > - > 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: @Parameter on a NIO Path
Someone needs to implement #563525[1] I've had the confirmation that increasing source/target of Java makes sense. thanks, Robert [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=563525 On 29-5-2021 16:07:50, Gary Gregory wrote: Hi All, How do I use a @Parameter on a NIO Path? I don't a place to plugin a factory of some kind. TY, Gary
Re: Issues to be done for Maven Core 4.0.0-alpha-1?
If there are no objections, I'll do the release next week. Robert On 23-5-2021 11:43:54, Martin Kanters wrote: Hi all, With MNG-6915 [1] being merged yesterday, all Jansi-related PRs are merged. AFAIK there is nothing pressing left for the Maven 4.0.0-alpha-1 release, or am I missing something? Martin [1] https://issues.apache.org/jira/browse/MNG-6915 Op di 4 mei 2021 om 19:56 schreef Martin Kanters : > @Guillaume Great, thanks for updating them! I'm processing them as we > speak. > > Martin > > Op di 4 mei 2021 om 15:13 schreef Michael Osipov : > >> Am 2021-05-03 um 20:35 schrieb Guillaume Nodet: >> > Now that maven-shared-utils has been released, I've rebased my PRs: >> > https://github.com/apache/maven/pulls/gnodet >> >> Darn, I would I could review your quality PRs, still busy with Resolver... >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >>
Welcome Guillaume Nodet as new Maven Committer
Hi, On behalf of the Apache Maven PMC I am pleased to announce that Guillaume Nodet has been voted in as new Apache Maven committer and he has accepted this invitation. Welcome on board and have a lot of fun! Thanks, Robert Scholte
Re: Issues to be done for Maven Core 4.0.0-alpha-1?
The main driver is POM Model Version 5.0.0[1]
We are confronted more and more with issues in the current model, but we cannot
fix it.
Even when there was an optional attribute added to an element, we had a lot of
issues.
I picked this topic up several years ago and now we're at a point where we need
people to start verifying it.
The original idea was Maven 3.7.0 and the build/consumer turned off by default,
but that wouldn't give us enough feedback.
Hence the Maven 4 where it is turned on by default (but you can disable it).
The rest of the issues can be separated into 2 groups:
- issues that were already marked for Maven 4 due to their impact
- issues there could have been added to Maven 3, but since the next release
will be Maven 4 they'll be part if that release.
Regarding the transformation, the first documentation[2] is already available
With uploaded I actually mean distributed, as done by the maven-install-plugin
and maven-deploy-plugin.
Currently the maven-gpg-plugin is using the local pom.xml to calculate the
signature, but because the local pom will be different compared to the
distributed pom, the signature won't match.
This needs to be fixed of course, but shouldn't block the users that never sign
their artifacts.
The checksums should be fine: these were generated by the maven-install-plugin,
but is has been superseded by maven-artifact-resolver (formally known as
Aether).
I don't know if there are other plugins in the world that should be using the
distributed pom.xml like the maven-gpg-plugin does, but those need to be
rewritten too.
thanks,
Robert
[1] https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0
[2] http://maven.apache.org/ref/4-LATEST/maven-model-transform/
On 23-5-2021 13:34:47, Fred Cooke wrote:
Thanks for that, Robert!
Aside from the 5 page issue list of what actually got done, is there
somewhere where the intention and motivation for the change was documented
before the key work (a subset of that list) was done? Or just other threads
in this mailing list (which I don't read as often as I should, but I do
recall some of the two-poms discussions a while back).
I was unable to find the ticket about what "ci-friendly versions" means but
if that's only for mostly-anti-pattern MM projects, no bother, my curiosity
will quickly fade :-D
Duplicate dependencies will be an error is most welcome! :-) I don't think
that's ever happened to me, but the number of times I've fixed it for
sloppy careless others is horrendous.
The wrapper plugin main page could do with an intro and some use cases that
it satisfies, there's almost nothing there but the usage page goes through
it in a bit more detail than belongs on the main page and makes it clear
(except why that would be useful, maybe some CI where you don't control the
container content?).
I don't understand the concept of a local execution of a plugin using an
uploaded pom rather than the local one. To make it clear why, what about -o
builds? What does "uploaded" really mean?
But yes, the two-poms stepping stone makes it clear why the bump, that's a
big departure from the past.
Cheers,
Fred.
On Sun, 23 May 2021 at 22:58, Robert Scholte wrote:
> TLDR; Most things will still work, but some things will break.
>
> Maven 4 is the preparation for Maven 5, where we will be able to introduce
> a new pom model. To keep the Maven eco system stable, it must be possible
> to upload model 4.0.0 compatible poms to remote repositories, especially to
> Central.
> Every plugin that uses the local pom where it should be using the uploaded
> pom will fail, think about the plugins that sign. These need to be
> rewritten.
> To support this, huge changes had to be made in the architecture of Maven.
> This to proof that we can transform pom files without any impact.
> Maven 4 must proof this transforming mechanism, Maven for will be able to
> expand and clean up the pom.This is reflected by the following new features
> for multimodule projects:
> - automatic parent version based on relativePath
>
> - automatic dependency version for reactor dependencies.
> - proper ci-friendly versioning
>
> Some other things that might break your build:
> - require Java 8
> - upgrade of the default versions of the plugins per packaging type
> - strict checksum validation
>
> - removal of some deprecated Maven2 commandline flags
> - some warnings will now be errors (e.g. duplicate dependencies in your
> pom.xml)
> - removal of release-profile from super-pom
>
> New features:
> - maven-wrapper is now part of Maven core. There's a new lifecycle for it
> ('mvn wrapper') and a new plugin('maven-wrapper-plugin)
> - improved commandline options when working with multimodule projects.
> - jansi based console output improvements
>
> This is just a short summary of the release[1], but it should give you an
> idea
Re: Issues to be done for Maven Core 4.0.0-alpha-1?
TLDR; Most things will still work, but some things will break.
Maven 4 is the preparation for Maven 5, where we will be able to introduce a
new pom model. To keep the Maven eco system stable, it must be possible to
upload model 4.0.0 compatible poms to remote repositories, especially to
Central.
Every plugin that uses the local pom where it should be using the uploaded pom
will fail, think about the plugins that sign. These need to be rewritten.
To support this, huge changes had to be made in the architecture of Maven. This
to proof that we can transform pom files without any impact.
Maven 4 must proof this transforming mechanism, Maven for will be able to
expand and clean up the pom.This is reflected by the following new features for
multimodule projects:
- automatic parent version based on relativePath
- automatic dependency version for reactor dependencies.
- proper ci-friendly versioning
Some other things that might break your build:
- require Java 8
- upgrade of the default versions of the plugins per packaging type
- strict checksum validation
- removal of some deprecated Maven2 commandline flags
- some warnings will now be errors (e.g. duplicate dependencies in your pom.xml)
- removal of release-profile from super-pom
New features:
- maven-wrapper is now part of Maven core. There's a new lifecycle for it ('mvn
wrapper') and a new plugin('maven-wrapper-plugin)
- improved commandline options when working with multimodule projects.
- jansi based console output improvements
This is just a short summary of the release[1], but it should give you an idea
why this version should be called Maven 4.
thanks,
Robert
[1]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%204.0.0-alpha-1
On 23-5-2021 11:55:59, Fred Cooke wrote:
Is there somewhere where I can read about the rationale behind the first
major version bump since I learned M2 15 years ago and what's changed in a
positive but breaking fashion that warranted that bump?
Just the 4 sounds exciting without any context. I hope the context lives up
to it, but 3 has been serving me SO well for such a long time, I'm
skeptical :-D
Introduction of repaint.io tiles as the default parent mechanism, perhaps?
Cheers,
Fred.
PS: Disclaimer: I've not even tried 3.8.2 yet! And only just upgraded my
personal stuff from 3.3.9 to 3.6.3 without any breakage at all.
On Sun, 23 May 2021 at 21:43, Martin Kanters
wrote:
> Hi all,
>
> With MNG-6915 [1] being merged yesterday, all Jansi-related PRs are merged.
> AFAIK there is nothing pressing left for the Maven 4.0.0-alpha-1 release,
> or am I missing something?
>
> Martin
>
> [1] https://issues.apache.org/jira/browse/MNG-6915
>
> Op di 4 mei 2021 om 19:56 schreef Martin Kanters
> >:
>
> > @Guillaume Great, thanks for updating them! I'm processing them as we
> > speak.
> >
> > Martin
> >
> > Op di 4 mei 2021 om 15:13 schreef Michael Osipov :
> >
> >> Am 2021-05-03 um 20:35 schrieb Guillaume Nodet:
> >> > Now that maven-shared-utils has been released, I've rebased my PRs:
> >> > https://github.com/apache/maven/pulls/gnodet
> >>
> >> Darn, I would I could review your quality PRs, still busy with
> Resolver...
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
>
[ANN] Apache Maven Javadoc Plugin 3.3.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven
Javadoc Plugin, version 3.3.0
The Javadoc Plugin uses the Javadoc tool to generate javadocs for the specified
project.
https://maven.apache.org/plugins/maven-javadoc-plugin/
You should specify the version in your project's plugin configuration:
org.apache.maven.plugins
maven-javadoc-plugin
3.3.0
You can download the appropriate sources etc. from the download page:
http://maven.apache.org/plugins/maven-javadoc-plugin/download.html
Release Notes - Maven Javadoc Plugin - Version 3.3.0
** Bug
* [MJAVADOC-453] - Using Alternate Doclet documentation example snippet is
out of date and does not work
* [MJAVADOC-571] - javadoc:aggregate triggers Javadoc error for test-only
modules
* [MJAVADOC-584] - excludePackageNames is not working as documented anymore
* [MJAVADOC-588] - "includeDependencySources" doesn't work in
maven-javadoc-plugin 3.1.0 when all modules have "Automatic-Module-Name"
* [MJAVADOC-590] - Setting nooverview option always causes a build failure
* [MJAVADOC-614] - "No source files for package" in a directory with accent
characters
* [MJAVADOC-619] - Maven Javadoc bottom claims copyright for future years
* [MJAVADOC-623] - [ERROR] Error fetching link:
%{project.basedir}/target/javadoc-bundle-options. Ignored it.
* [MJAVADOC-634] - Error in test-aggregate-no-fork when using modules
* [MJAVADOC-643] - make build Reproducible for secondary artifacts
* [MJAVADOC-644] - StaleHelper does not close DirectoryStream
* [MJAVADOC-650] - Fix Javadoc search path for Java 9+
* [MJAVADOC-657] - The fix operation duplicates annotations on private
methods that have an annotation line between the method body and the javadoc
comments.
* [MJAVADOC-658] - The fix operation deletes generic functions's
generic-class javadoc if exist, and add it if lack, and will not create it if
param part of javadoc be empty
* [MJAVADOC-659] - javadoc:fix replaces existing @throws descriptions
* [MJAVADOC-660] - No periods without complete sentences in @param fixes
* [MJAVADOC-661] - tagletArtifact fails to scan multi-release JARs (MRJARs)
for Taglets
* [MJAVADOC-662] - Generated javadoc for static final fields should be HTML
escaped
* [MJAVADOC-664] - Detection of stale files not working on Windows
* [MJAVADOC-667] - Broken links in Javadoc comments
** New Feature
* [MJAVADOC-625] - Support for multiple stylesheets
** Improvement
* [MJAVADOC-592] - detectJavaApiLink should also respect
maven.compiler.source property
* [MJAVADOC-611] - Support adjustment javadoc link of dependency
* [MJAVADOC-653] - fix javadoc; fix code smells; performance improvement;
add travis-ci script.
* [MJAVADOC-663] - Add GitHub Action to confirm build PR
* [MJAVADOC-668] - Improve parameter description
* [MJAVADOC-672] - misleading Exit code: 2 - javadoc: error - No source
files for package
* [MJAVADOC-675] - Require Java 8
Enjoy,
-The Apache Maven team
[RESULT] [VOTE] Release Apache Maven Javadoc Plugin version 3.3.0
Hi, The vote has passed with the following result: +1 : Robert Scholte, Hervé BOUTEMY, Frederik Boster, Arnaud Héritier, Michael Osipov PMC quorum: reached I will promote the artifacts to the central repo. On 18-5-2021 20:43:37, Robert Scholte wrote: Hi, We solved 28 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317529=12346637=Text There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317529%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1649 https://repository.apache.org/content/repositories/maven-1649/org/apache/maven/plugins/maven-javadoc-plugin/3.3.0/maven-javadoc-plugin-3.3.0-source-release.zip Source release checksum(s): maven-javadoc-plugin-3.3.0-source-release.zip sha512: 780e485ea5bb05a074089f243f6442ad43d9627e7a3805e5985dbda67751fcf140504e48b1e74596dc10d187cb6bb3d9a153f74dda3b733e2d8d3a42062d4794 Staging site: https://maven.apache.org/plugins-archives/maven-javadoc-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: [VOTE] Release Apache Maven Javadoc Plugin version 3.3.0
Dear all, I need some extra votes in order to release this. thanks, Robert On 18-5-2021 20:43:37, Robert Scholte wrote: Hi, We solved 28 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317529=12346637=Text There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317529%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1649 https://repository.apache.org/content/repositories/maven-1649/org/apache/maven/plugins/maven-javadoc-plugin/3.3.0/maven-javadoc-plugin-3.3.0-source-release.zip Source release checksum(s): maven-javadoc-plugin-3.3.0-source-release.zip sha512: 780e485ea5bb05a074089f243f6442ad43d9627e7a3805e5985dbda67751fcf140504e48b1e74596dc10d187cb6bb3d9a153f74dda3b733e2d8d3a42062d4794 Staging site: https://maven.apache.org/plugins-archives/maven-javadoc-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: [VOTE] Release Apache Maven Javadoc Plugin version 3.3.0
+1 On 18-5-2021 20:43:37, Robert Scholte wrote: Hi, We solved 28 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317529=12346637=Text There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317529%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1649 https://repository.apache.org/content/repositories/maven-1649/org/apache/maven/plugins/maven-javadoc-plugin/3.3.0/maven-javadoc-plugin-3.3.0-source-release.zip Source release checksum(s): maven-javadoc-plugin-3.3.0-source-release.zip sha512: 780e485ea5bb05a074089f243f6442ad43d9627e7a3805e5985dbda67751fcf140504e48b1e74596dc10d187cb6bb3d9a153f74dda3b733e2d8d3a42062d4794 Staging site: https://maven.apache.org/plugins-archives/maven-javadoc-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
[VOTE] Release Apache Maven Javadoc Plugin version 3.3.0
Hi, We solved 28 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317529=12346637=Text There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317529%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1649 https://repository.apache.org/content/repositories/maven-1649/org/apache/maven/plugins/maven-javadoc-plugin/3.3.0/maven-javadoc-plugin-3.3.0-source-release.zip Source release checksum(s): maven-javadoc-plugin-3.3.0-source-release.zip sha512: 780e485ea5bb05a074089f243f6442ad43d9627e7a3805e5985dbda67751fcf140504e48b1e74596dc10d187cb6bb3d9a153f74dda3b733e2d8d3a42062d4794 Staging site: https://maven.apache.org/plugins-archives/maven-javadoc-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: Accessing Maven Repository with Java11, SplitPackages
The codebase of Maven is over 15 years old and you can clearly see that it has evolved over the years. This implies that sometimes we've decided to move classes from one jar to the other. On the classpath this is not an issue and as Maven is using only the classpath to run there is no issue here. Having said that, you're clearly trying to use the maven-resolver-provider on the module-path, which is not going to work without any tricks (such as providing extra flags to java / javac or to rebundle jars). However, Java 11 (or actually Java 9) doesn't mean you can't use the classpath anymore. Currently there is no need for Maven to switch to the module path. Assuming we would do that, we need to rename packages which would probably make all current maven-plugins useless.It comes with much more pain than gain. So the advice is: remove your module-info file and stay on the classpath Robert On 30-4-2021 22:45:57, jan.uhli...@web.de wrote: Dear Maven Developers, I am currently struggling with a problem related to the maven-resolver-provider in version 3.8.1 because its’ inherent dependencies seem to not be compatible with Java14. This brought me to the question if there is an intention to migrate alike maven projects to at least Java11, regarding the restriction of package splitting since Java11. ( With the premise that maven-resolver-provider and such are built with Java8, what wouldn’t cause the problems at all. Sadly, I didn’t find much but some notes that many related projects are still developed under Java8. ) Derived from this more general question I can surely provide more information about my special issue and for sure can create an actual Issue on this, but as I am not that much experienced in this universe, I thought I’d like to contact you in advance: The maven-resolver-provider is the dependency that allows me to resolve a Maven repository in Java with access to Artifacts and much more. What is mainly what I want to do, and what worked with Java8 like a charm. Since split packages are restricted in Java11, at startup Java throws ResolutionExceptions as soon as the dependency* is declared. Amongst others, the really concerning issue strikes as follows: java.lang.module.ResolutionException: Modules maven.model and maven.model.builder export package org.apache.maven.model.merge to module maven.repository.metadata Looking at these projects, one can easily see that the only class provided by the maven-model-build -> org.apache.maven.model.merge package is a class called “MavenModelMerger.java” extends “ModelMerger.java” >From maven-model project and seems to have no dependencies on the >maven-model-builder project at all. Couldn’t this be moved to the maven-model >project to support Java11 at this point? (The image below shows the imports for the MavenModelMerger.class.) As you may have guessed, I really need these projects maven-model and maven-model-builder, what directly leads to the above provided question: Are there intentions to migrate these projects to a newer Java version? PS: In case I am completely misleaded, I am sorry. Best Regards, Stay Healthy, Jan Uhlig * org.apache.maven maven-resolver-provider 3.8.1 The following image demonstrates the imports in the MavenModelMerger class:
Re: [VOTE] Release Apache Maven Shared Utils version 3.3.4
+1 On 26-4-2021 19:59:53, Maarten Mulders wrote: Hi, We solved 6 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12350122=Text There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317922%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-shared-utils%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1643/ https://repository.apache.org/content/repositories/maven-1643/org/apache/maven/shared/maven-shared-utils/3.3.4/maven-shared-utils-3.3.4-source-release.zip Source release checksum(s): maven-shared-utils-3.3.4-source-release.zip sha512: 27b63d3c8214c3ced472c4eae69199adad85b4badabd3b1608b8ab288f2246efba8f833763e87ad13e55268814e392b0d8146fb4a32a9de6d3c50c9652d66326 Staging site: https://maven.apache.org/components/shared-archives/maven-shared-utils-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 Thanks in advance for your votes, Maarten
[ANN] Apache Maven Plugin Tools 3.6.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven
Plugin Tools, version 3.6.1
The Maven Plugin Tools contains the necessary tools to generate rebarbative
content like descriptor, help and documentation. In addition, it provides tools
to write Maven Plugins in scripting languages like Ant or Beanshell.
https://maven.apache.org/plugins-tools/index.html
You should specify the version in your project's plugin configuration:
org.apache.maven.plugins
maven-plugin-plugin
3.6.1
You can download the appropriate sources etc. from the download page:
https://maven.apache.org/plugin-tools/download.html
Release Notes - Maven Plugin Tools - Version 3.6.1
** Bug
* [MPLUGIN-346] - plugin:descriptor sometimes fails with
java.util.NoSuchElementException
* [MPLUGIN-348] - Why does maven-plugin-plugin always warn if goalPrefix is
set?
* [MPLUGIN-358] - Cannot build plugin embedding java 13 compiled code
* [MPLUGIN-360] - generated plugin-help.xml ignores descriptor mojo
outputDirectory
* [MPLUGIN-363] - HelpMojo result relies on 'clean'
* [MPLUGIN-369] - Descriptor generation fails if a Mojo uses Java Records
("UnsupportedOperationException: Record requires ASM8")
** Improvement
* [MPLUGIN-353] - Use Java 7 APIs and language features
* [MPLUGIN-357] - Custom search broken on pages rendered using Fluido Skin
1.7
* [MPLUGIN-361] - make build Reproducible
* [MPLUGIN-365] - Don't log a warning when packaging type unsupported ->
info is enough
** Task
* [MPLUGIN-367] - Improve documentation of @Execute(lifecycle=...)
* [MPLUGIN-368] - Improve documentation of @Execute(goal=...)
** Dependency upgrade
* [MPLUGIN-355] - Upgrade JUnit to 4.12
* [MPLUGIN-359] - upgrade Doxia Sitetools to 1.9.2 to remove dependency on
Struts
Enjoy,
-The Apache Maven team
[RESULT] [VOTE] Release Apache Maven Plugin Tools version 3.6.1
Hi, The vote has passed with the following result: +1 : Michael Osipov, Hervé BOUTEMY, Robert Scholte, Karl Heinz Marbaise, Tibor Digana PMC quorum: reached I will promote the artifacts to the central repo. On 23-4-2021 14:56:00, Robert Scholte wrote: Hi, We solved 14 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317820=12344365=Text There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317820%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1641/ https://repository.apache.org/content/repositories/maven-1641/org/apache/maven/plugin-tools/maven-plugin-tools/3.6.1/maven-plugin-tools-3.6.1-source-release.zip Source release checksum(s): maven-plugin-tools-3.6.1-source-release.zip sha512: 53346c71923025ec5935fb944a356535ad77b68768087e021b669e9736a8800db879839e5707b3b0a4d0cd45401481e98850148b68e3f76059325cb60ea0b4b5 Staging site: https://maven.apache.org/plugin-tools-archives/plugin-tools-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: [VOTE] Release Apache Maven Plugin Tools version 3.6.1
+1 On 23-4-2021 14:56:00, Robert Scholte wrote: Hi, We solved 14 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317820=12344365=Text There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317820%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1641/ https://repository.apache.org/content/repositories/maven-1641/org/apache/maven/plugin-tools/maven-plugin-tools/3.6.1/maven-plugin-tools-3.6.1-source-release.zip Source release checksum(s): maven-plugin-tools-3.6.1-source-release.zip sha512: 53346c71923025ec5935fb944a356535ad77b68768087e021b669e9736a8800db879839e5707b3b0a4d0cd45401481e98850148b68e3f76059325cb60ea0b4b5 Staging site: https://maven.apache.org/plugin-tools-archives/plugin-tools-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: JPMS compile problems
I think you need to talk with Christian Stein about blackbox and whitebox testing. Robert On 25-4-2021 08:47:20, Ralph Goers wrote: I am trying to convert Log4j 2 to be fully modularized and am running into problems with Log4j-core. First, I have hit a couple of nasty bugs when compiling on MacOS that are reflected in https://issues.apache.org/jira/browse/MCOMPILER-461 and https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8265826 . Basically the compiler seems to be converting directory names that have a class with the same name in the same package to upper case. To combat this I am forced to compile without a module-info.java during annotation processing and again with the module-info.java. To make matters worse, the log4j-api, log4j-plugins, and log4j-core modules all have test classes that need to be made available to downstream modules for testing. Prior to JPMS we just passed the test jars on, but since many of the unit tests need to use the same packages as the main source the test modules to be passed on had to be placed into their own “test” package and so had to be moved out from the rest of the unit test classes so they could be package in a valid module. As a result of this I had to convert my directory structure into src/main/java/ main classes src/main/java9/module-info.java src/test/java/ unit test classes & module-info.java src/test/java-test. Shared test classes src/test/java-test9/module-info.java and my build consists of: 1. Running Log4j’s annotation processor against the main classes without module-info.java. 2. Compiling Log4j’s main classes with module-info.java. 3. Compiling the separate test classes with its module-info.java. 4. Packaging these test classes into the tests jar. 5. Running Log4j’s annotation processor against the unit test classes. 6. Compiling the unit tests. But the build fails at step 5. If I do not include a module-info.java in the unit tests I get failures due to milling modules because maven is setting the module path (presumably because the main classes have one). If I do include the module-info.java then I run into the reported bugs and the compile fails with duplicate class errors. I’ve thought of trying to compile without module-info.java but I have to create a valid JPMS module for the separate test classes so that has to be done before starting on the unit tests. The only way I can see to do this is to run the annotation processor without the module path but it seems the compiler plugin provides no option to do that. My next thought is to try using https://github.com/bsorrentino/maven-annotation-plugin to perform the annotation processing and see if I have better luck. I should also add that these projects look like hell in Intellij as it has no idea how to resolve the second test directory. Does anyone have any thoughts on how this could be more easily accomplished? I can’t imagine I am the only person who needs to create a valid test jar. Ralph
[VOTE] Release Apache Maven Plugin Tools version 3.6.1
Hi, We solved 14 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317820=12344365=Text There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317820%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1641/ https://repository.apache.org/content/repositories/maven-1641/org/apache/maven/plugin-tools/maven-plugin-tools/3.6.1/maven-plugin-tools-3.6.1-source-release.zip Source release checksum(s): maven-plugin-tools-3.6.1-source-release.zip sha512: 53346c71923025ec5935fb944a356535ad77b68768087e021b669e9736a8800db879839e5707b3b0a4d0cd45401481e98850148b68e3f76059325cb60ea0b4b5 Staging site: https://maven.apache.org/plugin-tools-archives/plugin-tools-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
[ANN] Apache Maven JXR Plugin 3.1.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven JXR Plugin, version 3.1.1 The JXR Plugin produces a cross-reference of the project's sources. The generated reports make it easier for the user to reference or find specific lines of code. It is also handy when used with the PMD Plugin for referencing errors found in the code. https://maven.apache.org/jxr/maven-jxr-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-jxr-plugin 3.1.1 You can download the appropriate sources etc. from the download page: https://maven.apache.org/jxr/download.html Release Notes - Maven JXR - Version 3.1.1 ** Bug * [JXR-141] - Invalid HTML generation when having multiple occurences of the same class on one line * [JXR-153] - JxrReportTest depends on platform default encoding * [JXR-154] - xref-test package summary lists also classes from main source directories * [JXR-158] - StringEntry shouldn't be Comparable ** Improvement * [JXR-142] - Switch to CDI * [JXR-143] - New goals jxr-no-fork and test-jxr-no-fork which will not invoke generate-*-sources * [JXR-144] - Require Maven 3.1.0 * [JXR-147] - make build Reproducible * [JXR-150] - AbstractJxrReport.java uses or overrides a deprecated API. * [JXR-151] - Update apache commons ** Dependency upgrade * [JXR-146] - upgrade Doxia Sitetools to 1.9.2 to remove dependency on Struts * [JXR-159] - Prerequisites - Maven 3.1.1 Enjoy, -The Apache Maven team
[RESULT] [VOTE] Release Apache Maven JXR Plugin version 3.1.1
Hi, The vote has passed with the following result: +1 :Arnaud Héritier, Tibor Digana, Robert Scholte, Olivier Lamy, Andreas Sewe, Hervé BOUTEMY, Sylwester Lachiewicz PMC quorum: reached I will promote the artifacts to the central repo. On 18-4-2021 21:12:47, Robert Scholte wrote: Hi, We solved 12 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317527=12344185=Text There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317527%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1640/ https://repository.apache.org/content/repositories/maven-1640/org/apache/maven/jxr/jxr/3.1.1/jxr-3.1.1-source-release.zip Source release checksum(s): jxr-3.1.1-source-release.zip sha512: d7bdbedc72568192a9b63132a91852379ad542c606d222a87cf316e1cef8e60434c4b573b55d7e39c1159cb17728eb5ae5c1cb0922337bb5c06885805a36d76c Staging site: https://maven.apache.org/jxr-archives/jxr-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: Security/Versioning policy proposal
es as > long > > >> as it > > >> >> stays fairly forward drop-in compatible. > > >> >> > > >> >> Having said that, things like changing the policy for handling http > > >> might > > >> >> not be that drop-in, but on the other hand it’s just a config > option > > >> and > > >> >> does not require complicated (plugin) dependency updates. > > >> >> > > >> >> I do wonder if the version number should better reflect such > > >> incompatible > > >> >> requirement changes. (And if somebody really wants to provide > security > > >> >> fixes for those incompatible older branches why not, but I don’t > think > > >> you > > >> >> can require them from a project which does not offer them by > themself). > > >> >> > > >> >> > > >> >> -- > > >> >> http://bernd.eckenfels.net > > >> >> > > >> >> Von: Ralph Goers > > >> >> Gesendet: Sunday, April 4, 2021 9:55:50 PM > > >> >> An: Maven Developers List > > >> >> Betreff: Re: Security/Versioning policy proposal > > >> >> > > >> >> More than likely you will get whatever the next version number > happens > > >> to > > >> >> be. I can’t think of a case where Maven needed to go back and > patch a > > >> prior > > >> >> release. That could happen however, if Maven was modified to > require > > >> Java > > >> >> 11 to run and a security fix had to be applied to the last version > > >> >> supporting Java 8. > > >> >> > > >> >> Ralph > > >> >> > > >> >>> On Apr 4, 2021, at 6:25 AM, Romain Manni-Bucau > rmannibu...@gmail.com > > >> > > > >> >> wrote: > > >> >>> > > >> >>> Le dim. 4 avr. 2021 à 14:10, Robert Scholte > a > > >> >> écrit : > > >> >>> > > >> >>>> To me all releases can contain security fixes. > > >> >>>> Depending on the risk of the CVE we can decide to do a release > with > > >> only > > >> >>>> those fixes (see Maven 3.0.5 and 3.8.1) > > >> >>>> > > >> >>> > > >> >>> I get that but it does not help users to pick versions and to get > any > > >> >>> stability in their build - which is the goal of this thread. > > >> >>> Since you rejected a 3.6.4 for last CVE hitting us I have to > admit I > > >> >> have a > > >> >>> hard time to formalize it. > > >> >>> Best I come up is "we'll do what we want" which is hopefully just > a > > >> >>> complete misinterpretation of what you mean but hope shows how > > >> clueless I > > >> >>> am with such a statement at the moment. > > >> >>> Can you try to refine it please? > > >> >>> > > >> >>> Concretely, today I'm starting with a 3.8.1, what am I expecting > to > > >> use > > >> >> in > > >> >>> 5 years for this project trying to get security fixes and being > stable > > >> >> (ie > > >> >>> 4.x is assumed excluded?)? > > >> >>> > > >> >>> > > >> >>>> > > >> >>>> Robert > > >> >>>> > > >> >>>> On 4-4-2021 12:14:39, Romain Manni-Bucau > > >> wrote: > > >> >>>> Le dim. 4 avr. 2021 à 12:09, Robert Scholte a écrit : > > >> >>>> > > >> >>>>> I doubt we can or should make any promises, only intentions. > > >> >>>>> If we would have it, I wonder if it cover our choice to skip > 3.7.0. > > >> >>>>> To me we need to keep that flexibility. > > >> >>>>> > > >> >>>>> I want to reverse the approach: what could users expect as > > >> differences > > >> >>>>> between version x and y. > > >> >>>>> > > >> >>>>> For Maven shouldn't be more complex than: > > >
Re: [VOTE] Release Apache Maven JXR Plugin version 3.1.1
+1 On 18-4-2021 21:12:47, Robert Scholte wrote: Hi, We solved 12 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317527=12344185=Text There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317527%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1640/ https://repository.apache.org/content/repositories/maven-1640/org/apache/maven/jxr/jxr/3.1.1/jxr-3.1.1-source-release.zip Source release checksum(s): jxr-3.1.1-source-release.zip sha512: d7bdbedc72568192a9b63132a91852379ad542c606d222a87cf316e1cef8e60434c4b573b55d7e39c1159cb17728eb5ae5c1cb0922337bb5c06885805a36d76c Staging site: https://maven.apache.org/jxr-archives/jxr-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: [VOTE] Release Apache Maven JXR Plugin version 3.1.1
Hi Andreas, thanks for testing, I really appreciate it! Regarding the voting, every vote counts, maybe especially from users. Depending on the release manager, their negative votes might result in the cancelling of the release. A few years ago we decided to drop the word "binding" during the vote, because it doesn't motivate non-committers to verify a release. Instead we mention if there are enough PMC votes (for legal reasons). With that in mind, can I turn your message into a +1? thanks, Robert On 19-4-2021 14:39:42, Andreas Sewe wrote: Hi, > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. just a user of the maven-jxr-plugin and not a committer, but I wanted to let you know anyway that version 3.1.1 works fine for me, even if I cannot participate in the voting proper. So thanks for doing a release! Hope this helps. Andreas
[VOTE] Release Apache Maven JXR Plugin version 3.1.1
Hi, We solved 12 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317527=12344185=Text There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317527%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1640/ https://repository.apache.org/content/repositories/maven-1640/org/apache/maven/jxr/jxr/3.1.1/jxr-3.1.1-source-release.zip Source release checksum(s): jxr-3.1.1-source-release.zip sha512: d7bdbedc72568192a9b63132a91852379ad542c606d222a87cf316e1cef8e60434c4b573b55d7e39c1159cb17728eb5ae5c1cb0922337bb5c06885805a36d76c Staging site: https://maven.apache.org/jxr-archives/jxr-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
[ANN] Apache Maven ReleasePlugin 3.0.0-M4 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Release Plugin, version 3.0.0-M4 (NOTE: This version is still marked as milestone, because not all steps for a 3.0.0 have been finished. That includes removing Maven2 code and deprecated code plus completing some redesigns. However, it should be as stable as every previous release) This plugin is used to release a project with Maven, saving a lot of repetitive, manual work. Releasing a project is made in two steps: prepare and perform. https://maven.apache.org/maven-release/maven-release-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-release-plugin 3.0.0-M4 You can download the appropriate sources etc. from the download page: https://maven.apache.org/maven-release/download.html Release Notes - Maven Release Plugin - Version 3.0.0-M4 ** Bug * [MRELEASE-1016] - mvn release:branch fails on Windows to commit changed pom in branch * [MRELEASE-1042] - releaseProfiles get overriden by activeProfiles ** New Feature * [MRELEASE-1015] - Add tag signing support to prepare goal ** Improvement * [MRELEASE-1043] - make -sources.jar Reproducible * [MRELEASE-1062] - Require Java 8 Enjoy, -The Apache Maven team
