Re: Maven Runtime Metrics System - MNG-6899

[Romain Manni-Bucau]

Le lun. 1 juin 2020 à 10:31, Robert Scholte  a écrit :

> My main concerns are:
> - Performance: adding metrics should have (close to) no impact on current
> performance. For short builds metrics might not add enough value, and our
> aim should be fast and short builds. Metrics is a tool to analyze in case
> you seek improvements of your builds
>

Default should stay NOOP so think it matches that


> - Portability:Coincidentally there was just a thread about logging as
> well, Plexus Logger versus SLF4J. One of the things you see is  that we
> regret that Plexus Logger is part of the API.
> In Maven core there is no logging API, so for the same reason I think
> there should be no metrics API in Maven core either.
> Portability is about users being able to pick there own tool to do analysis
> Portability is about plugin-developers users being able to pick there own
> metrics API if they want.
>
> Portability is about Maven being able to switch to a future standard,
> like micrometer, microprofile or something else.
>

This can only be guaranteed having our own API since there is no standard -
and coming ones are biased (cloud) + spread accross vendors enough to not
match Maven anytime soon so abstracting it is securing our codebase and
avoid breaking change and to have to stay on outdated version.
(side note: not saying I'm happy with that but this is our current
ecosystem and it will not be better in the coming years IMHO).


>
> Robert
> On 1-6-2020 07:46:16, Enrico Olivelli  wrote:
> 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 having
> it
> > at all.
> >
>
> Here it is the implementation
> It is only a matter of pushing it to our ASF repository.
> It is mostly a cut and paste of the same stuff we did in Zookeeper project.
>
> No problem in pushing it to Maven repository from my side.
>
>
> Enrico
>
> In other words, if you want it as a vendor you put a javaagent on the JVM
> > and you are done with the added value of getting metrics.
> > I don't mean I think we must not have it, I strongly think we must, but I
> > also think it is only worth if usable directly, even if limited to in
> > memory case.
> >
> > Romain Manni-Bucau
> > @rmannibucau | Blog
> > | Old Blog
> > | Github <>
> > https://github.com/rmannibucau> |
> > LinkedIn | Book
> > <>
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le dim. 31 mai 2020 à 22:31, Enrico Olivelli a
> > écrit :
> >
> > > 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",
> > > implementations of the Provider API cannot alter the behaviour of Maven
> > > 3) Metrics are just "values in time" (counters, gauges, summaries) ,
> > > usually exposed as time series, they are useful to inspect the runtime
> > > low-level performances of internals of Maven core, internal libraries
> and
> > > plugins
> > > 4) The implementation of the API (the code that publishes and/or
> analyse
> > > data) is loaded using the Extensions mechanism, by default there will
> be
> > a
> > > noop implementation bundled with Maven distribution
> > > 5) We (Maven project) won't provide initially any implementation other
> > than
> > > the NOOP, in order not to add burden to Maven project. I can maintain a
> > few
> > > implementations on a separate repository, no need to add a burden to
> main
> > > Maven project.
> > > 6) Plugins will be able to register metric values using the Metrics
> API,
> > > the will look up the MetricSystem component with @Inject or with
> explicit
> > > lookup.
> > >
> > > I am glad to move forward with this project if we agree on all of the
> > > aspects.
> > > I am open to discuss again about all of the points.
> > >
> > > Thanks to everyone who already joined the discussion, I hope we could
> > ship
> > > v1 of the API in Maven 3.7 or Maven 3.8, the sooner the better
> > >
> > > Enrico
> > >
> > >
> > >
> > > Il giorno lun 11 mag 2020 alle ore 08:02 Romain Manni-Bucau <>
> > > rmannibu...@gmail.com> ha scritto:
> > >
> > > > Hmm, it shouldn't be:
> > > >
> > > > metricsSystem
> > > > .getMetricsContext()
> > > > .getSummary( "resolvePluginDependency", "Time to resolve dependencies
> > of
> > > a
> > > > plugin (ms)" )
> > > > .add( MetricsUtils.elapsedMillis( startResolve ) );
> > > >
> > > > but
> > > >
> > > > counter.add(duration).
> > > >
> > > > Resolution of the counter can be either (just in terms of inputs,
> then
> > > api
> > > > can be fluent or not, it is a detail for me):
> 

Re: [VOTE] Release Maven Resolver Ant Tasks version 1.2.1

[Michael Osipov]

Am 2020-05-30 um 22:09 schrieb Michael Osipov:

Hi,

We solved 6 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12348151 



There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20component%20%3D%20%22ant%20tasks%22%20AND%20resolution%20%3D%20Unresolved%20 



Staging repo:
https://repository.apache.org/content/repositories/maven-1583/
https://repository.apache.org/content/repositories/maven-1583/org/apache/maven/resolver/maven-resolver-ant-tasks/1.2.1/maven-resolver-ant-tasks-1.2.1-source-release.zip 



Source release checksum(s):
maven-resolver-ant-tasks-1.2.1-source-release.zip
sha512: 
746c4377e3923c071d8ed8117cc2f8e9303e325551f81040e7cb0bb5eae1cc7c604ae21e2c88496bb8b0f9919a1a121aaabcaa2aef64805b8e1a223f76fab07c 



Staging site:
https://maven.apache.org/resolver-archives/resolver-ant-tasks-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.


+1 from me

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

Re: [VOTE] Release Apache Maven Wrapper Plugin version 3.0.1

[Romain Manni-Bucau]

+1 (non binding)

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 1 juin 2020 à 09:46, Robert Scholte  a écrit :

> +1
>
>
> On 30-5-2020 11:17:43, Robert Scholte  wrote:
> Hi,
>
> I'd like to do a bootstrap release of the maven-wrapper-plugin, in order
> to configure it in the next maven-core.
>
> We solved 1 issue:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721=12348346=Text
>
> There are no issues in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MWRAPPER%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/service/local/repositories/maven-1584/
>
> https://repository.apache.org/service/local/repositories/maven-1584/content/org/apache/maven/plugins/maven-wrapper-plugin/3.0.1/maven-wrapper-plugin-3.0.1-source-release.zip
>
> (note: there are some issues with https://repository.apache.org/ : you
> cannot browse through the content, but you can download the zip )
>
> Source release checksum(s):
>
> maven-wrapper-plugin-3.0.1-source-release.zip sha512: 
> 04084e8806af4507996ce7d9caafc1a9ff2c9e278ba1c0f41552edb6516d75f1685177130c76c04c262376437d96be3083c2b46309c482ab07b74785c35dafcb
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-wrapper-plugin-LATEST/
>
> Guide to testing staged releases:
> As this is a special bootstrapping release, the following instructions are
> a proper way of testing:
>
> - clone/download+unpack current master branch of Apache Maven core (
> https://github.com/apache/maven ) (this will make all
> apache-maven-wrapper distributions available in your local repository)
> - run 'mvn -Dmaven.repo.local=/temp/wrapper-itrepo install'
> - download+unpack sources from maven-wrapper-plugin (see above)
> - run 'mvn -Dmaven.repo.local=/temp/wrapper-itrepo install'
> - go to the root of any Maven project
> - run 'mvn -Dmaven.repo.local=/temp/wrapper-itrepo wrapper:wrapper
> -DwrapperVersion=3.7.0-SNAPSHOT' with optional extra arguments
>
> NOTE: be aware of the difference between maven-wrapper and the
> maven-wrapper-plugin.
> The maven-wrapper-plugin only downloads and unpacks the maven wrapper
> scripts.
> The content of the maven-wrapper scripts are not part of the plugin, hence
> not part of this release.
> Adjustments to that content belong to Maven core
>
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>

Re: [VOTE] Release Apache Maven Wrapper Plugin version 3.0.1

[Robert Scholte]

+1


On 30-5-2020 11:17:43, Robert Scholte  wrote:
Hi,

I'd like to do a bootstrap release of the maven-wrapper-plugin, in order to 
configure it in the next maven-core. 

We solved 1 issue:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721=12348346=Text

There are no issues in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MWRAPPER%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

Staging repo:
https://repository.apache.org/service/local/repositories/maven-1584/
https://repository.apache.org/service/local/repositories/maven-1584/content/org/apache/maven/plugins/maven-wrapper-plugin/3.0.1/maven-wrapper-plugin-3.0.1-source-release.zip

(note: there are some issues with https://repository.apache.org/ : you cannot 
browse through the content, but you can download the zip )

Source release checksum(s):
maven-wrapper-plugin-3.0.1-source-release.zip sha512: 
04084e8806af4507996ce7d9caafc1a9ff2c9e278ba1c0f41552edb6516d75f1685177130c76c04c262376437d96be3083c2b46309c482ab07b74785c35dafcb

Staging site:
https://maven.apache.org/plugins-archives/maven-wrapper-plugin-LATEST/

Guide to testing staged releases:
As this is a special bootstrapping release, the following instructions are a 
proper way of testing:

- clone/download+unpack current master branch of Apache Maven core ( 
https://github.com/apache/maven ) (this will make all apache-maven-wrapper 
distributions available in your local repository)
- run 'mvn -Dmaven.repo.local=/temp/wrapper-itrepo install'
- download+unpack sources from maven-wrapper-plugin (see above)
- run 'mvn -Dmaven.repo.local=/temp/wrapper-itrepo install'
- go to the root of any Maven project
- run 'mvn -Dmaven.repo.local=/temp/wrapper-itrepo wrapper:wrapper 
-DwrapperVersion=3.7.0-SNAPSHOT' with optional extra arguments

NOTE: be aware of the difference between maven-wrapper and the 
maven-wrapper-plugin.
The maven-wrapper-plugin only downloads and unpacks the maven wrapper scripts.
The content of the maven-wrapper scripts are not part of the plugin, hence not 
part of this release.
Adjustments to that content belong to Maven core

https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1

Re: Maven Runtime Metrics System - MNG-6899

[Robert Scholte]

My main concerns are:
- Performance: adding metrics should have (close to) no impact on current 
performance. For short builds metrics might not add enough value, and our aim 
should be fast and short builds. Metrics is a tool to analyze in case you seek 
improvements of your builds
- Portability:Coincidentally there was just a thread about logging as well, 
Plexus Logger versus SLF4J. One of the things you see is  that we regret that 
Plexus Logger is part of the API.
In Maven core there is no logging API, so for the same reason I think there 
should be no metrics API in Maven core either. 
Portability is about users being able to pick there own tool to do analysis
Portability is about plugin-developers users being able to pick there own 
metrics API if they want.

Portability is about Maven being able to switch to a future standard, like 
micrometer, microprofile or something else.

Robert
On 1-6-2020 07:46:16, Enrico Olivelli  wrote:
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 having it
> at all.
>

Here it is the implementation
It is only a matter of pushing it to our ASF repository.
It is mostly a cut and paste of the same stuff we did in Zookeeper project.

No problem in pushing it to Maven repository from my side.


Enrico

In other words, if you want it as a vendor you put a javaagent on the JVM
> and you are done with the added value of getting metrics.
> I don't mean I think we must not have it, I strongly think we must, but I
> also think it is only worth if usable directly, even if limited to in
> memory case.
>
> Romain Manni-Bucau
> @rmannibucau | Blog
> | Old Blog
> | Github <>
> https://github.com/rmannibucau> |
> LinkedIn | Book
> <>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le dim. 31 mai 2020 à 22:31, Enrico Olivelli a
> écrit :
>
> > 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",
> > implementations of the Provider API cannot alter the behaviour of Maven
> > 3) Metrics are just "values in time" (counters, gauges, summaries) ,
> > usually exposed as time series, they are useful to inspect the runtime
> > low-level performances of internals of Maven core, internal libraries and
> > plugins
> > 4) The implementation of the API (the code that publishes and/or analyse
> > data) is loaded using the Extensions mechanism, by default there will be
> a
> > noop implementation bundled with Maven distribution
> > 5) We (Maven project) won't provide initially any implementation other
> than
> > the NOOP, in order not to add burden to Maven project. I can maintain a
> few
> > implementations on a separate repository, no need to add a burden to main
> > Maven project.
> > 6) Plugins will be able to register metric values using the Metrics API,
> > the will look up the MetricSystem component with @Inject or with explicit
> > lookup.
> >
> > I am glad to move forward with this project if we agree on all of the
> > aspects.
> > I am open to discuss again about all of the points.
> >
> > Thanks to everyone who already joined the discussion, I hope we could
> ship
> > v1 of the API in Maven 3.7 or Maven 3.8, the sooner the better
> >
> > Enrico
> >
> >
> >
> > Il giorno lun 11 mag 2020 alle ore 08:02 Romain Manni-Bucau <>
> > rmannibu...@gmail.com> ha scritto:
> >
> > > Hmm, it shouldn't be:
> > >
> > > metricsSystem
> > > .getMetricsContext()
> > > .getSummary( "resolvePluginDependency", "Time to resolve dependencies
> of
> > a
> > > plugin (ms)" )
> > > .add( MetricsUtils.elapsedMillis( startResolve ) );
> > >
> > > but
> > >
> > > counter.add(duration).
> > >
> > > Resolution of the counter can be either (just in terms of inputs, then
> > api
> > > can be fluent or not, it is a detail for me):
> > >
> > > Counter counter = metricSystem.get(new CounterSpec("my counter",
> "ms"));
> > >
> > > or, since any operation in maven has a scope (mojo, artifact
> resolution,
> > > ...):
> > >
> > > @Inject @MetricSpec("my-counter", "ms") Counter counter;
> > >
> > > Concretely metrics system should enable to resolve a counter from a few
> > > meta (at least name, likely also the unit) and counter is just a long
> > (then
> > > in terms of impl it is a LongAdder to be concurrency friendly I guess
> but
> > > it is a detail).
> > > We likely don't want to pay any other overhead otherwise I fully agree
> > > events are almost 1-1 in terms of feature but totally opposed in terms
> of
> > > design:
> > >
> > > 1. A counter is a unified view of data where data are 

Re: [VOTE] Release Apache Maven Wrapper Plugin version 3.0.1

[Olivier Lamy]

+1

On Sat, 30 May 2020 at 19:17, Robert Scholte  wrote:

> Hi,
>
> I'd like to do a bootstrap release of the maven-wrapper-plugin, in order
> to configure it in the next maven-core.
>
> We solved 1 issue:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721=12348346=Text
>
> There are no issues in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MWRAPPER%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/service/local/repositories/maven-1584/
>
> https://repository.apache.org/service/local/repositories/maven-1584/content/org/apache/maven/plugins/maven-wrapper-plugin/3.0.1/maven-wrapper-plugin-3.0.1-source-release.zip
>
> (note: there are some issues with https://repository.apache.org/ : you
> cannot browse through the content, but you can download the zip )
>
> Source release checksum(s):
>
> maven-wrapper-plugin-3.0.1-source-release.zip sha512: 
> 04084e8806af4507996ce7d9caafc1a9ff2c9e278ba1c0f41552edb6516d75f1685177130c76c04c262376437d96be3083c2b46309c482ab07b74785c35dafcb
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-wrapper-plugin-LATEST/
>
> Guide to testing staged releases:
> As this is a special bootstrapping release, the following instructions are
> a proper way of testing:
>
> - clone/download+unpack current master branch of Apache Maven core (
> https://github.com/apache/maven ) (this will make all
> apache-maven-wrapper distributions available in your local repository)
> - run 'mvn -Dmaven.repo.local=/temp/wrapper-itrepo install'
> - download+unpack sources from maven-wrapper-plugin (see above)
> - run 'mvn -Dmaven.repo.local=/temp/wrapper-itrepo install'
> - go to the root of any Maven project
> - run 'mvn -Dmaven.repo.local=/temp/wrapper-itrepo wrapper:wrapper
> -DwrapperVersion=3.7.0-SNAPSHOT' with optional extra arguments
>
> NOTE: be aware of the difference between maven-wrapper and the
> maven-wrapper-plugin.
> The maven-wrapper-plugin only downloads and unpacks the maven wrapper
> scripts.
> The content of the maven-wrapper scripts are not part of the plugin, hence
> not part of this release.
> Adjustments to that content belong to Maven core
>
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: [VOTE] Release Apache Maven Wrapper Plugin version 3.0.1

[Hervé BOUTEMY]

I fear there is a major issue: I could not make the injected scripts work 
because of a Windows newline:

$ ./mvnw clean
--2020-06-01 18:19:55--  
https://repository.apache.org/snapshots/org/apache/maven/maven-wrapper/3.7.0-SNAPSHOT/maven-wrapper-3.7.0-20200527.125905-8.jar%0D
Resolving repository.apache.org (repository.apache.org)... 
2a01:4f8:171:1513::2, 136.243.146.148
Connecting to repository.apache.org 
(repository.apache.org)|2a01:4f8:171:1513::2|:443... connected.
HTTP request sent, awaiting response... 401 Unauthorized

notice the %0D at the end of the downloaded url
the .mvn/maven-wrapper.properties has Windows newlines even if I'm on Linux, 
and it has more impact that expected

While at it, when download fails, there is an empty .mvn/maven-wrapper.jar 
remaining that does not trigger the download any more but 
$ ./mvnw clean
Error: Could not find or load main class 
org.apache.maven.wrapper.MavenWrapperMain


I don't know what has to be fixed at scripts level, then not really part of the 
maven-wrapper-plugin release: I'll wait for the evaluation before voting

I already fixed in Git little issues I found in sources or documentation
the release is reproducible (built with JDK 8 on Windows)

One key issue that will have to be fixed is that master is not the default 
branch (but MWRAPPER-0_WIP), then probably not protected against rewrite: I 
suppose it will require infra to be updated
https://github.com/apache/maven-wrapper-plugin/

Regards,

Hervé

Le samedi 30 mai 2020, 11:17:43 CEST Robert Scholte a écrit :
> Hi,
> 
> I'd like to do a bootstrap release of the maven-wrapper-plugin, in order to
> configure it in the next maven-core. 
> 
> We solved 1 issue:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721
> rsion=12348346=Text
> 
> There are no issues in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MWRAPPER%20AND%20
> resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
> 
> Staging repo:
> https://repository.apache.org/service/local/repositories/maven-1584/
> https://repository.apache.org/service/local/repositories/maven-1584/content/
> org/apache/maven/plugins/maven-wrapper-plugin/3.0.1/maven-wrapper-plugin-3.0
> .1-source-release.zip
> 
> (note: there are some issues with https://repository.apache.org/ : you
> cannot browse through the content, but you can download the zip )
> 
> Source release checksum(s):
> maven-wrapper-plugin-3.0.1-source-release.zip sha512: 04084e8806af4507996ce7
> d9caafc1a9ff2c9e278ba1c0f41552edb6516d75f1685177130c76c04c262376437d96be3083
> c2b46309c482ab07b74785c35dafcb
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-wrapper-plugin-LATEST/
> 
> Guide to testing staged releases:
> As this is a special bootstrapping release, the following instructions are a
> proper way of testing:
> 
> - clone/download+unpack current master branch of Apache Maven core (
> https://github.com/apache/maven ) (this will make all apache-maven-wrapper
> distributions available in your local repository) - run 'mvn
> -Dmaven.repo.local=/temp/wrapper-itrepo install'
> - download+unpack sources from maven-wrapper-plugin (see above)
> - run 'mvn -Dmaven.repo.local=/temp/wrapper-itrepo install'
> - go to the root of any Maven project
> - run 'mvn -Dmaven.repo.local=/temp/wrapper-itrepo wrapper:wrapper
> -DwrapperVersion=3.7.0-SNAPSHOT' with optional extra arguments
> 
> NOTE: be aware of the difference between maven-wrapper and the
> maven-wrapper-plugin. The maven-wrapper-plugin only downloads and unpacks
> the maven wrapper scripts. The content of the maven-wrapper scripts are not
> part of the plugin, hence not part of this release. Adjustments to that
> content belong to Maven core
> 
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1





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

Re: [VOTE] Release Maven Resolver Ant Tasks version 1.2.1

[Hervé BOUTEMY]

+1

reproducible build confirmed: reference is built with JDK 8 on Windows

Regards,

Hervé

Le samedi 30 mai 2020, 22:09:18 CEST Michael Osipov a écrit :
> Hi,
> 
> We solved 6 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628
> rsion=12348151
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%2
> 0component%20%3D%20%22ant%20tasks%22%20AND%20resolution%20%3D%20Unresolved%2
> 0
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1583/
> https://repository.apache.org/content/repositories/maven-1583/org/apache/mav
> en/resolver/maven-resolver-ant-tasks/1.2.1/maven-resolver-ant-tasks-1.2.1-so
> urce-release.zip
> 
> Source release checksum(s):
> maven-resolver-ant-tasks-1.2.1-source-release.zip
> sha512:
> 746c4377e3923c071d8ed8117cc2f8e9303e325551f81040e7cb0bb5eae1cc7c604ae21e2c88
> 496bb8b0f9919a1a121aaabcaa2aef64805b8e1a223f76fab07c
> 
> Staging site:
> https://maven.apache.org/resolver-archives/resolver-ant-tasks-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

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

[GitBox]

elharo closed 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 to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

Re: Plexus Logging API

[Romain Manni-Bucau]

Le lun. 1 juin 2020 à 13:39, Elliotte Rusty Harold  a
écrit :

> On Mon, Jun 1, 2020 at 1:06 AM Romain Manni-Bucau 
> wrote:
> >
> > So overall: +1 to clean up any internal from plexus but we should keep in
> > mind we must not expose SLF4J in *plugins* - once again it sounds like 2
> > topics even if it could be a single one to unify the logging in the whole
> > maven project.
> >
>
> Can you elaborate on what you mean by "expose"? No SLF4J types in
> public APIs? No transitive dependencies on SLF4J?
>

No promoted SLF4J package in the public API.


>
> So far what I'm gathering is that we should move away from Plexus
> logging toward SLF4J.
>

I agree but it impacts mojos (
https://github.com/apache/maven/blob/9567da2bc889a94f5c3b692b4afb310ddbacd6e5/maven-plugin-api/src/main/java/org/apache/maven/monitor/logging/DefaultLog.java)
but it is already backed by slf4j so guess while API is not broken nor
changes it is good to me.



>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Moving hashes (checksums) forward

[Brian Fox]

As will all things Maven and Central, we must consider the long tail
of versions in use. It's not going to work to flip a switch and fork
the community over updated hashes. Instead the role of Maven here
should be first to enable the new hashes but it shouldn't blow up if a
given upstream tool can't consume or produce the new hashes.

We were planning on doing some full system walks and validations on
Central in the near future for different reasons, I'll see if it's
possible to generate new hashes at the same time. I would only want to
publish updated sha2 hashes if the original sha1 hash was proper, I
don't think burying the broken hash is a good idea without subsequent
investigation.

On Sun, May 31, 2020 at 4:51 PM Michael Osipov  wrote:
>
> 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 with #1, but until then I would be careful with #2
>
> #2 can't be done w/o careful planning. That's clear.
> Who's the right contact at Sonatype? Brian Fox?
>
>
> > On 31-5-2020 16:58:58, Michael Osipov  wrote:
> > 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.
> >
> > I'd like also to discuss two proposals for the Maven community:
> > 1. Introduce SHA-2 support in Maven Resolver 1.4.3 which will go into
> > Maven 3.7.0
> > 2. Deprecate MD5 and SHA-1 with that release and make them obsolete with
> > Maven 4.0 and Maven Resolver 2.0 which will include package change also.
> >
> >
> > Those proposals have the following greater implications:
> > 1.
> > * Certain repo managers might reject hashes, they don't know. As did
> > Nexus on repository.a.o.
> > * This will incur two more requests with each upload and download. In
> > the latter, it will fail with 404 because most repo managers won't have
> > SHA-2 hashes. So fails Central for now. (will be solved with 2.)
> >
> > 2.
> > * All repo managers will need to
> > ** rehash all current content to provide SHA-2 hashes
> > ** Require SHA-2 hashes to be uploaded
> > ** Reject MD5 and SHA-1 hashes
> > * Old tools will fail because MD5 and SHA-1 hashes are gone:
> > ** Uploads will be rejected
> > ** Strict download validation will fail
> >
> > Please comment. I will also provide a draft PR soon.
> > I can cast two formal votes if required.
> >
> > Michael
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Re: Plexus Logging API

[Elliotte Rusty Harold]

On Mon, Jun 1, 2020 at 1:06 AM Romain Manni-Bucau  wrote:
>
> So overall: +1 to clean up any internal from plexus but we should keep in
> mind we must not expose SLF4J in *plugins* - once again it sounds like 2
> topics even if it could be a single one to unify the logging in the whole
> maven project.
>

Can you elaborate on what you mean by "expose"? No SLF4J types in
public APIs? No transitive dependencies on SLF4J?

So far what I'm gathering is that we should move away from Plexus
logging toward SLF4J.

-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: [VOTE] Release Apache Maven Wrapper Plugin version 3.0.1

[Hervé BOUTEMY]

ok

then +1

Regards,

Hervé

Le lundi 1 juin 2020, 23:44:07 CEST Robert Scholte a écrit :
> if you call ./mvnw, then you are already beyond the purpose of the plugin.
> The maven-wrapper-plugin is about an easy way to download and unpack the
> wrapper distribution.  What you are facing is an issue in the maven wrapper
> distribution, hence unrelated to the release of the maven-wrapper-plugin.
> 
> Robert
> 
> 
> On 1-6-2020 18:25:02, Hervé BOUTEMY  wrote:
> I fear there is a major issue: I could not make the injected scripts work
> because of a Windows newline:
> 
> $ ./mvnw clean
> --2020-06-01 18:19:55--
> https://repository.apache.org/snapshots/org/apache/maven/maven-wrapper/3.7.
> 0-SNAPSHOT/maven-wrapper-3.7.0-20200527.125905-8.jar%0D Resolving
> repository.apache.org (repository.apache.org)... 2a01:4f8:171:1513::2,
> 136.243.146.148 Connecting to repository.apache.org
> (repository.apache.org)|2a01:4f8:171:1513::2|:443... connected. HTTP
> request sent, awaiting response... 401 Unauthorized
> 
> notice the %0D at the end of the downloaded url
> the .mvn/maven-wrapper.properties has Windows newlines even if I'm on Linux,
> and it has more impact that expected
> 
> While at it, when download fails, there is an empty .mvn/maven-wrapper.jar
> remaining that does not trigger the download any more but $ ./mvnw clean
> Error: Could not find or load main class
> org.apache.maven.wrapper.MavenWrapperMain
> 
> 
> I don't know what has to be fixed at scripts level, then not really part of
> the maven-wrapper-plugin release: I'll wait for the evaluation before
> voting
> 
> I already fixed in Git little issues I found in sources or documentation
> the release is reproducible (built with JDK 8 on Windows)
> 
> One key issue that will have to be fixed is that master is not the default
> branch (but MWRAPPER-0_WIP), then probably not protected against rewrite: I
> suppose it will require infra to be updated
> https://github.com/apache/maven-wrapper-plugin/
> 
> Regards,
> 
> Hervé
> 
> Le samedi 30 mai 2020, 11:17:43 CEST Robert Scholte a écrit :
> > Hi,
> > 
> > I'd like to do a bootstrap release of the maven-wrapper-plugin, in order
> > to
> > configure it in the next maven-core.
> > 
> > We solved 1 issue:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721;
> > ve rsion=12348346=Text
> > 
> > There are no issues in JIRA:
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MWRAPPER%20AND%
> > 20
> > resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20D
> > ESC
> > 
> > Staging repo:
> > https://repository.apache.org/service/local/repositories/maven-1584/
> > https://repository.apache.org/service/local/repositories/maven-1584/conten
> > t/
> > org/apache/maven/plugins/maven-wrapper-plugin/3.0.1/maven-wrapper-plugin-
> > 3.0 .1-source-release.zip
> > 
> > (note: there are some issues with https://repository.apache.org/ : you
> > cannot browse through the content, but you can download the zip )
> > 
> > Source release checksum(s):
> > maven-wrapper-plugin-3.0.1-source-release.zip sha512:
> > 04084e8806af4507996ce7
> > d9caafc1a9ff2c9e278ba1c0f41552edb6516d75f1685177130c76c04c262376437d96be3
> > 083 c2b46309c482ab07b74785c35dafcb
> > 
> > Staging site:
> > https://maven.apache.org/plugins-archives/maven-wrapper-plugin-LATEST/
> > 
> > Guide to testing staged releases:
> > As this is a special bootstrapping release, the following instructions are
> > a proper way of testing:
> > 
> > - clone/download+unpack current master branch of Apache Maven core (
> > https://github.com/apache/maven ) (this will make all apache-maven-wrapper
> > distributions available in your local repository) - run 'mvn
> > -Dmaven.repo.local=/temp/wrapper-itrepo install'
> > - download+unpack sources from maven-wrapper-plugin (see above)
> > - run 'mvn -Dmaven.repo.local=/temp/wrapper-itrepo install'
> > - go to the root of any Maven project
> > - run 'mvn -Dmaven.repo.local=/temp/wrapper-itrepo wrapper:wrapper
> > -DwrapperVersion=3.7.0-SNAPSHOT' with optional extra arguments
> > 
> > NOTE: be aware of the difference between maven-wrapper and the
> > maven-wrapper-plugin. The maven-wrapper-plugin only downloads and unpacks
> > the maven wrapper scripts. The content of the maven-wrapper scripts are
> > not
> > part of the plugin, hence not part of this release. Adjustments to that
> > content belong to Maven core
> > 
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> > 
> > Vote open for at least 72 hours.
> > 
> > [ ] +1
> > [ ] +0
> > [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: [VOTE] Release Apache Maven Wrapper Plugin version 3.0.1

[Robert Scholte]

if you call ./mvnw, then you are already beyond the purpose of the plugin.
The maven-wrapper-plugin is about an easy way to download and unpack the 
wrapper distribution. 
What you are facing is an issue in the maven wrapper distribution, hence 
unrelated to the release of the maven-wrapper-plugin. 

Robert


On 1-6-2020 18:25:02, Hervé BOUTEMY  wrote:
I fear there is a major issue: I could not make the injected scripts work 
because of a Windows newline:

$ ./mvnw clean
--2020-06-01 18:19:55-- 
https://repository.apache.org/snapshots/org/apache/maven/maven-wrapper/3.7.0-SNAPSHOT/maven-wrapper-3.7.0-20200527.125905-8.jar%0D
Resolving repository.apache.org (repository.apache.org)... 
2a01:4f8:171:1513::2, 136.243.146.148
Connecting to repository.apache.org 
(repository.apache.org)|2a01:4f8:171:1513::2|:443... connected.
HTTP request sent, awaiting response... 401 Unauthorized

notice the %0D at the end of the downloaded url
the .mvn/maven-wrapper.properties has Windows newlines even if I'm on Linux, 
and it has more impact that expected

While at it, when download fails, there is an empty .mvn/maven-wrapper.jar 
remaining that does not trigger the download any more but
$ ./mvnw clean
Error: Could not find or load main class 
org.apache.maven.wrapper.MavenWrapperMain


I don't know what has to be fixed at scripts level, then not really part of the 
maven-wrapper-plugin release: I'll wait for the evaluation before voting

I already fixed in Git little issues I found in sources or documentation
the release is reproducible (built with JDK 8 on Windows)

One key issue that will have to be fixed is that master is not the default 
branch (but MWRAPPER-0_WIP), then probably not protected against rewrite: I 
suppose it will require infra to be updated
https://github.com/apache/maven-wrapper-plugin/

Regards,

Hervé

Le samedi 30 mai 2020, 11:17:43 CEST Robert Scholte a écrit :
> Hi,
>
> I'd like to do a bootstrap release of the maven-wrapper-plugin, in order to
> configure it in the next maven-core.
>
> We solved 1 issue:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721
> rsion=12348346=Text
>
> There are no issues in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MWRAPPER%20AND%20
> resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/service/local/repositories/maven-1584/
> https://repository.apache.org/service/local/repositories/maven-1584/content/
> org/apache/maven/plugins/maven-wrapper-plugin/3.0.1/maven-wrapper-plugin-3.0
> .1-source-release.zip
>
> (note: there are some issues with https://repository.apache.org/ : you
> cannot browse through the content, but you can download the zip )
>
> Source release checksum(s):
> maven-wrapper-plugin-3.0.1-source-release.zip sha512: 04084e8806af4507996ce7
> d9caafc1a9ff2c9e278ba1c0f41552edb6516d75f1685177130c76c04c262376437d96be3083
> c2b46309c482ab07b74785c35dafcb
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-wrapper-plugin-LATEST/
>
> Guide to testing staged releases:
> As this is a special bootstrapping release, the following instructions are a
> proper way of testing:
>
> - clone/download+unpack current master branch of Apache Maven core (
> https://github.com/apache/maven ) (this will make all apache-maven-wrapper
> distributions available in your local repository) - run 'mvn
> -Dmaven.repo.local=/temp/wrapper-itrepo install'
> - download+unpack sources from maven-wrapper-plugin (see above)
> - run 'mvn -Dmaven.repo.local=/temp/wrapper-itrepo install'
> - go to the root of any Maven project
> - run 'mvn -Dmaven.repo.local=/temp/wrapper-itrepo wrapper:wrapper
> -DwrapperVersion=3.7.0-SNAPSHOT' with optional extra arguments
>
> NOTE: be aware of the difference between maven-wrapper and the
> maven-wrapper-plugin. The maven-wrapper-plugin only downloads and unpacks
> the maven wrapper scripts. The content of the maven-wrapper scripts are not
> part of the plugin, hence not part of this release. Adjustments to that
> content belong to Maven core
>
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1





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

Re: Open Pull Requests

[Robert Oxspring]

>> Before we go to release stuff, will you need more changes maybe for
>> assembly plugin?
>> to make this faster and as we already did in past we can release all
>> together.
>> 
> 
> Great - good to know the process!
> 
> I’d briefly forgotten this all started with the assembly plugin so will bump 
> to SNAPSHOT dependencies locally and confirm whether further changes are 
> necessary.
> 

I’ve had a quick test with SNAPSHOT versions of everything and all works as 
expected. I don’t think there are any further changes I need.

Thanks,

Rob