Re: [VOTE] Retire Maven Runtime library

[Tamás Cservenák]

+1

On Wed, May 15, 2019, 22:33 Robert Scholte  wrote:

> 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 ideas for the next major version(s) of Maven itself.
> To be able to gain more focus we need to criticize the current subprojects
> and decide if it is worth maintaining.
>
> The Maven Runtime library has been released 3 times, the last time was May
> 2012 for version 1.0-alpha-3. According to
> https://mvnrepository.com/artifact/org.apache.maven.shared/maven-runtime [
> https://mvnrepository.com/artifact/org.apache.maven.shared/maven-runtime] this
> library is only used in 4 projects.
> The main purpose of the library is reading the pom.properties or pom.xml
> from an artifact to get the version. This functionality works so the
> library can be considered finished.
> See https://maven.apache.org/shared/maven-runtime/ [
> https://maven.apache.org/shared/maven-runtime/]
>
> I therefore propose that we retire the maven-runtime.
>
> I don't think it makes sense to do a final release. Instead we should
> update the documentation and the freeze the codebase.
>
> The process for retiring a plugin is described here:
> https://maven.apache.org/developers/retirement-plan-plugins.html
>
> The vote is open for 72 hours.
>
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...

Re: [VOTE] Retire Maven Runtime library

[Tibor Digana]

+1

On Wed, May 15, 2019 at 10:33 PM Robert Scholte 
wrote:

> 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 ideas for the next major version(s) of Maven itself.
> To be able to gain more focus we need to criticize the current subprojects
> and decide if it is worth maintaining.
>
> The Maven Runtime library has been released 3 times, the last time was May
> 2012 for version 1.0-alpha-3. According to
> https://mvnrepository.com/artifact/org.apache.maven.shared/maven-runtime [
> https://mvnrepository.com/artifact/org.apache.maven.shared/maven-runtime] this
> library is only used in 4 projects.
> The main purpose of the library is reading the pom.properties or pom.xml
> from an artifact to get the version. This functionality works so the
> library can be considered finished.
> See https://maven.apache.org/shared/maven-runtime/ [
> https://maven.apache.org/shared/maven-runtime/]
>
> I therefore propose that we retire the maven-runtime.
>
> I don't think it makes sense to do a final release. Instead we should
> update the documentation and the freeze the codebase.
>
> The process for retiring a plugin is described here:
> https://maven.apache.org/developers/retirement-plan-plugins.html
>
> The vote is open for 72 hours.
>
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...

Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)

[Tibor Digana]

Enrico, I checked the Checkstyle rules again (default value = system) and
Robert is right, please adjust the IT sources on the fly.
Not sure why INFRA or Jenkins sets the Windows EOL to LF.
Therefore we could not find this issue in version 3.0.0 (Jan 04) because
the IT was created on Jan 17 and we run it on local Windows the first time.

The library is fine. I used several old versions of the plugin having
identical results.
Few links:

http://checkstyle.sourceforge.net/config_misc.html#NewlineAtEndOfFile

http://checkstyle.sourceforge.net/google_style.html
https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/sun_checks.xml
https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml

I expected platform independence because my company used sun_checks.xml on
Windows with Unix EOL in Git/IDE without this problem.
The company improved sun_checks.xml long time ago, so I realized that later
that it is slightly different XML and different experience. Sorry.
Cheers
Tibor17


On Tue, May 14, 2019 at 2:11 PM Enrico Olivelli  wrote:

> I will get a windows box and try to reproduce.
> It is weird that on ASF Jenkins the build is passing even on windows
>
> Enrico
>
> -- Forwarded message -
> Da: Enrico Olivelli 
> Date: mar 14 mag 2019, 13:58
> Subject: Re: [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0
> To: Maven Developers List 
>
>
> Eric and Tibor,
> Thank you so much for your effort in testing Maven Checkstyle Plugin.
>
> This is the "official" VOTE thread, here we have to decide if the staged
> artifacts are good to be released or not.
>
> Feel free to cast a -1 if you think that the staged artifacts are not
> "stable" or there is any showstopper problem for the release.
>
> Let's move this discussion to a separate thread, something like "Validation
> failures in Windows over current checkstyle plugin master branch")
>
> Enrico
>
>
>
>
> Il giorno mar 14 mag 2019 alle ore 13:51 Eric Lilja 
> ha scritto:
>
> > Tried overriding line.separator when running using -Dline.separator="\n",
> > but then the builds fails (early) in maven-plugin-plugin:
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor
> > (default-descriptor) on project maven-checkstyle-plugin: Execution
> > default-descriptor of goal
> > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed:
> > Requested line separator is invalid. -> [Help 1]
> > [ERROR]
> > [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e
> > switch.
> > [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> > [ERROR]
> > [ERROR] For more information about the errors and possible solutions,
> > please read the following articles:
> > [ERROR] [Help 1]
> >
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
> >
> > Tried upgrading maven-plugin-plugin to 3.6.0 (lots of stuff
> > upgradeable...), but same error
> >
> > I also happened to notice this (probably unrelated, but wanted to bring
> it
> > to attention anyway so it can be fixed) warning:
> > [INFO] java-annotations mojo extractor found 4 mojo descriptors.
> > [WARNING]
> >
> > Unexpected situation: destinationDirectory not defined in
> > maven-plugin-help.properties during help mojo source generation but
> > expected during XML descriptor generation.
> > [WARNING] Please check helpmojo goal version used in previous build
> phase.
> > [WARNING] If you just upgraded to plugin-tools >= 3.2 you must run a
> clean
> > build at least once.
> > [WARNING] Trying default location: target\generated-sources\plugin
> >
> > - Eric L
> >
> > On Tue, May 14, 2019 at 11:04 AM Eric Lilja 
> wrote:
> >
> > > I tried bumping checkstyle to 8.20, plus a few of the plexus
> > dependencies,
> > > but that just brought an additional failure... (to
> > > MCHECKSTYLE-70-multi-sourcefolder\pom.xml)  :-)
> > >
> > > I suppose the problem might be that the files has linux-style line
> breaks
> > > (this is desired for me, I don't want to convert to windows-style line
> > > breaks locally), but the test think I should have windows-style line
> > > separators. It seems these files are generated by the tests because I
> > tried
> > > changing them to Windows style line breaks for re-running just to see
> if
> > > that would work, but those changes were overwritten)
> > >
> > > - Eric L
> > >
> > > On Tue, May 14, 2019 at 10:38 AM Eric Lilja 
> > wrote:
> > >
> > >> I also see a failure for MCHECKSTYLE-54 on Windows. (Sorry, I didn't
> try
> > >> the source zip, just cloned master)
> > >>
> > >> I tested on one of our corporate laptops:
> > >> Windows 10
> > >> Cygwin 64-bit (I use it to clone the repo and use Maven)
> > >> Maven 3.6.0
> > >> Java 8 update 202
> > >>
> > >> The build log says:
> > >> [INFO] There are 2 errors reported by Checkstyle 8.19 with
> > sun_checks.xml
> > >> ruleset.
> > >> [ERROR]
> > >>
> >
> 

Re: [VOTE] Retire Maven Runtime library

[Manfred Moser]

+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 projects, including our
> ambitious ideas for the next major version(s) of Maven itself.
> To be able to gain more focus we need to criticize the current subprojects and
> decide if it is worth maintaining.
>  
> The Maven Runtime library has been released 3 times, the last time was May 
> 2012
> for version 1.0-alpha-3. According
> to https://mvnrepository.com/artifact/org.apache.maven.shared/maven-runtime
> [https://mvnrepository.com/artifact/org.apache.maven.shared/maven-runtime] 
> this
> library is only used in 4 projects.
> The main purpose of the library is reading the pom.properties or pom.xml from
> an artifact to get the version. This functionality works so the library can be
> considered finished.
> See https://maven.apache.org/shared/maven-runtime/
> [https://maven.apache.org/shared/maven-runtime/]
>  
> I therefore propose that we retire the maven-runtime.
>  
> I don't think it makes sense to do a final release. Instead we should update
> the documentation and the freeze the codebase.
>  
> The process for retiring a plugin is described here:
> https://maven.apache.org/developers/retirement-plan-plugins.html 
>  
> The vote is open for 72 hours.
>  
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Retire Maven Runtime library

[Sylwester Lachiewicz]

+1
BR
Sylwester

śr., 15 maj 2019 o 22:59 Karl Heinz Marbaise  napisał(a):

> Hi,
>
> +1 from me.
>
> Kind regards
> Karl Heinz Marbaise
>
> On 15.05.19 22:33, Robert Scholte wrote:
> > 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 ideas for the next major version(s) of Maven itself.
> > To be able to gain more focus we need to criticize the current
> subprojects and decide if it is worth maintaining.
> >
> > The Maven Runtime library has been released 3 times, the last time was
> May 2012 for version 1.0-alpha-3. According to
> https://mvnrepository.com/artifact/org.apache.maven.shared/maven-runtime [
> https://mvnrepository.com/artifact/org.apache.maven.shared/maven-runtime] this
> library is only used in 4 projects.
> > The main purpose of the library is reading the pom.properties or pom.xml
> from an artifact to get the version. This functionality works so the
> library can be considered finished.
> > See https://maven.apache.org/shared/maven-runtime/ [
> https://maven.apache.org/shared/maven-runtime/]
> >
> > I therefore propose that we retire the maven-runtime.
> >
> > I don't think it makes sense to do a final release. Instead we should
> update the documentation and the freeze the codebase.
> >
> > The process for retiring a plugin is described here:
> > https://maven.apache.org/developers/retirement-plan-plugins.html
> >
> > The vote is open for 72 hours.
> >
> > [ ] +1 Yes, it's about time
> > [ ] -1 No, because...
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)

[Tibor Digana]

Robert, see this https://issues.apache.org/jira/browse/MCHECKSTYLE-376
The Git clone fails on Windows. Most probably our Jenkins is using LF EOL
on Windows and not CRLF.
We cannot hack Java files only to pass the IT.
Why one or two ITs failed and the other dont.
The IT has only one POM and two Java source files. This can be run without
out IT mechanism just from CLI, and this fails the same way and I am sure
this will happen to customer.
We did something wrong or Checkstyle library?
In real situations user projects use Git editor and IDEs using Unix EOL but
the operating system is Windows. In such case the checkstyle becomes a
blocker and their projects would never pass through.
Checkstyle documentation all lists characers of EOL and they are all
possible characters by default. The question is why the library behaves
against the documentation. Bug?
The rules are designed so that they are platform independent and EOL
character is not mandatory but it is mandatory for a good parser of the
text file.
Which code is parsing the text files?


On Wed, May 15, 2019 at 7:52 PM Robert Scholte  wrote:

> FYI, I'm on Windows (by default), just cmdline, so no powercommand or
> gitbash or similar prompts.
> A clone from Git succeeds, but the sources.zip fails.
> The files in the zip are generated on a unix system, so all EOLs in text
> files are LF
> If I replace the EOL from unix to Windows the build succeeds.
> This also explains why it succeeds on builds.a.o, there the EOLs are
> always based on the OS due to the Auto Crlf convert option.
> The fix: add a setup.groovy to the IT and rewrite the java files with OS
> specific EOLs
>
> Robert
>
> On 14-5-2019 16:32:29, Enrico Olivelli  wrote:
> Thanks
> I am able to reproduce the issue on a Windows box.
> Still I can't understand why we aren't seeing problems on CI.
>
> Eric,
> do you have cycles to create a JIRA and send a Pull request ?
> We can fix it in master.
> As Tibor said, I think this is not a blocker for the 3.1.0 release.
>
> Otherwise I will fix it when I have time, but not today
>
>
> Thank you very much for reporting
> Enrico
>
>
>
> Il giorno mar 14 mag 2019 alle ore 16:24 Enrico Olivelli
> eolive...@gmail.com> ha scritto:
>
> >
> >
> > Il giorno mar 14 mag 2019 alle ore 14:34 Tibor Digana
> > tibordig...@apache.org> ha scritto:
> >
> >> Two files in one IT are problematic but I don't think it is a problem
> for
> >> your release.
> >> The CPD should be fixed and a method should be reused but again it is
> not
> >> a reason to interrupt the vote.
> >>
> >> One more question. Why did you "git push" the history from Maven Release
> >> plugin?
> >> This should be done after the vote because yet you do not know the vote
> >> result.
> >>
> >
> > Please explain better.
> > I apologize if I did a mistake, but I can't understand your concern.
> >
> > I have used these commands:
> > mvn release:clean
> > mvn release:prepare
> > mvn release:perform
> > "Closed" the staged repository
> >
> > current master is 3.1.1-SNAPSHOT
> > https://github.com/apache/maven-checkstyle-plugin
> >
> > tag is at: 3.1.0
> >
> >
> https://github.com/apache/maven-checkstyle-plugin/tree/maven-checkstyle-plugin-3.1.0
> >
> >
> >
> >
> >
> > Enrico
> >
> >
> >
> >>
> >> Cheers
> >> Tibor
> >>
> >> On Tue, May 14, 2019 at 2:11 PM Enrico Olivelli
> >> wrote:
> >>
> >> > I will get a windows box and try to reproduce.
> >> > It is weird that on ASF Jenkins the build is passing even on windows
> >> >
> >> > Enrico
> >> >
> >> > -- Forwarded message -
> >> > Da: Enrico Olivelli
> >> > Date: mar 14 mag 2019, 13:58
> >> > Subject: Re: [VOTE] Release Apache Maven Checkstyle Plugin version
> 3.1.0
> >> > To: Maven Developers List
> >> >
> >> >
> >> > Eric and Tibor,
> >> > Thank you so much for your effort in testing Maven Checkstyle Plugin.
> >> >
> >> > This is the "official" VOTE thread, here we have to decide if the
> staged
> >> > artifacts are good to be released or not.
> >> >
> >> > Feel free to cast a -1 if you think that the staged artifacts are not
> >> > "stable" or there is any showstopper problem for the release.
> >> >
> >> > Let's move this discussion to a separate thread, something like
> >> "Validation
> >> > failures in Windows over current checkstyle plugin master branch")
> >> >
> >> > Enrico
> >> >
> >> >
> >> >
> >> >
> >> > Il giorno mar 14 mag 2019 alle ore 13:51 Eric Lilja
> >> mindcoo...@gmail.com>
> >> > ha scritto:
> >> >
> >> > > Tried overriding line.separator when running using
> >> -Dline.separator="\n",
> >> > > but then the builds fails (early) in maven-plugin-plugin:
> >> > > [ERROR] Failed to execute goal
> >> > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor
> >> > > (default-descriptor) on project maven-checkstyle-plugin: Execution
> >> > > default-descriptor of goal
> >> > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed:
> >> > > Requested line separator is invalid. -> [Help 1]
> >> > > [ERROR]
> >> > > 

Re: [VOTE] Retire Maven Runtime library

[Karl Heinz Marbaise]

Hi,

+1 from me.

Kind regards
Karl Heinz Marbaise

On 15.05.19 22:33, Robert Scholte wrote:

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 ideas for the next major version(s) of Maven itself.
To be able to gain more focus we need to criticize the current subprojects and 
decide if it is worth maintaining.

The Maven Runtime library has been released 3 times, the last time was May 2012 
for version 1.0-alpha-3. According to 
https://mvnrepository.com/artifact/org.apache.maven.shared/maven-runtime 
[https://mvnrepository.com/artifact/org.apache.maven.shared/maven-runtime] this 
library is only used in 4 projects.
The main purpose of the library is reading the pom.properties or pom.xml from 
an artifact to get the version. This functionality works so the library can be 
considered finished.
See https://maven.apache.org/shared/maven-runtime/ 
[https://maven.apache.org/shared/maven-runtime/]

I therefore propose that we retire the maven-runtime.

I don't think it makes sense to do a final release. Instead we should update 
the documentation and the freeze the codebase.

The process for retiring a plugin is described here:
https://maven.apache.org/developers/retirement-plan-plugins.html

The vote is open for 72 hours.

[ ] +1 Yes, it's about time
[ ] -1 No, because...



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[VOTE] Retire Maven Runtime library

[Robert Scholte]

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 ideas for the next major version(s) of Maven itself.
To be able to gain more focus we need to criticize the current subprojects and 
decide if it is worth maintaining.
 
The Maven Runtime library has been released 3 times, the last time was May 2012 
for version 1.0-alpha-3. According to 
https://mvnrepository.com/artifact/org.apache.maven.shared/maven-runtime 
[https://mvnrepository.com/artifact/org.apache.maven.shared/maven-runtime] this 
library is only used in 4 projects.
The main purpose of the library is reading the pom.properties or pom.xml from 
an artifact to get the version. This functionality works so the library can be 
considered finished.
See https://maven.apache.org/shared/maven-runtime/ 
[https://maven.apache.org/shared/maven-runtime/]
 
I therefore propose that we retire the maven-runtime.
 
I don't think it makes sense to do a final release. Instead we should update 
the documentation and the freeze the codebase.
 
The process for retiring a plugin is described here:
https://maven.apache.org/developers/retirement-plan-plugins.html 
 
The vote is open for 72 hours.
 
[ ] +1 Yes, it's about time
[ ] -1 No, because...

[VOTE] Release Apache Maven Source Plugin version 3.1.0

[Karl Heinz Marbaise]

Hi,

We solved 11 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317924=12336941

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSOURCES%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1504

https://repository.apache.org/content/repositories/maven-1504/org/apache/maven/plugins/maven-source-plugin/3.1.0/maven-source-plugin-3.1.0-source-release.zip

Source release checksum(s):
maven-source-plugin-3.1.0-source-release.zip sha1:
525e119423432ad850edcb308c2c15f20fd2dcbe

maven-source-plugin-3.1.0-source-release.zip sha512:
9714d8e44c0e1e298190cf280694608502b3110c4077742189edc72136e733a025727092363774e51b9329df9fdd7b098795da2d3c1735c3bf926fce8d7b774b

Staging site:
https://maven.apache.org/plugins-archives/maven-source-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

Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MNG-6069 2nd - seconders

[Robert Scholte]

There's an important line in the description:
"Ensure that the following command succeeds: mvn -X -D x=1 -D y=2 test (  
watch out for the space after -D )"


Maybe I'm not looking good enough, but I don't see any related codechanges  
for this.


thanks,
Robert

On Wed, 15 May 2019 21:10:43 +0200, Sylwester Lachiewicz  
 wrote:



kindly reminder, anyone to look and confirm on ML?

W dniu niedz., 12.05.2019 o 23:08 Sylwester Lachiewicz <
slachiew...@gmail.com> napisał(a):


Hi,
We have fix for MNG-6069 Migrate to non deprecated parts of Commons CLI  
-

2nd attempt
https://issues.apache.org/jira/browse/MNG-6069
PR: https://github.com/apache/maven/pull/247
commit:
https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=b01f861729214e45a1f3754ed5456bcdc1c3b4fc
CI build:
https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/MNG-6069v2/

Seconders, please?

Regards,
Sylwester


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MNG-6069 2nd - seconders

[Sylwester Lachiewicz]

kindly reminder, anyone to look and confirm on ML?

W dniu niedz., 12.05.2019 o 23:08 Sylwester Lachiewicz <
slachiew...@gmail.com> napisał(a):

> Hi,
> We have fix for MNG-6069 Migrate to non deprecated parts of Commons CLI -
> 2nd attempt
> https://issues.apache.org/jira/browse/MNG-6069
> PR: https://github.com/apache/maven/pull/247
> commit:
> https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=b01f861729214e45a1f3754ed5456bcdc1c3b4fc
> CI build:
> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/MNG-6069v2/
>
> Seconders, please?
>
> Regards,
> Sylwester
>

Re: Open pull requests

[Karl Heinz Marbaise]

Hi,

yes please don't stop to help...as Robert and Enrico already mentioned
every eye help..

Kind regards
Karl Heinz Marbaise
On 15.05.19 19:08, Robert Scholte wrote:

Hi Joseph,

great to hear you want to contribute, we appreciate that a lot!
But you mind have noticed there are a huge amount of open issues and pull 
request and we simple can not catch up due to the limited amount of time and 
volunteers.

Regarding the open PRs, I expect that most were created in a period where Maven 
itself was still on subversion, but the Apache Software Foundation provided 
read-only copies at Github.
The integration between both systems was bad, we didn't get notifications and 
trying to patch it back to subversion was a nightmare.
Things are better nowadays, but we still suffer from that period.

My main activity is currently reading and writing daily e-mails and trying to 
get and keep everything stable.So development is not even in the top 3 
activities.
Going through older PRs is something that should be done, but I'm afraid it is 
not getting the highest priority.

Don't let this be a message to stop contributing, just be aware that it 
requires some patience.

thanks,
Robert


On 14-5-2019 06:21:17, Joseph Walton  wrote:
- To 
unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, 
e-mail: dev-h...@maven.apache.org
As an interested contributor, I've opened a couple of pull requests, and it's 
not always clear what the next step is for a non-project-member to get things 
merged.

To see how other PRs (https://github.com/apache/maven/pulls 
[https://github.com/apache/maven/pulls] -- currently, '32 open') are being 
handled, I thought it might make sense to chart them; chart attached.

Notable:
* a significant number were opened more than a year ago (as far back as 2014), 
haven't been merged and now have conflicts. Could they be closed?

* some more recent ones are mergeable, and approved. Can these be merged?
* for the other PRs in between -- do they need work, or would closing them send 
a clearer message?

Thanks.



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Open pull requests

[Enrico Olivelli]

Thank you Joseph,
If you have time you can help us review the pending pulls and see if they
are still useful and/or suggest changes before merge.
Every eye on patches is very valuable and it helps commiters of the project
in their work.

Enrico

Il mer 15 mag 2019, 19:08 Robert Scholte  ha scritto:

> Hi Joseph,
>
> great to hear you want to contribute, we appreciate that a lot!
> But you mind have noticed there are a huge amount of open issues and pull
> request and we simple can not catch up due to the limited amount of time
> and volunteers.
>
> Regarding the open PRs, I expect that most were created in a period where
> Maven itself was still on subversion, but the Apache Software Foundation
> provided read-only copies at Github.
> The integration between both systems was bad, we didn't get notifications
> and trying to patch it back to subversion was a nightmare.
> Things are better nowadays, but we still suffer from that period.
>
> My main activity is currently reading and writing daily e-mails and trying
> to get and keep everything stable.So development is not even in the top 3
> activities.
> Going through older PRs is something that should be done, but I'm afraid
> it is not getting the highest priority.
>
> Don't let this be a message to stop contributing, just be aware that it
> requires some patience.
>
> thanks,
> Robert
>
>
> On 14-5-2019 06:21:17, Joseph Walton  wrote:
> - To
> unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional
> commands, e-mail: dev-h...@maven.apache.org
> As an interested contributor, I've opened a couple of pull requests, and
> it's not always clear what the next step is for a non-project-member to get
> things merged.
>
> To see how other PRs (https://github.com/apache/maven/pulls [
> https://github.com/apache/maven/pulls] -- currently, '32 open') are being
> handled, I thought it might make sense to chart them; chart attached.
>
> Notable:
> * a significant number were opened more than a year ago (as far back as
> 2014), haven't been merged and now have conflicts. Could they be closed?
>
> * some more recent ones are mergeable, and approved. Can these be merged?
> * for the other PRs in between -- do they need work, or would closing them
> send a clearer message?
>
> Thanks.
>

Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)

[Robert Scholte]

FYI, I'm on Windows (by default), just cmdline, so no powercommand or gitbash 
or similar prompts. 
A clone from Git succeeds, but the sources.zip fails.
The files in the zip are generated on a unix system, so all EOLs in text files 
are LF
If I replace the EOL from unix to Windows the build succeeds.
This also explains why it succeeds on builds.a.o, there the EOLs are always 
based on the OS due to the Auto Crlf convert option.
The fix: add a setup.groovy to the IT and rewrite the java files with OS 
specific EOLs

Robert

On 14-5-2019 16:32:29, Enrico Olivelli  wrote:
Thanks
I am able to reproduce the issue on a Windows box.
Still I can't understand why we aren't seeing problems on CI.

Eric,
do you have cycles to create a JIRA and send a Pull request ?
We can fix it in master.
As Tibor said, I think this is not a blocker for the 3.1.0 release.

Otherwise I will fix it when I have time, but not today


Thank you very much for reporting
Enrico



Il giorno mar 14 mag 2019 alle ore 16:24 Enrico Olivelli
eolive...@gmail.com> ha scritto:

>
>
> Il giorno mar 14 mag 2019 alle ore 14:34 Tibor Digana
> tibordig...@apache.org> ha scritto:
>
>> Two files in one IT are problematic but I don't think it is a problem for
>> your release.
>> The CPD should be fixed and a method should be reused but again it is not
>> a reason to interrupt the vote.
>>
>> One more question. Why did you "git push" the history from Maven Release
>> plugin?
>> This should be done after the vote because yet you do not know the vote
>> result.
>>
>
> Please explain better.
> I apologize if I did a mistake, but I can't understand your concern.
>
> I have used these commands:
> mvn release:clean
> mvn release:prepare
> mvn release:perform
> "Closed" the staged repository
>
> current master is 3.1.1-SNAPSHOT
> https://github.com/apache/maven-checkstyle-plugin
>
> tag is at: 3.1.0
>
> https://github.com/apache/maven-checkstyle-plugin/tree/maven-checkstyle-plugin-3.1.0
>
>
>
>
>
> Enrico
>
>
>
>>
>> Cheers
>> Tibor
>>
>> On Tue, May 14, 2019 at 2:11 PM Enrico Olivelli
>> wrote:
>>
>> > I will get a windows box and try to reproduce.
>> > It is weird that on ASF Jenkins the build is passing even on windows
>> >
>> > Enrico
>> >
>> > -- Forwarded message -
>> > Da: Enrico Olivelli
>> > Date: mar 14 mag 2019, 13:58
>> > Subject: Re: [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0
>> > To: Maven Developers List
>> >
>> >
>> > Eric and Tibor,
>> > Thank you so much for your effort in testing Maven Checkstyle Plugin.
>> >
>> > This is the "official" VOTE thread, here we have to decide if the staged
>> > artifacts are good to be released or not.
>> >
>> > Feel free to cast a -1 if you think that the staged artifacts are not
>> > "stable" or there is any showstopper problem for the release.
>> >
>> > Let's move this discussion to a separate thread, something like
>> "Validation
>> > failures in Windows over current checkstyle plugin master branch")
>> >
>> > Enrico
>> >
>> >
>> >
>> >
>> > Il giorno mar 14 mag 2019 alle ore 13:51 Eric Lilja
>> mindcoo...@gmail.com>
>> > ha scritto:
>> >
>> > > Tried overriding line.separator when running using
>> -Dline.separator="\n",
>> > > but then the builds fails (early) in maven-plugin-plugin:
>> > > [ERROR] Failed to execute goal
>> > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor
>> > > (default-descriptor) on project maven-checkstyle-plugin: Execution
>> > > default-descriptor of goal
>> > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed:
>> > > Requested line separator is invalid. -> [Help 1]
>> > > [ERROR]
>> > > [ERROR] To see the full stack trace of the errors, re-run Maven with
>> the
>> > -e
>> > > switch.
>> > > [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>> > > [ERROR]
>> > > [ERROR] For more information about the errors and possible solutions,
>> > > please read the following articles:
>> > > [ERROR] [Help 1]
>> > >
>> >
>> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
>> > >
>> > > Tried upgrading maven-plugin-plugin to 3.6.0 (lots of stuff
>> > > upgradeable...), but same error
>> > >
>> > > I also happened to notice this (probably unrelated, but wanted to
>> bring
>> > it
>> > > to attention anyway so it can be fixed) warning:
>> > > [INFO] java-annotations mojo extractor found 4 mojo descriptors.
>> > > [WARNING]
>> > >
>> > > Unexpected situation: destinationDirectory not defined in
>> > > maven-plugin-help.properties during help mojo source generation but
>> > > expected during XML descriptor generation.
>> > > [WARNING] Please check helpmojo goal version used in previous build
>> > phase.
>> > > [WARNING] If you just upgraded to plugin-tools >= 3.2 you must run a
>> > clean
>> > > build at least once.
>> > > [WARNING] Trying default location: target\generated-sources\plugin
>> > >
>> > > - Eric L
>> > >
>> > > On Tue, May 14, 2019 at 11:04 AM Eric Lilja
>> > wrote:
>> > >
>> > > 

Re: Open pull requests

[Robert Scholte]

Hi Joseph,

great to hear you want to contribute, we appreciate that a lot!
But you mind have noticed there are a huge amount of open issues and pull 
request and we simple can not catch up due to the limited amount of time and 
volunteers.

Regarding the open PRs, I expect that most were created in a period where Maven 
itself was still on subversion, but the Apache Software Foundation provided 
read-only copies at Github.
The integration between both systems was bad, we didn't get notifications and 
trying to patch it back to subversion was a nightmare.
Things are better nowadays, but we still suffer from that period.

My main activity is currently reading and writing daily e-mails and trying to 
get and keep everything stable.So development is not even in the top 3 
activities.
Going through older PRs is something that should be done, but I'm afraid it is 
not getting the highest priority.

Don't let this be a message to stop contributing, just be aware that it 
requires some patience.

thanks,
Robert


On 14-5-2019 06:21:17, Joseph Walton  wrote:
- To 
unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, 
e-mail: dev-h...@maven.apache.org
As an interested contributor, I've opened a couple of pull requests, and it's 
not always clear what the next step is for a non-project-member to get things 
merged.

To see how other PRs (https://github.com/apache/maven/pulls 
[https://github.com/apache/maven/pulls] -- currently, '32 open') are being 
handled, I thought it might make sense to chart them; chart attached.

Notable:
* a significant number were opened more than a year ago (as far back as 2014), 
haven't been merged and now have conflicts. Could they be closed?

* some more recent ones are mergeable, and approved. Can these be merged?
* for the other PRs in between -- do they need work, or would closing them send 
a clearer message?

Thanks.

Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)

[Enrico Olivelli]

Il mer 15 mag 2019, 17:44 Tibor Digana  ha scritto:

> @Enrico did you announce the Checkstyle team about our issue [1]?
> What is going on with that?
> [1]: https://issues.apache.org/jira/browse/MCHECKSTYLE-376
> Thx
> Tibor17
>


Not yet sorry. I have been busy today. Will do this evening


Enrico



>
> On Tue, May 14, 2019 at 2:11 PM Enrico Olivelli 
> wrote:
>
> > I will get a windows box and try to reproduce.
> > It is weird that on ASF Jenkins the build is passing even on windows
> >
> > Enrico
> >
> > -- Forwarded message -
> > Da: Enrico Olivelli 
> > Date: mar 14 mag 2019, 13:58
> > Subject: Re: [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0
> > To: Maven Developers List 
> >
> >
> > Eric and Tibor,
> > Thank you so much for your effort in testing Maven Checkstyle Plugin.
> >
> > This is the "official" VOTE thread, here we have to decide if the staged
> > artifacts are good to be released or not.
> >
> > Feel free to cast a -1 if you think that the staged artifacts are not
> > "stable" or there is any showstopper problem for the release.
> >
> > Let's move this discussion to a separate thread, something like
> "Validation
> > failures in Windows over current checkstyle plugin master branch")
> >
> > Enrico
> >
> >
> >
> >
> > Il giorno mar 14 mag 2019 alle ore 13:51 Eric Lilja <
> mindcoo...@gmail.com>
> > ha scritto:
> >
> > > Tried overriding line.separator when running using
> -Dline.separator="\n",
> > > but then the builds fails (early) in maven-plugin-plugin:
> > > [ERROR] Failed to execute goal
> > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor
> > > (default-descriptor) on project maven-checkstyle-plugin: Execution
> > > default-descriptor of goal
> > > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed:
> > > Requested line separator is invalid. -> [Help 1]
> > > [ERROR]
> > > [ERROR] To see the full stack trace of the errors, re-run Maven with
> the
> > -e
> > > switch.
> > > [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> > > [ERROR]
> > > [ERROR] For more information about the errors and possible solutions,
> > > please read the following articles:
> > > [ERROR] [Help 1]
> > >
> >
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
> > >
> > > Tried upgrading maven-plugin-plugin to 3.6.0 (lots of stuff
> > > upgradeable...), but same error
> > >
> > > I also happened to notice this (probably unrelated, but wanted to bring
> > it
> > > to attention anyway so it can be fixed) warning:
> > > [INFO] java-annotations mojo extractor found 4 mojo descriptors.
> > > [WARNING]
> > >
> > > Unexpected situation: destinationDirectory not defined in
> > > maven-plugin-help.properties during help mojo source generation but
> > > expected during XML descriptor generation.
> > > [WARNING] Please check helpmojo goal version used in previous build
> > phase.
> > > [WARNING] If you just upgraded to plugin-tools >= 3.2 you must run a
> > clean
> > > build at least once.
> > > [WARNING] Trying default location: target\generated-sources\plugin
> > >
> > > - Eric L
> > >
> > > On Tue, May 14, 2019 at 11:04 AM Eric Lilja 
> > wrote:
> > >
> > > > I tried bumping checkstyle to 8.20, plus a few of the plexus
> > > dependencies,
> > > > but that just brought an additional failure... (to
> > > > MCHECKSTYLE-70-multi-sourcefolder\pom.xml)  :-)
> > > >
> > > > I suppose the problem might be that the files has linux-style line
> > breaks
> > > > (this is desired for me, I don't want to convert to windows-style
> line
> > > > breaks locally), but the test think I should have windows-style line
> > > > separators. It seems these files are generated by the tests because I
> > > tried
> > > > changing them to Windows style line breaks for re-running just to see
> > if
> > > > that would work, but those changes were overwritten)
> > > >
> > > > - Eric L
> > > >
> > > > On Tue, May 14, 2019 at 10:38 AM Eric Lilja 
> > > wrote:
> > > >
> > > >> I also see a failure for MCHECKSTYLE-54 on Windows. (Sorry, I didn't
> > try
> > > >> the source zip, just cloned master)
> > > >>
> > > >> I tested on one of our corporate laptops:
> > > >> Windows 10
> > > >> Cygwin 64-bit (I use it to clone the repo and use Maven)
> > > >> Maven 3.6.0
> > > >> Java 8 update 202
> > > >>
> > > >> The build log says:
> > > >> [INFO] There are 2 errors reported by Checkstyle 8.19 with
> > > sun_checks.xml
> > > >> ruleset.
> > > >> [ERROR]
> > > >>
> > >
> >
> src\main\java\org\apache\maven\plugins\checkstyle\mcheckstyle54\Mcheckstyle54.java:[1]
> > > >> (misc) NewlineAtEndOfFile: File does not end with a newline.
> > > >> [ERROR]
> > > >>
> > >
> >
> src\main\java\org\apache\maven\plugins\checkstyle\mcheckstyle54\package-info.java:[1]
> > > >> (misc) NewlineAtEndOfFile: File does not end with a newline.
> > > >>
> > > >> These two files end with unix-style line breaks (as expected with my
> > > >> setup).
> > > >>
> > > >> - Eric L
> > > 

Re: Problems with checkstyle tests on Windows (Was [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0)

[Tibor Digana]

@Enrico did you announce the Checkstyle team about our issue [1]?
What is going on with that?
[1]: https://issues.apache.org/jira/browse/MCHECKSTYLE-376
Thx
Tibor17


On Tue, May 14, 2019 at 2:11 PM Enrico Olivelli  wrote:

> I will get a windows box and try to reproduce.
> It is weird that on ASF Jenkins the build is passing even on windows
>
> Enrico
>
> -- Forwarded message -
> Da: Enrico Olivelli 
> Date: mar 14 mag 2019, 13:58
> Subject: Re: [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.0
> To: Maven Developers List 
>
>
> Eric and Tibor,
> Thank you so much for your effort in testing Maven Checkstyle Plugin.
>
> This is the "official" VOTE thread, here we have to decide if the staged
> artifacts are good to be released or not.
>
> Feel free to cast a -1 if you think that the staged artifacts are not
> "stable" or there is any showstopper problem for the release.
>
> Let's move this discussion to a separate thread, something like "Validation
> failures in Windows over current checkstyle plugin master branch")
>
> Enrico
>
>
>
>
> Il giorno mar 14 mag 2019 alle ore 13:51 Eric Lilja 
> ha scritto:
>
> > Tried overriding line.separator when running using -Dline.separator="\n",
> > but then the builds fails (early) in maven-plugin-plugin:
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor
> > (default-descriptor) on project maven-checkstyle-plugin: Execution
> > default-descriptor of goal
> > org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed:
> > Requested line separator is invalid. -> [Help 1]
> > [ERROR]
> > [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e
> > switch.
> > [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> > [ERROR]
> > [ERROR] For more information about the errors and possible solutions,
> > please read the following articles:
> > [ERROR] [Help 1]
> >
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
> >
> > Tried upgrading maven-plugin-plugin to 3.6.0 (lots of stuff
> > upgradeable...), but same error
> >
> > I also happened to notice this (probably unrelated, but wanted to bring
> it
> > to attention anyway so it can be fixed) warning:
> > [INFO] java-annotations mojo extractor found 4 mojo descriptors.
> > [WARNING]
> >
> > Unexpected situation: destinationDirectory not defined in
> > maven-plugin-help.properties during help mojo source generation but
> > expected during XML descriptor generation.
> > [WARNING] Please check helpmojo goal version used in previous build
> phase.
> > [WARNING] If you just upgraded to plugin-tools >= 3.2 you must run a
> clean
> > build at least once.
> > [WARNING] Trying default location: target\generated-sources\plugin
> >
> > - Eric L
> >
> > On Tue, May 14, 2019 at 11:04 AM Eric Lilja 
> wrote:
> >
> > > I tried bumping checkstyle to 8.20, plus a few of the plexus
> > dependencies,
> > > but that just brought an additional failure... (to
> > > MCHECKSTYLE-70-multi-sourcefolder\pom.xml)  :-)
> > >
> > > I suppose the problem might be that the files has linux-style line
> breaks
> > > (this is desired for me, I don't want to convert to windows-style line
> > > breaks locally), but the test think I should have windows-style line
> > > separators. It seems these files are generated by the tests because I
> > tried
> > > changing them to Windows style line breaks for re-running just to see
> if
> > > that would work, but those changes were overwritten)
> > >
> > > - Eric L
> > >
> > > On Tue, May 14, 2019 at 10:38 AM Eric Lilja 
> > wrote:
> > >
> > >> I also see a failure for MCHECKSTYLE-54 on Windows. (Sorry, I didn't
> try
> > >> the source zip, just cloned master)
> > >>
> > >> I tested on one of our corporate laptops:
> > >> Windows 10
> > >> Cygwin 64-bit (I use it to clone the repo and use Maven)
> > >> Maven 3.6.0
> > >> Java 8 update 202
> > >>
> > >> The build log says:
> > >> [INFO] There are 2 errors reported by Checkstyle 8.19 with
> > sun_checks.xml
> > >> ruleset.
> > >> [ERROR]
> > >>
> >
> src\main\java\org\apache\maven\plugins\checkstyle\mcheckstyle54\Mcheckstyle54.java:[1]
> > >> (misc) NewlineAtEndOfFile: File does not end with a newline.
> > >> [ERROR]
> > >>
> >
> src\main\java\org\apache\maven\plugins\checkstyle\mcheckstyle54\package-info.java:[1]
> > >> (misc) NewlineAtEndOfFile: File does not end with a newline.
> > >>
> > >> These two files end with unix-style line breaks (as expected with my
> > >> setup).
> > >>
> > >> - Eric L
> > >>
> > >>
> > >> On Tue, May 14, 2019 at 8:10 AM Enrico Olivelli 
> > >> wrote:
> > >>
> > >>> Il lun 13 mag 2019, 23:48 Tibor Digana  ha
> > >>> scritto:
> > >>>
> > >>> > Robert, I did *not* use the source zip.
> > >>> >
> > >>>
> > >>> IMHO we should vote on the staged zip
> > >>>
> > >>>
> > >>> > git clone
> > https://gitbox.apache.org/repos/asf/maven-checkstyle-plugin
> > >>> > Oracle jdk 1.8.0u212, Maven 3.3.9, Windows 10
> > 

Re: Maven-enforcer-plugin's use of aether-util in transitive dependency

[Tomo Suzuki]

Hi Enrico,

I see you successfully merged the pull request. Thank you for taking care
of this!

Regards,
Tomo


On Wed, May 15, 2019 at 4:29 AM Enrico Olivelli  wrote:

> Thanks Tomo for the heads up.
> I will move the patch forward.
>
>
> Enrico
>
> Il giorno mar 14 mag 2019 alle ore 22:08 Tomo Suzuki
>  ha scritto:
>
> > Hi Enrico,
> >
> > The PR https://github.com/apache/maven-enforcer/pull/52  has been
> approved
> > (Thanks!) but not merged yet.
> > Is this something you can take care of, or should I take any action?
> >
> > Regards,
> > Tomo
> >
> > *From: *Tomo Suzuki 
> > *Date: *Mon, Mar 18, 2019 at 12:15 AM
> > *To: *Maven Developers List
> >
> > Enrico,
> > >
> > > Created the PR. https://github.com/apache/maven-enforcer/pull/52
> > >
> > > Regards,
> > > Tomo
> > >
> > >
> > > On Sun, Mar 17, 2019 at 5:17 PM Enrico Olivelli 
> > > wrote:
> > >
> > >> Awesome
> > >> Let's see the PR
> > >>
> > >> Thanks
> > >> Enrico
> > >>
> > >> Il mer 13 mar 2019, 22:19 Tomo Suzuki  ha
> > >> scritto:
> > >>
> > >> > Hi Maven developers,
> > >> > (following "Contributing" section of maven-enforcer-plugin
> > >> > )
> > >> >
> > >> > I'm thinking to raise a PR to fix an issue below, so that
> > >> > maven-enforcer-plugin can work with maven-resolver-util without
> > explicit
> > >> > "exclusion" element. Let me know what you think!
> > >> >
> > >> > While writing a custom enforcer rule, I encountered
> NoSuchMethodError
> > >> > org.eclipse.aether.util.ConfigUtils.getFloat. I believe it is caused
> > by
> > >> > transitive dependency in org.eclipse.aether:aether-util. The class
> is
> > >> also
> > >> > in org.apache.maven.resolver:maven-resolver-util:1.3.1. A workaround
> > >> with
> > >> > exclusion element
> > >> > <
> > >> >
> > >>
> >
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/master/enforcer-rules/pom.xml#L64
> > >> > >
> > >> > just worked fine for me but I'd like to contribute to fix the root
> > >> cause if
> > >> > possible.
> > >> >
> > >> > --
> > >> > Regards,
> > >> > Tomo
> > >> >
> > >>
> > >
> > >
> > > --
> > > Regards,
> > > Tomo
> > >
> >
> >
> > --
> > Regards,
> > Tomo
> >
>


-- 
Regards,
Tomo

Re: Maven-enforcer-plugin's use of aether-util in transitive dependency

[Enrico Olivelli]

Thanks Tomo for the heads up.
I will move the patch forward.


Enrico

Il giorno mar 14 mag 2019 alle ore 22:08 Tomo Suzuki
 ha scritto:

> Hi Enrico,
>
> The PR https://github.com/apache/maven-enforcer/pull/52  has been approved
> (Thanks!) but not merged yet.
> Is this something you can take care of, or should I take any action?
>
> Regards,
> Tomo
>
> *From: *Tomo Suzuki 
> *Date: *Mon, Mar 18, 2019 at 12:15 AM
> *To: *Maven Developers List
>
> Enrico,
> >
> > Created the PR. https://github.com/apache/maven-enforcer/pull/52
> >
> > Regards,
> > Tomo
> >
> >
> > On Sun, Mar 17, 2019 at 5:17 PM Enrico Olivelli 
> > wrote:
> >
> >> Awesome
> >> Let's see the PR
> >>
> >> Thanks
> >> Enrico
> >>
> >> Il mer 13 mar 2019, 22:19 Tomo Suzuki  ha
> >> scritto:
> >>
> >> > Hi Maven developers,
> >> > (following "Contributing" section of maven-enforcer-plugin
> >> > )
> >> >
> >> > I'm thinking to raise a PR to fix an issue below, so that
> >> > maven-enforcer-plugin can work with maven-resolver-util without
> explicit
> >> > "exclusion" element. Let me know what you think!
> >> >
> >> > While writing a custom enforcer rule, I encountered NoSuchMethodError
> >> > org.eclipse.aether.util.ConfigUtils.getFloat. I believe it is caused
> by
> >> > transitive dependency in org.eclipse.aether:aether-util. The class is
> >> also
> >> > in org.apache.maven.resolver:maven-resolver-util:1.3.1. A workaround
> >> with
> >> > exclusion element
> >> > <
> >> >
> >>
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/master/enforcer-rules/pom.xml#L64
> >> > >
> >> > just worked fine for me but I'd like to contribute to fix the root
> >> cause if
> >> > possible.
> >> >
> >> > --
> >> > Regards,
> >> > Tomo
> >> >
> >>
> >
> >
> > --
> > Regards,
> > Tomo
> >
>
>
> --
> Regards,
> Tomo
>