Re: [VOTE] Release Apache Maven Wrapper 3.3.2

Looks good! +1 On 2024-05-21 8:17 a.m., Tamás Cservenák wrote: Howdy, We solved 6 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721=12354608 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/projects/MWRAPPER/issues Staging repo:

Re: Quo Vadis Maven?

Awesome work everyone. It is great to see all the progress Maven and related tooling is making. Manfred On 2024-04-23 2:12 p.m., Tamás Cservenák wrote: Howdy, This is just a short newsflash about upcoming planned releases related to Maven. Recently we got a huge spike in plugin releases,

Re: [VOTE] Require Java 17 for Maven 4

+100 (committer) For build and runtime and source code level. Also +100 for later upgrade to 21 ;-) On 2024-02-27 23:30, Benjamin Marwell wrote: Hi Maven Devs/Users/Committers and PMC members! After several discussions on the mailing lists, I would like to start a vote in favour of setting

Re: [DISCUSS] Java version for Maven

Given that it will still be quite a while until Maven 4 comes out and we are probably going to stick to the same Java version for Maven 4 until we move to 5, I would strongly suggest to go with Java 21. There are a lot of further performance and other improvements from 17 to 21. Also from our

Re: Java version for Maven 4?

I agree with observations ... in the Trino project we switched to require Java 17 ages ago and now switched to 21 for the project itself. The language improvements to 17 and then to 21 allow for a lot of code improvements on the source level. As a build tool that supports building other

Re: Question - JDK Minimum of future Apache Maven 4.0.0

I have to strongly disagree. If Maven wants to remain relevant it needs to be using a relatively modern JDK and language that is available to open source developers and interesting to work on. Nobody wants to work on Java 8 code. Ultimately the committers and project maintainers can vote and

Re: Question - JDK Minimum of future Apache Maven 4.0.0

+1 Totally also agree with upping to Java 17. Working mostly on Trino these days and we have been on 17 for quite a while and are getting ready to go to 21 soon after it hits. In my opinion Maven should do the same. There should be no reason not to support and also default to the latest LTS.

Re: [ANN] Release Apache Maven Surefire 3.0.0

Massive congratulations! I am so glad we got beyond the milestones finally. Manfred On 2023-03-14 03:11, Slawomir Jaranowski wrote: Hi The Apache Maven team is pleased to announce the availability of Maven Surefire 3.0.0 Release Notes - Maven Surefire - Version 3.0.0 ** Bug *

Re: [DISCUSS] Speed up release process?

+1 That sounds good to me. There is plenty of communication going on BEFORE the release is even kicked off.. from then on it really should be just process and minimal validation. If something goes wrong.. run another patch release. I would even go for .. lazy consensus after 48 hours counts

Re: [DISCUSS] Quo Vadis Maven Site

There are a couple of things I would like to mention: * the current output format of HTML is immediately usable, which is great * any other format (md, asciidoc) is NOT and requires more tools to make them consumable * reporting into an additional format like asciidoc will require some post

Re: Maven search for a class or method on classpath - how?

This might not help .. but your IDE will allow you to do that.. On the command line you might have to do a dependency:tree or dependency:list and then dependency:list-classes ... Or you could fork the plugin to create a new goal that basically does the two in one go on the code level.. and

Re: [ANN] Apache Maven Wrapper 3.1.1 Released

Awesome work everyone. I am glad this made it to the users from Apache now. Manfred Hervé Boutemy wrote on 2022-05-14 07:06 (GMT -07:00): > The Apache Maven team is pleased to announce the release of the Apache Maven > Wrapper, version 3.1.1. > > The Maven Wrapper is an easy way to ensure a

Re: We need to lay down strategy

I could not agree more. It is extremely important for users to understand that we are NOT a commercial entity providing support. And contrary to other open source products there is large, well known commercial entity either. I also second all the other points from Tamas. Manfred Tamás

Re: [VOTE] Release Apache Maven Wrapper version 3.1.0

ager does not proxy > staging repos. > > Can build from tag, generate the wrapper files, and run mvnw on some other > host, it will fail if I use the staging RC, but I can pull > maven-wrapper.jar from snapshot > > Thanks > > -D > > On Mon, Dec 13, 2021 at 1:12 PM Manfre

