AW: AW: Maven intern projects

[Markus KARG]

Yes, it might be hard work, and yes, it implies discussions, and yes, currently 
only few people benefit from it.

But we need to understand to look on Maven from the side of Java 14 coders (and 
from day to day they will become more people):
* Maven has default support for totally outdated Java version.
* Maven has no native support for some Java 9 features (like this one).
* Java 9 is around for many years.
* The current LTS is Java 11, which is around for years, too.
* To sum up: From the point of *modern* users, with every day of not supporting 
these features, Maven becomes more and more NOT the best choice for them.

We should not further focus on making old things run better, but start 
investing in becoming the best build tool for Java 14 again.

-Markus


-Ursprüngliche Nachricht-
Von: Robert Scholte [mailto:rfscho...@apache.org] 
Gesendet: Montag, 13. April 2020 21:39
An: dev@maven.apache.org
Betreff: Re: AW: Maven intern projects

the problem is that with every folder you'll need a separate execution-block of 
the maven-compiler-plugin. 
I've tried to solve within a single execution block, but that made it worse and 
impossible to manage.
In the end having 1 execution block for every javac call makes sense.

Multirelease jars are only interesting for libraries, I would not advice to do 
this for applications.
So you might expect from library maintainer that they are experienced Java / 
Maven users, so I don't mind that they need to specify multiple execution 
blocks.

https://github.com/metlos/multi-release-jar-maven-plugin was an attempt to do 
what you want: 1 execution block.

However, he confirmed he did not solve the testing part.

IF you want to solve this, you need to make clear separations of what should be 
solved by Maven and what by the maven-compiler-plugin:
- Maven should make it possible to register multiple execution blocks by 
plugins *dynamically* (only the maven-compiler-plugin should be aware of all 
the source folders and the requirements per folder).

It is really not that easy and the number of users will be low.
I would invest in other issues.

Robert
On 13-4-2020 19:43:44, Markus KARG  wrote:
What users finally expect is to have multirelease JAR building being a Maven 
native functionality. This means, it should be as-easy-as putting code in these 
folders:

src/main/java/9/
src/main/java/
src/main/java/11/

then perform

mvn clean package

to get a multi-release jar -- without *any* special switches, config, or 
POM.xml tweaking, and *all* maven-*-plugins will perform the necessary steps on 
their own (e. g. compiler runs multiple times as the compiler plugins knows 
this is needed when it sees /java/number/ folders).

-Markus

-Ursprüngliche Nachricht-
Von: Elliotte Rusty Harold [mailto:elh...@ibiblio.org]
Gesendet: Montag, 13. April 2020 19:02
An: Maven Developers List
Betreff: Re: Maven intern projects

On Mon, Apr 13, 2020 at 11:50 AM Robert Scholte wrote:
>
> Just to be clear: Multirelease jars is a JDK 9+ feature. With Maven it is 
> possible to make them, to test them and to run them. But they are pretty hard 
> to maintain.
> So I would prefer NOT to try make Multirelease Jars of our libraries, unless 
> there's a very good reason.

Yes, that's what I was thinking. Have we documented anywhere how to
make multirelease jars with Maven? My impression from googling was
that this doesn't work yet, but I guess that's not true?

What improvements could we make to improve the workflow for multimodule builds?

> If there is one thing that should be solved, but requires a lot of time, it 
> is support of ServicesLoaders
> https://issues.apache.org/jira/browse/MNG-6275
>

Thanks. I'll look at that.

I did a review pass through the issue tracker. So far these are the
ones I've found that look like they might make parts of plausible
intern level projects:

https://issues.apache.org/jira/browse/MDEP-644?jql=labels%20%3D%20intern

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



-
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 AntRun Plugin version 3.0.0

[Olivier Lamy]

+1

On Sun, 12 Apr 2020 at 17:57, Hervé BOUTEMY  wrote:

