2010/1/7 Kristian Rosenvold <kristian.rosenv...@gmail.com>:
> On Thu, 2010-01-07 at 08:37 +0000, Stephen Connolly wrote:
>> > I realized that the prime subject of contention is the injected
>> > resources - maybe ONLY that. So "scheduling" attached to phases or
>> > plugins is really ultimately not the prime target. When thinking of
>> > Dan's Antrun plugin requirement of
>> > ${maven.dependency.org.apache.maven.antrunbug.provider.jar.path} I
>> > realized that if this were Spring/Guice; these problems would be solved
>> > by giving you a dynamic proxy instead of the real dependency. This proxy
>> > could/would know about the availability of the actual resource. If the
>> > resource isn't available yet it'd wait for it to become available before
>> > handing it off to the user. Spring handles web "Session" scope by
>> > injecting a singleton dynamic proxy into the client. Upon invocation,
>> > this object decides what the REAL target is and forwards the request
>> > there. Along the same lines it's at least theoretically possible that
>> > you could inject a proxy that potentially waits until the actual
>> > resource is available; effectively letting the injected project
>> > resources control the scheduling. Doesn't work well with injected
>> > Strings, though ;)
>> >
>>
>> but if you have the dynamic proxy wait before injecting!
>>
>> I haven't looked at the m3 core codebase, but we should only finalize
>> the mojo immediately before executing it, therefore we should be able
>> to block until all it's requirements are in the appropriate state...
>> should not matter if they are strings
>>
>
> Oooo. I can practically hear the hudson alarm bells from the m3
> integration test build chiming already ;)
>
> If you're right, the real essence of the problem is capturing the
> creation of the injectable state. If I was at a pub drinking (lots of)
> beer, I would probably suggest that you could invert the whole process
> and actually attach the creation of the state to the "fact" that someone
> is requesting it. This would be after a large number of beers.
>
> Cheers !
Side note:
Now that sounds like the concurrency code I wrote to convert from
Accurev to Subversion....
I actually ended up creating the state of a stream at a specific
revision because it was asked for (by a downstream stream/workspace or
by a subsequent revision)
Then I had a dynamic cache that tracked popular states... and then you
just step through each revision one by one and solve every stream.
I was able to convert 115789 revisions in one depot with 1000's of
streams/workspaces/snapshots on my quad core2 with 4GB of ram in only
3 days! The SVN dump file took 4 days to load into subversion!
Of course if we were to implement that kind of approach for Maven then
you might not even build a specific module because nobody was looking
for it... hmmm even faster builds
>
> Kristian
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
