[
http://jira.codehaus.org/browse/MNG-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147819#action_147819
]
John Casey commented on MNG-3379:
---------------------------------
Hi Don,
(reposting my email to you here).
{noformat}
I was wondering if you could help us get this feature ready for introduction
into Maven 2.1.0. We're putting together a release plan for it right now at:
http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Release+Plan
As you can see, things have changed WRT the versioning in Maven's future. The
former 2.1 code - on trunk - has been renamed to 3.0-SNAPSHOT since it contains
extensive changes, and we've decided to introduce some intermediary releases
that will incorporate less risky new features such as parallel downloads that
don't fit on the 2.0.x codeline appropriately. We're also going to be putting
2.0.x in end-of-life mode very soon.
I've heard good things about your patch for parallel downloads, but since I'm
trying to push to make sure we have adequate documentation and tests for
everything new that goes into Maven, we're still coming up short on this
feature.
Can you provide us with a small design document just laying out the problem you
solved, including scoping (for instance discussion about groupId limitations,
and maybe any known issues on CI systems where multiple Maven processes may be
sharing a single local repository with large numbers of parallel downloads
happening simultaneously) and a short blurb describing your solution.
Also, we need to create some tests that we can use to guard against regressions
in the future. Since you know this code the best, it'd be very helpful if you
could help us design some test cases that might verify key pieces of the code
to make sure nothing is broken (for instance, nothing that might introduce
threading problems or file-locking issues).
If you can provide some of this information, it will allow us to put this
feature into 2.1.0. Otherwise, I'm not sure whether we have the resource-hours
available to grok the code, reconstruct the design decisions you took, and come
up with adequate tests.
{noformat}
> Parallel resolution of artifacts
> --------------------------------
>
> Key: MNG-3379
> URL: http://jira.codehaus.org/browse/MNG-3379
> Project: Maven 2
> Issue Type: New Feature
> Components: Artifacts and Repositories
> Affects Versions: 2.0.8
> Reporter: Don Brown
> Assignee: Brett Porter
> Fix For: 2.0.11
>
> Attachments: parallel-resolution-2.diff, parallel-resolution-3.diff,
> parallel-resolution.diff
>
>
> Artifacts should be resolved in parallel, grouped by group id's to get around
> the lack of synchronization in the local repository. The patch does the
> following:
> * Use a ThreadPoolExecutor to parallelize artifact resolution, but takes care
> not to resolve multiple artifacts from the same group id simultaneously.
> (requires Java 5)
> * Makes the http wagon the default instead of the poor performing http-client
> Disadvantages:
> * Requires Java 5, but the backport jars could be substituted pretty easily
> * Breaks some plugins due to commons-logging being in the Maven uber jar
> (required by commons-httpclient), notably the apt plugin (maybe more should
> use the isolatedRealm setting?)
> * Screws up the progress monitor as multiple threads are updating it
> Advantages:
> * Much faster when combined with the http wagon (WAGON-98). I was seeing 40%
> improvement on some test builds.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
