Re: Maven Runtime Metrics System - MNG-6899

Il Lun 1 Giu 2020, 07:08 Romain Manni-Bucau ha scritto: > Hi Enrico, > > As mentionned I think 5 would be an error, we should provide an in memory > flavor with a dump at exist (-Dmaven.metrics.dumpOnExit=/tmp/metrics.csv or > so?) otherwise it will be a noop for user so not sure it is worth

Re: Maven Runtime Metrics System - MNG-6899

Hi Enrico, As mentionned I think 5 would be an error, we should provide an in memory flavor with a dump at exist (-Dmaven.metrics.dumpOnExit=/tmp/metrics.csv or so?) otherwise it will be a noop for user so not sure it is worth having it at all. In other words, if you want it as a vendor you put a

Re: Plexus Logging API

Le dim. 31 mai 2020 à 23:26, Benson Margulies a écrit : > We made a community decision years ago to support slf4j. It's not helpful > to cast aspersions on it. If someone wants to lead an effort to supplant > that with log4j now that it's alive again, or even jul (please, no), > someone can

Re: Plexus Logging API

We made a community decision years ago to support slf4j. It's not helpful to cast aspersions on it. If someone wants to lead an effort to supplant that with log4j now that it's alive again, or even jul (please, no), someone can start that process. Until then, using slf4j in an plugin is an

Re: Plexus Logging API

I'd be happy to use JUL instead if that works better. No extra dependencies at all, and presumably no version conflicts. For the moment I'm not proposing any major changes to existing APIs, aside from perhaps marking some classes no longer implement AbstractLogEnabled. My question is when we have

Re: Moving hashes (checksums) forward

Am 2020-05-31 um 17:19 schrieb Robert Scholte: hi, I would be great if Sonatype could lead this request. It seems like a similar process compared to the TLSv1.2 requirement and the drop of http They have the best overview in how to handle the switch to different hashes. You can already start

Re: Moving hashes (checksums) forward

Here is the PR draft: https://github.com/apache/maven-resolver/pull/52 Feel free to review - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org

Re: Plexus Logging API

niedz., 31 maj 2020 o 21:41 Romain Manni-Bucau napisał(a): > True but JUL is also there since more time, no? I meant that the SLF4J API is delivered with the Maven 3.1 installation > More seriously I think most plugins stick to getLog and bridge the output > cause otherwise the behavior is

Re: Maven Runtime Metrics System - MNG-6899

Hey guys, I feel this Metrics Runtime API will be very useful to Maven and Maven plugins. But I am not sure we are reaching consensus. Main points: 1) We will introduce a Metrics Provider API, maintained by Maven project. 2) Metrics are not "extension points", they are not "events",

Re: Plexus Logging API

True but JUL is also there since more time, no? More seriously I think most plugins stick to getLog and bridge the output cause otherwise the behavior is often undefined depending the stack. For ex, exec:java maven plugin generally breaks slf4j binding, so most impl caring of logs (:run) just

Re: Plexus Logging API

Just note - we already have SLF4J API from Maven 3.1 [1] available for all plugins since 2013. Sylwester [1] http://maven.apache.org/maven-logging.html niedz., 31 maj 2020 o 20:49 Xeno Amess napisał(a): > I like slf4j. > But slf4j can cause dependency hell as it really lack something > named

Re: Moving hashes (checksums) forward

I also think a phase parallel rollout would be more useful, also consider lots of projects still won't upgrade to java 8 because they want to maintain backwards compatibility. 1. maven 3.7.0 add support for list of hashes, valid list, warning list and banned list 2. maven 3.7.0 add sha-2 and

Re: Plexus Logging API

I like slf4j. But slf4j can cause dependency hell as it really lack something named backward compatibility. I met that thing in one of my repo. Really bad experience for me. Romain Manni-Bucau 于2020年6月1日周一 上午2:35写道： > Hmm,we are already bound to slf4j simple logger by conf and we dont want to >

Re: Moving hashes (checksums) forward

Am 2020-05-31 um 18:46 schrieb Maarten Mulders: Hi, It's great to see support for more secure hashing algorithms coming. At the risk of suggesting something that is already there, or is just not feasible... Wouldn't it be possible to have a smoother transition by allowing multiple hashes at

Re: Plexus Logging API

Hmm,we are already bound to slf4j simple logger by conf and we dont want to break it so less costly is slf4j, will avoid to reimpl the binding (needed with jul and log4j)...but does not solve all issues with plugins and conflicts (jul would). That said not sure we can do better without a huge

Re: Plexus Logging API

I'm sure you all know that Apache's own Log4j 2 has it's own API facade with a backing implementation and bridges to other logging systems like SLF4 and Logback, and Java Logging. Not only that but it is actively maintained by more than a single BDFL (like yours truly) I won't debate the pros vs

Re: Plexus Logging API

We are talking about Maven Core and package org.codehaus.plexus.logging. right? If I understand correctly the current dependency tree - it's imported and used from org.eclipse.sisu:org.eclipse.sisu.plexus artifact In general +1 to move all internal Logger instances to from Plexus to SLF4J S.

[GitHub] [maven-shared-jar] slachiewicz commented on pull request #4: [MSHARED-887] set Maven 3.1.0 as minimum and cleanup dependencies

slachiewicz commented on pull request #4: URL: https://github.com/apache/maven-shared-jar/pull/4#issuecomment-636504356 I use the plexus version that was imported by the Maven 3.1 dependencies (3.1.1 already has a different version). It seems to me that if we use a newer version of Plexus

Re: Plexus Logging API

Some pro's and cons: There have always been concerns about SLF4J, especially because it is maintained by only one person. Although Ceki did help us to make Maven work well with SLF4J, it still is a risk. Depending on third party libraries always comes with a risk. Having our own logging

Re: Plexus Logging API

To be clear, my proposal is not to do anything to the plexus logging API or the code in the plexus project. I simply would like to chamge some Maven code to call SLF4J instead of Plexus logging. On Sun, May 31, 2020 at 12:43 PM Romain Manni-Bucau wrote: > > If it does not break mojos (thinking

Re: Moving hashes (checksums) forward

Hi, It's great to see support for more secure hashing algorithms coming. At the risk of suggesting something that is already there, or is just not feasible... Wouldn't it be possible to have a smoother transition by allowing multiple hashes at the same time? When resolving, if there is a

Re: Plexus Logging API

If it does not break mojos (thinking to getLog API) +1 from me, otherwise I would be -1 until a compatibility module is properly added to the distro. Romain Manni-Bucau @rmannibucau | Blog | Old Blog

Re: Plexus Logging API

+1 to rip out plexus logging On Sun, May 31, 2020, 17:58 Elliotte Rusty Harold wrote: > Moved from slack per suggestion: > > The documentation on logging for Maven seems of two minds: > > "Maven uses [Plexus logging API][6] with basic Maven implementation > writing to stdout. > We have reached

Plexus Logging API

Moved from slack per suggestion: The documentation on logging for Maven seems of two minds: "Maven uses [Plexus logging API][6] with basic Maven implementation writing to stdout. We have reached the decision that SLF4J is the best option for a logging API: SLF4J has reached a certain level of

[GitHub] [maven-site] elharo merged pull request #172: docs: https links

elharo merged pull request #172: URL: https://github.com/apache/maven-site/pull/172 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to

[GitHub] [maven-shared-jar] elharo commented on pull request #4: [MSHARED-887] set Maven 3.1.0 as minimum and cleanup dependencies

elharo commented on pull request #4: URL: https://github.com/apache/maven-shared-jar/pull/4#issuecomment-636486988 @slachiewicz After looking at that commit, the difference seems to be that this PR imports plexus-containers-default and that one imports org.eclipse.sisu.plexus. I'm

Re: Moving hashes (checksums) forward

hi, I would be great if Sonatype could lead this request. It seems like a similar process compared to the TLSv1.2 requirement and the drop of http They have the best overview in how to handle the switch to different hashes. You can already start with #1, but until then I would be careful with #2

Moving hashes (checksums) forward

Folks, I have been recently (indirectly) approached by Mark Thomas for the Tomcat committers that he wants to provide SHA-2 hashes for all uploaded Tomcat artifacts in Central. Since Nexus 2.14.18 supports this properly for validation, I have picked up MRESOLVER-56 and asked for testing.

[GitHub] [maven-shared-jar] elharo commented on pull request #4: [MSHARED-905] set Maven 3.1.0 as minimum and cleanup dependencies

elharo commented on pull request #4: URL: https://github.com/apache/maven-shared-jar/pull/4#issuecomment-636474949 That code doesn't seem to be in HEAD? This is an automated message from the Apache Git Service. To respond

[GitHub] [maven-shared-jar] elharo merged pull request #3: ignore more metadata files

elharo merged pull request #3: URL: https://github.com/apache/maven-shared-jar/pull/3 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go

[GitHub] [maven-shared-jar] slachiewicz commented on pull request #4: [MSHARED-905] set Maven 3.1.0 as minimum and cleanup dependencies

slachiewicz commented on pull request #4: URL: https://github.com/apache/maven-shared-jar/pull/4#issuecomment-636472449 https://github.com/apache/maven-shared-jar/commit/580f53c1b63a7630cb3a70822035f4531bfadf2b This is an

[GitHub] [maven-shared-jar] slachiewicz edited a comment on pull request #4: [MSHARED-905] set Maven 3.1.0 as minimum and cleanup dependencies

slachiewicz edited a comment on pull request #4: URL: https://github.com/apache/maven-shared-jar/pull/4#issuecomment-636472449 See other jira and commit https://github.com/apache/maven-shared-jar/commit/580f53c1b63a7630cb3a70822035f4531bfadf2b

[GitHub] [maven-site] elharo opened a new pull request #172: docs: https links

elharo opened a new pull request #172: URL: https://github.com/apache/maven-site/pull/172 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to

[GitHub] [maven-shared-jar] elharo opened a new pull request #4: [MSHARED-905] set Maven 3.1.0 as minimum and cleanup dependencies

elharo opened a new pull request #4: URL: https://github.com/apache/maven-shared-jar/pull/4 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above

[GitHub] [maven-shared-jar] elharo opened a new pull request #3: ignore more metadata files

elharo opened a new pull request #3: URL: https://github.com/apache/maven-shared-jar/pull/3 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above

Re: [VOTE] Release Apache Maven Shade Plugin version 3.2.4

+1 niedz., 31 maj 2020, 12:09 użytkownik Karl Heinz Marbaise napisał: > Hi, > > +1 from me. > > Kind regards > Karl Heinz Marbaise > On 23.05.20 17:38, Hervé BOUTEMY wrote: > > Hi, > > > > We solved 4 issues: > > >

Re: [VOTE] Release Apache Maven Shade Plugin version 3.2.4

Hi, +1 from me. Kind regards Karl Heinz Marbaise On 23.05.20 17:38, Hervé BOUTEMY wrote: Hi, We solved 4 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12348077=Text Staging repo: https://repository.apache.org/content/repositories/maven-1578/

[RESULT] [VOTE] Release Apache Maven Shade Plugin version 3.2.4

Hi, The vote has passed with the following result: +1 : Robert Scholte, Olivier Lamy, Hervé Boutemy PMC quorum reached I will promote the artifacts to the central repo. - To unsubscribe, e-mail:

Re: PR spam

The Former Roles chapter on the Project Roles page [1] describes how we work, including the use of Commit Then Review. Robert [1] https://maven.apache.org/project-roles.html#formal-roles On 31-5-2020 08:00:20, Enrico Olivelli wrote: Il Dom 31 Mag 2020, 00:57 Olivier Lamy ha scritto: > Hi >

Re: PR spam

Il Dom 31 Mag 2020, 00:57 Olivier Lamy ha scritto: > Hi > First I'm not against PR and people asking review. > But for obvious changes, we can probably avoid PR (ie some spam especially > when people tag you in the description of a PR). > We have a long history about commit-then-review so let's