Re: seconders to first pass of performance improvements

[Sylwester Lachiewicz]

+1

W dniu pt., 26.04.2019 o 02:24 Olivier Lamy  napisał(a):

> +1
>
> On Fri, 26 Apr 2019 at 09:34, Hervé BOUTEMY  wrote:
>
> > Hi,
> >
> > I'd like to merge Stefan Oehme's PRs step by step, starting with PR #242
> > "Speed up project discovery" [1].
> > There are 4 commits for 4 Jira issues: MNG-6629, MNG-6630, MNG-6631 and
> > MNG-6632 [2]
> > Branches on ASF Jenkins are ok [3], I just had to relaunch a little bit
> > since
> > there were apparently server-related issues
> >
> > We already have 3 Maven-dev reviewers who agreed on the PR content, and
> an
> > external review asking for a little comment I'll add later: I consider
> > that as
> > the seconders we expect, and let some time for people to step in if there
> > are
> > any blocker. Without any feedback, I'll merge this WE and continue with
> > other
> > PRs the same way (using PR reviews as first pass then confirm on the ML).
> >
> > At the moment, we don't have real measures everybody can reproduce for
> > himself
> > to check the improvements: if anybody has a concrete recipe to start
> doing
> > local measure, don't hesitate to share.
> >
> > Regards,
> >
> > Hervé
> >
> >
> > [1] https://github.com/apache/maven/pull/242
> >
> > [2] https://issues.apache.org/jira/browse/MNG-6629
> > https://issues.apache.org/jira/browse/MNG-6630
> > https://issues.apache.org/jira/browse/MNG-6631
> > https://issues.apache.org/jira/browse/MNG-6632
> >
> > [3]
> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/
> >
> >
> >
> >
> > -
> > 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
>

Re: seconders to first pass of performance improvements

[Olivier Lamy]

+1

On Fri, 26 Apr 2019 at 09:34, Hervé BOUTEMY  wrote:

> Hi,
>
> I'd like to merge Stefan Oehme's PRs step by step, starting with PR #242
> "Speed up project discovery" [1].
> There are 4 commits for 4 Jira issues: MNG-6629, MNG-6630, MNG-6631 and
> MNG-6632 [2]
> Branches on ASF Jenkins are ok [3], I just had to relaunch a little bit
> since
> there were apparently server-related issues
>
> We already have 3 Maven-dev reviewers who agreed on the PR content, and an
> external review asking for a little comment I'll add later: I consider
> that as
> the seconders we expect, and let some time for people to step in if there
> are
> any blocker. Without any feedback, I'll merge this WE and continue with
> other
> PRs the same way (using PR reviews as first pass then confirm on the ML).
>
> At the moment, we don't have real measures everybody can reproduce for
> himself
> to check the improvements: if anybody has a concrete recipe to start doing
> local measure, don't hesitate to share.
>
> Regards,
>
> Hervé
>
>
> [1] https://github.com/apache/maven/pull/242
>
> [2] https://issues.apache.org/jira/browse/MNG-6629
> https://issues.apache.org/jira/browse/MNG-6630
> https://issues.apache.org/jira/browse/MNG-6631
> https://issues.apache.org/jira/browse/MNG-6632
>
> [3] https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/
>
>
>
>
> -
> 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

seconders to first pass of performance improvements

[Hervé BOUTEMY]

Hi,

I'd like to merge Stefan Oehme's PRs step by step, starting with PR #242 
"Speed up project discovery" [1].
There are 4 commits for 4 Jira issues: MNG-6629, MNG-6630, MNG-6631 and 
MNG-6632 [2]
Branches on ASF Jenkins are ok [3], I just had to relaunch a little bit since 
there were apparently server-related issues

We already have 3 Maven-dev reviewers who agreed on the PR content, and an 
external review asking for a little comment I'll add later: I consider that as 
the seconders we expect, and let some time for people to step in if there are 
any blocker. Without any feedback, I'll merge this WE and continue with other 
PRs the same way (using PR reviews as first pass then confirm on the ML).

