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 +, Stephen Connolly wrote:
however you might have to wait for install as the attached
On Wed, 2010-01-06 at 18:36 -0800, Dan Fabulich wrote:
Kristian Rosenvold wrote:
In this process I removed your original implementation, simply because
it allowed me to work freely in simplifying my own implementation (and I
truly believe I managed to make some good simplifications). I
On Thu, 2010-01-07 at 08:37 +, 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
2010/1/7 Kristian Rosenvold kristian.rosenv...@gmail.com:
On Thu, 2010-01-07 at 08:37 +, 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
On Thu, 2010-01-07 at 10:17 +, Stephen Connolly wrote:
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
2010/1/7 Kristian Rosenvold kristian.rosenv...@gmail.com:
On Thu, 2010-01-07 at 10:17 +, Stephen Connolly wrote:
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
Currently you can only say compile is outputDependenant upon itself,
meaning it'll wait for compile in all upstream projects to finish
before proceeding. We also need to be able to specify the explicit
target of the dependency, so you could say test is outputDependant on
compile in all
Sent from my [rhymes with tryPod] ;-)
On 7 Jan 2010, at 23:20, Barrie Treloar baerr...@gmail.com wrote:
Currently you can only say compile is outputDependenant upon
itself,
meaning it'll wait for compile in all upstream projects to finish
before proceeding. We also need to be able to
On Fri, Jan 8, 2010 at 10:10 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On 7 Jan 2010, at 23:20, Barrie Treloar baerr...@gmail.com wrote:
Currently you can only say compile is outputDependenant upon itself,
meaning it'll wait for compile in all upstream projects to finish
Kristian Rosenvold wrote:
I will re-add your stuff, and I will also set it up to use my output
demultiplexer that causes output to appear in normal order.
Does the demultiplexer do anything in weave mode when threads=1? Does it
make the projects appear to unweave (as far as the log is
On 1/8/10, Dan Fabulich d...@fabulich.com wrote:
Kristian Rosenvold wrote:
I will re-add your stuff, and I will also set it up to use my output
demultiplexer that causes output to appear in normal order.
Does the demultiplexer do anything in weave mode when threads=1? Does it
make the
Cool. I'll do the *simple* clarifications first:
Without a threads argument it behaves like a totally standard M3. All
integration tests pass, and I spent a lot of energy to make sure I
didn't break anything. So in answer to (1), it builds maven3 without
threading. With threading is a different
On 06/01/2010, at 10:15 PM, Kristian Rosenvold wrote:
- Given that parallel execution is an alternate mode that may have
additional constraints, does 3.0 need something that is guaranteed to
work for the vast majority of projects ? I think Dan's implementation
does this already, while the
On Wed, 2010-01-06 at 22:36 +1100, Brett Porter wrote:
On 06/01/2010, at 10:15 PM, Kristian Rosenvold wrote:
- Given that parallel execution is an alternate mode that may have
additional constraints, does 3.0 need something that is guaranteed to
work for the vast majority of projects ? I
2010/1/6 Kristian Rosenvold kristian.rosenv...@gmail.com:
On Wed, 2010-01-06 at 22:36 +1100, Brett Porter wrote:
On 06/01/2010, at 10:15 PM, Kristian Rosenvold wrote:
- Given that parallel execution is an alternate mode that may have
additional constraints, does 3.0 need something that is
On Wed, 2010-01-06 at 13:41 +, 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
On 07/01/2010, at 1:16 AM, Kristian Rosenvold wrote:
On Wed, 2010-01-06 at 13:41 +, 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
Kristian Rosenvold wrote:
In this process I removed your original implementation, simply because
it allowed me to work freely in simplifying my own implementation (and I
truly believe I managed to make some good simplifications). I also
considered that I'd re-add your implementation as a third
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 +, Stephen Connolly wrote:
however you might have to wait for install as the attached artifact
can be replaced in the reactor, e.g.
On 07/01/2010, at 6:45 PM, Kristian Rosenvold wrote:
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
1) I'm encountering some integration failures in my build at work when
using -Dmaven.threads.experimental=1; I'll try to turn them into proper
bugs in the next few days.
2) In the documentation on http://github.com/krosenvold/maven3/ it says
that it does not yet build Maven 3. Does this
21 matches
Mail list logo
