2.1 isn't handling snapshot lookups as efficiently as it could be and this contributes to longer build times the first run of the day. Having a repo man like proximity/nexus will help because it is smart enough to not reach out to the remote on every request. Once 2.1's artifact code rewrite is finished, this should be much better.
-----Original Message----- From: Langs Gerhard [mailto:[EMAIL PROTECTED] Sent: Friday, April 18, 2008 2:08 AM To: [email protected] Subject: AW: [m2eclipse-user] update dependencies performance in 0.9.x Some remarks on it, as we are also somehow hurt by performance here... In context of MNGECLIPSE-517, where I tried to setup a testcase, I noticed that for a relatively small test-situation, it worked quite fast in an Intranet szenario (see details below) and it was unusable slow, when I tried the same from home (VPN connection). So as it seems to me now, bad performance could come from a large set of remote-maven-repository aceesses. Unfortunately, I dont have time these days to investigate on it, but I would suggest to - analyze the debug output of m2eclipse: how many remote-repo accessess happen, and how often do you see the same artefact being queried. - try to understand the time such a perhaps remote access takes. I can darkly remember, that in the "VPN" szenario, CTRL-BREAK on eclipse alsways showed be, that System was in remote HTTP requests. Details: our intranet szenario: - Proximity as Shared Repo Server acessible via GB LAN VPN Szeanario: - CISCO VPN tunnel over ASDL HTH, Gerhard. -----Ursprüngliche Nachricht----- Von: Eugene Kuleshov [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 17. April 2008 19:20 An: [email protected] Betreff: Re: [m2eclipse-user] update dependencies performance in 0.9.x manuel aldana wrote: >> I would be interested to hear if you get better performance with >> 0.0.12, because in my observation 0.9 is about magnitude faster then >> 0.0.12 and it is clearly something specific to your environment that >> cause such performance issues. > it depends on the way how you keep projects in the workspace. when > having only a few (<=4) projects in workspace 0.9 is far better. in > contrast when keeping many (>=5) projects in workspace the update > dependencies task is just taking ages. i think it is better to keep as > few projects in workspace as neccessary so the 0.9.2 is fine for me. > never the less other colleagures are often having many projects in > workspace so 0.0.12 works better for them. Like I said before, that is very strange. I do have more then 5 Maven projects in my Eclipse workspace and don't see such issues. Besides, it is not really related to how many project you have. There are test in jira somewhere with 40 dependent projects (technically 40 levels down dependencies) and it takes seconds to open/close those. Most time spent on closing/opening projects and updating dependencies is in reading Maven projects, which could go into checking dependencies on remote repositories (especially for snapshots). So, it is more like related to how many external dependencies your projects have. > as i said i guess this is because resolving is done for all projects > if you go rightClickOnProject->Maven->UpdateDepenendencies. In my view > i would expect that resolving is done only for the project i chose. This action only resolves dependencies for selected projects and projects that depends on that (because that is how Maven dependency resolution works). One thing that comes to mind is that we may not need to update dependent projects if there was no updates found in selected one, though it might get tricky to detect if there was any updates... regards, Eugene --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
