Maven Integration for Eclipse

[mng] performance problem open/close project

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Critical Critical
  • Resolution: Unresolved
  • Affects Version/s: 0.9.1
  • Fix Version/s: 0.9.9
  • Component/s: Dependency Resolver
  • Labels:
    None
  • Number of attachments :
    2

Description

when opening or closing a project inside workspace the maven auto builing ('Updating Maven Dependencies') takes very long to complete (around a minute). the same is when checking out or deleting a project

for me this is a major issue, for i keep only open projects in workspace i am working on. i.e. i am checking-out/closing/opening very often. for this performance reasons i still have to use 0.0.12 version. with 0.0.12 in fact i had to make Project->Clean... manually, when workspace changed. never the less this went much quicker (around 15 seconds vs. 1 minute of auto refresh).

eclipse install is very slim and there are only two checked out projects, so i guess it has something to do with dep-resolving refresh after project-set workspace change.

  1. logAfterCheckout.txt
    04/Apr/08 3:46 AM
    715 kB
    manuel aldana
  2. logRebuild.txt
    04/Apr/08 3:08 AM
    239 kB
    manuel aldana

Issue Links

Activity

Hide
Igor Fedorenko added a comment -

Can you please provide sample project(s) and logs as described here http://docs.codehaus.org/display/M2ECLIPSE/Reporting+Issues ?

Also, if you use svn/subclipse, can you disable deep calculation of outgoing state and see if it makes things better (Window->Preferences->Team->SVN->Label Decoration)?

Show
Igor Fedorenko added a comment - Can you please provide sample project(s) and logs as described here http://docs.codehaus.org/display/M2ECLIPSE/Reporting+Issues ? Also, if you use svn/subclipse, can you disable deep calculation of outgoing state and see if it makes things better (Window->Preferences->Team->SVN->Label Decoration)?
Hide
manuel aldana added a comment -

unfortunately i cannot reproduce it with some simple workspace setup. simple projects with just a few classes or dependencies just work fine. the build after closing,opening projects is just a matter of seconds.

after having a look at the debug for my bigger projects (around 50 dependencies with many snapshots, where resolving is slow) i could make an assumption why things are taking considerably longer: there is too much resolving done (many output loggings for dependencies). instead of only updating the project which has been changed (through close/open/checkout/delete) it is doing the resolving for the whole set of dependencies.

in my view it should only update the classpath setting and resolve to jars for the only project/projects whose state just had been changed. maybe this could be done by caching the full-qualified name of the state-changed project and thus m2eclipse would know which dependency to newly resolve.

though i do not know if this is possible with maven...

Show
manuel aldana added a comment - unfortunately i cannot reproduce it with some simple workspace setup. simple projects with just a few classes or dependencies just work fine. the build after closing,opening projects is just a matter of seconds. after having a look at the debug for my bigger projects (around 50 dependencies with many snapshots, where resolving is slow) i could make an assumption why things are taking considerably longer: there is too much resolving done (many output loggings for dependencies). instead of only updating the project which has been changed (through close/open/checkout/delete) it is doing the resolving for the whole set of dependencies. in my view it should only update the classpath setting and resolve to jars for the only project/projects whose state just had been changed. maybe this could be done by caching the full-qualified name of the state-changed project and thus m2eclipse would know which dependency to newly resolve. though i do not know if this is possible with maven...
Hide
Igor Fedorenko added a comment -

I have m2eclipse workspace with maven 2.1 source projects. It takes about 10-15 seconds to refresh dependencies for all projects after I close/open them, so 1 minutes does look excessive. What snapshot update policy do you have? "Always" can certainly slow down dependencies update. Without ability to reproduce the problem there is not much more suggest, unfortunately.

Show
Igor Fedorenko added a comment - I have m2eclipse workspace with maven 2.1 source projects. It takes about 10-15 seconds to refresh dependencies for all projects after I close/open them, so 1 minutes does look excessive. What snapshot update policy do you have? "Always" can certainly slow down dependencies update. Without ability to reproduce the problem there is not much more suggest, unfortunately.
Hide
Eugene Kuleshov added a comment -

Manuel, can you please open maven console in Console view, clean it, enable debug output (see icon on toolbar), then open your project and capture all output from the console. Also note that closing some project can affect other projects in workspace if that project is using them as dependencies or it is a dependency of those projects. This kind of relationship can be controlled by "resolve workspace projects" setting.

BTW, how long does it take to run mvn clean build on projects affected by such refresh?