> Hi,
>
> We solved 22 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317121=12330278=Text
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1562/
>
> https://repository.apache.org/content/repositories/maven-1562/org/apache/maven/plugins/maven-antrun-plugin/3.0.0/maven-antrun-plugin-3.0.0-source-release.zip
>
> Source release checksum(s):
> maven-antrun-plugin-3.0.0-source-release.zip sha512:
> 27976fb318c8481013ba89f90eba118f25bad72704b642185b5bae2d796a3f57af7eddb7f665f1db402b2351d34b7487bb28d32e01e9c0180967f64be4836725
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-antrun-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
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

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

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

[Hervé BOUTEMY]

Hi,
 
The vote has passed with the following result:
 
+1 : Robert Scholte, Sylwester Lachiewicz, Hervé BOUTEMY, Karl Heinz Marbaise, 
Romain Manni-Bucau
 
PMC quorum reached
 
I will promote the artifacts to the central repo.



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

[VOTE] Release Maven Fluido Skin version 1.9

[Michael Osipov]

Hi,

We solved 8 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12346750=Text=12317926

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

Staging repo:
https://repository.apache.org/content/repositories/maven-1564/
https://repository.apache.org/content/repositories/maven-1564/org/apache/maven/skins/maven-fluido-skin/1.9/maven-fluido-skin-1.9-source-release.zip

Source release checksum(s):
maven-fluido-skin-1.9-source-release.zip
sha512: 
32430d431d0f578e448bd276326078a8b9acea6a5c028d1a68e0951c583ae3d3a13eaaa690446f9da593d4d3e59dae1ff843ca68f1e3b0b46596555a018810b8


Staging site:
https://maven.apache.org/components/skins-archives/maven-fluido-skin-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

Re: AW: Maven intern projects

[Robert Scholte]

the problem is that with every folder you'll need a separate execution-block of 
the maven-compiler-plugin. 
I've tried to solve within a single execution block, but that made it worse and 
impossible to manage.
In the end having 1 execution block for every javac call makes sense.

Multirelease jars are only interesting for libraries, I would not advice to do 
this for applications.
So you might expect from library maintainer that they are experienced Java / 
Maven users, so I don't mind that they need to specify multiple execution 
blocks.

https://github.com/metlos/multi-release-jar-maven-plugin was an attempt to do 
what you want: 1 execution block.

However, he confirmed he did not solve the testing part.

IF you want to solve this, you need to make clear separations of what should be 
solved by Maven and what by the maven-compiler-plugin:
- Maven should make it possible to register multiple execution blocks by 
plugins *dynamically* (only the maven-compiler-plugin should be aware of all 
the source folders and the requirements per folder).

It is really not that easy and the number of users will be low.
I would invest in other issues.

Robert
On 13-4-2020 19:43:44, Markus KARG  wrote:
What users finally expect is to have multirelease JAR building being a Maven 
native functionality. This means, it should be as-easy-as putting code in these 
folders:

src/main/java/9/
src/main/java/
src/main/java/11/

then perform

mvn clean package

to get a multi-release jar -- without *any* special switches, config, or 
POM.xml tweaking, and *all* maven-*-plugins will perform the necessary steps on 
their own (e. g. compiler runs multiple times as the compiler plugins knows 
this is needed when it sees /java/number/ folders).

-Markus

-Ursprüngliche Nachricht-
Von: Elliotte Rusty Harold [mailto:elh...@ibiblio.org]
Gesendet: Montag, 13. April 2020 19:02
An: Maven Developers List
Betreff: Re: Maven intern projects

On Mon, Apr 13, 2020 at 11:50 AM Robert Scholte wrote:
>
> Just to be clear: Multirelease jars is a JDK 9+ feature. With Maven it is 
> possible to make them, to test them and to run them. But they are pretty hard 
> to maintain.
> So I would prefer NOT to try make Multirelease Jars of our libraries, unless 
> there's a very good reason.