Re: [VOTE] Release Apache Maven Wrapper version 3.1.0

Awesome. Thank you Herve. + 100 Hervé BOUTEMY wrote on 2021-12-13 13:09 (GMT -08:00): > Hi, > > We solved 18 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721=12350068=Text > > Staging repo: > https://repository.apache.org/content/repositories/maven-1679/ >

Re: reviewing Maven Wrapper before releasing

e 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.

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

Re: Moving away from Modello

I agree with a lot of what has been said towards keeping modello in use. There is really no existing drop-in alternative. The benefits of moving off Modello are mostly unknown until we actually do the work. And in the end it should be mostly internal refactoring. However that work is a very

Re: [DISCUSS] Allow attributes shorthand in pom.xml

You can use polyglot-maven for a compatible approach for your own pom files right now.. https://github.com/takari/polyglot-maven/tree/master/polyglot-xml Manfred Will Iverson wrote on 2020-12-11 14:40 (GMT -08:00): > One of the biggest complaints about Maven has long been the verbosity of

Re: Speed of Maven build

Mickael Istria wrote on 2020-08-25 14:17 (GMT -07:00): > I > > On Tuesday, August 25, 2020, Manfred Moser wrote: >> And the VS code integration from Red Hat might also do something along > those lines. > > It embeds and uses m2eclipse. > Haha.. thank

Re: Speed of Maven build

Also the M2Eclipse integration does basically embed maven and make the Maven build incremental. The Takari plugin does that on the commandline with the eclipse compiler And the VS code integration from Red Hat might also do something along those lines. Others can chime in with more details.

Re: Your project website

di 20 août 2020, 11:21:56 CEST Gavin McDonald a écrit : >> I think you guys are fine and there is nothing to do. We still have some >> Maven configs in our CMS system but looks like you have not used it since >> 2018. >> >> I'll go ahead and remove your old CMS content a

Re: Your project website

Also ... from a technical standpoint the Maven site is just a bunch of static html files and I think some server side includes. We might have to fix those to be different depending on whatever we migrate to .. with that in mind.. What are our options within the Apache infrastructure or outside?

Re: Fwd: Your project website

I am not sure but I think that SVN commit is a backend for the CMS .. Olivier Lamy wrote on 2020-08-19 00:06 (GMT -07:00): > Hi > I'm not sure if we use CMS. > I don't think so AFAIK to publish website content we only commit to a svn > repo. > Am I missing something? > > cheers > Olivier > >

Re: second apache-maven-wrapper

Awesome! +1 Robert Scholte wrote on 2020-05-22 13:36 (GMT -07:00): > I've reached the point where apache-maven-wrapper is ready to be merged into > master. > The code contains all original commits and a few from me to get them step by > step into core. > > Related tickets: >

Re: APIs for reading Maven repositories

Elliotte Rusty Harold wrote on 2020-05-04 07:02 (GMT -07:00): > 2. Is it possible to boostrap the resolver without using the internal > class MavenRepositorySystemUtils? > > https://issues.apache.org/jira/browse/MNG-6579 > I am using the resolver in my Maven Repository Provisioner and

Re: Proposal to deprecate Maven 3.0.x

ven-resolver has exactly the same API as Eclipse Aether >> > (in >> > > > > org.eclipse.aether java package) but just a change in Maven >> > coordinates >> > > > > (that are all filtered by Maven core class loading, then not really >> > an >> &

Re: Proposal to deprecate Maven 3.0.x

All features are already in Maven Resolver .. We should deprecate everything before 3.5.0 imho Or if really necessary everything before 3.2.5 Gabriel Belingueres wrote on 2020-04-16 17:35 (GMT -07:00): > +1 to deprecate 3.0.x to get rid of Sonatype Aether, which would > considerably simplify

Re: Proposal to deprecate Maven 3.0.x

+100 I would deprecate everything before the maven-resolver import back to the project while you are at it. Not sure exact version but 3.1x would definitely on that list as well. Maybe also 3.2x Manfred Tibor Digana wrote on 2020-04-15 13:39 (GMT -07:00): > Some users still use Maven 3.0.5

Re: .checkstyle

I agree with adding it to .gitignore Elliotte Rusty Harold wrote on 2020-03-03 04:07 (GMT -08:00): > There's content in it but it's autogenerated as a consequence of > building the project. It's not hand edited. > > On Tue, Mar 3, 2020 at 3:24 AM Maarten Mulders wrote: >> >> It depends a

Re: Maven Repository Security issues: any war stories?

The order of repositories in a pom, settings and repo manager is crucial. Some companies use their own repos on top since they trust them the most. I have seen internal teams deploying patched version into those which then essentially override the real dep from central. This is a feature and

Re: Maven GroupID authority

Anything that goes to Central is immutable .. so no edits or updates or whatever. Make sure you keep that in mind Manfred Jonathan Valliere wrote on 2020-02-20 09:50 (GMT -08:00): > Just indicate a date in the pom at which point the relocation warning turns > into a relocation error. date.

Re: Maven Wrapper

PM > An: dev@maven.apache.org > Betreff: Re: Maven Wrapper > > I will write several integration tests matching these use cases. > Based on that we can decide what to do. > > Robert > > On 19-2-2020 21:04:51, Manfred Moser wrote: > There are kinda three main use cases th

Re: Maven Wrapper

That sounds good. Robert Scholte wrote on 2020-02-19 12:50 (GMT -08:00): > I will write several integration tests matching these use cases. > Based on that we can decide what to do. > > Robert > > On 19-2-2020 21:04:51, Manfred Moser wrote: > There are kinda three mai

Re: Maven Wrapper

es. > > I would like to understand the need for every class, otherwise remove it, > especially if we start over with a clean codebase. > Do you see a risk? > > Robert > > On 19-2-2020 06:19:54, Manfred Moser wrote: > All done. All note with pointers to both project read

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:

Re: Maven Wrapper

ression 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

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

Re: Maven GroupID authority

>From what I know it is no taken into account by the resolver. Elliotte Rusty Harold wrote on 2020-02-14 14:25 (GMT -08:00): > On Fri, Feb 14, 2020 at 5:12 PM Hervé BOUTEMY wrote: >> >> Le vendredi 14 février 2020, 14:11:07 CET Elliotte Rusty Harold a écrit : >> > Changing group IDs of

Re: Maven GroupID authority

dependency in the same classpath, is only going to become > impossible with Java Modules. > > Maven is at an optimal position within the community to prevent module > naming from going haywire and becoming useless. I believe these two issues > are intrinsically linked. > > O

Re: Maven GroupID authority

ovide symlinks for backwards compatibility for a limited period of > time (1 year) > - Update Maven clients to provide warnings for symlinks during > builds/tests/etc > > > On Thu, Feb 13, 2020 at 10:23 PM Manfred Moser > <mailto:manf...@simpligility.com> >

Re: Maven GroupID authority

compliance > - Provide symlinks for backwards compatibility for a limited period of > time (1 year) > - Update Maven clients to provide warnings for symlinks during > builds/tests/etc > > > On Thu, Feb 13, 2020 at 10:23 PM Manfred Moser > wrote: > >> This is

Re: Maven GroupID authority

This is a left over from bad choices made decades ago. Now Maven Central has well documented criteria ... very contrary to nearly all other binary repos.. https://central.sonatype.org/pages/ossrh-guide.html https://central.sonatype.org/pages/requirements.html#correct-coordinates And the

Re: Maven Wrapper

Chris, IANAL but I dont think we can make such a claim ... even though there is not much to the code and scripts ... its still an Apache project and code of it.. Manfred Christofer Dutz wrote on 2020-02-12 22:29 (GMT -08:00): > Hi all, > > would it also be possible for some sort of official

Re: Maven Wrapper

I have maintained the wrapper in a separate repo the last couple of years. In my opinion the wrapper should automatically default to the latest release of Maven, but allow configuration to use older versions. Of course that comes with the usual claim that there is no such thing as support for

Re: Version poll results

> —Matt > — > Open Source Technologies @  > > > On Jan 7, 2020, at 1:29 PM, Manfred Moser wrote: > > To be honest I dont think this needs fixing on the Maven side. If we change > behavior we just break other approaches. > > Instead users that want to use semv

Re: Version poll results

Elliotte Rusty Harold wrote on 2020-01-07 13:38 (GMT -08:00): > On Tue, Jan 7, 2020 at 4:00 PM Clemens Quoss wrote: >> >> artifactId-version-classifier.jar >> >> How do i separate the classifier? >> > > If all you have is the name of the jar, I don't think you can. You > need the repo metadata

Re: Version poll results

To be honest I dont think this needs fixing on the Maven side. If we change behavior we just break other approaches. Instead users that want to use semver with three digits and want logic ordering should just do so. So do NOT use a version like 2.1 .. instead use 2.1.0. Problem solved. Also

Re: Defining EoL for Older Maven Versions

Chiming in late since I remember we discussed this before. Here is my view. All releases beyond the most recent one are essentially end of lifed. We never backport, we have no explicit support and whenever we fix something it goes into the next release. That is what we concluded last time

New Maven wrapper release

I just release a new version which now default to use Maven 3.6.3. Update your projects with mvn -N io.takari:maven:0.7.7:wrapper and enjoy. More info at https://github.com/takari/maven-wrapper Manfred - To unsubscribe,

Re: [VOTE] Release Apache Maven version 3.6.3

+1 works for polyglot-maven, maven-wrapper and a whole bunch of other projects of various sizes and complexity. Manfred Robert Scholte wrote on 2019-11-21 12:06 (GMT -08:00): > Hi, > > This will be a regression release based on some critical issues discovered in > Maven 3.6.2 > > We solved

Re: [VOTE] Release Apache Wagon version 3.3.4

Why? jsoup is MIT licensed which is compatible with Apache V2. Manfred Vladimir Sitnikov wrote on 2019-11-05 11:10 (GMT -08:00): >> Staging repo: >> https://repository.apache.org/content/repositories/maven-1535/ > > -1 since >

Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

+1 or more ... haha Manfred Stephen Connolly wrote on 2019-10-29 16:23 (GMT -07:00): > +1 > > On Tue 29 Oct 2019 at 20:11, Karl Heinz Marbaise wrote: > >> Hi to all, >> >> based on the discusion this is the formal VOTE to lift the minimum of >> Maven Core with version 3.7.0 to JDK 8

Re: Kotlin pom

wrote on 2019-06-08 07:52: > If polyglot was included directly in Maven dist, we could run the build > with something like this: > $ mvn -f pom.kts install > > Any thoughts? > > On Sat, Jun 8, 2019 at 1:55 AM Manfred Moser > wrote: > >> Shipped 0.4.1 of polyglo

Kotlin pom

Shipped 0.4.1 of polyglot-maven with more kotlin goodness ;-) https://www.simpligility.com/2019/06/kotlin-improvements-for-polyglot-maven/ Enjoy Manfred - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For

Re: [VOTE] Retire Maven Ant Plugin

Somewhere between +5 and +10 ;-) Robert Scholte wrote on 2019-05-28 11:54: > Hi, > > The Apache Maven project consist of about 100 (sub)projects. Due to the small > number of volunteers and the huge amount of code to maintain we're missing > enough space to make real progress on all these

Re: [VOTE] Retire Maven Runtime library

+1 .. definitely about time ;-) Robert Scholte wrote on 2019-05-15 13:33: > Hi, >   > The Apache Maven project consist of about 100 (sub)projects. Due to the small > number of volunteers and the huge amount of code to maintain we're missing > enough space to make real progress on all these

Re: [VOTE] Retire Maven Repository Plugin

+1 Robert Scholte wrote on 2019-04-23 12:43: > Hi, > > The Apache Maven project consist of about 100 (sub)projects. Due to the small > number of volunteers and the huge amount of code to maintain we're missing > enough space to make real progress on all these projects, including > our ambitious

Maven Wrapper updated to Apache Maven Version 3.6.1

I just cut a new release of maven wrapper and the plugin for installing it. It now defaults to the shiny new 3.6.1 Enjoy manfred Karl Heinz Marbaise wrote on 2019-04-13 03:03: > The Apache Maven team is pleased to announce the release of the Apache > Maven 3.6.1. > > Apache Maven is a

