|
|
|
[
Permlink
| « Hide
]
Chris Custine - 28/Jan/08 11:50 AM
I like the way this is going, but if I am not mistaken it appears that the patch ignores certain settings such as -Dmaven.repo.local and mirror settings in ~/.m2/settings.xml.
Hey Don, you are right, it isn't your patch that broke this. I was testing this patch against 2.0.9-SNAPSHOT from SVN and got your changes intermingled with some recent updates from SVN which broke maven.repo.local setting.
Hey Chris - have you created a new issue for the problems you are experiencing?
Don, can you clarify the 3rd patch? It seems that you are using the normal wagon-http, not the standalone one from WAGONHTTP-17 - is this because you just substituted it in your local repo, or did you actually get it working with the standard dependency?
do you have a test project that fails if you use standard wagon-http, but works with your version? The ones I've tested worked without making the substitution and I want to check the shade plugin is working as expected... you mentioned the apt plugin?
Try struts2-core - https://svn.apache.org/repos/asf/struts/struts2/trunk/core
that worked. I'll be integrating this on another branch since some modifications are still needed and I noticed your own branch has moved on already
branch is at https://svn.apache.org/repos/asf/maven/sandbox/branches/maven/MNG-3379
Here are the changes I'd like to review:
on the last one - it was more to be able to limit the number if you don't want to soak your bandwidth too
might want to adjust the shading mechanism and do that in the distribution rather than the wagonhttp-17 method
do we need to be concerned at all with file-locking in the repository with this? We have an issue open for concurrent writes into the local repo, MNG-2802, but I expect this to be more about concurrent Maven processes running on the same machine, rather than concurrent retrieval of artifacts within one process. This is mainly because the resolution process will probably not cause the type of file overlap that could cause problems, though in the case of metadata I can see how it might...
Are there any plans to patch this into a version of maven 2? I had hoped it would make it into 2.0.9. I was really looking forward to the speed improvements as a result of parallel/asynchronous downloads of dependencies.
I recreated the MNG-3379 branch but without the wagon changes. I also improved the console monitor so it now properly handles multiple files being retrieved simultaneously. What more needs to be done before the changes are moved into the 2.0.x branch?
the branch for this issue looks ok to me - though I see you've made additional changes on a labeled branch as well.
Is the MNG-3379 branch the complete list of changes you want to submit? Brian - what kind of ITs do you envisage for this? Something that downloads a large number of artifacts from a file://
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. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||