You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Milos Kleint <mk...@gmail.com> on 2007/12/19 20:10:15 UTC
possible performance bottleneck in current trunk
Hello,
i've started building my project with current 2.1-SNAPSHOT trunk and I
noticed the build is taking more time than before. I did a bit of profiling.
I've executed "mvn install" on a set of 24 projects, all build before, right
before the profiling test.
What struck me is that half of the time seems to be spent in
DefaultPluginManager.resolveTransitiveDependencies(). See attached picture
from netbeans profiler.
It was executed 82 times. I suppose the root of the problem will be
somewhere much deeper and I guess there's a way to optimize the number of
calls to the method as well.
After a bit of debugging i figured that for a single project this method is
called multiple times during execution. First the "compile" scope is
resolved, later "runtime" or "test" eventually (depends on actual plugins
bound to the project)
Ideally it should be called 24 times max as far as I understand the problem.
The BuildPlan should know up front what mojos will be executed and what is
the maximum level or dependency resolution for the given project.
Agreed? Is that something that I should pursue further or am I on the wrong
track?
Milos
PS: If anyone is interested I can send the actual netbeans profiler dump
files for browsing (via private email).
Re: possible performance bottleneck in current trunk
Posted by Jerome Lacoste <je...@gmail.com>.
On Dec 19, 2007 8:10 PM, Milos Kleint <mk...@gmail.com> wrote:
> Hello,
>
> i've started building my project with current 2.1-SNAPSHOT trunk and I
> noticed the build is taking more time than before. I did a bit of profiling.
> I've executed "mvn install" on a set of 24 projects, all build before, right
> before the profiling test.
>
> What struck me is that half of the time seems to be spent in
> DefaultPluginManager.resolveTransitiveDependencies(). See attached picture
> from netbeans profiler.
missing attachment ?
J
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: possible performance bottleneck in current trunk
Posted by Jason van Zyl <ja...@maven.org>.
On 22 Dec 07, at 9:09 AM 22 Dec 07, Milos Kleint wrote:
> On Dec 22, 2007 5:17 PM, Jason van Zyl <ja...@maven.org> wrote:
>
>>
>> On 22 Dec 07, at 1:02 AM 22 Dec 07, Milos Kleint wrote:
>>
>>> i've played with the DefaultLifecycleExecutor and
>>> DefaultPluginManager a bit and tried to separate the preparation
>>> phase from the actual mojo executions. The preparations seem to
>>> attribute to astonishing 90% of the build execution.
>>> See http://picasaweb.google.com/mkleint/Maven/
>>> photo#5146520463951211778
>>>
>>> what have I actually done? (patch attached, I hope it gets through)
>>>
>>> in the preparation phase
>>> 1. iterate all the projects, figure out the mojo bindings.
>>> 2. for each binding, load the asociated plugin
>>> 3. for each project figure out what the required maximum project
>>> dependency resolution is and resolve it.
>>>
>>> in the execution phase actually just run the mojo's execute method.
>>> (ripped the project dependency resolution from there)
>>>
>>> The work i've done is probably not generally useful, but it clearly
>>> shows where space for improvements is.
>>
>> Why is it not generally useful? I think as part of improving the
>> build
>> plan and exposing what can be configured and change they the user is
>> good. How the mojo bindings are put together would definitely affect
>> the subsequent execution. John should take a look at the patch as
>> well, but I will take a look but. Did you manage to reduce any
>> complexity or reduce any code or did you just add different
>> processing?
>
>
>
> The build doesn't fail fast now in some cases. It will prepare all
> the 20
> project's lifecycles, perform dependency resolution of all the 20
> projects
> and then the first one compiler plugin invocation fails in
> compilation.
Just keep in mind any API that would allow us to expose configuring
all the bits before hand. It's John's build plan code, but I don't
think he'd mind making it performant but the ultimate goal is being
able to tweak whatever is planned to happen so that the user
ultimately has full control before the build executes. Even if this is
limited at first that's the ultimate goal. The metadata being couple
to the artifacts for plugins already makes this someone inefficient
but that's what we have right now. We can incrementally change this as
I would like to boot alpha-1 out the door asap.
>
>
> the only complexity reduction was trimming down 80+ invocations of
> project
> dependency resolution to 20 (thus once per project)
>
I'd say that's a good start, just make sure we don't lose the edge
cases which is probably why John repeatedly grabbed everything to
chase down the cases where the same plugin is configured in the same
project, or else where in the reactor. I'm sure it can be tuned.
>
>
>
>
>>
>>
>>>
>>> However I'd like to use this in the Netbeans IDE, to "preload"
>>> various actions as the user edits the files, so that the build/run/
>>> debug cycle gets faster (as I'm dependent on running maven goals on
>>> these actions) and when the user actually triggers "Run" only the
>>> execution phase needs to be run.
>>>
>>
>> Yes, definitely useful to IDE integration. Visualization of the build
>> plan will be one of the most useful features there will be.
>
>
> agree about visualization. That's something very useful and the
> patch is
> relevant to it.
> However my usecase was different, I want to run the preparation
> phase behind
> the scenes (triggered by a user edit of a java file for example).
> With some added heuristics, later when the user invokes "Run
> project" or
> "Debug project" in the main menu, I can only grab this prepared
> build and
> invoke it very fast..
> That's a consequence of the fact that everything project related in
> netbeans
> is done through maven.
>
> Milos
>
>
>>
>>> Milos
>>>
>>>
>>> On Dec 19, 2007 10:34 PM, Jason van Zyl <ja...@maven.org> wrote:
>>>
>>> On 19 Dec 07, at 12:28 PM 19 Dec 07, Milos Kleint wrote:
>>>
>>>> here is the actual screenshot.
>>>>
>>>> http://picasaweb.google.com/mkleint/Maven
>>>>
>>>> more inline..
>>>>
>>>> On Dec 19, 2007 9:19 PM, Jason van Zyl <ja...@maven.org> wrote:
>>>>
>>>>>
>>>>> On 19 Dec 07, at 11:10 AM 19 Dec 07, Milos Kleint wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> i've started building my project with current 2.1-SNAPSHOT trunk
>>> and
>>>>>> I noticed the build is taking more time than before. I did a bit
>>> of
>>>>>> profiling.
>>>>>> I've executed "mvn install" on a set of 24 projects, all build
>>>>>> before, right before the profiling test.
>>>>>>
>>>>>> What struck me is that half of the time seems to be spent in
>>>>>> DefaultPluginManager.resolveTransitiveDependencies(). See
>>>>>> attached
>>>>>> picture from netbeans profiler.
>>>>>> It was executed 82 times. I suppose the root of the problem
>>> will be
>>>>>> somewhere much deeper and I guess there's a way to optimize the
>>>>>> number of calls to the method as well.
>>>>>> After a bit of debugging i figured that for a single project this
>>>>>> method is called multiple times during execution. First the
>>>>>> "compile" scope is resolved, later "runtime" or "test" eventually
>>>>>> (depends on actual plugins bound to the project)
>>>>>> Ideally it should be called 24 times max as far as I understand
>>> the
>>>>>> problem. The BuildPlan should know up front what mojos will be
>>>>>> executed and what is the maximum level or dependency resolution
>>> for
>>>>>> the given project.
>>>>>>
>>>>>> Agreed? Is that something that I should pursue further or am I on
>>>>>> the wrong track?
>>>>>>
>>>>>
>>>>> Sure, take a look but in the plugin manager I started ripping out
>>> all
>>>>> the optimizations after ripping out a bunch of other code. But
>>> narrow
>>>>> it down for one build where
>>>>>
>>>>> 1) You don't have anything downloaded i.e. a clean repository, and
>>>>> 2) Where you have all the dependencies downloaded
>>>>>
>>>>> For one pass it shouldn't be resolving more then once for each
>>>>> plugin.
>>>>> I wouldn't try to start caching anything but if you're seeing more
>>>>> then one call per plugin then something needs to be reworked.
>>>>
>>>>
>>>> well, from what I understand I see 1 resolution per plugin per
>>>> project, if
>>>> the plugin requires dependency resolution.
>>>
>>> Yes, this is a reactor this is to account for cases where you may
>>> have
>>> the same plugin used, but might have dependencies stated itself
>>> which
>>> can change things so you need to track this. The non-optimized
>>> version
>>> obviously deals with this but you will end up with a case where
>>> different plugin declarations have slightly different dependency
>>> requirements. John tried to account for everything, but we could
>>> still
>>> cache most of the information.
>>>
>>>>
>>>> my ''optimization'' involves looking up front what is the maximum
>>>> dependency
>>>> resolution scope and resolve it just once per project. In your case
>>>> 1 it
>>>> means more than necessary gets downloaded upfront probably, but
>>> case 2
>>>> should be faster.
>>>
>>> So we can sync up here as I'm remaking the project builder and
>>> trying
>>> to setup a listener that can watch for things as projects are being
>>> built. One of the things I'm trying to collect are profiles and
>>> extensions so that we don't have to scan the POMs again after they
>>> are
>>> built. We could do the same with plugin declarations so that up-
>>> front
>>> you would know what you needed. So you could see that for all the
>>> plugin configurations there were no variations, pick off which ones
>>> need resolution, do that and then fire the build.
>>>
>>> So if you could determine what information you needed up front I can
>>> factor that in, and in the short term you can take the approach John
>>> has made with things like the extension scanner. But ultimately we
>>> should not need to read any pom.xml file more then once. Whether it
>>> come in the maven-artifact, the project builder or anything else.
>>>
>>>>
>>>>
>>>> Milos
>>>>
>>>>
>>>>>
>>>>>
>>>>>> Milos
>>>>>>
>>>>>> PS: If anyone is interested I can send the actual netbeans
>>> profiler
>>>>>> dump files for browsing (via private email).
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jason
>>>>>
>>>>> ----------------------------------------------------------
>>>>> Jason van Zyl
>>>>> Founder, Apache Maven
>>>>> jason at sonatype dot com
>>>>> ----------------------------------------------------------
>>>>>
>>>>> believe nothing, no matter where you read it,
>>>>> or who has said it,
>>>>> not even if i have said it,
>>>>> unless it agrees with your own reason
>>>>> and your own common sense.
>>>>>
>>>>> -- Buddha
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> jason at sonatype dot com
>>> ----------------------------------------------------------
>>>
>>> What matters is not ideas, but the people who have them. Good people
>>> can fix bad ideas, but good ideas can't save bad people.
>>>
>>> -- Paul Graham
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>> <
>>> lifecycleexecutor
>>> .patch
>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>> We know what we are, but know not what we may be.
>>
>> -- Shakespeare
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: possible performance bottleneck in current trunk
Posted by Jason van Zyl <ja...@maven.org>.
On 22 Dec 07, at 9:55 AM 22 Dec 07, Ralph Goers wrote:
> If I can get some time I might look at it as well. This wouldn't
> necessarily be a bad thing if it can tell you all of the errors
> after preparing the projects.
>
There are probably things we can know before project collection, like
listening to the POM building process and picking off problems, and
things we can only determine once the whole build plan is made.
You'll definitely want to look at the painstaking work John did with
the error reporting to try and capture every last possible error that
can occur and report it. The process of building up the projects, by
reading the metadata only, creating the build plan, gather the
resources for the build plan (i.e. the actual artifact resolution),
and then executing the build plan.
> Milos Kleint wrote:
>> The build doesn't fail fast now in some cases. It will prepare all
>> the 20
>> project's lifecycles, perform dependency resolution of all the 20
>> projects
>> and then the first one compiler plugin invocation fails in
>> compilation.
>>
>> the only complexity reduction was trimming down 80+ invocations of
>> project
>> dependency resolution to 20 (thus once per project)
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
What matters is not ideas, but the people who have them. Good people
can fix bad ideas, but good ideas can't save bad people.
-- Paul Graham
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: possible performance bottleneck in current trunk
Posted by Ralph Goers <Ra...@dslextreme.com>.
If I can get some time I might look at it as well. This wouldn't
necessarily be a bad thing if it can tell you all of the errors after
preparing the projects.
Milos Kleint wrote:
> The build doesn't fail fast now in some cases. It will prepare all the 20
> project's lifecycles, perform dependency resolution of all the 20 projects
> and then the first one compiler plugin invocation fails in compilation.
>
> the only complexity reduction was trimming down 80+ invocations of project
> dependency resolution to 20 (thus once per project)
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: possible performance bottleneck in current trunk
Posted by Milos Kleint <mk...@gmail.com>.
On Dec 22, 2007 5:17 PM, Jason van Zyl <ja...@maven.org> wrote:
>
> On 22 Dec 07, at 1:02 AM 22 Dec 07, Milos Kleint wrote:
>
> > i've played with the DefaultLifecycleExecutor and
> > DefaultPluginManager a bit and tried to separate the preparation
> > phase from the actual mojo executions. The preparations seem to
> > attribute to astonishing 90% of the build execution.
> > See http://picasaweb.google.com/mkleint/Maven/
> > photo#5146520463951211778
> >
> > what have I actually done? (patch attached, I hope it gets through)
> >
> > in the preparation phase
> > 1. iterate all the projects, figure out the mojo bindings.
> > 2. for each binding, load the asociated plugin
> > 3. for each project figure out what the required maximum project
> > dependency resolution is and resolve it.
> >
> > in the execution phase actually just run the mojo's execute method.
> > (ripped the project dependency resolution from there)
> >
> > The work i've done is probably not generally useful, but it clearly
> > shows where space for improvements is.
>
> Why is it not generally useful? I think as part of improving the build
> plan and exposing what can be configured and change they the user is
> good. How the mojo bindings are put together would definitely affect
> the subsequent execution. John should take a look at the patch as
> well, but I will take a look but. Did you manage to reduce any
> complexity or reduce any code or did you just add different processing?
The build doesn't fail fast now in some cases. It will prepare all the 20
project's lifecycles, perform dependency resolution of all the 20 projects
and then the first one compiler plugin invocation fails in compilation.
the only complexity reduction was trimming down 80+ invocations of project
dependency resolution to 20 (thus once per project)
>
>
> >
> > However I'd like to use this in the Netbeans IDE, to "preload"
> > various actions as the user edits the files, so that the build/run/
> > debug cycle gets faster (as I'm dependent on running maven goals on
> > these actions) and when the user actually triggers "Run" only the
> > execution phase needs to be run.
> >
>
> Yes, definitely useful to IDE integration. Visualization of the build
> plan will be one of the most useful features there will be.
agree about visualization. That's something very useful and the patch is
relevant to it.
However my usecase was different, I want to run the preparation phase behind
the scenes (triggered by a user edit of a java file for example).
With some added heuristics, later when the user invokes "Run project" or
"Debug project" in the main menu, I can only grab this prepared build and
invoke it very fast..
That's a consequence of the fact that everything project related in netbeans
is done through maven.
Milos
>
> > Milos
> >
> >
> > On Dec 19, 2007 10:34 PM, Jason van Zyl <ja...@maven.org> wrote:
> >
> > On 19 Dec 07, at 12:28 PM 19 Dec 07, Milos Kleint wrote:
> >
> > > here is the actual screenshot.
> > >
> > > http://picasaweb.google.com/mkleint/Maven
> > >
> > > more inline..
> > >
> > > On Dec 19, 2007 9:19 PM, Jason van Zyl <ja...@maven.org> wrote:
> > >
> > >>
> > >> On 19 Dec 07, at 11:10 AM 19 Dec 07, Milos Kleint wrote:
> > >>
> > >>> Hello,
> > >>>
> > >>> i've started building my project with current 2.1-SNAPSHOT trunk
> > and
> > >>> I noticed the build is taking more time than before. I did a bit
> > of
> > >>> profiling.
> > >>> I've executed "mvn install" on a set of 24 projects, all build
> > >>> before, right before the profiling test.
> > >>>
> > >>> What struck me is that half of the time seems to be spent in
> > >>> DefaultPluginManager.resolveTransitiveDependencies(). See attached
> > >>> picture from netbeans profiler.
> > >>> It was executed 82 times. I suppose the root of the problem
> > will be
> > >>> somewhere much deeper and I guess there's a way to optimize the
> > >>> number of calls to the method as well.
> > >>> After a bit of debugging i figured that for a single project this
> > >>> method is called multiple times during execution. First the
> > >>> "compile" scope is resolved, later "runtime" or "test" eventually
> > >>> (depends on actual plugins bound to the project)
> > >>> Ideally it should be called 24 times max as far as I understand
> > the
> > >>> problem. The BuildPlan should know up front what mojos will be
> > >>> executed and what is the maximum level or dependency resolution
> > for
> > >>> the given project.
> > >>>
> > >>> Agreed? Is that something that I should pursue further or am I on
> > >>> the wrong track?
> > >>>
> > >>
> > >> Sure, take a look but in the plugin manager I started ripping out
> > all
> > >> the optimizations after ripping out a bunch of other code. But
> > narrow
> > >> it down for one build where
> > >>
> > >> 1) You don't have anything downloaded i.e. a clean repository, and
> > >> 2) Where you have all the dependencies downloaded
> > >>
> > >> For one pass it shouldn't be resolving more then once for each
> > >> plugin.
> > >> I wouldn't try to start caching anything but if you're seeing more
> > >> then one call per plugin then something needs to be reworked.
> > >
> > >
> > > well, from what I understand I see 1 resolution per plugin per
> > > project, if
> > > the plugin requires dependency resolution.
> >
> > Yes, this is a reactor this is to account for cases where you may have
> > the same plugin used, but might have dependencies stated itself which
> > can change things so you need to track this. The non-optimized version
> > obviously deals with this but you will end up with a case where
> > different plugin declarations have slightly different dependency
> > requirements. John tried to account for everything, but we could still
> > cache most of the information.
> >
> > >
> > > my ''optimization'' involves looking up front what is the maximum
> > > dependency
> > > resolution scope and resolve it just once per project. In your case
> > > 1 it
> > > means more than necessary gets downloaded upfront probably, but
> > case 2
> > > should be faster.
> >
> > So we can sync up here as I'm remaking the project builder and trying
> > to setup a listener that can watch for things as projects are being
> > built. One of the things I'm trying to collect are profiles and
> > extensions so that we don't have to scan the POMs again after they are
> > built. We could do the same with plugin declarations so that up-front
> > you would know what you needed. So you could see that for all the
> > plugin configurations there were no variations, pick off which ones
> > need resolution, do that and then fire the build.
> >
> > So if you could determine what information you needed up front I can
> > factor that in, and in the short term you can take the approach John
> > has made with things like the extension scanner. But ultimately we
> > should not need to read any pom.xml file more then once. Whether it
> > come in the maven-artifact, the project builder or anything else.
> >
> > >
> > >
> > > Milos
> > >
> > >
> > >>
> > >>
> > >>> Milos
> > >>>
> > >>> PS: If anyone is interested I can send the actual netbeans
> > profiler
> > >>> dump files for browsing (via private email).
> > >>>
> > >>>
> > >>>
> > >>>
> > ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >>> For additional commands, e-mail: dev-help@maven.apache.org
> > >>
> > >> Thanks,
> > >>
> > >> Jason
> > >>
> > >> ----------------------------------------------------------
> > >> Jason van Zyl
> > >> Founder, Apache Maven
> > >> jason at sonatype dot com
> > >> ----------------------------------------------------------
> > >>
> > >> believe nothing, no matter where you read it,
> > >> or who has said it,
> > >> not even if i have said it,
> > >> unless it agrees with your own reason
> > >> and your own common sense.
> > >>
> > >> -- Buddha
> > >>
> > >>
> > >>
> > >>
> > >>
> > ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: dev-help@maven.apache.org
> > >>
> > >>
> >
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder, Apache Maven
> > jason at sonatype dot com
> > ----------------------------------------------------------
> >
> > What matters is not ideas, but the people who have them. Good people
> > can fix bad ideas, but good ideas can't save bad people.
> >
> > -- Paul Graham
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> > <
> > lifecycleexecutor
> > .patch
> > >---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> We know what we are, but know not what we may be.
>
> -- Shakespeare
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: possible performance bottleneck in current trunk
Posted by Jason van Zyl <ja...@maven.org>.
On 22 Dec 07, at 1:02 AM 22 Dec 07, Milos Kleint wrote:
> i've played with the DefaultLifecycleExecutor and
> DefaultPluginManager a bit and tried to separate the preparation
> phase from the actual mojo executions. The preparations seem to
> attribute to astonishing 90% of the build execution.
> See http://picasaweb.google.com/mkleint/Maven/
> photo#5146520463951211778
>
> what have I actually done? (patch attached, I hope it gets through)
>
> in the preparation phase
> 1. iterate all the projects, figure out the mojo bindings.
> 2. for each binding, load the asociated plugin
> 3. for each project figure out what the required maximum project
> dependency resolution is and resolve it.
>
> in the execution phase actually just run the mojo's execute method.
> (ripped the project dependency resolution from there)
>
> The work i've done is probably not generally useful, but it clearly
> shows where space for improvements is.
Why is it not generally useful? I think as part of improving the build
plan and exposing what can be configured and change they the user is
good. How the mojo bindings are put together would definitely affect
the subsequent execution. John should take a look at the patch as
well, but I will take a look but. Did you manage to reduce any
complexity or reduce any code or did you just add different processing?
>
> However I'd like to use this in the Netbeans IDE, to "preload"
> various actions as the user edits the files, so that the build/run/
> debug cycle gets faster (as I'm dependent on running maven goals on
> these actions) and when the user actually triggers "Run" only the
> execution phase needs to be run.
>
Yes, definitely useful to IDE integration. Visualization of the build
plan will be one of the most useful features there will be.
> Milos
>
>
> On Dec 19, 2007 10:34 PM, Jason van Zyl <ja...@maven.org> wrote:
>
> On 19 Dec 07, at 12:28 PM 19 Dec 07, Milos Kleint wrote:
>
> > here is the actual screenshot.
> >
> > http://picasaweb.google.com/mkleint/Maven
> >
> > more inline..
> >
> > On Dec 19, 2007 9:19 PM, Jason van Zyl <ja...@maven.org> wrote:
> >
> >>
> >> On 19 Dec 07, at 11:10 AM 19 Dec 07, Milos Kleint wrote:
> >>
> >>> Hello,
> >>>
> >>> i've started building my project with current 2.1-SNAPSHOT trunk
> and
> >>> I noticed the build is taking more time than before. I did a bit
> of
> >>> profiling.
> >>> I've executed "mvn install" on a set of 24 projects, all build
> >>> before, right before the profiling test.
> >>>
> >>> What struck me is that half of the time seems to be spent in
> >>> DefaultPluginManager.resolveTransitiveDependencies(). See attached
> >>> picture from netbeans profiler.
> >>> It was executed 82 times. I suppose the root of the problem
> will be
> >>> somewhere much deeper and I guess there's a way to optimize the
> >>> number of calls to the method as well.
> >>> After a bit of debugging i figured that for a single project this
> >>> method is called multiple times during execution. First the
> >>> "compile" scope is resolved, later "runtime" or "test" eventually
> >>> (depends on actual plugins bound to the project)
> >>> Ideally it should be called 24 times max as far as I understand
> the
> >>> problem. The BuildPlan should know up front what mojos will be
> >>> executed and what is the maximum level or dependency resolution
> for
> >>> the given project.
> >>>
> >>> Agreed? Is that something that I should pursue further or am I on
> >>> the wrong track?
> >>>
> >>
> >> Sure, take a look but in the plugin manager I started ripping out
> all
> >> the optimizations after ripping out a bunch of other code. But
> narrow
> >> it down for one build where
> >>
> >> 1) You don't have anything downloaded i.e. a clean repository, and
> >> 2) Where you have all the dependencies downloaded
> >>
> >> For one pass it shouldn't be resolving more then once for each
> >> plugin.
> >> I wouldn't try to start caching anything but if you're seeing more
> >> then one call per plugin then something needs to be reworked.
> >
> >
> > well, from what I understand I see 1 resolution per plugin per
> > project, if
> > the plugin requires dependency resolution.
>
> Yes, this is a reactor this is to account for cases where you may have
> the same plugin used, but might have dependencies stated itself which
> can change things so you need to track this. The non-optimized version
> obviously deals with this but you will end up with a case where
> different plugin declarations have slightly different dependency
> requirements. John tried to account for everything, but we could still
> cache most of the information.
>
> >
> > my ''optimization'' involves looking up front what is the maximum
> > dependency
> > resolution scope and resolve it just once per project. In your case
> > 1 it
> > means more than necessary gets downloaded upfront probably, but
> case 2
> > should be faster.
>
> So we can sync up here as I'm remaking the project builder and trying
> to setup a listener that can watch for things as projects are being
> built. One of the things I'm trying to collect are profiles and
> extensions so that we don't have to scan the POMs again after they are
> built. We could do the same with plugin declarations so that up-front
> you would know what you needed. So you could see that for all the
> plugin configurations there were no variations, pick off which ones
> need resolution, do that and then fire the build.
>
> So if you could determine what information you needed up front I can
> factor that in, and in the short term you can take the approach John
> has made with things like the extension scanner. But ultimately we
> should not need to read any pom.xml file more then once. Whether it
> come in the maven-artifact, the project builder or anything else.
>
> >
> >
> > Milos
> >
> >
> >>
> >>
> >>> Milos
> >>>
> >>> PS: If anyone is interested I can send the actual netbeans
> profiler
> >>> dump files for browsing (via private email).
> >>>
> >>>
> >>>
> >>>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder, Apache Maven
> >> jason at sonatype dot com
> >> ----------------------------------------------------------
> >>
> >> believe nothing, no matter where you read it,
> >> or who has said it,
> >> not even if i have said it,
> >> unless it agrees with your own reason
> >> and your own common sense.
> >>
> >> -- Buddha
> >>
> >>
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> What matters is not ideas, but the people who have them. Good people
> can fix bad ideas, but good ideas can't save bad people.
>
> -- Paul Graham
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> <
> lifecycleexecutor
> .patch
> >---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
We know what we are, but know not what we may be.
-- Shakespeare
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: possible performance bottleneck in current trunk
Posted by Milos Kleint <mk...@gmail.com>.
i've played with the DefaultLifecycleExecutor and DefaultPluginManager a bit
and tried to separate the preparation phase from the actual mojo executions.
The preparations seem to attribute to astonishing 90% of the build
execution.
See http://picasaweb.google.com/mkleint/Maven/photo#5146520463951211778
what have I actually done? (patch attached, I hope it gets through)
in the preparation phase
1. iterate all the projects, figure out the mojo bindings.
2. for each binding, load the asociated plugin
3. for each project figure out what the required maximum project dependency
resolution is and resolve it.
in the execution phase actually just run the mojo's execute method. (ripped
the project dependency resolution from there)
The work i've done is probably not generally useful, but it clearly shows
where space for improvements is.
However I'd like to use this in the Netbeans IDE, to "preload" various
actions as the user edits the files, so that the build/run/debug cycle gets
faster (as I'm dependent on running maven goals on these actions) and when
the user actually triggers "Run" only the execution phase needs to be run.
Milos
On Dec 19, 2007 10:34 PM, Jason van Zyl <ja...@maven.org> wrote:
>
> On 19 Dec 07, at 12:28 PM 19 Dec 07, Milos Kleint wrote:
>
> > here is the actual screenshot.
> >
> > http://picasaweb.google.com/mkleint/Maven
> >
> > more inline..
> >
> > On Dec 19, 2007 9:19 PM, Jason van Zyl <ja...@maven.org> wrote:
> >
> >>
> >> On 19 Dec 07, at 11:10 AM 19 Dec 07, Milos Kleint wrote:
> >>
> >>> Hello,
> >>>
> >>> i've started building my project with current 2.1-SNAPSHOT trunk and
> >>> I noticed the build is taking more time than before. I did a bit of
> >>> profiling.
> >>> I've executed "mvn install" on a set of 24 projects, all build
> >>> before, right before the profiling test.
> >>>
> >>> What struck me is that half of the time seems to be spent in
> >>> DefaultPluginManager.resolveTransitiveDependencies(). See attached
> >>> picture from netbeans profiler.
> >>> It was executed 82 times. I suppose the root of the problem will be
> >>> somewhere much deeper and I guess there's a way to optimize the
> >>> number of calls to the method as well.
> >>> After a bit of debugging i figured that for a single project this
> >>> method is called multiple times during execution. First the
> >>> "compile" scope is resolved, later "runtime" or "test" eventually
> >>> (depends on actual plugins bound to the project)
> >>> Ideally it should be called 24 times max as far as I understand the
> >>> problem. The BuildPlan should know up front what mojos will be
> >>> executed and what is the maximum level or dependency resolution for
> >>> the given project.
> >>>
> >>> Agreed? Is that something that I should pursue further or am I on
> >>> the wrong track?
> >>>
> >>
> >> Sure, take a look but in the plugin manager I started ripping out all
> >> the optimizations after ripping out a bunch of other code. But narrow
> >> it down for one build where
> >>
> >> 1) You don't have anything downloaded i.e. a clean repository, and
> >> 2) Where you have all the dependencies downloaded
> >>
> >> For one pass it shouldn't be resolving more then once for each
> >> plugin.
> >> I wouldn't try to start caching anything but if you're seeing more
> >> then one call per plugin then something needs to be reworked.
> >
> >
> > well, from what I understand I see 1 resolution per plugin per
> > project, if
> > the plugin requires dependency resolution.
>
> Yes, this is a reactor this is to account for cases where you may have
> the same plugin used, but might have dependencies stated itself which
> can change things so you need to track this. The non-optimized version
> obviously deals with this but you will end up with a case where
> different plugin declarations have slightly different dependency
> requirements. John tried to account for everything, but we could still
> cache most of the information.
>
> >
> > my ''optimization'' involves looking up front what is the maximum
> > dependency
> > resolution scope and resolve it just once per project. In your case
> > 1 it
> > means more than necessary gets downloaded upfront probably, but case 2
> > should be faster.
>
> So we can sync up here as I'm remaking the project builder and trying
> to setup a listener that can watch for things as projects are being
> built. One of the things I'm trying to collect are profiles and
> extensions so that we don't have to scan the POMs again after they are
> built. We could do the same with plugin declarations so that up-front
> you would know what you needed. So you could see that for all the
> plugin configurations there were no variations, pick off which ones
> need resolution, do that and then fire the build.
>
> So if you could determine what information you needed up front I can
> factor that in, and in the short term you can take the approach John
> has made with things like the extension scanner. But ultimately we
> should not need to read any pom.xml file more then once. Whether it
> come in the maven-artifact, the project builder or anything else.
>
> >
> >
> > Milos
> >
> >
> >>
> >>
> >>> Milos
> >>>
> >>> PS: If anyone is interested I can send the actual netbeans profiler
> >>> dump files for browsing (via private email).
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder, Apache Maven
> >> jason at sonatype dot com
> >> ----------------------------------------------------------
> >>
> >> believe nothing, no matter where you read it,
> >> or who has said it,
> >> not even if i have said it,
> >> unless it agrees with your own reason
> >> and your own common sense.
> >>
> >> -- Buddha
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> What matters is not ideas, but the people who have them. Good people
> can fix bad ideas, but good ideas can't save bad people.
>
> -- Paul Graham
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: possible performance bottleneck in current trunk
Posted by Jason van Zyl <ja...@maven.org>.
On 19 Dec 07, at 12:28 PM 19 Dec 07, Milos Kleint wrote:
> here is the actual screenshot.
>
> http://picasaweb.google.com/mkleint/Maven
>
> more inline..
>
> On Dec 19, 2007 9:19 PM, Jason van Zyl <ja...@maven.org> wrote:
>
>>
>> On 19 Dec 07, at 11:10 AM 19 Dec 07, Milos Kleint wrote:
>>
>>> Hello,
>>>
>>> i've started building my project with current 2.1-SNAPSHOT trunk and
>>> I noticed the build is taking more time than before. I did a bit of
>>> profiling.
>>> I've executed "mvn install" on a set of 24 projects, all build
>>> before, right before the profiling test.
>>>
>>> What struck me is that half of the time seems to be spent in
>>> DefaultPluginManager.resolveTransitiveDependencies(). See attached
>>> picture from netbeans profiler.
>>> It was executed 82 times. I suppose the root of the problem will be
>>> somewhere much deeper and I guess there's a way to optimize the
>>> number of calls to the method as well.
>>> After a bit of debugging i figured that for a single project this
>>> method is called multiple times during execution. First the
>>> "compile" scope is resolved, later "runtime" or "test" eventually
>>> (depends on actual plugins bound to the project)
>>> Ideally it should be called 24 times max as far as I understand the
>>> problem. The BuildPlan should know up front what mojos will be
>>> executed and what is the maximum level or dependency resolution for
>>> the given project.
>>>
>>> Agreed? Is that something that I should pursue further or am I on
>>> the wrong track?
>>>
>>
>> Sure, take a look but in the plugin manager I started ripping out all
>> the optimizations after ripping out a bunch of other code. But narrow
>> it down for one build where
>>
>> 1) You don't have anything downloaded i.e. a clean repository, and
>> 2) Where you have all the dependencies downloaded
>>
>> For one pass it shouldn't be resolving more then once for each
>> plugin.
>> I wouldn't try to start caching anything but if you're seeing more
>> then one call per plugin then something needs to be reworked.
>
>
> well, from what I understand I see 1 resolution per plugin per
> project, if
> the plugin requires dependency resolution.
Yes, this is a reactor this is to account for cases where you may have
the same plugin used, but might have dependencies stated itself which
can change things so you need to track this. The non-optimized version
obviously deals with this but you will end up with a case where
different plugin declarations have slightly different dependency
requirements. John tried to account for everything, but we could still
cache most of the information.
>
> my ''optimization'' involves looking up front what is the maximum
> dependency
> resolution scope and resolve it just once per project. In your case
> 1 it
> means more than necessary gets downloaded upfront probably, but case 2
> should be faster.
So we can sync up here as I'm remaking the project builder and trying
to setup a listener that can watch for things as projects are being
built. One of the things I'm trying to collect are profiles and
extensions so that we don't have to scan the POMs again after they are
built. We could do the same with plugin declarations so that up-front
you would know what you needed. So you could see that for all the
plugin configurations there were no variations, pick off which ones
need resolution, do that and then fire the build.
So if you could determine what information you needed up front I can
factor that in, and in the short term you can take the approach John
has made with things like the extension scanner. But ultimately we
should not need to read any pom.xml file more then once. Whether it
come in the maven-artifact, the project builder or anything else.
>
>
> Milos
>
>
>>
>>
>>> Milos
>>>
>>> PS: If anyone is interested I can send the actual netbeans profiler
>>> dump files for browsing (via private email).
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>> believe nothing, no matter where you read it,
>> or who has said it,
>> not even if i have said it,
>> unless it agrees with your own reason
>> and your own common sense.
>>
>> -- Buddha
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
What matters is not ideas, but the people who have them. Good people
can fix bad ideas, but good ideas can't save bad people.
-- Paul Graham
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: possible performance bottleneck in current trunk
Posted by Milos Kleint <mk...@gmail.com>.
here is the actual screenshot.
http://picasaweb.google.com/mkleint/Maven
more inline..
On Dec 19, 2007 9:19 PM, Jason van Zyl <ja...@maven.org> wrote:
>
> On 19 Dec 07, at 11:10 AM 19 Dec 07, Milos Kleint wrote:
>
> > Hello,
> >
> > i've started building my project with current 2.1-SNAPSHOT trunk and
> > I noticed the build is taking more time than before. I did a bit of
> > profiling.
> > I've executed "mvn install" on a set of 24 projects, all build
> > before, right before the profiling test.
> >
> > What struck me is that half of the time seems to be spent in
> > DefaultPluginManager.resolveTransitiveDependencies(). See attached
> > picture from netbeans profiler.
> > It was executed 82 times. I suppose the root of the problem will be
> > somewhere much deeper and I guess there's a way to optimize the
> > number of calls to the method as well.
> > After a bit of debugging i figured that for a single project this
> > method is called multiple times during execution. First the
> > "compile" scope is resolved, later "runtime" or "test" eventually
> > (depends on actual plugins bound to the project)
> > Ideally it should be called 24 times max as far as I understand the
> > problem. The BuildPlan should know up front what mojos will be
> > executed and what is the maximum level or dependency resolution for
> > the given project.
> >
> > Agreed? Is that something that I should pursue further or am I on
> > the wrong track?
> >
>
> Sure, take a look but in the plugin manager I started ripping out all
> the optimizations after ripping out a bunch of other code. But narrow
> it down for one build where
>
> 1) You don't have anything downloaded i.e. a clean repository, and
> 2) Where you have all the dependencies downloaded
>
> For one pass it shouldn't be resolving more then once for each plugin.
> I wouldn't try to start caching anything but if you're seeing more
> then one call per plugin then something needs to be reworked.
well, from what I understand I see 1 resolution per plugin per project, if
the plugin requires dependency resolution.
my ''optimization'' involves looking up front what is the maximum dependency
resolution scope and resolve it just once per project. In your case 1 it
means more than necessary gets downloaded upfront probably, but case 2
should be faster.
Milos
>
>
> > Milos
> >
> > PS: If anyone is interested I can send the actual netbeans profiler
> > dump files for browsing (via private email).
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> believe nothing, no matter where you read it,
> or who has said it,
> not even if i have said it,
> unless it agrees with your own reason
> and your own common sense.
>
> -- Buddha
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
RE: possible performance bottleneck in current trunk
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Would it be safe to hold on to the resolved dependencies per scope /
project? So if two plugins in the same project consecutively ask for
scope=test, we don't have to go fetch them again? The current impl
simply leaves those dependencies around which means plugins that don't
properly declare the scope they want will work in some situations.
-----Original Message-----
From: Jason van Zyl [mailto:jason@maven.org]
Sent: Wednesday, December 19, 2007 3:19 PM
To: Maven Developers List
Subject: Re: possible performance bottleneck in current trunk
On 19 Dec 07, at 11:10 AM 19 Dec 07, Milos Kleint wrote:
> Hello,
>
> i've started building my project with current 2.1-SNAPSHOT trunk and
> I noticed the build is taking more time than before. I did a bit of
> profiling.
> I've executed "mvn install" on a set of 24 projects, all build
> before, right before the profiling test.
>
> What struck me is that half of the time seems to be spent in
> DefaultPluginManager.resolveTransitiveDependencies(). See attached
> picture from netbeans profiler.
> It was executed 82 times. I suppose the root of the problem will be
> somewhere much deeper and I guess there's a way to optimize the
> number of calls to the method as well.
> After a bit of debugging i figured that for a single project this
> method is called multiple times during execution. First the
> "compile" scope is resolved, later "runtime" or "test" eventually
> (depends on actual plugins bound to the project)
> Ideally it should be called 24 times max as far as I understand the
> problem. The BuildPlan should know up front what mojos will be
> executed and what is the maximum level or dependency resolution for
> the given project.
>
> Agreed? Is that something that I should pursue further or am I on
> the wrong track?
>
Sure, take a look but in the plugin manager I started ripping out all
the optimizations after ripping out a bunch of other code. But narrow
it down for one build where
1) You don't have anything downloaded i.e. a clean repository, and
2) Where you have all the dependencies downloaded
For one pass it shouldn't be resolving more then once for each plugin.
I wouldn't try to start caching anything but if you're seeing more
then one call per plugin then something needs to be reworked.
> Milos
>
> PS: If anyone is interested I can send the actual netbeans profiler
> dump files for browsing (via private email).
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.
-- Buddha
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: possible performance bottleneck in current trunk
Posted by Jason van Zyl <ja...@maven.org>.
On 19 Dec 07, at 11:10 AM 19 Dec 07, Milos Kleint wrote:
> Hello,
>
> i've started building my project with current 2.1-SNAPSHOT trunk and
> I noticed the build is taking more time than before. I did a bit of
> profiling.
> I've executed "mvn install" on a set of 24 projects, all build
> before, right before the profiling test.
>
> What struck me is that half of the time seems to be spent in
> DefaultPluginManager.resolveTransitiveDependencies(). See attached
> picture from netbeans profiler.
> It was executed 82 times. I suppose the root of the problem will be
> somewhere much deeper and I guess there's a way to optimize the
> number of calls to the method as well.
> After a bit of debugging i figured that for a single project this
> method is called multiple times during execution. First the
> "compile" scope is resolved, later "runtime" or "test" eventually
> (depends on actual plugins bound to the project)
> Ideally it should be called 24 times max as far as I understand the
> problem. The BuildPlan should know up front what mojos will be
> executed and what is the maximum level or dependency resolution for
> the given project.
>
> Agreed? Is that something that I should pursue further or am I on
> the wrong track?
>
Sure, take a look but in the plugin manager I started ripping out all
the optimizations after ripping out a bunch of other code. But narrow
it down for one build where
1) You don't have anything downloaded i.e. a clean repository, and
2) Where you have all the dependencies downloaded
For one pass it shouldn't be resolving more then once for each plugin.
I wouldn't try to start caching anything but if you're seeing more
then one call per plugin then something needs to be reworked.
> Milos
>
> PS: If anyone is interested I can send the actual netbeans profiler
> dump files for browsing (via private email).
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.
-- Buddha
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org