Re: java version for jlink plugin
yup it's only a cli generator/executor and this upgrade is not really mandatory. but it just doesn't make much sense for me to be java7 as the goal is to execute a cli which is only available >=9 :) On Wed, 19 Feb 2020 at 17:53, Romain Manni-Bucau wrote: > If upgrading helps I dont see how it could hurt but I see it as a process > executor so shouldnt be important, no? > > Le mer. 19 févr. 2020 à 08:39, Olivier Lamy a écrit : > > > Hi > > I was looking at jlink plugin and trying it. > > I'm using java11 and got issues because of this.. > > Easy fix is upgrading plexus-java version > > > > But I noticed java for jlink plugin is java7. > > As jlink has been released with java9 I wonder if this java7 minimum > really > > makes sense? > > > > cheers > > -- > > Olivier Lamy > > http://twitter.com/olamy | http://linkedin.com/in/olamy > > > -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: java version for jlink plugin
If upgrading helps I dont see how it could hurt but I see it as a process executor so shouldnt be important, no? Le mer. 19 févr. 2020 à 08:39, Olivier Lamy a écrit : > Hi > I was looking at jlink plugin and trying it. > I'm using java11 and got issues because of this.. > Easy fix is upgrading plexus-java version > > But I noticed java for jlink plugin is java7. > As jlink has been released with java9 I wonder if this java7 minimum really > makes sense? > > cheers > -- > Olivier Lamy > http://twitter.com/olamy | http://linkedin.com/in/olamy >
java version for jlink plugin
Hi I was looking at jlink plugin and trying it. I'm using java11 and got issues because of this.. Easy fix is upgrading plexus-java version But I noticed java for jlink plugin is java7. As jlink has been released with java9 I wonder if this java7 minimum really makes sense? cheers -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
[VOTE] Release Apache Maven Doxia Sitetools version 1.9.2
Hi, We solved 5 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317320=12345961=Text Staging repo: https://repository.apache.org/content/repositories/maven-1552/ https://repository.apache.org/content/repositories/maven-1552/org/apache/maven/doxia/doxia-sitetools/1.9.2/doxia-sitetools-1.9.2-source-release.zip Source release checksum(s): doxia-sitetools-1.9.2-source-release.zip sha512: 23ad72b6e7f1830aa70c5844a06a64960412ed1c6ef22bb377d735323605469c100c44c370f4bf883647bc4411b1a033386dfe6771596ecde2c3f4a1b328b2a3 Staging site: https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-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 Wrapper
All done. All note with pointers to both project readme files, closed all issues and closed all PRs. Hopefully further input and help will show up here now. Manfred Robert Scholte wrote on 2020-02-18 10:56 (GMT -08:00): > sure, go ahead > On 18-2-2020 19:47:29, Manfred Moser wrote: > Okay .. so then I think I should update the Takari repos with a note about > that > and send any contributors to the Maven dev list NOW. I think this has the > potential to drive some more help in this effort. > > If you agree I can do that tonight .. > > manfred > > Robert Scholte wrote on 2020-02-18 10:40 (GMT -08:00): > >> This will be part of 3.7.0 together with other huge changes. >> Having the wrapper makes it possible to start updating the defaults for our >> Maven plugins. >> I don't expect a release soon and I don't see a reason to hurry that. >> We've done 3.6.2 and a 3.6.3 regression release to give us time to work on >> 3.7.0. >> >> Robert >> On 18-2-2020 18:50:01, Manfred Moser wrote: >> Agreed... if you think now is a good time, I am happy to update the Takari >> repos with a redirect to the maven dev list and the sandbox repo for now. >> >> I plan to close all issues and all PR and declare the project inactive and >> moved to Apache Maven upstream. Just not sure what the best timing for that >> is. >> >> And in terms of getting the scripts in a separate repo or Maven core ... I >> see >> good reasons for both and dont really have a preference. I just would love to >> get it moved and into main Maven as soon as possible. >> >> Would we cut 3.6.4 when the wrapper is done in core? >> >> Manfred >> >> Robert Scholte wrote on 2020-02-16 04:13 (GMT -08:00): >> >>> I want to prevent legal issues, so I won't pick up PRs from that repository. >>> Once the Maven Wrapper has it's final location, one can provide new PRs on >>> our >>> codebase. >>> >>> Robert >>> On 16-2-2020 12:56:55, James Gao wrote: >>> On Sun, Feb 16, 2020 at 5:50 PM Robert Scholte wrote: >>> I've found another reason to move it to core: the mvnw scripts are extended versions of the mvn scripts. If you do a diff, you'll recognize a block responsible for downloading the wrapper jar. But you also notice that all recent improvements on the mvn scripts have not been adopted. If you use the mvnw for Maven x.y.z, it should behalve as calling mvn of Maven x.y.z, now it doesn't. >>> >>> Hi Robert, there is a PR to >>> integrate the new boot behavior from maven core to the original wrapper. >>> >> >> - >> 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
[RESULT] [VOTE] Release Apache Maven Doxia version 1.9.1
Hi, The vote has passed with the following result: +1 : Sylwester Lachiewicz, Michael Osipov, Olivier Lamy, Tibor Digana, Hervé Boutemy PMC quorum reached I will promote the artifacts to the central repo. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Wrapper
sure, go ahead On 18-2-2020 19:47:29, Manfred Moser wrote: Okay .. so then I think I should update the Takari repos with a note about that and send any contributors to the Maven dev list NOW. I think this has the potential to drive some more help in this effort. If you agree I can do that tonight .. manfred Robert Scholte wrote on 2020-02-18 10:40 (GMT -08:00): > This will be part of 3.7.0 together with other huge changes. > Having the wrapper makes it possible to start updating the defaults for our > Maven plugins. > I don't expect a release soon and I don't see a reason to hurry that. > We've done 3.6.2 and a 3.6.3 regression release to give us time to work on > 3.7.0. > > Robert > On 18-2-2020 18:50:01, Manfred Moser wrote: > Agreed... if you think now is a good time, I am happy to update the Takari > repos with a redirect to the maven dev list and the sandbox repo for now. > > I plan to close all issues and all PR and declare the project inactive and > moved to Apache Maven upstream. Just not sure what the best timing for that > is. > > And in terms of getting the scripts in a separate repo or Maven core ... I see > good reasons for both and dont really have a preference. I just would love to > get it moved and into main Maven as soon as possible. > > Would we cut 3.6.4 when the wrapper is done in core? > > Manfred > > Robert Scholte wrote on 2020-02-16 04:13 (GMT -08:00): > >> I want to prevent legal issues, so I won't pick up PRs from that repository. >> Once the Maven Wrapper has it's final location, one can provide new PRs on >> our >> codebase. >> >> Robert >> On 16-2-2020 12:56:55, James Gao wrote: >> On Sun, Feb 16, 2020 at 5:50 PM Robert Scholte wrote: >> >>> I've found another reason to move it to core: the mvnw scripts are >>> extended versions of the mvn scripts. >>> If you do a diff, you'll recognize a block responsible for downloading the >>> wrapper jar. >>> But you also notice that all recent improvements on the mvn scripts have >>> not been adopted. >>> If you use the mvnw for Maven x.y.z, it should behalve as calling mvn of >>> Maven x.y.z, now it doesn't. >>> >> >> Hi Robert, there is a PR to >> integrate the new boot behavior from maven core to the original wrapper. >> > > - > 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 Wrapper
I've created MWRAPPER in Jira[1] so please register those wishes there. Be aware that the wrapper already exists and that a buildtoold like Maven is already about downloading and executing. The community is asking for the wrapper because they like that feature in tools like Gradle. I understand your comment, but the added mvnw scripts can already be changed by the maintainers its project. It should be possible to check files at a certain level, but once these scripts are added to any project it is out of our hands. Robert [1] https://issues.apache.org/jira/projects/MWRAPPER/ On 18-2-2020 18:58:02, Vladimir Sitnikov wrote: Robert>Once the Maven Wrapper has it's final location, one can provide new PRs on our codebase Do you think Wrapper script should verify the integrity of the downloaded file? AFAIK the current implementation just downloads a file and executes it. Executing random files from the internet does not sound like a nice idea. Vladimir
Re: Maven Wrapper
Okay .. so then I think I should update the Takari repos with a note about that and send any contributors to the Maven dev list NOW. I think this has the potential to drive some more help in this effort. If you agree I can do that tonight .. manfred Robert Scholte wrote on 2020-02-18 10:40 (GMT -08:00): > This will be part of 3.7.0 together with other huge changes. > Having the wrapper makes it possible to start updating the defaults for our > Maven plugins. > I don't expect a release soon and I don't see a reason to hurry that. > We've done 3.6.2 and a 3.6.3 regression release to give us time to work on > 3.7.0. > > Robert > On 18-2-2020 18:50:01, Manfred Moser wrote: > Agreed... if you think now is a good time, I am happy to update the Takari > repos with a redirect to the maven dev list and the sandbox repo for now. > > I plan to close all issues and all PR and declare the project inactive and > moved to Apache Maven upstream. Just not sure what the best timing for that > is. > > And in terms of getting the scripts in a separate repo or Maven core ... I see > good reasons for both and dont really have a preference. I just would love to > get it moved and into main Maven as soon as possible. > > Would we cut 3.6.4 when the wrapper is done in core? > > Manfred > > Robert Scholte wrote on 2020-02-16 04:13 (GMT -08:00): > >> I want to prevent legal issues, so I won't pick up PRs from that repository. >> Once the Maven Wrapper has it's final location, one can provide new PRs on >> our >> codebase. >> >> Robert >> On 16-2-2020 12:56:55, James Gao wrote: >> On Sun, Feb 16, 2020 at 5:50 PM Robert Scholte wrote: >> >>> I've found another reason to move it to core: the mvnw scripts are >>> extended versions of the mvn scripts. >>> If you do a diff, you'll recognize a block responsible for downloading the >>> wrapper jar. >>> But you also notice that all recent improvements on the mvn scripts have >>> not been adopted. >>> If you use the mvnw for Maven x.y.z, it should behalve as calling mvn of >>> Maven x.y.z, now it doesn't. >>> >> >> Hi Robert, there is a PR to >> integrate the new boot behavior from maven core to the original wrapper. >> > > - > 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 Wrapper
This will be part of 3.7.0 together with other huge changes. Having the wrapper makes it possible to start updating the defaults for our Maven plugins. I don't expect a release soon and I don't see a reason to hurry that. We've done 3.6.2 and a 3.6.3 regression release to give us time to work on 3.7.0. Robert On 18-2-2020 18:50:01, Manfred Moser wrote: Agreed... if you think now is a good time, I am happy to update the Takari repos with a redirect to the maven dev list and the sandbox repo for now. I plan to close all issues and all PR and declare the project inactive and moved to Apache Maven upstream. Just not sure what the best timing for that is. And in terms of getting the scripts in a separate repo or Maven core ... I see good reasons for both and dont really have a preference. I just would love to get it moved and into main Maven as soon as possible. Would we cut 3.6.4 when the wrapper is done in core? Manfred Robert Scholte wrote on 2020-02-16 04:13 (GMT -08:00): > I want to prevent legal issues, so I won't pick up PRs from that repository. > Once the Maven Wrapper has it's final location, one can provide new PRs on our > codebase. > > Robert > On 16-2-2020 12:56:55, James Gao wrote: > On Sun, Feb 16, 2020 at 5:50 PM Robert Scholte wrote: > >> I've found another reason to move it to core: the mvnw scripts are >> extended versions of the mvn scripts. >> If you do a diff, you'll recognize a block responsible for downloading the >> wrapper jar. >> But you also notice that all recent improvements on the mvn scripts have >> not been adopted. >> If you use the mvnw for Maven x.y.z, it should behalve as calling mvn of >> Maven x.y.z, now it doesn't. >> > > Hi Robert, there is a PR to > integrate the new boot behavior from maven core to the original wrapper. > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Wrapper
Robert>Once the Maven Wrapper has it's final location, one can provide new PRs on our codebase Do you think Wrapper script should verify the integrity of the downloaded file? AFAIK the current implementation just downloads a file and executes it. Executing random files from the internet does not sound like a nice idea. Vladimir
Re: Maven Wrapper
Agreed... if you think now is a good time, I am happy to update the Takari repos with a redirect to the maven dev list and the sandbox repo for now. I plan to close all issues and all PR and declare the project inactive and moved to Apache Maven upstream. Just not sure what the best timing for that is. And in terms of getting the scripts in a separate repo or Maven core ... I see good reasons for both and dont really have a preference. I just would love to get it moved and into main Maven as soon as possible. Would we cut 3.6.4 when the wrapper is done in core? Manfred Robert Scholte wrote on 2020-02-16 04:13 (GMT -08:00): > I want to prevent legal issues, so I won't pick up PRs from that repository. > Once the Maven Wrapper has it's final location, one can provide new PRs on our > codebase. > > Robert > On 16-2-2020 12:56:55, James Gao wrote: > On Sun, Feb 16, 2020 at 5:50 PM Robert Scholte wrote: > >> I've found another reason to move it to core: the mvnw scripts are >> extended versions of the mvn scripts. >> If you do a diff, you'll recognize a block responsible for downloading the >> wrapper jar. >> But you also notice that all recent improvements on the mvn scripts have >> not been adopted. >> If you use the mvnw for Maven x.y.z, it should behalve as calling mvn of >> Maven x.y.z, now it doesn't. >> > > Hi Robert, there is a PR to > integrate the new boot behavior from maven core to the original wrapper. > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [maven-dependency-plugin] Proposal: Additional parameter to order tree output
Would this simply affect the output of what's shown to the user by maven dependency:tree or would it also affect the order of resolution for compile, exec:java, and everything else? On Mon, Feb 17, 2020 at 3:28 PM Loïc Le Doyen wrote: > > Hello @dev team ! > > Being a frequent user of the *maven-dependency-plugin*, I often lack the > possibility to order the output of the *tree* goal to compare effective > trees when refactoring POM files. > > So, following the same idea of comparing trees, it could be also > interesting to be able to output in a computer-friendly language such as > XML or JSON. > > I will be happy to supply PR, if this is something that the Maven community > is interested in. > > Best regards, > > Loïc Ledoyen -- 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
