Re: Publish Maven releases on SDKMAN!

I've started using SDKMAN a couple of months ago and while it's fairly easy to install maven by downloading the zip/tgz there are still some manual steps involved. Using sdkman makes it simpler and removes the manual steps. I don't quite understand the resistance against supporting it. It is a

Re: Publish Maven releases on SDKMAN!

Yeah, all I see is a silly name and no compelling reason to look further. Why should I look at it and how does it make life better? Seen it mentioned at conferences but just as another way to install something already super simple to install. So what is compelling about it? cheers On Sat, Apr

Re: Publish Maven releases on SDKMAN!

So by sell, I meant an idea too. I'm forever trying to sell things I think are best, but am not going to make money from. Can you link to the conversations about the lack of Maven in SDKMAN-land? Did you understand what I was getting at in my last mail? You didn't address them, which is your

Re: Publish Maven releases on SDKMAN!

Paul, I really am not trying to sell anything. I'm trying to help your community. You will get no *arguments* in favour or against from me. My users keep asking for Maven on SDKMAN, and I sincerely wish to give them what they ask for. Whether the community is willing to lend a hand is entirely

Re: Publish Maven releases on SDKMAN!

Marco, You could sell your idea better, I think. You have "Most of the big projects want to do this" as one of the stronger arguments in favor, which isn't enough. For 20 years, Lean/Agilistas have focussed on "what is the problem you're trying to solve?". And that is the question, I personally*

Re: Publish Maven releases on SDKMAN!

Prior conversation - https://www.mail-archive.com/search?q=Vermeulen=dev%40maven.apache.org On Sat, Apr 15, 2017 at 6:56 PM, Marco Vermeulen wrote: > Hi Maven folks, > > Some time ago I asked the Maven dev community whether they would be willing > to publish their

Publish Maven releases on SDKMAN!

Hi Maven folks, Some time ago I asked the Maven dev community whether they would be willing to publish their releases on SDKMAN! [1] using our Vendor API [2]. Unfortunately, my request was met with scepticism and ultimately resulted in no action taken. I would like to appeal to the Maven dev

[GitHub] maven-scm pull request #53: [SCM-707] Git : spaces in username / password in...

Github user asfgit closed the pull request at: https://github.com/apache/maven-scm/pull/53 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

[GitHub] maven-scm pull request #53: [SCM-707] Git : spaces in username / password in...

GitHub user gfouquet opened a pull request: https://github.com/apache/maven-scm/pull/53 [SCM-707] Git : spaces in username / password in URL should be encode… …d as '%20' instead of '+' [SCM-707](https://issues.apache.org/jira/browse/SCM-707) implementation for git (in

Re: svn commit: r1791488 - /maven/plugins/trunk/maven-jar-plugin/src/main/filtered-resources/META-INF/plexus/components.xml

I would have reopened MJAR-235, because effectively there's no change. But that's a matter of taste. It's fine like this, Robert On Sat, 15 Apr 2017 13:04:41 +0200, Karl Heinz Marbaise wrote: Hi, On 15/04/17 13:02, Robert Scholte wrote: Thanks, not sure if this is

Re: svn commit: r1791488 - /maven/plugins/trunk/maven-jar-plugin/src/main/filtered-resources/META-INF/plexus/components.xml

Hi, On 15/04/17 13:02, Robert Scholte wrote: Thanks, not sure if this is worth a separate jira-issue, because IMHO it will pollute the release notes a bit. But that's another topic. But it makes clear why this change has been made and the detailed explanation... Kind regards Karl Heinz

Re: svn commit: r1791488 - /maven/plugins/trunk/maven-jar-plugin/src/main/filtered-resources/META-INF/plexus/components.xml

Thanks, not sure if this is worth a separate jira-issue, because IMHO it will pollute the release notes a bit. But that's another topic. Robert On Sat, 15 Apr 2017 12:58:25 +0200, Karl Heinz Marbaise wrote: Hi Robert, Done. See MJAR-236.. Kind regards Karl Heinz

Re: svn commit: r1791488 - /maven/plugins/trunk/maven-jar-plugin/src/main/filtered-resources/META-INF/plexus/components.xml

Hi Robert, Done. See MJAR-236.. Kind regards Karl Heinz On 15/04/17 12:44, Robert Scholte wrote: Hi Karl Heinz, I'd prefer to leave maven-compiler-plugin on 3.5.1 as default. The 3.6.x have Java 9 features which are not optimal yet. E.g. in some circumstances we should warn the developer

Re: New branch SUREFIRE-1363 to prove

>>still have Windows line endings I will refactor these two classes to UNIX line ending. Thx for pointing out this. >>I am confused why the entire system uses two different character encodings UTF-8/US-ASCII and ISO-8859-1 Class names are encoded in ASCII in byte code [1]. Right, this should not

Re: svn commit: r1791488 - /maven/plugins/trunk/maven-jar-plugin/src/main/filtered-resources/META-INF/plexus/components.xml

Hi Robert, On 15/04/17 12:44, Robert Scholte wrote: Hi Karl Heinz, I'd prefer to leave maven-compiler-plugin on 3.5.1 as default. The 3.6.x have Java 9 features which are not optimal yet. E.g. in some circumstances we should warn the developer about automodules. If this version becomes the

Re: svn commit: r1791488 - /maven/plugins/trunk/maven-jar-plugin/src/main/filtered-resources/META-INF/plexus/components.xml

Hi Karl Heinz, I'd prefer to leave maven-compiler-plugin on 3.5.1 as default. The 3.6.x have Java 9 features which are not optimal yet. E.g. in some circumstances we should warn the developer about automodules. If this version becomes the default, it is more likely to have issues with our

Re: New branch SUREFIRE-1363 to prove

Am 2017-04-15 um 03:55 schrieb Tibor Digana: Hi, I have one branch [1] for approval, SUREFIRE-1363. Currently finished the local build successfully. [1] https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=c47c6bbaf857c71a23f0623b552c0e7b7ab28b4c The changes are only about