As far as I know, we're not using ranges. However, I don't know if we're pulling anything in that does use ranges. What's a good way to find out?
As far as the aether stuff, I noticed as much from looking at the source. I'm just trying to figure out if there is a way to make the dependency-resolution process faster. Thanks! Vivin On Tue, Jul 19, 2011 at 1:06 PM, Kristian Rosenvold < [email protected]> wrote: > Are you using version ranges ? There seems to be an issue with a > combinatorial explosion of sorts with version ranges, I am not sure if > there has been a jira submitted anywhere for that with a reproducible > test case, though. > > The version range jump (3.0b1 to 3.0.3 include aether), so there's some > pretty substantial changes to the dependency resolution stuff. > > Kristian > > > > ti., 19.07.2011 kl. 09.27 -0700, skrev Vivin Suresh Paliath: > > I'm trying to track down the reason that our builds take much longer to > > build under 3.0.3 rather than 3.0b1. Under 3.0.3, our build takes around > 9 > > minutes, whereas under 3.0b1, it's 3 minutes and 30 seconds. While using > > jconsole, I saw that most of the time (in 3.0.3) is spent inside > > DefaultProjectDependenciesResolver.java. So I downloaded the source to > both > > 3.0b1 and 3.0.3 to see what's happening. I noticed that in 3.0.3 there > are > > two versions of the class. One is in org.apache.maven.project, while the > > other is in org.apache.maven. It also appears that in 3.0.3, the former > is > > being used. While stepping through the code, I saw that bulk of the time > is > > spent when it reaches this statement: > > > > node = repoSystem.collectDependencies( session, collect ).getRoot(); > > > > In 3.0b1, the code does: > > > > ArtifactResolutionResult result = repositorySystem.resolve( request ); > > > > I also noticed that respositorySystem is of type RepositorySystem, and > the > > concrete implementation is LegacyRepositorySystem. I'm assuming that this > > was being used while the Maven 3 was in beta until the new implementation > > was created? Going back to 3.0.3, the collectDependencies method lives in > > DefaultRepositorySystem.java which is part of > > org.sonatype.aether.impl.internal. This eventually calls > > collectDependenciesinside > > DefaultDependencyCollector.java which is also part of > > org.sonatype.aether.impl.internal. I'm assuming that this is how the > > dependency graph is built. My question is if there is a way to make this > > process faster? Could there be something wrong in the way we've set up > our > > dependencies in our project which could cause this process to be so slow? > > > > Or, is this a performance regression? If this is the case, I can open an > > Jira issue. > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Ruin untold; And thine own sadness, Sing in the grass, When eve has forgot, that no more hear common things that gleam and pass; But seek alone to lip, sad Rose of love and ruin untold; And thine own mother Can know it as I know More than another What makes your own sadness, Set in her eyes. $s="01:11:02:11:01:11:02:13:01:11:01:11:01:13:02:12:01:13:01:11: 04:11:06:12:04:11:01:12:01:13:02:12:01:14:01:13:01:11:03:12: 01:11:04:12:02:11:01:11:01:13:02:11:03:11:06:11:01:11:05:12: 02:11:01:11:01:13:02:11:02:12:01:12:04:11:06:12:01:11:04:12: 04:11:01:12:03:12:01:12:01:11:01:12:01:12:02:11:01:11:01:13: 02:11:01:02:11:01:12:02"; @a=split(/:/,$s);$j="";foreach$c(@a) {@n=split(//,$c);$j.=$n[0]x$n[1];} for($i=0;$i<$j=~y///c;$i+=8){print chr(unpack("N",pack("B32",substr("0"x32 .substr($j,$i,8),-32))));}
