2010/1/7 Kristian Rosenvold <kristian.rosenv...@gmail.com>:
> 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 ;)
>
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
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