At the moment, we don't have real measures everybody can reproduce for himself 
to check the improvements: if anybody has a concrete recipe to start doing 
local measure, don't hesitate to share.

Regards,

Hervé


[1] https://github.com/apache/maven/pull/242

[2] https://issues.apache.org/jira/browse/MNG-6629
https://issues.apache.org/jira/browse/MNG-6630
https://issues.apache.org/jira/browse/MNG-6631
https://issues.apache.org/jira/browse/MNG-6632

[3] https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/




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

Re: [VOTE] Retire Maven Repository Plugin

[Sylwester Lachiewicz]

+1
good to refresh site

W dniu wt., 23.04.2019 o 23:59 Hervé BOUTEMY 
napisał(a):

> +1
>
> I didn't even see how this plugin documentation looked like:
> https://maven.apache.org/plugins/maven-repository-plugin/
>
> Regards,
>
> Hervé
>
> Le mardi 23 avril 2019, 21:43:18 CEST Robert Scholte a écrit :
> > 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.
> >
> > One of those subprojects is the maven-repository-plugin, last released on
> > February 22, 2015. It's main purpose: a plugin that can be used to create
> > bundles of artifacts that can be uploaded to the central repository.
> Based
> > on that it seems that the maven-assembly-plugin is a better fit for that.
> >
> > I therefore propose that we retire the maven-repository-plugin.
> >
> > 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 Repository Plugin

[gaurav]

+1

On Wed 24 Apr, 2019, 2:51 AM Manfred Moser, 
wrote:

> +1
>
> Robert Scholte wrote on 2019-04-23 12:43:
>
> > Hi,
> >
> > The Apache Maven project consist of about 100 (sub)projects. Due to the
> small
> > number of volunteers and the huge amount of code to maintain we're
> missing
> > enough space to make real progress on all these projects, including
> > our ambitious 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.
> >
> > One of those subprojects is the maven-repository-plugin, last released on
> > February 22, 2015. It's main purpose: a plugin that can be used to create
> > bundles of artifacts that can be uploaded to the central repository.
> > Based on that it seems that the maven-assembly-plugin is a better fit
> for that.
> >
> > I therefore propose that we retire the maven-repository-plugin.
> >
> > 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: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Surefire maintenance release

[Enrico Olivelli]

FYI
I have staged the release artifacts at
https://repository.apache.org/content/repositories/maven-1500/
and created the tag

but I have to do some burocratic steps in JIRA before sending the
official [VOTE] email
I have sent other emails on this mailing list in order to complete my task

@Stephane Nicoll if you want to try out the artifacts you are welcome.
Anyway I will expect an official +1 on the VOTE thread

I am sorry that the procedure takes so long but the staging proceure
(mvn release:prepare...release:perform) must run all of the Its and it
longs 2h

Enrico

Il giorno gio 25 apr 2019 alle ore 10:25 Enrico Olivelli
 ha scritto:
>
> Staging the artifact now.
> It will take the whole day I guess
>
> Enrico
>
> Il mer 24 apr 2019, 13:21 Enrico Olivelli  ha scritto:
>>
>> Il giorno mer 24 apr 2019 alle ore 12:30 Tibor Digana
>>  ha scritto:
>> >
>> > What a test has failed?
>> > In this CI job all tests have passed successfully and the job is "blue".
>>
>> You are right !
>> My browser should have get messed somehow
>>
>> So we are good to go
>> sorry for beeing so late
>>
>> Enrico
>>
>> >
>> > On Wed, Apr 24, 2019 at 8:28 AM Enrico Olivelli  
>> > wrote:
>> >
>> > > I am sorry,
>> > > I had other priorities, this task is not still complete.
>> > >
>> > > Tests are still failing and this is weird because I think I saw them 
>> > > green.
>> > >
>> > > This is the link to the job
>> > >
>> > >
>> > > https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-surefire/job/release%252F2.22.2/
>> > >
>> > > Enrico
>> > >
>> > > Il gio 11 apr 2019, 08:11 Christian Stein  ha 
>> > > scritto:
>> > >
>> > > > On Thu, Apr 11, 2019 at 8:09 AM Enrico Olivelli 
>> > > > wrote:
>> > > >
>> > > > > This is the final branch from which I will cut the release.
>> > > > > https://github.com/apache/maven-surefire/tree/release/2.22.2
>> > > > >
>> > > > > Re-launched Jenkins to check for the last time:
>> > > > >
>> > > > >
>> > > >
>> > > https://builds.apache.org/job/maven-box/job/maven-surefire/job/release%252F2.22.2/
>> > > > >
>> > > > >
>> > > > Go, Jenkins, go! ;-)
>> > > >
>> > >

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

Releasing Surefire 2.22.2 - JIRA ?

[Enrico Olivelli]

Hi,
I am cutting release 2.22.2 for surefire.
Can any JIRA admin create the 2.22.2 version ?

I am also sseing a 2.22.1 version, this is to be closed, isn't it ?

Thanks
Enrico

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

Releasing Surefire 2.22.2 - no website update ?

[Enrico Olivelli]

Hi,
I am staging a release for Surefire 2.22.2, I am not cuting it from
master branchm which is 3.x.

I think I should not update the website, and in the VOTE email I don't
have to include any reference to any staging website

Is it the good way ?


Enrico

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

Re: [MJAVADOC] Where can I find the latest SNAPSHOT?

[Benedikt Ritter]

Am Do., 25. Apr. 2019 um 10:23 Uhr schrieb Olivier Lamy :

> Hi
> 3.1.1-SNAPSHOT just deployed. (
>
> https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-javadoc-plugin/3.1.1-SNAPSHOT/maven-javadoc-plugin-3.1.1-20190425.073608-1.jar
> )
> hth
> Olivier
>

Cool, thank you!


>
> On Thu, 25 Apr 2019 at 17:04, Benedikt Ritter  wrote:
>
> > Hi,
> >
> > I'd like to try my work project with the latest SNAPSHOT of the
> > maven-javadoc-plugin. The repository has 3.1.1-SNAPSHOT as latest version
> > [1] but the ASF snapshot repository only has 3.0.2-SNAPSHOT [2]. Any
> chance
> > of getting 3.1.1-SNAPSHOT into the snapshot repo?
> >
> > Thanks!
> > Benedikt
> >
> > [1]
> https://github.com/apache/maven-javadoc-plugin/blob/master/pom.xml#L33
> > [2]
> >
> >
> https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-javadoc-plugin/
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Re: Surefire maintenance release

[Enrico Olivelli]

Staging the artifact now.
It will take the whole day I guess

Enrico

Il mer 24 apr 2019, 13:21 Enrico Olivelli  ha scritto:

> Il giorno mer 24 apr 2019 alle ore 12:30 Tibor Digana
>  ha scritto:
> >
> > What a test has failed?
> > In this CI job all tests have passed successfully and the job is "blue".
>
> You are right !
> My browser should have get messed somehow
>
> So we are good to go
> sorry for beeing so late
>
> Enrico
>
> >
> > On Wed, Apr 24, 2019 at 8:28 AM Enrico Olivelli 
> wrote:
> >
> > > I am sorry,
> > > I had other priorities, this task is not still complete.
> > >
> > > Tests are still failing and this is weird because I think I saw them
> green.
> > >
> > > This is the link to the job
> > >
> > >
> > >
> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-surefire/job/release%252F2.22.2/
> > >
> > > Enrico
> > >
> > > Il gio 11 apr 2019, 08:11 Christian Stein  ha
> scritto:
> > >
> > > > On Thu, Apr 11, 2019 at 8:09 AM Enrico Olivelli  >
> > > > wrote:
> > > >
> > > > > This is the final branch from which I will cut the release.
> > > > > https://github.com/apache/maven-surefire/tree/release/2.22.2
> > > > >
> > > > > Re-launched Jenkins to check for the last time:
> > > > >
> > > > >
> > > >
> > >
> https://builds.apache.org/job/maven-box/job/maven-surefire/job/release%252F2.22.2/
> > > > >
> > > > >
> > > > Go, Jenkins, go! ;-)
> > > >
> > >
>

Re: [MJAVADOC] Where can I find the latest SNAPSHOT?

[Olivier Lamy]

Hi
3.1.1-SNAPSHOT just deployed. (
https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-javadoc-plugin/3.1.1-SNAPSHOT/maven-javadoc-plugin-3.1.1-20190425.073608-1.jar
)
hth
Olivier

On Thu, 25 Apr 2019 at 17:04, Benedikt Ritter  wrote:

> Hi,
>
> I'd like to try my work project with the latest SNAPSHOT of the
> maven-javadoc-plugin. The repository has 3.1.1-SNAPSHOT as latest version
> [1] but the ASF snapshot repository only has 3.0.2-SNAPSHOT [2]. Any chance
> of getting 3.1.1-SNAPSHOT into the snapshot repo?
>
> Thanks!
> Benedikt
>
> [1] https://github.com/apache/maven-javadoc-plugin/blob/master/pom.xml#L33
> [2]
>
> https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-javadoc-plugin/
>


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

[MJAVADOC] Where can I find the latest SNAPSHOT?

[Benedikt Ritter]

Hi,

I'd like to try my work project with the latest SNAPSHOT of the
maven-javadoc-plugin. The repository has 3.1.1-SNAPSHOT as latest version
[1] but the ASF snapshot repository only has 3.0.2-SNAPSHOT [2]. Any chance
of getting 3.1.1-SNAPSHOT into the snapshot repo?

Thanks!
Benedikt

[1] https://github.com/apache/maven-javadoc-plugin/blob/master/pom.xml#L33
[2]
https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-javadoc-plugin/

Dependency resolution

[Morrissey, Jozsef]

Hi,

My basic question is can a code base compiled entirely with maven built 
artifacts need any dependencies not defined in the pom?

Background on my issue:
I have been unable to find technical documents describing how dependencies are 
resolved based on the code base.

I am working for a company who is transferring legacy code to maven. These 
projects can contain dozens of mystery jars. I can get the applications up and 
running using mavens dependency information, however my higher ups want me to 
include all the mystery jars even if they do not appear to be required.

While playing with a decompiler and trying to curdly map the dependencies 
myself, I have discovered there are many imports which the maven configuration 
does not satisfy. This could easily be explained if maven uses an inheritance 
tree to map source code files. i.e.

project1: A->B->C   &   D->B->E
project2: F->A

In this scenario project2 would require A, B, and C, with no 
need to import D and E.

It would be great to get confirmation that this is how maven works, or else I 
may be forced to fill the companies nexus repository with garbage.

Thanks,
Jozsef Morrissey

This e-mail may contain confidential or privileged information. If you think 
you have received this e-mail in error, please advise the sender by reply 
e-mail and then delete this e-mail immediately. Thank you. Aetna

Re: Summary of meeting about Maven performance improvements

[Hervé BOUTEMY]

when your improvements are more related to some plugins, it's another type of 
issue: currently, the issues that are worked on are issues on Maven core 
preparing the full reactor model in memory, when there are many modules, 
dependencies, dependencyManagement, eventually with high depth.

But we're not yet at the stage of measuring the run after that preparation = 
when the plugins start working,. Key criterias here will probably be the 
number of source files per module, resources files, and so on. And perhaps 
some improvements here will come from core, but probably often more at plugin 
level.

Keeping a common view and common energy will be required to avoid someone 
exhausting alone on one aspect, staying misunderstood by others

Regards,

Hervé

