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 !
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
