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:
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,
+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
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
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
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
+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.
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
*
+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
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
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
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
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
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
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/
>
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.
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
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
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
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
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.
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
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?
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
>
>
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:
>
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
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
>> &
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
+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
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
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
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.
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
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
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
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:
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
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
>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
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
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>
>
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
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
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
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
> —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
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
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
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
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,
+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
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
>
+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
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
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
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
+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
+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
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
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
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 ...
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
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
>>
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
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:
>
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:
>
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.
>
>
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
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
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
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,
>
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
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
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
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:
>
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
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
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 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
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
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
[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
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
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
>
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
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
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
> >
>> >> > > 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.>
>>
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..
+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
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,
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
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
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
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:
>
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
>
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
-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.
>
>
>
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
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 - 100 of 321 matches
Mail list logo