Skip to content

Conversation

slachiewicz
Copy link
Member

Rebased version of@hwellmann pull #2

I do not know if it's faster now, but I managed to compile the Maven project successfully and the it-core-tests completed correctly.

@slachiewicz slachiewicz changed the title Feature/mresolver 7v2 [MRESOLVER-7] Download dependency POMs in parallel v2 Nov 25, 2017
Copy link
Member

@michael-o michael-o left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There changes need to be separate issues.

Copy link
Member

@michael-o michael-o left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should also be a separate issue.

@slachiewicz
Copy link
Member Author

@michael-o what changes i should move? all 3 commits?

@michael-o
Copy link
Member

The subpackage and version bumps.

@slachiewicz
Copy link
Member Author

slachiewicz commented Nov 30, 2017

ok, I updated this PR to contain only MRESOLVER-7 and created a new #11 for dependencies update and #12 to move the dependency collector to submodule (#10 must be tested/merged first)

@mikehearn
Copy link

It looks like this has bit-rotted again. It'd be really nice to get this in.

Some classes have moved into a sub-package in #12, so now package-private visibilities are getting in the way. I wanted to try it out and see how much difference to speed it made, so I just quickly undid #12.

For me it seems to roughly double the speed of artifact fetch. It'll probably make a much bigger difference on higher latency links. Nice work!

mikehearn added a commit to mikehearn/maven-resolver that referenced this pull request Apr 7, 2018
@michael-o
Copy link
Member

@mikehearn What needs to be changed to make classes accesible for this PR? I'll change it.

@slachiewicz
Copy link
Member Author

strange, but You requested to move #11 to diffrent PR. So now You need to revert #11 then you can apply again this PR..

@michael-o
Copy link
Member

@slachiewicz I maybe wrote gibberish, I am working on five projects in parallel and simply lost track. Don't take my request as imperative.

@slachiewicz
Copy link
Member Author

and I’m just trying to help:)

@steve-todorov
Copy link

Hi guys, are there any plans for this to be merged anytime soon? We have a bit project which might benefit from this. Is there anything more needed to be done?

@michael-o
Copy link
Member

michael-o commented Jun 30, 2018

@steve-todorov Did you try the patch yourself? Unfortunately, there is a very little amount of people working on Resolver right now. I am personally too busy. There is so much new code that I have trouble to understand it, especially because I am not fully comfortable with the Resolver code. But I am still looking into it.

@slachiewicz Can you rebase again?

@slachiewicz
Copy link
Member Author

I did rebase code and I compile few projects with clean repo - it looks good and fast.
@steve-todorov could you try to test with Your projects also?

@mikehearn
Copy link

For what it's worth I've been testing it locally a fair bit and it's been working fine. However I had to fork Maven Resolver and add a few commits on top to get it working as well as I wanted it to:

https://github.com/mikehearn/maven-resolver/commits/master

Specifically, I had to roll back a change that conflicted with this PR, and then I added this commit:

mikehearn@1e2ed26

to avoid creating non-daemon threads.

@slachiewicz
Copy link
Member Author

Thx @mikehearn for tests and suggestion to use cachedThreadPool. I made small modification to use 5 core threads and max to 10 thread. Could you test new version?

@michael-o
Copy link
Member

Can someone tell why the daemon threads along with the cached pool is necessary?

@slachiewicz
Copy link
Member Author

ok, finaly i reuse in f195414 existing code used to create threads (org.eclipse.aether.util.concurrency.WorkerThreadFactory) in org.eclipse.aether.internal.impl.DefaultMetadataResolver#getExecutor

@michael-o
Copy link
Member

Is this one now complete and can be reviewed again by me?

@slachiewicz
Copy link
Member Author

yes, it’s final version :)

@michael-o
Copy link
Member

I will drop cf1a1f7 because this is a different issue.

Copy link
Member

@michael-o michael-o left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are you passing DefaultDependencyCollectionContext around where you have an interface for? The callers should be decoupled form the implementations.

/**
* Setup executor with 5 daemon threads in pool, max to 10 concurrent and keep alive to 10 sec inactivity.
*/
private ExecutorService executor = createExecutorService( 5, 10, 10 );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Last arg is 10L.

private static final ThreadGroup THREAD_GROUP = new ThreadGroup( "Maven Resolver dependency resolution" );