Show
Eugene Kuleshov added a comment - Manuel, can you please open maven console in Console view, clean it, enable debug output (see icon on toolbar), then open your project and capture all output from the console. Also note that closing some project can affect other projects in workspace if that project is using them as dependencies or it is a dependency of those projects. This kind of relationship can be controlled by "resolve workspace projects" setting. BTW, how long does it take to run mvn clean build on projects affected by such refresh?
Hide
manuel aldana added a comment - - edited

i attached log-output after doing a open/close project for one single project in my workspace

as said before it takes about a minute. to have a comparison: when doing it on command-line (mvn test-compile )it takes about 15 seconds.

you are right i set snapshot update policy to always for our common internal projects, which are updated more often as once a day.

what would speed up performance considerably if an update would be done for the closed/opened/checkedout project only. the log output tells me that it is done for all dependencies.

Show
manuel aldana added a comment - - edited i attached log-output after doing a open/close project for one single project in my workspace as said before it takes about a minute. to have a comparison: when doing it on command-line (mvn test-compile )it takes about 15 seconds. you are right i set snapshot update policy to always for our common internal projects, which are updated more often as once a day. what would speed up performance considerably if an update would be done for the closed/opened/checkedout project only. the log output tells me that it is done for all dependencies.
Hide
manuel aldana added a comment -

i attached another log-output which had been created after checking out project. this took much longer than a simple open/close project. the resolving for after checking out lasted around 2 minutes.

Show
manuel aldana added a comment - i attached another log-output which had been created after checking out project. this took much longer than a simple open/close project. the resolving for after checking out lasted around 2 minutes.
Hide
manuel aldana added a comment -

it is getting worse if there are multiple projects checked out in workspace because the resolving is done for each project.

this makes working with m2eclipse not possible (e.g. 4 checked out projects cause the resolving time to increase to around 5 minutes).

Show
manuel aldana added a comment - it is getting worse if there are multiple projects checked out in workspace because the resolving is done for each project. this makes working with m2eclipse not possible (e.g. 4 checked out projects cause the resolving time to increase to around 5 minutes).
Hide
Stefan Seidel added a comment -

5 minutes! How lucky. Mine is working for about 20 minutes if I only start up eclipse. I usually ignore it, but sometimes I need to wait for it to finish because I have changed dependencies. If there was some way to speed this up, I would greatly appreciate it, too.

Show
Stefan Seidel added a comment - 5 minutes! How lucky. Mine is working for about 20 minutes if I only start up eclipse. I usually ignore it, but sometimes I need to wait for it to finish because I have changed dependencies. If there was some way to speed this up, I would greatly appreciate it, too.
Hide
manuel aldana added a comment -

found out the reason why resolution is hanging. certain dependencies in my internal repository did not have a pom.xml provided and m2eclipse always tried to resolve it again. after cleaning up repository (redeploying with adding pom.xml for all problematic dependencies it worked fine) performance is good.

suggestion for patch: in case pom of dependency cannot be found, m2eclipse should remember this and not constantly trying to resolve it again. otherwise time costs can be severe. trying to resolve poms again should be done once a day or by explicit manual trigger.

for better diagnostics, maybe a logging output could be done, to tell user to provide a pom for dependency.

Show
manuel aldana added a comment - found out the reason why resolution is hanging. certain dependencies in my internal repository did not have a pom.xml provided and m2eclipse always tried to resolve it again. after cleaning up repository (redeploying with adding pom.xml for all problematic dependencies it worked fine) performance is good. suggestion for patch: in case pom of dependency cannot be found, m2eclipse should remember this and not constantly trying to resolve it again. otherwise time costs can be severe. trying to resolve poms again should be done once a day or by explicit manual trigger. for better diagnostics, maybe a logging output could be done, to tell user to provide a pom for dependency.
Hide
Igor Fedorenko added a comment -

I am glad to hear that m2eclipse performs well for you now, Manuel. The proper fix for this problem will require changes to maven embedder, and we'll try to implement it in 0.9.3/0.9.4 timeframe. Thank you for your patience and all the help diagnosing thing bug.

Show
Igor Fedorenko added a comment - I am glad to hear that m2eclipse performs well for you now, Manuel. The proper fix for this problem will require changes to maven embedder, and we'll try to implement it in 0.9.3/0.9.4 timeframe. Thank you for your patience and all the help diagnosing thing bug.

People

Vote (16)
Watch (15)

Dates

  • Created:
    Updated: