On Thu, 2010-01-07 at 08:26 +1100, Brett Porter wrote:
> On 07/01/2010, at 1:16 AM, Kristian Rosenvold wrote:
>
> > On Wed, 2010-01-06 at 13:41 +0000, Stephen Connolly wrote:
> >> however you might have to wait for "install" as the attached artifact
> >> can be replaced in the reactor, e.g. maven-shade-plugin could be
> >> replacing the artifact with its shaded version
> >>
> >> you only know by the time you hit install (or the last phase in the
> >> invoked lifecycle, whichever comes first) that the attached artifacts
> >> are the final attached artifacts for consumption by dependent modules
> >>
> >
> > This is really interesting, because it probably has the same solution
> > as the antrun problem.
> >
> >> From a 10000 foot perspective, what my patch really does is augment the
> > ProjectDependencyGraph with Scheduling information, effectively
> > constructing a much richer dependency graph.
>
> Is the way this is designed something that's potentially reusable outside of
> Maven in an embedded scenario? Continuum currently builds Maven projects
> module by module, with some crude parallelism and the old project sorter. The
> availability of this and the Maven embedder would be smoking for CI :)
I think a key part of my work so far (and actually, most of the effort),
has been in "opening up" the DefaultLifecycleExecutor. Most of this
stuff used to be internal to that class, and it was a huge class. That
being said, all the "opened" code is in a package called "internal", and
if this were an OSGI component it would not be exported until someone
decides to ;) By the same reasoning, it'd probably not be immediately
available for embedded usage. I've tried to stay away from redesigning
the public apis, which I think should be left to the real veterans ;)
>
> >
> > The "Schedule" that is added to the ExecutionPlanItem describes the
> > relationship to upstream plugins/phases. So when a given plugin has a
> > specific requirement (i.e. "I require a jar file") it expresses a
> > dependency upon the install plugin.
> This is all behind the scenes? I usually raise a flag hearing "expressing a
> dependency on the install plugin",
> as its one of the anti-patterns of maven 1 that we keep trying to avoid
> (where you couldn't switch in other plugins because of hard dependencies).
> But if I understand correctly, you're just figuring out that it is the
> install plugin at runtime because install was run,
> and it produced the relevant copy of the artifact that now needs to be used.
> Along the lines of what Stephen mentioned - the use cases I'd expect to still
> work is proper ordering when running "mvn package",
> cases like the shade plugin that replace the main artifact, or the creation
> of attached artifacts.
Initially I implemented the solution Dan came up with (it worked). And I
immediately walked off in several directions looking for gold. I'll try
to summarize this when I reply to Dan.
It's been a long journey for me ;)
Initially I figured this was about phases and the relationship between
phases. Then I learned that at one point in the code (execution
planning) the phases more or less go away, and get replaced by an
execution plan - after which its mostly about executions.
So at the moment a single "Schedule" allows expressing both
relationships between phases and plugins, and the actual effect of a
schedule is determined in execution planning. My thought were that we'd
maybe have a number of available (declaratively expressed) concurrency
schedules that could be used for different "typical" execution
scenarios. This could be used to gain HUGE performance at the cost of
not supporting all plugin combinations. I'm still not sure if this is
realistic, but I have 1 schedule implemented that builds my 2 favourite
builds ;)
Right here I'll leave this subject, seeking an even bigger picture.
Somewhere along this process my world view of what maven /is/ changed
slightly. It became a "build-dependency injection framework". (I'm crazy
about DI, and it shines through; be happy it's not soccer or you'd have
"maven is a soccer field" ;)
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 ;)
Every time I say "wait" the concurrency nerd in me knows there's a
chance of deadlocks, this has been one of my prime motivators for "not"
choosing a number of different scheduling strategies I tried - they all
ended up being too complex and/or deadlock prone. I'm not sure how this
would work but if you liberally sprinkle enough threads around it might
float.
I'm a bit sorry for going in & out of "ideas" mode here. I'll try to be
more down-to earth when I reply to Dan's mail .
>This sounds a lot like the need for something like this in 3.1:
>http://jira.codehaus.org/browse/MNG-193 :)
Issue created 12/mar/05 ;)
Kristian
> Thanks for continuing to give us insight into how this is working!
>
> Cheers,
> Brett
>
> --
> Brett Porter
> br...@apache.org
> http://brettporter.wordpress.com/
>
>
>
>
>
> ---------------------------------------------------------------------
> 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