Yes, that's what I was thinking. Have we documented anywhere how to
make multirelease jars with Maven? My impression from googling was
that this doesn't work yet, but I guess that's not true?

What improvements could we make to improve the workflow for multimodule builds?

> If there is one thing that should be solved, but requires a lot of time, it 
> is support of ServicesLoaders
> https://issues.apache.org/jira/browse/MNG-6275
>

Thanks. I'll look at that.

I did a review pass through the issue tracker. So far these are the
ones I've found that look like they might make parts of plausible
intern level projects:

https://issues.apache.org/jira/browse/MDEP-644?jql=labels%20%3D%20intern

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



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

RE: Maven intern projects

[Jason Pyeron]

> -Original Message-
> From: Markus KARG
> Sent: Monday, April 13, 2020 1:44 PM
> 
> What users finally expect is to have multirelease JAR building being a Maven 
> native
> functionality. This means, it should be as-easy-as putting code in these 
> folders:
> 
> src/main/java/9/
> src/main/java/
> src/main/java/11/

JEP 238 does not require any specific source folder organization. Please do not 
step on 
the contents of the /java/ folder. You can accomplish the same with /java/ | 
/java.9/ | /java.11/ .

Doing so will break many, many assumptions those have made in many, many 
existing packages.

In fact, for those already having large multi release source trees, having POM 
properties to 
specify the java version source folders would be handy.

> 
> then perform
> 
> mvn clean package
> 
> to get a multi-release jar -- without *any* special switches, config, or 
> POM.xml tweaking,
> and *all* maven-*-plugins will perform the necessary steps on their own (e. 
> g. compiler
> runs multiple times as the compiler plugins knows this is needed when it sees
> /java/number/ folders).

I concur, strongly, otherwise.

> 
> -Markus

-Jason


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

AW: Maven intern projects

[Markus KARG]

What users finally expect is to have multirelease JAR building being a Maven 
native functionality. This means, it should be as-easy-as putting code in these 
folders:

src/main/java/9/
src/main/java/
src/main/java/11/

then perform

mvn clean package

to get a multi-release jar -- without *any* special switches, config, or 
POM.xml tweaking, and *all* maven-*-plugins will perform the necessary steps on 
their own (e. g. compiler runs multiple times as the compiler plugins knows 
this is needed when it sees /java/number/ folders).

-Markus

-Ursprüngliche Nachricht-
Von: Elliotte Rusty Harold [mailto:elh...@ibiblio.org] 
Gesendet: Montag, 13. April 2020 19:02
An: Maven Developers List
Betreff: Re: Maven intern projects

On Mon, Apr 13, 2020 at 11:50 AM Robert Scholte  wrote:
>
> Just to be clear: Multirelease jars is a JDK 9+ feature. With Maven it is 
> possible to make them, to test them and to run them. But they are pretty hard 
> to maintain.
> So I would prefer NOT to try make Multirelease Jars of our libraries, unless 
> there's a very good reason.

Yes, that's what I was thinking. Have we documented anywhere how to
make multirelease jars with Maven? My impression from googling was
that this doesn't work yet, but I guess that's not true?

What improvements could we make to improve the workflow for multimodule builds?

> If there is one thing that should be solved, but requires a lot of time, it 
> is support of ServicesLoaders
> https://issues.apache.org/jira/browse/MNG-6275
>

Thanks. I'll look at that.

I did a review pass through the issue tracker. So far these are the
ones I've found that look like they might make parts of plausible
intern level projects:

https://issues.apache.org/jira/browse/MDEP-644?jql=labels%20%3D%20intern

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



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

Re: support --resume-from improvement

[Enrico Olivelli]

Okay from me
The patch you are referring to is
https://github.com/apache/maven/pull/325

But I am still new to this code, other eyes are needed

Enrico


Il Lun 13 Apr 2020, 15:47 Robert Scholte  ha scritto:

> I've already demonstrated this during my video conference.
> To me it is now ready to be merged to master if others agree.
>
> In short:
> if a multimodule now fails, it'll say: call --resume-from :some-module
> This used to work with Maven 2, because for multimodule you had to call
> "install".
> However, with Maven 3 it is advices not to do so, but that implies this
> flag is broken.
> This improvement will pick up either the jar or target/classes (always the
> most recent of the 2) from the previous build.
>
> thanks,
> Robert
>
>
> https://issues.apache.org/jira/browse/MNG-4660
>

Re: Maven intern projects

[Elliotte Rusty Harold]

On Mon, Apr 13, 2020 at 11:50 AM Robert Scholte  wrote:
>
> Just to be clear: Multirelease jars is a JDK 9+ feature. With Maven it is 
> possible to make them, to test them and to run them. But they are pretty hard 
> to maintain.
> So I would prefer NOT to try make Multirelease Jars of our libraries, unless 
> there's a very good reason.

Yes, that's what I was thinking. Have we documented anywhere how to
make multirelease jars with Maven? My impression from googling was
that this doesn't work yet, but I guess that's not true?

What improvements could we make to improve the workflow for multimodule builds?

> If there is one thing that should be solved, but requires a lot of time, it 
> is support of ServicesLoaders
> https://issues.apache.org/jira/browse/MNG-6275
>

Thanks. I'll look at that.

I did a review pass through the issue tracker. So far these are the
ones I've found that look like they might make parts of plausible
intern level projects:

https://issues.apache.org/jira/browse/MDEP-644?jql=labels%20%3D%20intern

-- 
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: Maven intern projects

[Robert Scholte]

Just to be clear: Multirelease jars is a JDK 9+ feature. With Maven it is 
possible to make them, to test them and to run them. But they are pretty hard 
to maintain.
So I would prefer NOT to try make Multirelease Jars of our libraries, unless 
there's a very good reason.
The next version of Maven will require Java 8, so that already makes a lot of 
improvements available.

If there is one thing that should be solved, but requires a lot of time, it is 
support of ServicesLoaders
https://issues.apache.org/jira/browse/MNG-6275


especially with the modular system more libraries have defined services and it 
would be great if plugins could use those via the serviceloader factory or via 
guice.
I should be able to find other interesting issues.

Robert



On 13-4-2020 16:41:40, Elliotte Rusty Harold  wrote:
On Fri, Apr 10, 2020 at 1:17 PM Markus KARG wrote:

> Having said this, it would be a really great feature to get an easy-to-use 
> solution for creating multi-version-JARs.
>

This is probably the best idea so far. (Google specifically does not
want interns working on refactoring or maintenance work. New feature
development only.) Looking around I found this which appears to be a
few notes on the subject, but not more:

https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html

So I gather we don't have any multirelease support in maven yet, and I
don't think any is under way. That might be tractable for an intern
team provided they started with a clear design of what the input and
the output look like. Output is defined by the Java specs. For input,
we'd need to understand the source layout for multi-release jars. E.g.

src
main
java
java9
java14

or what exactly. We would also need to know how the pom.xml is going
to change to support this. If the maintainers think we can develop,
agree on, and commit to a specification for multirelease support in
Maven within the next month, then this could work. Does that sound
useful and feasible?

--
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 AntRun Plugin version 3.0.0

[Eric Lilja]

I was personally hoping to see the java 8 edition of ant used, as indicated
it would be in previous email threads on this list, but +1 from me
(non-binding)

A release is greatly appreciated!

- Eric L

On Sun, Apr 12, 2020 at 10:25 PM Sylwester Lachiewicz 
wrote:

> +1
> Tested with maven-archetypes, Maven ITs, resolver-ant-tasks
>
> BR
> Sylwester
>
> niedz., 12 kwi 2020 o 09:57 Hervé BOUTEMY 
> napisał(a):
>
> > Hi,
> >
> > We solved 22 issues:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317121=12330278=Text
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1562/
> >
> >
> https://repository.apache.org/content/repositories/maven-1562/org/apache/maven/plugins/maven-antrun-plugin/3.0.0/maven-antrun-plugin-3.0.0-source-release.zip
> >
> > Source release checksum(s):
> > maven-antrun-plugin-3.0.0-source-release.zip sha512:
> >
> 27976fb318c8481013ba89f90eba118f25bad72704b642185b5bae2d796a3f57af7eddb7f665f1db402b2351d34b7487bb28d32e01e9c0180967f64be4836725
> >
> > Staging site:
> > https://maven.apache.org/plugins-archives/maven-antrun-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
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Maven intern projects

[Elliotte Rusty Harold]

On Fri, Apr 10, 2020 at 1:17 PM Markus KARG  wrote:

> Having said this, it would be a really great feature to get an easy-to-use 
> solution for creating multi-version-JARs.
>

This is probably the best idea so far. (Google specifically does not
want interns working on refactoring or maintenance work. New feature
development only.) Looking around I found this which appears to be a
few notes on the subject, but not more:

https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html

So I gather we don't have any multirelease support in maven yet, and I
don't think any is under way. That might be tractable for an intern
team provided they started with a clear design of what the input and
the output look like. Output is defined by the Java specs. For input,
we'd need to understand the source layout for multi-release jars. E.g.

src
  main
   java
   java9
   java14

or what exactly. We would also need to know how the pom.xml is going
to change to support this. If the maintainers think we can develop,
agree on, and commit to a specification for multirelease support in
Maven within the next month, then this could work. Does that sound
useful and feasible?

-- 
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: Maven Runtime Metrics

[Romain Manni-Bucau]

Looks very interesting (and good work btw!), very impatient to see what the
end dump looks like with wagon and potentially local (disk) I/O!
Next step is likely to try to use as an extension a shade of a "common"
impl (I'm thinking to microprofile metrics but could be codehale one) to
have exporters and be able to persist that.

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



Le lun. 13 avr. 2020 à 15:32, Enrico Olivelli  a
écrit :

> Hi,
> news about the status of my POC:
> 1) I have created a demo Metrics Provider [1]
> 2) I have updated my branch on Maven Studies [2]
>
> It works everything as expected.
> In order to setup an appealing "demo" I have to add "interesting"
> metrics...
>
> Every suggestion is welcome, as my next step I will try to instrument the
> I/O done by Maven itself like local repository access and the model
> building time
>
> Enrico
>
> [1] https://github.com/eolivelli/simplemavenmetrics
> [2] https://github.com/apache/maven-studies/tree/maven-metrics
>
> Il giorno dom 5 apr 2020 alle ore 14:37 Enrico Olivelli <
> eolive...@gmail.com>
> ha scritto:
>
> > I have managed to use @Inject and the extensions mechanism.
> > Thank you for your advices.
> >
> > I am now implementing some useful "simple" metrics providers (two
> > "extensions") in order to see this stuff working.
> > My idea is to have two interesting implementations:
> > - Dump stats at the end of the CLI session (using local DropWizard
> > counters/summaries)
> > - Send stats to some Metrics Systems: I am using Prometheus.io at work
> > so I will use that system
> >
> > It will be interesting to have some Grafana dashboard that tells be
> > how Maven is working on my laptop or on Jenkins.
> >
> > Once my POC is ready the next step will be to start instrumenting
> > useful places in Maven Core.
> > We should instrument only "useful" parts of Maven Core.
> > Many Metrics libraries provide standard JVM metrics by default.
> > I think it will be mostly up to the plugins to expose use full value.
> >
> > Personally I am interesting in seeing this stuff:
> > - execution time for checkstyle, spotbugs...
> > - execution time for javac
> > - number of network transfers (Wagon HTTP) and bandwidth
> > - time to write to disk artifacts (to local repository, in 'install',
> > to "target")
> >
> > Enrico
> >
> > Il giorno dom 29 mar 2020 alle ore 10:40 Romain Manni-Bucau
> >  ha scritto:
> > >
> > > It depends how it is done.
> > >
> > > @Inject MetricsSystem ms; will likely fail but if you inject the
> > container
> > > and do the lookup you can handle the absence of the metrics, less
> elegant
> > > but working as well.
> > >
> > > Alternative is to inject a custom compiler component and have 2
> > components
> > > impl (hints being different), one with injected metrics, one with noop
> > > metrics hardcoded.
> > > Depending the current maven version you select the right hint.
> > > Think it is more or less what we do to handle aether change in some
> > earlier
> > > maven version.
> > >
> > > 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. 29 mars 2020 à 10:33, Enrico Olivelli  a
> > > écrit :
> > >
> > > > Self answer: I had written the DefaultMetricsSystem file in the wrong
> > > > directory ! (in maven core tests!)
> > > > Sorry fo the noise
> > > >
> > > > I have just one problem.
> > > > Currently I am using Jsr300 to plug the MetricsSystem to Maven Core
> > > > and this would be the expected way for Plugins.
> > > >
> > > > Say now that I want to use my MetricsSystem bean (@Inject
> > > > MetricsSystem) in the Maven Compiler Plugin or in Wagon...
> > > > let's say we do a 3.8.2 Maven Compiler plugin and that we deliver
> this
> > > > MetricsSystem in Maven 3.7.0...
> > > > Will Maven compiler plugin 3.8.2 work on Maven 3.6.x that does not
> > > > bundle the definition of the MetricsSytem ?
> > > >
> > > > Ideally I would like to have a "null" value or a Default NOOP
> > > > implementation when the plugin is not running on Maven 3.7.0
> > > > Will it work ?
> > > >
> > > > I will continue with the POC then I will share my model.
> > > > The change to Maven Core is almost there.
> > > > Now my plan is:
> > > > - Create an independent "Maven Extension" (in my github space, non
> ASF
> > > > by now, to make it clear that this system is totally pluggable with
> > > > extensions) that 