Le mercredi 24 avril 2019, 13:29:29 CEST Jonathan Haber a écrit :
> > We need to find out who is interested in these kind improvements inside
> > the Maven community.
> 
> Just wanted to throw my two cents in. My company is a relatively large
> Maven user and we're very interested in these sorts of improvements. We've
> tried to upstream improvements in the past, but have been a bit discouraged
> by patches/PRs stagnating. So we mostly end up forking plugins and using
> those forks internally, which is a shame because no one else in the Maven
> community gets to benefit. It sounds like this customer did something
> similar with their performance improvements. So you have Maven users who
> are ready, willing, and able to contribute improvements but get defeated by
> the process, which is a shame. Obviously the Maven team has finite
> resources so I'm not suggesting that there's a trivial answer.
> 
> On Wed, Apr 24, 2019 at 4:51 AM Benedikt Ritter  wrote:
> > Hello,
> > 
> > this is a summary of a video conference call that happened yesterday
> > (April
> > 24).
> > 
> > Topic:
> > Discussion about performance improvements that have been proposed by
> > Stefan
> > Oehme, namely:
> > 
> > - [MNG-6638] - Prevent reparsing POMs in MavenMetadataSource (
> > https://github.com/apache/maven/pull/244)
> > 
> > - [MNG-6633] - Reduce memory usage of excludes (
> > https://github.com/apache/maven/pull/243)
> > 
> > - Speed up project discovery (
> > https://github.com/apache/maven/pull/242)
> > 
> > - Make location handling more
> > memory efficient (https://github.com/codehaus-plexus/modello/pull/31
> > 
> > )
> > 
> > The goal of this call was to give some more insights into how Stefan found
> > the improvements and to better understand what is missing before these
> > changes be merged.
> > 
> > Attendees of the call:
> > - Benedikt Ritter (Gradle Inc.)
> > - Stefan Oehme (Gradle Inc.)
> > - Robert Scholte (Apache Maven Team)
> > - Hervé Boutemy (Apache Maven Team; joined about half an hour after the
> > call started)
> > 
> > Summary:
> > 
> > Stefan gave some insights into how he discovered bottlenecks in Maven:
> > 
> > -
> > 
> > One of our customers has a huge Maven build:
> > -
> > 
> > Lots of sub projects (2000)
> > -
> > 
> > Lots of entries in dependency management (4000)
> > -
> > 
> > Results in a lot of garbage collection
> > -
> > 
> > Problems discovered in that build:
> > -
> > 
> > Re-parsing project POMs during dependency resolution
> > -
> > 
> > Model objects are too large because of location tracking
> > -
> > 
> > Low-level bottlenecks in project discovery (especially version
> > parsing)
> > -
> > 
> > Customer now has a Maven fork with the proposed changes included:
> > -
> > 
> > 1h 50min, 12GB RAM without changes
> > -
> > 
> > 45min, 8GB RAM with changes
> > 
> > 
> > Robert:
> > 
> > -
> > 
> > How to ensure that improvements are not broken?
> > -
> > 
> > No answer to how to test this
> > 
> > 
> > Stefan gave some insights into how performance testing works in the Gradle
> > project:
> > 
> > -
> > 
> > Build has a project generator
> > -
> > 
> > Create different projects in different shapes (e.g. lots of subprojects,
> > deeply nested projects) during the build
> > -
> > 
> > Download old Gradle version and run the build on generated projects
> > -
> > 
> > Run build again with current Gradle version
> > -
> > 
> > Compare results
> > -
> > 
> > use statistic methods to filter out variance
> > -
> > 
> > Downside to this approach is that it requires a lot of computing
> > resources
> > 
> > More information can be found on GitHub:
> > https://github.com/gradle/gradle/tree/master/subprojects/performance
> > 
> > The corresponding TeamCity build can be found here:
> > 
> > https://builds.gradle.org/viewLog.html?buildId=22179604=Gradle
> > _Check_PerformanceExperimentCoordinator=report_project941_Performance&
> > branch_Gradle_Check_Stage_ReadyforRelease=master
> >