/**
* Setup executor with 5 daemon threads in pool, max to 10 concurrent and keep alive to 10 sec inactivity.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

10 sec to > 10 s.

@michael-o
Copy link
Member

Maven master fails with:

[INFO] Running org.apache.maven.repository.MirrorProcessorTest
[INFO] Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 s - in org.apache.maven.repository.MirrorProcessorTest
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   ProjectInheritanceTest.testDependencyManagement:68 Set size should be 4, is 3
[INFO]
[ERROR] Tests run: 142, Failures: 1, Errors: 0, Skipped: 0

Please review.

@michael-o
Copy link
Member

@slachiewicz I'd like to publish MRESOLVER in a couple of days. Can you have a look at the PR again please?

hwellmann and others added 2 commits September 28, 2018 21:13
Dependencies are now processed asynchronously by an Executor

Cherry-pick commit from PR#2 Nov 1, 2016
Logic aligned with DefaultMetadataResolver and BasicRepositoryConnector Executors
@slachiewicz
Copy link
Member Author

That use of DDCC is hard to remove without extending resolver-api and its jhard to understand how this work. I’m able to reproduce this bug but no idea about reason. I’ll look into this more later.

@slachiewicz
Copy link
Member Author

slachiewicz commented Oct 3, 2018

Testcase:
org.apache.maven.project.inheritance.t06.ProjectInheritanceTest#testDependencyManagement
and poms in maven-compat/src/test/resources/inheritance-repo/t06

Expected:
Artifact: maven-test:t06-a:jar 1.0 scope=compile optional=false
Artifact: maven-test:t06-b:jar 1.0 scope=compile optional=false
Artifact: maven-test:t06-d:jar 1.0 scope=test optional=false
Artifact: maven-test:t06-c:jar 1.0 scope=compile optional=false

Actual:
Artifact: maven-test:t06-a:jar 1.0 scope=compile optional=false
Artifact: maven-test:t06-b:jar 1.0 scope=compile optional=false
Artifact: maven-test:t06-c:jar 1.0 scope=compile optional=false

Can be related to https://issues.apache.org/jira/browse/MRESOLVER-9

@michael-o
Copy link
Member

While I understand MRESOLVER-9 I do not understand this failure. How can this happen if we don't have any changes in dep resolution, do we? Do I need to merge MRESOLVER-9 first?

@michael-o
Copy link
Member

@slachiewicz, do you want to take another look at it. We want to roll 1.3.1 next week. I'd be cool if we could include this. My last questions are still open.

@michael-o
Copy link
Member

@slachiewicz, do you think you can take on this? You know the change best by now.

@slachiewicz
Copy link
Member Author

Unfortunately not for this release - I need more time to isolate a problem.

@michael-o
Copy link
Member

No issue, take your time.

@gdubicki
Copy link

Hi @slachiewicz ! Were you able to get back to this? A lot of people would love to get this PR merged, see https://stackoverflow.com/questions/32299902/parallel-downloads-of-maven-artifacts/43832592 . :)

@ghost
Copy link

ghost commented Feb 9, 2019

Hi @slachiewicz, I'm very interested in this PR, what is blocking it ? What can I do to help ?

@michael-o
Copy link
Member

@juliendemaziere. Time issues. You can work on it if you like, I'll be happy to review it.

@hwellmann
Copy link
Contributor

FYI, I've looked at this issue again after all this time, and I've got it working now locally, including the entire maven-integration-testing suite.

It looks like the missing bit is indeed related to https://issues.apache.org/jira/browse/MRESOLVER-9. I'm going to submit a new PR based on this one.

Thanks to @slachiewicz and everyone else who kept the candle burning!

@michael-o
Copy link
Member

@hwellmann, what exact missing bit?

@hwellmann
Copy link
Contributor

The missing bit: see this commit 884928f in the new PR #30.

@michael-o
Copy link
Member

@hwellmann, why is #30 necessary for this PR?

@hwellmann
Copy link
Contributor

It fixes the failing test org.apache.maven.project.inheritance.t06.ProjectInheritanceTest observed by @slachiewicz in October 2018 as well as some failing tests from maven-integration-testing when using a build of Maven with this verion of Maven Resolver.

@michael-o
Copy link
Member

Can this one be closed in favor of #30?

@slachiewicz
Copy link
Member Author

Yes, of course.

@slachiewicz slachiewicz deleted the feature/MRESOLVER-7v2 branch April 23, 2019 21:11
@jira-importer
Copy link

Resolve #817

@jira-importer
Copy link

Resolve #1397

@jira-importer
Copy link

Resolve #817

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants