I have now submitted my work as a patch attched to MNG3004. It still
only solves MNG3004 (I am considering 2802 a different patch or I'll
never finish anything ;)
The last version can be downloaded from
http://cloud.github.com/downloads/krosenvold/maven3/apache-maven-3.0-SNAPSHOT-bin.tar.gz
(Th
On 2009-12-09, at 9:15 AM, Kristian Rosenvold wrote:
> There's a lot of fun to be had with modern DI ;) I assume you're
> planning to keep the plexus interfaces and just change implementation ?
>
> Do you have any documentation/references on how you're intending to do
> this ? Will the plugins b
On 10/12/2009, at 3:38 AM, Kristian Rosenvold wrote:
> My personal short-list on MNG-3004 now only contains 1 thing, getting
> order on log output. I need some help on this one;
>
> It seems like there's two sensible ways to handle this
>
> A) Intercept plexus "Logger" and sort according to cal
On 10/12/2009, at 3:50 AM, Jason van Zyl wrote:
>
> On 2009-12-09, at 8:38 AM, Kristian Rosenvold wrote:
>
>> My personal short-list on MNG-3004 now only contains 1 thing, getting
>> order on log output. I need some help on this one;
>>
>> It seems like there's two sensible ways to handle this
Correct
On 2009-12-09, at 10:16 AM, Paul Benedict wrote:
> Typo? Nothing will appear *different* to users or plugin developers.?
>
> On Wed, Dec 9, 2009 at 12:14 PM, Jason van Zyl wrote:
>>
>> On 2009-12-09, at 9:15 AM, Kristian Rosenvold wrote:
>>
>>> There's a lot of fun to be had with mode
Typo? Nothing will appear *different* to users or plugin developers.?
On Wed, Dec 9, 2009 at 12:14 PM, Jason van Zyl wrote:
>
> On 2009-12-09, at 9:15 AM, Kristian Rosenvold wrote:
>
>> There's a lot of fun to be had with modern DI ;) I assume you're
>> planning to keep the plexus interfaces and
On 2009-12-09, at 9:15 AM, Kristian Rosenvold wrote:
> There's a lot of fun to be had with modern DI ;) I assume you're
> planning to keep the plexus interfaces and just change implementation ?
>
Yes, we have to support all the old plugins with all the old metadata. We drop
in Guice+Plexus shi
There's a lot of fun to be had with modern DI ;) I assume you're
planning to keep the plexus interfaces and just change implementation ?
Do you have any documentation/references on how you're intending to do
this ? Will the plugins be wired up with guice too ?
On the grand scale of things, this i
On 2009-12-09, at 8:38 AM, Kristian Rosenvold wrote:
> My personal short-list on MNG-3004 now only contains 1 thing, getting
> order on log output. I need some help on this one;
>
> It seems like there's two sensible ways to handle this
>
> A) Intercept plexus "Logger" and sort according to cal
My personal short-list on MNG-3004 now only contains 1 thing, getting
order on log output. I need some help on this one;
It seems like there's two sensible ways to handle this
A) Intercept plexus "Logger" and sort according to calling thread.
B) Intercept System.out/err and sort according to call
Wow, big improvement here too. I had to fix a couple of things in my
build to migrate it to 3.0 (like remove duplicate dependencies I didn't even
know about), and a couple of tests on evil stateful singletons (don't
ask), and voilà! Full clean install dropped from 9m44s or so to 4m45s.
Con
I'm just starting to take a look now.
Have you buy chance run what you've built against the integration tests?
http://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/
If not, happy to help, or we can pull it into the grid and try it out there.
On 2009-12-03, at 1:05 AM, Kristian R
It's getting close enough, as long as you satisfy the
following constraints:
- Make sure your build works with "regular" maven3 snapshots first ;)
- You're not too reliant on snapshot artifacts (MNG-2802 is next on my
TODO list now)
- You're not generating source code in generate-sources
- Runnin
On Tue, Dec 1, 2009 at 9:49 PM, Kristian Rosenvold
wrote:
> I am pleased to announce that the "weave" mode now does a
> "mvn clean install" of a fairly regular project with any number of
> threads, and at great speed improvement - 2-4x is not uncommon.
>
> There are still issues to be sorted out,
I am pleased to announce that the "weave" mode now does a
"mvn clean install" of a fairly regular project with any number of
threads, and at great speed improvement - 2-4x is not uncommon.
There are still issues to be sorted out, and I'd be really grateful
for any reports of problems.
See http:/
I have now come a long way towards implementing a massively concurrent
maven. To whet some appetites before ifs/but/whens/problems come up:
Using 16 threads on my Intel i7, build time for my daytime project went
from 87 seconds to 19.7 seconds. An average of 500% CPU was consumed to
deliver this,
I have tried to summarize the discussion/results of this topic so far. I
was not able to write to the wiki (user krosenvold), but if someone with
permissions would consider uploading this http://gist.github.com/241344
to the wiki (it's confluence format), It'd bring the process one step
forward.
One downside to this kind of parallelism that you should consider is the
output. If all these tasks are writing to stdout or stderr simultaneously it is
going to make the build output hard to understand. It might be preferable to
pipe the output from a thread into a cache and then write the who
I like it!
Well, except for the "1 thread per module" part; that's clearly too many
threads. You'd want a fixed thread pool.
But restructuring the multithreading around the individual phases and
*scheduling* phases from later projects when earlier project phases are
done seems workable.
W
I've looked over the code and thought a bit further about the
constraints involved, and given that:
- Multi module reactor builds are the only interesting targets of
multithreading.
- Reactor builds do not use the "install" output of their upstream
dependencies (I was not aware of that ;)
You do
In m3 (which is what we are talking about) AFAIK we can have a
listener that waits for the end of the start of the deploy phase
and/or the end of execution.
With a customized install plugin, we could just install to the
"transaction" repository. The listener can then block until the
criteria have
I seem to understand that there's room for several different
types of solution here;
Starting with the single-machine solution; I now understand that
you could start forking downstream builds straight after
compile in a reactor build, maybe after install in other cases.
In this scenario I think
> What about users doing multi-machine builds? Earlier this week I wrote that
> users desiring to do multi-machine parallelism should deploy their builds to
> a remote repository shared between the machines. Should their tests run
> post-deploy?
>
I think what you meant is "my" tests should run
I'm conceptually using the transactional "local" repository as a
get-out-of-jail card for possible violations of contract,
the full build must be ok for the real repository update to
come through, creating any publicly visible artifacts.
Obviously, you're right, the tests should be pushed
to after
I've been meaning to reply to your earlier emails (it's been a busy week);
to this I'll just say that moving the "test" phase after the "install"
phase is a fascinating idea, which I personally like, but it seems like a
big violation of the contract for the lifecycle, and I suspect it won't be
I've been thinking further about parallelity within maven. The proposed
solution to MNG-3004
achieves parallelity by analyzing inter-module dependencies and scheduling
parallel dependencies in parallel.
A simple further evolution of this would be to collect and download all
external dependencies
f
26 matches
Mail list logo
