Maven Integration for Eclipse

Plugin tries to download dependencies N times

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 0.0.11
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    2

Description

Since two weeks, I see this in the console:

14.03.07 10:51:31 CET: Reading /groovy-maven-plugin/pom.xml
14.03.07 10:51:32 CET: Downloading Repositorycentral/org/codehaus/mojo/mojo/13/mojo-13.pom.sha1
14.03.07 10:52:20 CET: Downloaded Repositorycentral/org/codehaus/mojo/mojo/13/mojo-13.pom.sha1
14.03.07 10:52:21 CET: Downloaded Repositorycentral/org/codehaus/mojo/mojo/13/mojo-13.pom.sha1
14.03.07 10:52:22 CET: Unable to index org/codehaus/mojo/mojo/13/mojo-13.pom.sha1; Lock obtain timed out: Lock@C:\DOKUME~1\DIGULAA\LOKALE~1\Temp\lucene-0de289983e6540e3d48d6e053dd4ed09-write.lock
14.03.07 10:52:22 CET: Downloaded Repositorycentral/org/codehaus/mojo/mojo/13/mojo-13.pom.sha1
14.03.07 10:52:23 CET: Downloaded Repositorycentral/org/codehaus/mojo/mojo/13/mojo-13.pom.sha1
14.03.07 10:52:24 CET: Unable to index org/codehaus/mojo/mojo/13/mojo-13.pom.sha1; Lock obtain timed out: Lock@C:\DOKUME~1\DIGULAA\LOKALE~1\Temp\lucene-0de289983e6540e3d48d6e053dd4ed09-write.lock
14.03.07 10:52:24 CET: Downloaded Repositorycentral/org/codehaus/mojo/mojo/13/mojo-13.pom.sha1
14.03.07 10:52:25 CET: Downloaded Repositorycentral/org/codehaus/mojo/mojo/13/mojo-13.pom.sha1

Am I the only one who sees this?

Attachments

  2. Text File
    MNGECLIPSE-302.patch
    31/May/07 2:58 PM
    5 kB
    Abel Muiño

Issue Links

This issue is duplicated by:
MNGECLIPSE-329 Adding a dependency to the pom causes plugin to go into loop and freeze eclipse, issuing lots of "Unable to index ..." messages Critical Closed
MNGECLIPSE-320 Strange Behaviour in TransferListenerAdapter Major Closed
This issue depends upon:
MNG-2985 DefaultWagonManager does not safely remove TransferListeners from the wagon Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Yuri Schimke added a comment -

Yeah, we were getting it with a development release of 0.11. We were having other issues with 0.10.

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.

Show
Yuri Schimke added a comment - Yeah, we were getting it with a development release of 0.11. We were having other issues with 0.10. 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.
Hide
Permalink
Phil Webb added a comment -

Are you by any chance using mirrors in your .m2/settings.xml file? If so you might want to track this bug MNGECLIPSE-274.

Show
Phil Webb added a comment - Are you by any chance using mirrors in your .m2/settings.xml file? If so you might want to track this bug MNGECLIPSE-274.
Hide
Permalink
Aaron Digulla added a comment -

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.

Show
Aaron Digulla added a comment - 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.
Hide
Permalink
Aaron Digulla added a comment -

I'll try the patch for MNGECLIPSE-274 on Monday.

Show
Aaron Digulla added a comment - I'll try the patch for MNGECLIPSE-274 on Monday.
Hide
Permalink
Eugene Kuleshov added a comment -

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.

Show
Eugene Kuleshov added a comment - 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.
Hide
Permalink
Aaron Digulla added a comment -

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))
TransferListenerAdapter.transferStarted(TransferEvent) line: 58
TransferEventSupport.fireTransferStarted(TransferEvent) line: 103
LightweightHttpWagon(AbstractWagon).fireGetStarted(Resource, File) line: 434
LightweightHttpWagon(AbstractWagon).getTransfer(Resource, File, InputStream, boolean, int) line: 249
LightweightHttpWagon(AbstractWagon).getTransfer(Resource, File, InputStream) line: 239
LightweightHttpWagon(StreamWagon).get(String, File) line: 80
DefaultArtifactManager.getRemoteFile(ArtifactRepository, File, String, String, boolean) line: 350
DefaultArtifactManager.getArtifact(Artifact, ArtifactRepository) line: 263
DefaultArtifactManager.getArtifact(Artifact, List) line: 217
EclipseArtifactResolver(DefaultArtifactResolver).resolve(Artifact, List, ArtifactRepository, boolean) line: 185
EclipseArtifactResolver(DefaultArtifactResolver).resolve(Artifact, List, ArtifactRepository) line: 73
EclipseArtifactResolver.resolve(Artifact, List, ArtifactRepository) line: 57
DefaultMavenProjectBuilder.findModelFromRepository(Artifact, List, ArtifactRepository, boolean) line: 519
DefaultMavenProjectBuilder.buildFromRepository(Artifact, List, ArtifactRepository, boolean) line: 250
MavenMetadataSource.retrieve(Artifact, ArtifactRepository, List) line: 115
DefaultArtifactCollector.recurse(ResolutionNode, Map, Map, ArtifactRepository, List, ArtifactMetadataSource, ArtifactFilter, List) line: 278
DefaultArtifactCollector.collect(Set, Artifact, Map, ArtifactRepository, List, ArtifactMetadataSource, ArtifactFilter, List) line: 70
EclipseArtifactResolver(DefaultArtifactResolver).resolveTransitively(Set, Artifact, Map, ArtifactRepository, List, ArtifactMetadataSource, ArtifactFilter, List) line: 284
EclipseArtifactResolver.resolveTransitively(Set, Artifact, Map, ArtifactRepository, List, ArtifactMetadataSource, ArtifactFilter, List) line: 96
EclipseArtifactResolver(DefaultArtifactResolver).resolveTransitively(Set, Artifact, Map, ArtifactRepository, List, ArtifactMetadataSource, ArtifactFilter) line: 272
EclipseArtifactResolver.resolveTransitively(Set, Artifact, Map, ArtifactRepository, List, ArtifactMetadataSource, ArtifactFilter) line: 105
EclipseArtifactResolver(DefaultArtifactResolver).resolveTransitively(Set, Artifact, Map, ArtifactRepository, List, ArtifactMetadataSource) line: 253
EclipseArtifactResolver.resolveTransitively(Set, Artifact, Map, ArtifactRepository, List, ArtifactMetadataSource) line: 114
DefaultMavenProjectBuilder.buildWithDependencies(File, ArtifactRepository, ProfileManager, TransferListener) line: 388
MavenEmbedder.readProjectWithDependencies(MavenExecutionRequest) line: 434
MavenModelManager.readMavenProject(IFile, IProgressMonitor, boolean, boolean) line: 360
BuildPathManager.resolveClasspathEntries(Set, Map, IFile, IFile, boolean, IProgressMonitor) line: 158
BuildPathManager.updateClasspathContainer(IProject, boolean, IProgressMonitor) line: 121
Maven2Builder.build(int, Map, IProgressMonitor) line: 75
BuildManager$2.run() line: 603
SafeRunner.run(ISafeRunnable) line: 37
BuildManager.basicBuild(int, IncrementalProjectBuilder, Map, MultiStatus, IProgressMonitor) line: 167
BuildManager.basicBuild(IProject, int, ICommand[], MultiStatus, IProgressMonitor) line: 201
BuildManager$1.run() line: 230
SafeRunner.run(ISafeRunnable) line: 37
BuildManager.basicBuild(IProject, int, MultiStatus, IProgressMonitor) line: 233
BuildManager.basicBuildLoop(IProject[], IProject[], int, MultiStatus, IProgressMonitor) line: 252
BuildManager.build(int, IProgressMonitor) line: 285
AutoBuildJob.doBuild(IProgressMonitor) line: 154
AutoBuildJob.run(IProgressMonitor) line: 217
Worker.run() line: 58

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.

Show
Aaron Digulla added a comment - 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)) TransferListenerAdapter.transferStarted(TransferEvent) line: 58 TransferEventSupport.fireTransferStarted(TransferEvent) line: 103 LightweightHttpWagon(AbstractWagon).fireGetStarted(Resource, File) line: 434 LightweightHttpWagon(AbstractWagon).getTransfer(Resource, File, InputStream, boolean, int) line: 249 LightweightHttpWagon(AbstractWagon).getTransfer(Resource, File, InputStream) line: 239 LightweightHttpWagon(StreamWagon).get(String, File) line: 80 DefaultArtifactManager.getRemoteFile(ArtifactRepository, File, String, String, boolean) line: 350 DefaultArtifactManager.getArtifact(Artifact, ArtifactRepository) line: 263 DefaultArtifactManager.getArtifact(Artifact, List) line: 217 EclipseArtifactResolver(DefaultArtifactResolver).resolve(Artifact, List, ArtifactRepository, boolean) line: 185 EclipseArtifactResolver(DefaultArtifactResolver).resolve(Artifact, List, ArtifactRepository) line: 73 EclipseArtifactResolver.resolve(Artifact, List, ArtifactRepository) line: 57 DefaultMavenProjectBuilder.findModelFromRepository(Artifact, List, ArtifactRepository, boolean) line: 519 DefaultMavenProjectBuilder.buildFromRepository(Artifact, List, ArtifactRepository, boolean) line: 250 MavenMetadataSource.retrieve(Artifact, ArtifactRepository, List) line: 115 DefaultArtifactCollector.recurse(ResolutionNode, Map, Map, ArtifactRepository, List, ArtifactMetadataSource, ArtifactFilter, List) line: 278 DefaultArtifactCollector.collect(Set, Artifact, Map, ArtifactRepository, List, ArtifactMetadataSource, ArtifactFilter, List) line: 70 EclipseArtifactResolver(DefaultArtifactResolver).resolveTransitively(Set, Artifact, Map, ArtifactRepository, List, ArtifactMetadataSource, ArtifactFilter, List) line: 284 EclipseArtifactResolver.resolveTransitively(Set, Artifact, Map, ArtifactRepository, List, ArtifactMetadataSource, ArtifactFilter, List) line: 96 EclipseArtifactResolver(DefaultArtifactResolver).resolveTransitively(Set, Artifact, Map, ArtifactRepository, List, ArtifactMetadataSource, ArtifactFilter) line: 272 EclipseArtifactResolver.resolveTransitively(Set, Artifact, Map, ArtifactRepository, List, ArtifactMetadataSource, ArtifactFilter) line: 105 EclipseArtifactResolver(DefaultArtifactResolver).resolveTransitively(Set, Artifact, Map, ArtifactRepository, List, ArtifactMetadataSource) line: 253 EclipseArtifactResolver.resolveTransitively(Set, Artifact, Map, ArtifactRepository, List, ArtifactMetadataSource) line: 114 DefaultMavenProjectBuilder.buildWithDependencies(File, ArtifactRepository, ProfileManager, TransferListener) line: 388 MavenEmbedder.readProjectWithDependencies(MavenExecutionRequest) line: 434 MavenModelManager.readMavenProject(IFile, IProgressMonitor, boolean, boolean) line: 360 BuildPathManager.resolveClasspathEntries(Set, Map, IFile, IFile, boolean, IProgressMonitor) line: 158 BuildPathManager.updateClasspathContainer(IProject, boolean, IProgressMonitor) line: 121 Maven2Builder.build(int, Map, IProgressMonitor) line: 75 BuildManager$2.run() line: 603 SafeRunner.run(ISafeRunnable) line: 37 BuildManager.basicBuild(int, IncrementalProjectBuilder, Map, MultiStatus, IProgressMonitor) line: 167 BuildManager.basicBuild(IProject, int, ICommand[], MultiStatus, IProgressMonitor) line: 201 BuildManager$1.run() line: 230 SafeRunner.run(ISafeRunnable) line: 37 BuildManager.basicBuild(IProject, int, MultiStatus, IProgressMonitor) line: 233 BuildManager.basicBuildLoop(IProject[], IProject[], int, MultiStatus, IProgressMonitor) line: 252 BuildManager.build(int, IProgressMonitor) line: 285 AutoBuildJob.doBuild(IProgressMonitor) line: 154 AutoBuildJob.run(IProgressMonitor) line: 217 Worker.run() line: 58 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.
Hide
Permalink
Aaron Digulla added a comment -

Snapshot of the groovy-maven-plugin

Show
Aaron Digulla added a comment - Snapshot of the groovy-maven-plugin
Hide
Permalink
Stefan Seidel added a comment -

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.

Show
Stefan Seidel added a comment - 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.
Hide
Permalink
Aaron Digulla added a comment -

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?

Show
Aaron Digulla added a comment - 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?
Hide
Permalink
Abel Muiņo added a comment -

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?

Show
Abel Muiņo added a comment - 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?
Hide
Permalink
Abel Muiņo added a comment -

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

Show
Abel Muiņo added a comment - 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
Hide
Permalink
Abel Muiņo added a comment -

MNG-2985 has been resolved. It should be possible now to build a new release bundling the new maven-embedder with minor changes to existing code.

The new maven embedder should fix this bug (and probably also MNGECLIPSE-320 and MNGECLIPSE-329)

I've got an unnoficial build at http://candy4appfuse.sourceforge.net/site/plugins/org.maven.ide.eclipse_0.0.11.v20070521-2114.jar and can provide a patch if needed (I'm not sure if I need to include the maven-embedder jar in the patch, though).

Show
Abel Muiņo added a comment - MNG-2985 has been resolved. It should be possible now to build a new release bundling the new maven-embedder with minor changes to existing code. The new maven embedder should fix this bug (and probably also MNGECLIPSE-320 and MNGECLIPSE-329) I've got an unnoficial build at http://candy4appfuse.sourceforge.net/site/plugins/org.maven.ide.eclipse_0.0.11.v20070521-2114.jar and can provide a patch if needed (I'm not sure if I need to include the maven-embedder jar in the patch, though).
Hide
Permalink
Stefan Seidel added a comment -

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.)

Show
Stefan Seidel added a comment - 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.)
Hide
Permalink
Abel Muiņo added a comment -

Patch for using a newer maven-embeder (not included).

The maven-embedder jar can be found at http://candy4appfuse.sourceforge.net/tmp/. I've included the binary jar and the source code zip (which is bundled with the plugin in previous versions).

Show
Abel Muiņo added a comment - Patch for using a newer maven-embeder (not included). The maven-embedder jar can be found at http://candy4appfuse.sourceforge.net/tmp/. I've included the binary jar and the source code zip (which is bundled with the plugin in previous versions).
Hide
Permalink
Eugene Kuleshov added a comment -

I committed new embedder build yesterday. Can anyone please test if this issue still occur with code from trunk?

Show
Eugene Kuleshov added a comment - I committed new embedder build yesterday. Can anyone please test if this issue still occur with code from trunk?
Hide
Permalink
Abel Muiņo added a comment -

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, which still points to the old jar (lib/maven-embedder-2.1.0.v20070302-2248-dep.jar).

If you want me to create a patch for the committed jar, I can do that.

Show
Abel Muiņo added a comment - 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, which still points to the old jar (lib/maven-embedder-2.1.0.v20070302-2248-dep.jar). If you want me to create a patch for the committed jar, I can do that.
Hide
Permalink
Eugene Kuleshov added a comment -

Oh. Sorry, please wait. I hit into some issue that need to be resolved first.

Show
Eugene Kuleshov added a comment - Oh. Sorry, please wait. I hit into some issue that need to be resolved first.
Hide
Permalink
Eugene Kuleshov added a comment -

It is in now

Show
Eugene Kuleshov added a comment - It is in now
Hide
Permalink
Abel Muiņo added a comment - - edited

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
Show
Abel Muiņo added a comment - - edited 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
Hide
Permalink
William Ferguson added a comment -

0.0.11.20070603-1200 works fine for me.
Dependencies only get downloaded once - yeeha

Show
William Ferguson added a comment - 0.0.11.20070603-1200 works fine for me. Dependencies only get downloaded once - yeeha
Hide
Permalink
Aaron Digulla added a comment -

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.

Show
Aaron Digulla added a comment - 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.
Hide
Permalink
Derek Clarkson added a comment -

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.

Show
Derek Clarkson added a comment - 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.
Hide
Permalink
Aaron Digulla added a comment -

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.

Show
Aaron Digulla added a comment - 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.

People

Vote (3)
Watch (4)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.