maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Casey (JIRA)" <j...@codehaus.org>
Subject [jira] Issue Comment Edited: (MNG-3379) Parallel resolution of artifacts
Date Fri, 12 Sep 2008 16:08:51 GMT

    [ http://jira.codehaus.org/browse/MNG-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=147819#action_147819
] 

jdcasey edited comment on MNG-3379 at 9/12/08 11:07 AM:
-----------------------------------------------------------

Hi Don,

(reposting my email to you here, since I never got a reply)

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.


      was (Author: jdcasey):
    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

        

Mime
View raw message