|
History
| Log In
|
|
|
|
Are you by any chance using mirrors in your .m2/settings.xml file? If so you might want to track this bug
I'm using DSMP as a proxy but the files are already cached, to it should deliver them on the first access. I'm a bit puzzled myself. I mean, even if DSMP returns an error or something, the plugin shouldn't try to download the same artifact more then once and, as you can see at the timestamps, it's really pumps! I mean, we're talking 100 download attempts per second.
I'll try the patch for
Please try 0.0.11 dev build from update site at http://m2eclipse.codehaus.org/update/
If it still has this issue, feel free to reopen and provide settings.xml and Eclipse project with Maven's pom.xml sufficient to reproduce. Thanks. The bug is in the latest SVN version.
Here is the stack trace when the download loop happens: Thread [Worker-13] (Suspended (breakpoint at line 58 in TransferListenerAdapter)) I've set a breakpoint in TransferListenerAdapter.transferStarted() and this method is called N times with the same repository. N depends on the number of remote repositories in the project (DefaultArtifactManager.getArtifact(Artifact, List) line: 217). There are a couple of things which puzzle me: 1. I've set a breakpoint in DefaultArtifactManager.java:351 (after wagon.get()!) and I only return here after N download attempts have been made. It seems that wagon.get() already loops through the list of known remote repositories but I couldn't find the place where it does this loop! It's not the loop from DefaultArtifactManager.getArtifact(Artifact, List) line: 217! This one runs as well. It looks like the two loops run inside of each other (first, getArtifact() will call getRemoteFile(), then getRemoteFile() will invoke transferStarted() N times, then the next repository will be tried). It's also not the retry-loop in getRemoteFile(). 2. The repository in TransferListenerAdapter.transferStarted() is always the same. Next, DefaultArtifactManager.verifyChecksum() is called which calls wagon.get() again resulting in the same output again even though the files could be downloaded. I think this is because wagon doesn't create the file but a tmp-file. So when you verify the checksum, the artifact doesn't exist yet. I could reproduce this behavior with the attached project which contains more than one remote repository and which needs an artifact which isn't in the local repo, yet. I have looked into the source and I think the problem is not on the plugin side, this time.
Everytime the plugin does something with the Maven Embedder, it creates a new one and adds a new TransferListenerAdapter. This should not be a problem, because the embedder and thus the execution request and thus the TransferListener are used only for this one action and not further. But nevertheless, new embedders (or, the "wagon" component used by the embedder) still call the old transferListeners when the new embedder is invoked. This became obvious when I logged TransferListenerAdapter.toString() in its constructor and the event handler methods. This is bad because in TransferListenerAdapter.transferCompleted(), the index is updated.
Should I open a new issue against Embedder or do you want to make Jason responsible for this bug here? I'm running into the same project (a TransferListener used in a request is never being removed from the wagon).
What's the status of this issue? Has it been reported to the Maven Embedder? After examining the code, I've created a new JIRA issue to the Maven project and attached a patch.
You can track it at MNG-2985 The new maven embedder should fix this bug (and probably also I've got an unnoficial build at http://candy4appfuse.sourceforge.net/site/plugins/org.maven.ide.eclipse_0.0.11.v20070521-2114.jar The patch and a link to the embedder would be good, because it is quite an effort to build it from scratch. (Although the JAR is contained in the plugin JAR that you built.)
Patch for using a newer maven-embeder (not included).
The maven-embedder jar can be found at http://candy4appfuse.sourceforge.net/tmp/ I committed new embedder build yesterday. Can anyone please test if this issue still occur with code from trunk?
I see the jar commited to SVN, but the plug-in files haven't been modified yet, so builds from svn head will still be using the old embedder.
For example, check the bundle-classpath entry in MANIFEST.MF from head If you want me to create a patch for the committed jar, I can do that. Oh. Sorry, please wait. I hit into some issue that need to be resolved first.
It is working for me from SVN trunk.
3/06/07 23:19:51 CEST: Downloading [central] -> http://repo1.maven.org/maven2/org/hibernate/hibernate-annotations/3.2.1.ga/hibernate-annotations-3.2.1.ga.pom 3/06/07 23:19:51 CEST: Downloaded [central] -> http://repo1.maven.org/maven2/org/hibernate/hibernate-annotations/3.2.1.ga/hibernate-annotations-3.2.1.ga.pom 3/06/07 23:19:53 CEST: Downloading [central] -> http://repo1.maven.org/maven2/org/hibernate/hibernate/3.2.1.ga/hibernate-3.2.1.ga.pom 3/06/07 23:19:53 CEST: Downloaded [central] -> http://repo1.maven.org/maven2/org/hibernate/hibernate/3.2.1.ga/hibernate-3.2.1.ga.pom 3/06/07 23:19:55 CEST: Downloading [appfuse] -> http://static.appfuse.org/repository/org/hibernate/hibernate-annotations/3.2.1.ga/hibernate-annotations-3.2.1.ga.jar 3/06/07 23:20:01 CEST: Downloaded [appfuse] -> http://static.appfuse.org/repository/org/hibernate/hibernate-annotations/3.2.1.ga/hibernate-annotations-3.2.1.ga.jar 3/06/07 23:20:03 CEST: Downloading [appfuse] -> http://static.appfuse.org/repository/org/hibernate/hibernate/3.2.1.ga/hibernate-3.2.1.ga.jar 3/06/07 23:20:31 CEST: Downloaded [appfuse] -> http://static.appfuse.org/repository/org/hibernate/hibernate/3.2.1.ga/hibernate-3.2.1.ga.jar 0.0.11.20070603-1200 works fine for me.
Dependencies only get downloaded once - yeeha Same here. I think the bug can be closed.
PS: Thanks for truncating my initial comment; I didn't realize that JIRA would include it with every mail. I'm sorry to report guys that this is NOT FIXED in the latests trunk. I download and compiled 0.0.11.v2007...etc and I still get the problem. All be it not a serverly. Now it only looks for about 8-10 times each file before moving on so at best I would say it is partially fixed.
However ! This version has introduced a major new bug - dependencies in modules are not resolved at all ! This means that your eclipse project is left in a state where it think there are a lot of missing packages and junits etc will not run at all due to missing jars. It is fixed for me when I use the version from SVN (https://svn.codehaus.org/m2eclipse/trunk/org.maven.ide.eclipse
).
The dependencies problem is another issue and unrelated to this one. Please open a new issue for that. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
Plugin tries to download dependencies N times
We were also getting issues with an invalid jtds pom in ibiblio, and continually looping and complaining about it. We got past it on two desktops, but couldn't get past this problem on someone elses, so we had to drop back to using mvn eclipse:eclipse, which is a real pain.