support --resume-from improvement

[Robert Scholte]

I've already demonstrated this during my video conference.
To me it is now ready to be merged to master if others agree.

In short:
if a multimodule now fails, it'll say: call --resume-from :some-module
This used to work with Maven 2, because for multimodule you had to call 
"install".
However, with Maven 3 it is advices not to do so, but that implies this flag is 
broken.
This improvement will pick up either the jar or target/classes (always the most 
recent of the 2) from the previous build.

thanks,
Robert 


https://issues.apache.org/jira/browse/MNG-4660

Re: Maven Runtime Metrics

[Enrico Olivelli]

Hi,
news about the status of my POC:
1) I have created a demo Metrics Provider [1]
2) I have updated my branch on Maven Studies [2]

It works everything as expected.
In order to setup an appealing "demo" I have to add "interesting" metrics...

Every suggestion is welcome, as my next step I will try to instrument the
I/O done by Maven itself like local repository access and the model
building time

Enrico

[1] https://github.com/eolivelli/simplemavenmetrics
[2] https://github.com/apache/maven-studies/tree/maven-metrics

Il giorno dom 5 apr 2020 alle ore 14:37 Enrico Olivelli 
ha scritto:

> I have managed to use @Inject and the extensions mechanism.
> Thank you for your advices.
>
> I am now implementing some useful "simple" metrics providers (two
> "extensions") in order to see this stuff working.
> My idea is to have two interesting implementations:
> - Dump stats at the end of the CLI session (using local DropWizard
> counters/summaries)
> - Send stats to some Metrics Systems: I am using Prometheus.io at work
> so I will use that system
>
> It will be interesting to have some Grafana dashboard that tells be
> how Maven is working on my laptop or on Jenkins.
>
> Once my POC is ready the next step will be to start instrumenting
> useful places in Maven Core.
> We should instrument only "useful" parts of Maven Core.
> Many Metrics libraries provide standard JVM metrics by default.
> I think it will be mostly up to the plugins to expose use full value.
>
> Personally I am interesting in seeing this stuff:
> - execution time for checkstyle, spotbugs...
> - execution time for javac
> - number of network transfers (Wagon HTTP) and bandwidth
> - time to write to disk artifacts (to local repository, in 'install',
> to "target")
>
> Enrico
>
> Il giorno dom 29 mar 2020 alle ore 10:40 Romain Manni-Bucau
>  ha scritto:
> >
> > It depends how it is done.
> >
> > @Inject MetricsSystem ms; will likely fail but if you inject the
> container
> > and do the lookup you can handle the absence of the metrics, less elegant
> > but working as well.
> >
> > Alternative is to inject a custom compiler component and have 2
> components
> > impl (hints being different), one with injected metrics, one with noop
> > metrics hardcoded.
> > Depending the current maven version you select the right hint.
> > Think it is more or less what we do to handle aether change in some
> earlier
> > maven version.
> >
> > 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. 29 mars 2020 à 10:33, Enrico Olivelli  a
> > écrit :
> >
> > > Self answer: I had written the DefaultMetricsSystem file in the wrong
> > > directory ! (in maven core tests!)
> > > Sorry fo the noise
> > >
> > > I have just one problem.
> > > Currently I am using Jsr300 to plug the MetricsSystem to Maven Core
> > > and this would be the expected way for Plugins.
> > >
> > > Say now that I want to use my MetricsSystem bean (@Inject
> > > MetricsSystem) in the Maven Compiler Plugin or in Wagon...
> > > let's say we do a 3.8.2 Maven Compiler plugin and that we deliver this
> > > MetricsSystem in Maven 3.7.0...
> > > Will Maven compiler plugin 3.8.2 work on Maven 3.6.x that does not
> > > bundle the definition of the MetricsSytem ?
> > >
> > > Ideally I would like to have a "null" value or a Default NOOP
> > > implementation when the plugin is not running on Maven 3.7.0
> > > Will it work ?
> > >
> > > I will continue with the POC then I will share my model.
> > > The change to Maven Core is almost there.
> > > Now my plan is:
> > > - Create an independent "Maven Extension" (in my github space, non ASF
> > > by now, to make it clear that this system is totally pluggable with
> > > extensions) that wraps Dropwizard Metrics and outputs the results to
> > > file at the end of the build
> > > - Add some initial metrics in Maven runtime
> > > - Try with some plugin
> > >
> > >
> > >
> > >
> > > Enrico
> > >
> > > Il giorno sab 28 mar 2020 alle ore 15:57 Enrico Olivelli
> > >  ha scritto:
> > > >
> > > > Hi,
> > > > I have pushed a new version of my prof-of-concept
> > > >
> https://github.com/apache/maven-studies/compare/maven-metrics?expand=1
> > > >
> > > > I am introducing a MetricsSystem interface and a DefaultMetricsSystem
> > > CDI bean.
> > > > I am new to sisu/plexsus container.
> > > > It looks like that DefaultMetricsSystem is getting instantiated in
> > > > Maven Core tests
> > > >
> > > > This is my work:
> > > >
> https://github.com/apache/maven-studies/compare/maven-metrics?expand=1
> > > >
> > > > But if I run Maven from the command line I get the error below
> > > >
> > > > Maybe I missing some config/annotation
> > > >
> > > > Any help 

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

[Romain Manni-Bucau]

+1

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



Le lun. 13 avr. 2020 à 11:42, Karl Heinz Marbaise  a
écrit :

> Hi,
>
>
> +1 from me.
>
> Kind regards
> Karl Heinz Marbaise
> On 10.04.20 23:02, Hervé BOUTEMY wrote:
> > Hi,
> >
> > We solved 3 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12346981=Text
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1561/
> >
> https://repository.apache.org/content/repositories/maven-1561/org/apache/maven/plugins/maven-shade-plugin/3.2.3/maven-shade-plugin-3.2.3-source-release.zip
> >
> > Source release checksum(s):
> > maven-shade-plugin-3.2.3-source-release.zip sha512:
> 3dba07212d0f0f5427bea7192e2fa0dea7a7919bf396f4d93081ebc1fc02aa16b8c9a9c9139043c74138a4ae5ed7cd10ac20d9852fa59a8bbd3258a6ed6980ea
> >
> > Staging site:
> > https://maven.apache.org/plugins-archives/maven-shade-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
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

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

[Karl Heinz Marbaise]

Hi,


+1 from me.

Kind regards
Karl Heinz Marbaise
On 10.04.20 23:02, Hervé BOUTEMY wrote:

Hi,

We solved 3 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12346981=Text

Staging repo:
https://repository.apache.org/content/repositories/maven-1561/
https://repository.apache.org/content/repositories/maven-1561/org/apache/maven/plugins/maven-shade-plugin/3.2.3/maven-shade-plugin-3.2.3-source-release.zip

Source release checksum(s):
maven-shade-plugin-3.2.3-source-release.zip sha512: 
3dba07212d0f0f5427bea7192e2fa0dea7a7919bf396f4d93081ebc1fc02aa16b8c9a9c9139043c74138a4ae5ed7cd10ac20d9852fa59a8bbd3258a6ed6980ea

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



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

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

[Hervé BOUTEMY]

here is my +1

Le vendredi 10 avril 2020, 23:02:27 CEST Hervé BOUTEMY a écrit :
> Hi,
> 
> We solved 3 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921
> rsion=12346981=Text
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1561/
> https://repository.apache.org/content/repositories/maven-1561/org/apache/mav
> en/plugins/maven-shade-plugin/3.2.3/maven-shade-plugin-3.2.3-source-release.
> zip
> 
> Source release checksum(s):
> maven-shade-plugin-3.2.3-source-release.zip sha512:
> 3dba07212d0f0f5427bea7192e2fa0dea7a7919bf396f4d93081ebc1fc02aa16b8c9a9c9139
> 043c74138a4ae5ed7cd10ac20d9852fa59a8bbd3258a6ed6980ea
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-shade-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
> 
> 
> 
> -
> 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 Shade Plugin version 3.2.3

[Sylwester Lachiewicz]

+1
Sylwester

pon., 13 kwi 2020 o 10:42 Robert Scholte  napisał(a):

> +1
>
> On 10-4-2020 23:02:40, Hervé BOUTEMY  wrote:
> Hi,
>
> We solved 3 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12346981=Text
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1561/
>
> https://repository.apache.org/content/repositories/maven-1561/org/apache/maven/plugins/maven-shade-plugin/3.2.3/maven-shade-plugin-3.2.3-source-release.zip
>
> Source release checksum(s):
> maven-shade-plugin-3.2.3-source-release.zip sha512:
> 3dba07212d0f0f5427bea7192e2fa0dea7a7919bf396f4d93081ebc1fc02aa16b8c9a9c9139043c74138a4ae5ed7cd10ac20d9852fa59a8bbd3258a6ed6980ea
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-shade-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
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

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

[Robert Scholte]

+1

On 10-4-2020 23:02:40, Hervé BOUTEMY  wrote:
Hi,

We solved 3 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12346981=Text

Staging repo:
https://repository.apache.org/content/repositories/maven-1561/
https://repository.apache.org/content/repositories/maven-1561/org/apache/maven/plugins/maven-shade-plugin/3.2.3/maven-shade-plugin-3.2.3-source-release.zip

Source release checksum(s):
maven-shade-plugin-3.2.3-source-release.zip sha512: 
3dba07212d0f0f5427bea7192e2fa0dea7a7919bf396f4d93081ebc1fc02aa16b8c9a9c9139043c74138a4ae5ed7cd10ac20d9852fa59a8bbd3258a6ed6980ea

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



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