Re: Accessing a maven repository programatically (in 2019)

Michael, Have a look at my Maven Repository Provisioner codebase. It does exactly what you want and also includes dependencies and upload to a repo manager. It now uses the Maven Resolver in the latest version so its up to date.. https://github.com/simpligility/maven-repository-tools

Kotlin for your pom

Hi all, Just a quick heads up that the new polyglot-maven release I cut recently features a MUCH improved support for Kotlin. So with the help of polyglot-maven you can write your pom in yaml, ruby, scala, kotlin and a bunch of other formats now. Check it out and send us any feedback ...

Recent Maven Wrapper releases

Hi all, Just wanted to give you a heads up about the recent Maven wrapper and plugin releases. https://www.simpligility.com/2019/03/recent-maven-wrapper-updates/ Some pretty nice features worth checking out imho. Go update your projects to this latest version! Manfred

Re: Enable Travis on Maven Scripting Plugin

Fair enough. If its just for outside contributor PRs I am agree with not owning the risk ;-) Stephen Connolly wrote on 2019-01-04 16:06: > On Fri 4 Jan 2019 at 22:00, Tibor Digana wrote: > >> @Stephen Connolly >> After such a big investment, especially made on your side, in Jenkins >>

Re: Enable Travis on Maven Scripting Plugin

I agree with Tibor. I would rather not have to deal with two different CI systems... Manfred Tibor Digana wrote on 2019-01-04 14:00: > @Stephen Connolly > After such a big investment, especially made on your side, in Jenkins > plugin you developed you do not want to support the GitHub PRs and

Re: [VOTE] Release Apache Maven 3.6.0

Used it every day since this email for a bunch of different projects of varying complexity and everything is working fine. +1 Manfred Karl Heinz Marbaise wrote on 2018-10-24 12:50: > Hi, > > We have solved 26 issues: >

Re: [VOTE] Release Apache Maven 3.5.4

Tried on a bunch of small to largish projects. All good +1 Stephen Connolly wrote on 2018-06-17 13:44: > Hi, > > We solved 16 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12342826=Text=12316922 > > There are 356 issues left in JIRA for Maven core: >

Re: Welcome Christian Stein to the Apache Maven Team

Great to have you on the team Christian. Looking forward to see your contributions. Manfred Robert Scholte wrote on 2018-05-07 15:01: > Hi, > > On behalf of the Apache Maven PMC I am pleased to announce that Christian > Stein (sor) has been voted in as a new Apache Maven committer. > >

Re: [VOTE] Release Apache Maven 3.5.3

agreed +1 again ;-) Olivier Lamy wrote on 2018-03-02 18:14: > +1 to release as is > > On 3 March 2018 at 05:55, wrote: > >> the issue is a multi-threading issue on Windows Jansi, then this affects >> people on Windows who try to use parallel build. >> >> I can commit

Re: [VOTE] Release Apache Maven 3.5.3

Used on a bunch of project for a couple of days now without problems. +1 Manfred Stephen Connolly wrote on 2018-02-24 16:00: > Hi, > > We solved 22 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12341428=Text=12316922 > > There are 381 issues left in JIRA for Maven

Re: seconders for Maven 3.5.x

Seconding with +2 ;-) Olivier Lamy wrote on 2018-02-07 17:18: > +1 > > On 8 February 2018 at 00:09, Hervé BOUTEMY wrote: > >> Hi, >> >> I need seconders for: >> >> http://git-wip-us.apache.org/repos/asf/maven/commit/7fed4792 >> [MNG-5992] Upgrade default version

Re: Plan for releasing Maven core

As a team we are not actively maintaining a presence on Facebook or G+ as far as I know so I vote for removing them... Manfred Hervé BOUTEMY wrote on 2018-01-31 09:40: > I must confess that I don't understand G+ nor Facebook buttons result > > any reason not to remove them? > > Regards, >

Re: Plan for releasing Maven core

t > > On Sat, 27 Jan 2018 19:56:49 +0100, Manfred Moser > <manf...@simpligility.com> wrote: > >> Awesome. On the resolver release can we make sure we release the ant >> task as well (maybe even the current version first since that has never >> been released

Re: Plan for releasing Maven core

Awesome. On the resolver release can we make sure we release the ant task as well (maybe even the current version first since that has never been released yet..) Manfred Stephen Connolly wrote on 2018-01-27 09:52: > Robert and I discussed on IRC... > > Our plan is as follows: > > 1. Fix

Re: Maven resolver branch consolidation

All done on the ant-tasks migration now as well. Next would be a release of the ant-tasks for which I filed https://issues.apache.org/jira/browse/MRESOLVER-37 Imho we should do that but I don't know what is involved and wont be able to work on it until some time in January. manfred

Re: [VOTE] Release Maven Indexer 6.0.0

Awesome! +1 Tamás Cservenák wrote on 2017-11-28 02:20: > [VOTE] Release Maven Indexer 6.0.0 > > Hi, > > We solved 25 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317523=12330802 > > There are still a couple of issues left in JIRA: >

Re: beam leaving maven, anything doable?

Just my 2c as a long terms Maven user and committer.. People have been moving from one build tool the other for years. That includes to Gradle, to Maven and to all sorts of others stuff and back. If the Beam project thinks they will get significant improvements for their build times and they

Re: Maven resolver branch consolidation

All done on demos including cleanup and closing the issue. For the ant tasks everything is ready in the new repo. If someone could set up the CI jenkins build that would be good. Once we are happy I can delete the branch in the old repo. And I think we also have to cut a release of the ant

Re: Maven resolver branch consolidation

medi 25 novembre 2017, 22:07:12 CET Manfred Moser a écrit : >> So .. I tried this now. Seems like something on gitbox is not configured >> correctly for me because the Your PMCs drop down contains no entries apart >> from Your PMCs. >> >> Can someone either

Re: Maven resolver branch consolidation

re 2017, 19:27:06 CET Stephen Connolly a écrit : >> Hervé might know... could be self-service on gitbox! >> >> I have two repos to create after the Jenkins Server is upgraded on Sunday, >> so let me know the process >> >> On Thu 23 Nov 2017 at 16:13, Manf

Re: Maven resolver branch consolidation

So how do I make this repo copy happen? An infra ticket or something like that? Stephen Connolly wrote on 2017-11-22 23:53: > On Thu 23 Nov 2017 at 04:20, Manfred Moser <manf...@simpligility.com> wrote: > >> Status update and questions: >> >> - demos are all now i

Re: Maven resolver branch consolidation

Status update and questions: - demos are all now in master and part of the multi module build - no changes on the ant tasks for now Questions: 1. Can I delete the demos branch now or do we wait until next release? I would prefer to delete the branch and close the ticket to be honest. 2. I

Re: Maven resolver branch consolidation

[2] > https://git1-us-west.apache.org/repos/asf?p=maven-resolver.git;a=blob_plain;f=src/site/resources/images/maven-resolver-deps.png;hb=f5439fde > > On Thu, 16 Nov 2017 18:13:15 +0100, Manfred Moser > <manf...@simpligility.com> wrote: > >> Thanks for the explanation an

Re: Maven resolver branch consolidation

O, another consequence could be: maven-resolver-ant-tasks would >> > >> > perhaps >> > >> > > better be versionned like maven-resolver-provider >> > > >> > > >> > > Merging resolver-demos is really the great big id

Re: Maven resolver branch consolidation

ist and on the 2 Jira issues > In summary, +1 to merge demos, -1 to merge ant-tasks > > Regards, > > Hervé > > Le mardi 14 novembre 2017, 18:19:40 CET Manfred Moser a écrit : >> Any feedback or should I just go ahead with the cleanup? >> >> Manfred >

Re: Maven resolver branch consolidation

Any feedback or should I just go ahead with the cleanup? Manfred Manfred Moser wrote on 2017-11-08 21:35: > Hi all, > > I have started and made good progress on getting Maven resolver all into the > master branch instead of having master, demos and ant-tasks in separat

Maven resolver branch consolidation

Hi all, I have started and made good progress on getting Maven resolver all into the master branch instead of having master, demos and ant-tasks in separate branches. Details are tracked in https://issues.apache.org/jira/browse/MRESOLVER-28 All of it is now in a new branch called master-all

Re: Maven Docker Images

Following up on that remark and my earlier remark that we should NOT make this official .. here are my remarks: - so far the only binaries we assemble and call official are the tar.gz and zip archives (and even that is a gray line since official there are only sources from Apache) - we do NOT

Re: Maven Docker Images

> > >> >> > > When he started that (several years ago) Docker wasn't what it is >> >> >> >> nowadays.> >> >> >> >> > > With docker being mainstream I agree that we can reconsider this.> >>

Re: Maven Plugin that provides alternative repository

I think this would modify the overall Maven behaviour and you would therefore have to implement this as an extension rather than as a plugin. Fyi. we have such an extension that modifies usage of the local repository already within Takari. Use it as inspiration..

Re: [VOTE] Release Apache Maven JMod Plugin version 3.0.0-alpha-1 (First Public Release)

+1 Ship it. Karl Heinz Marbaise wrote on 2017-09-09 06:52: > Hi, > > this is the VOTE for the first public release for Maven JMod Plugin... > > We solved 1 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321433=12341363 > > There are currently no issues left in

Re: [VOTE] Release Apache Maven Enforcer Plugin version 3.0.0-M1

Wow Karl! Very nice testing effort. +1 from me (with less testing but still some ubuntu and osx based runs..) Manfred Karl Heinz Marbaise wrote on 2017-07-28 14:44: > Hi, > > +1 from me. > > > Tested with JDK 9+180 the following Maven versions: > o Maven 3.5.0, Maven 3.3.9, Maven 3.2.5,

Re: Maven Resolver

Great. https://issues.apache.org/jira/browse/MRESOLVER-28 https://issues.apache.org/jira/browse/MRESOLVER-29 Let me know if you want me to work on them. Manfred Michael Osipov wrote on 2017-07-19 14:44: > Am 2017-07-19 um 23:39 schrieb Manfred Moser: >> Hi all, >> >> I

Maven Resolver

Hi all, I found out that maven-resolver has main codebase, demos and ant tasks as separate branches in the same repository. Anybody know why this is the case instead of having three separate repositories? I must have missed that in the discussions about pulling Aether in.. Related to that

Maven Resolver Provider, Repo Provisioner and 3.5.1

Hi all, I moved my Maven Repository Provisioner to using Maven Resolver and 3.5.0 from Aether and 3.3.9 and have to say.. nice work on the migration. It essentially compiled after just changing a few dependencies! I did run into an issue in the Maven Resolver Provider where a missing setter

Re: [VOTE] Release Maven Resolver version 1.1.0

Excellent. Looking forward to using this. +1 manfred Michael Osipov wrote on 2017-06-30 13:12: > Hi, > > We solved 15 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12339212 > > There are still a couple of issues left in JIRA: >

Re: Anyone object if I release Maven Enforcer?

A release is always welcome ;-) +1 Stephen Connolly wrote on 2017-06-15 04:13: > Jesse Glick needs this release for some downstream fixes in the Jenkins > project. > > If nobody objects I'll cut the release on Monday. > > -Stephen >

Re: convert maven-resolver-provider to jsr330

Lgtm +1 Igor Fedorenko wrote on 2017-05-24 14:38: > I'd like to ask for somebody to second my change described in > [MNG-6233]. The change cleans up mixture of jsr330 and plexus > annotations used in maven-resolver-provider, leaving only jsr330. The > change is small and I believe safe, does not

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

-javadocs.git > g...@central.maven.org: > maven2/<group-name-with-slashes-for-dots-sources.git > > More likely though (as you mentioned in your opening line) is the way > homebrew works - you point at repos elsewhere, but control poms/shas etc on > 'central. > > >

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

Having worked with repository managers and the implementation for various formats on Nexus for years I think such a format is a bit like Bower. It is a registry format that in turn points to git repositories that have the content. >From a corporate usage and implementation point of view this is

Re: The maven-archetype-plugin paradox

I think you have done the right thing even if some users are not necessarily happy. The documentation about the new behavior is clear enough, but maybe it needs to be more explicit. In either I would just keep the plugin at ASF and do minimal maintenance like you have been doing. If someone

  1   2   3   4   >