Only build changed modules in a maven job

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Only build changed modules in a maven job

Erik Ramfelt
On my hudson server I have a maven job for all Hudson plugins because
Im too lazy to create separate jobs for each plugin and I dont really
see an advantage of doing that. The downside for this is that I use
SCM Polling for job which trigger a rebuild of all modules, even if it
is only one module that has changed. A full rebuild takes longer and
longer, (yes, im here whining about the build time again) as more and
more plugins are added.

Ive been thinking if it would be possible to do a little smarter
rebuild for maven jobs with modules. What if the maven job could use
the file paths from the
build.getChangeSet().getItems().getAffectedPaths() method, and only
call the maven goals for those paths? It should somehow find the
deepest pom.xml and use that for each path. I guess if there are
dependencies within the modules, that should be solved as well.

I guess its doable, but would it be a good idea?

//Erik

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Only build changed modules in a maven job

Kohsuke Kawaguchi
Administrator
Erik Ramfelt wrote:
> On my hudson server I have a maven job for all Hudson plugins because
> Im too lazy to create separate jobs for each plugin and I dont really
> see an advantage of doing that. The downside for this is that I use
> SCM Polling for job which trigger a rebuild of all modules, even if it
> is only one module that has changed. A full rebuild takes longer and
> longer, (yes, im here whining about the build time again) as more and
> more plugins are added.

Yes.

> Ive been thinking if it would be possible to do a little smarter
> rebuild for maven jobs with modules. What if the maven job could use
> the file paths from the
> build.getChangeSet().getItems().getAffectedPaths() method, and only
> call the maven goals for those paths? It should somehow find the
> deepest pom.xml and use that for each path. I guess if there are
> dependencies within the modules, that should be solved as well.

We wanted to go to this direction, too. In fact, this is how the m2
support was done initially. Today there's a mode in Hudson in which you
can build modules in parallel, which is the remnant of what was done
originally.

Since then I think we've got the feedback that some people do want this,
so we should do this.

I think one of the major problem here is the initial hit in creating
Maven JVM, because Hudson needs to inject a bunch of classes. I have
some ideas to fix that, but haven't worked on implementing it yet.

> I guess its doable, but would it be a good idea?

So I think the answer is yes --- now, would you be interested in helping
with the development? :-)


--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Only build changed modules in a maven job

Erik Ramfelt
On Wed, Jun 4, 2008 at 1:37 AM, Kohsuke Kawaguchi
<[hidden email]> wrote:

> Erik Ramfelt wrote:
>>
>> On my hudson server I have a maven job for all Hudson plugins because
>> Im too lazy to create separate jobs for each plugin and I dont really
>> see an advantage of doing that. The downside for this is that I use
>> SCM Polling for job which trigger a rebuild of all modules, even if it
>> is only one module that has changed. A full rebuild takes longer and
>> longer, (yes, im here whining about the build time again) as more and
>> more plugins are added.
>
> Yes.
>
>> Ive been thinking if it would be possible to do a little smarter
>> rebuild for maven jobs with modules. What if the maven job could use
>> the file paths from the
>> build.getChangeSet().getItems().getAffectedPaths() method, and only
>> call the maven goals for those paths? It should somehow find the
>> deepest pom.xml and use that for each path. I guess if there are
>> dependencies within the modules, that should be solved as well.
>
> We wanted to go to this direction, too. In fact, this is how the m2 support
> was done initially. Today there's a mode in Hudson in which you can build
> modules in parallel, which is the remnant of what was done originally.

Why was the functionality removed/changed? Was there any problem with it?

> Since then I think we've got the feedback that some people do want this, so
> we should do this.
>
> I think one of the major problem here is the initial hit in creating Maven
> JVM, because Hudson needs to inject a bunch of classes. I have some ideas to
> fix that, but haven't worked on implementing it yet.

How big is the hit in creating the JVM, do you have any rough numbers?
Ive noticed on my hudson instance that building the clearcase plugin
takes 3 min as a separate maven job; while it takes 1 min as a part of
the plugins maven job.

So maybe this should be configurable as not everyone will benefit of
this, next to the "Build modules in parallel".

>> I guess its doable, but would it be a good idea?
>
> So I think the answer is yes --- now, would you be interested in helping
> with the development? :-)

Of course!  I've looked briefly at the current implementation and it
does not seem to calculate dependencies within the modules. So my aim
is to test first and see if there is any real benefit from it.

Maven-agent does not contain any related to this change, right?

//Erik

>
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems                   [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Only build changed modules in a maven job

Tom Huybrechts
In reply to this post by Kohsuke Kawaguchi
On Wed, Jun 4, 2008 at 1:37 AM, Kohsuke Kawaguchi
<[hidden email]> wrote:

> Erik Ramfelt wrote:
>>
>> On my hudson server I have a maven job for all Hudson plugins because
>> Im too lazy to create separate jobs for each plugin and I dont really
>> see an advantage of doing that. The downside for this is that I use
>> SCM Polling for job which trigger a rebuild of all modules, even if it
>> is only one module that has changed. A full rebuild takes longer and
>> longer, (yes, im here whining about the build time again) as more and
>> more plugins are added.
>
> Yes.
>
>> Ive been thinking if it would be possible to do a little smarter
>> rebuild for maven jobs with modules. What if the maven job could use
>> the file paths from the
>> build.getChangeSet().getItems().getAffectedPaths() method, and only
>> call the maven goals for those paths? It should somehow find the
>> deepest pom.xml and use that for each path. I guess if there are
>> dependencies within the modules, that should be solved as well.
>
> We wanted to go to this direction, too. In fact, this is how the m2 support
> was done initially. Today there's a mode in Hudson in which you can build
> modules in parallel, which is the remnant of what was done originally.
>
> Since then I think we've got the feedback that some people do want this, so
> we should do this.
>
> I think one of the major problem here is the initial hit in creating Maven
> JVM, because Hudson needs to inject a bunch of classes. I have some ideas to
> fix that, but haven't worked on implementing it yet.

I suggest fixing the Maven startup problem by creating a dummy POM
which only contains a modules section referring to the projects you
want to build.

>
>> I guess its doable, but would it be a good idea?
>
> So I think the answer is yes --- now, would you be interested in helping
> with the development? :-)
>
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems                   [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Only build changed modules in a maven job

Kohsuke Kawaguchi
Administrator
In reply to this post by Erik Ramfelt
Erik Ramfelt wrote:

> On Wed, Jun 4, 2008 at 1:37 AM, Kohsuke Kawaguchi
> <[hidden email]> wrote:
>> Erik Ramfelt wrote:
>>>
>>> On my hudson server I have a maven job for all Hudson plugins because
>>> Im too lazy to create separate jobs for each plugin and I dont really
>>> see an advantage of doing that. The downside for this is that I use
>>> SCM Polling for job which trigger a rebuild of all modules, even if it
>>> is only one module that has changed. A full rebuild takes longer and
>>> longer, (yes, im here whining about the build time again) as more and
>>> more plugins are added.
>>
>> Yes.
>>
>>> Ive been thinking if it would be possible to do a little smarter
>>> rebuild for maven jobs with modules. What if the maven job could use
>>> the file paths from the
>>> build.getChangeSet().getItems().getAffectedPaths() method, and only
>>> call the maven goals for those paths? It should somehow find the
>>> deepest pom.xml and use that for each path. I guess if there are
>>> dependencies within the modules, that should be solved as well.
>>
>> We wanted to go to this direction, too. In fact, this is how the m2 support
>> was done initially. Today there's a mode in Hudson in which you can build
>> modules in parallel, which is the remnant of what was done originally.
>
> Why was the functionality removed/changed? Was there any problem with it?
The main issue was the one I mentioned in the e-mail, which is the CM
creation hit. IIRC, it has some interaction with the aggregated mojos.
And whenever we deviate from the way Maven is run on people's
workstations, we tend to get more bug reports and we'd have to spend
more time digging in Maven.


>> Since then I think we've got the feedback that some people do want this, so
>> we should do this.
>>
>> I think one of the major problem here is the initial hit in creating Maven
>> JVM, because Hudson needs to inject a bunch of classes. I have some ideas to
>> fix that, but haven't worked on implementing it yet.
>
> How big is the hit in creating the JVM, do you have any rough numbers?
> Ive noticed on my hudson instance that building the clearcase plugin
> takes 3 min as a separate maven job; while it takes 1 min as a part of
> the plugins maven job.
The pause between "starting a chennel" and Maven banner is the time delay.


> So maybe this should be configurable as not everyone will benefit of
> this, next to the "Build modules in parallel".
>
>>> I guess its doable, but would it be a good idea?
>>
>> So I think the answer is yes --- now, would you be interested in helping
>> with the development? :-)
>
> Of course!  I've looked briefly at the current implementation and it
> does not seem to calculate dependencies within the modules. So my aim
> is to test first and see if there is any real benefit from it.
I thought it does calculate dependencies among modules. I believe this
is contingent on whether the parallel mode is on or off.


> Maven-agent does not contain any related to this change, right?

Correct.


--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Only build changed modules in a maven job

Kohsuke Kawaguchi
Administrator
In reply to this post by Tom Huybrechts
Tom Huybrechts wrote:

> On Wed, Jun 4, 2008 at 1:37 AM, Kohsuke Kawaguchi
> <[hidden email]> wrote:
>> Erik Ramfelt wrote:
>>>
>>> On my hudson server I have a maven job for all Hudson plugins because
>>> Im too lazy to create separate jobs for each plugin and I dont really
>>> see an advantage of doing that. The downside for this is that I use
>>> SCM Polling for job which trigger a rebuild of all modules, even if it
>>> is only one module that has changed. A full rebuild takes longer and
>>> longer, (yes, im here whining about the build time again) as more and
>>> more plugins are added.
>>
>> Yes.
>>
>>> Ive been thinking if it would be possible to do a little smarter
>>> rebuild for maven jobs with modules. What if the maven job could use
>>> the file paths from the
>>> build.getChangeSet().getItems().getAffectedPaths() method, and only
>>> call the maven goals for those paths? It should somehow find the
>>> deepest pom.xml and use that for each path. I guess if there are
>>> dependencies within the modules, that should be solved as well.
>>
>> We wanted to go to this direction, too. In fact, this is how the m2 support
>> was done initially. Today there's a mode in Hudson in which you can build
>> modules in parallel, which is the remnant of what was done originally.
>>
>> Since then I think we've got the feedback that some people do want this, so
>> we should do this.
>>
>> I think one of the major problem here is the initial hit in creating Maven
>> JVM, because Hudson needs to inject a bunch of classes. I have some ideas to
>> fix that, but haven't worked on implementing it yet.
>
> I suggest fixing the Maven startup problem by creating a dummy POM
> which only contains a modules section referring to the projects you
> want to build.
Ah, your idea is interesting. But does it really work? When child POMs
point back to parent via <parentPath>../pom.xml</parentPath> don't we
end up seeing all the modules right there?

But as Stephen likes to point out, Maven2 job type has been rather
fragile, and my experience is that every time we deviate from the
standard CLI behavior, we add more headaches.

So I'm rather nervous about doing something creative.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Only build changed modules in a maven job

Tom Huybrechts
On Fri, Jun 6, 2008 at 4:02 AM, Kohsuke Kawaguchi
<[hidden email]> wrote:

> Tom Huybrechts wrote:
>>
>> On Wed, Jun 4, 2008 at 1:37 AM, Kohsuke Kawaguchi
>> <[hidden email]> wrote:
>>>
>>> Erik Ramfelt wrote:
>>>>
>>>> On my hudson server I have a maven job for all Hudson plugins because
>>>> Im too lazy to create separate jobs for each plugin and I dont really
>>>> see an advantage of doing that. The downside for this is that I use
>>>> SCM Polling for job which trigger a rebuild of all modules, even if it
>>>> is only one module that has changed. A full rebuild takes longer and
>>>> longer, (yes, im here whining about the build time again) as more and
>>>> more plugins are added.
>>>
>>> Yes.
>>>
>>>> Ive been thinking if it would be possible to do a little smarter
>>>> rebuild for maven jobs with modules. What if the maven job could use
>>>> the file paths from the
>>>> build.getChangeSet().getItems().getAffectedPaths() method, and only
>>>> call the maven goals for those paths? It should somehow find the
>>>> deepest pom.xml and use that for each path. I guess if there are
>>>> dependencies within the modules, that should be solved as well.
>>>
>>> We wanted to go to this direction, too. In fact, this is how the m2
>>> support
>>> was done initially. Today there's a mode in Hudson in which you can build
>>> modules in parallel, which is the remnant of what was done originally.
>>>
>>> Since then I think we've got the feedback that some people do want this,
>>> so
>>> we should do this.
>>>
>>> I think one of the major problem here is the initial hit in creating
>>> Maven
>>> JVM, because Hudson needs to inject a bunch of classes. I have some ideas
>>> to
>>> fix that, but haven't worked on implementing it yet.
>>
>> I suggest fixing the Maven startup problem by creating a dummy POM
>> which only contains a modules section referring to the projects you
>> want to build.
>
> Ah, your idea is interesting. But does it really work? When child POMs point
> back to parent via <parentPath>../pom.xml</parentPath> don't we end up
> seeing all the modules right there?
>

Parent references are only used for project inheritance, and never for modules.

> But as Stephen likes to point out, Maven2 job type has been rather fragile,
> and my experience is that every time we deviate from the standard CLI
> behavior, we add more headaches.
>
> So I'm rather nervous about doing something creative.
>

Well, the good thing about this is that you are using "pure" Maven -
no need to fiddle with its internals.
It is also very easy for people to try out a partial build outside Hudson.

But yes, there will definitely be projects that depend on the entire
project being built in its natural order.
You're not going to like this, but you should make it optional :)



> --
> Kohsuke Kawaguchi
> Sun Microsystems                   [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Only build changed modules in a maven job

Erik Ramfelt
On Fri, Jun 6, 2008 at 9:07 AM, Tom Huybrechts <[hidden email]> wrote:

> On Fri, Jun 6, 2008 at 4:02 AM, Kohsuke Kawaguchi
> <[hidden email]> wrote:
>> Tom Huybrechts wrote:
>>>
>>> On Wed, Jun 4, 2008 at 1:37 AM, Kohsuke Kawaguchi
>>> <[hidden email]> wrote:
>>>>
>>>> Erik Ramfelt wrote:
>>>>>
>>>>> On my hudson server I have a maven job for all Hudson plugins because
>>>>> Im too lazy to create separate jobs for each plugin and I dont really
>>>>> see an advantage of doing that. The downside for this is that I use
>>>>> SCM Polling for job which trigger a rebuild of all modules, even if it
>>>>> is only one module that has changed. A full rebuild takes longer and
>>>>> longer, (yes, im here whining about the build time again) as more and
>>>>> more plugins are added.
>>>>
>>>> Yes.
>>>>
>>>>> Ive been thinking if it would be possible to do a little smarter
>>>>> rebuild for maven jobs with modules. What if the maven job could use
>>>>> the file paths from the
>>>>> build.getChangeSet().getItems().getAffectedPaths() method, and only
>>>>> call the maven goals for those paths? It should somehow find the
>>>>> deepest pom.xml and use that for each path. I guess if there are
>>>>> dependencies within the modules, that should be solved as well.
>>>>
>>>> We wanted to go to this direction, too. In fact, this is how the m2
>>>> support
>>>> was done initially. Today there's a mode in Hudson in which you can build
>>>> modules in parallel, which is the remnant of what was done originally.
>>>>
>>>> Since then I think we've got the feedback that some people do want this,
>>>> so
>>>> we should do this.
>>>>
>>>> I think one of the major problem here is the initial hit in creating
>>>> Maven
>>>> JVM, because Hudson needs to inject a bunch of classes. I have some ideas
>>>> to
>>>> fix that, but haven't worked on implementing it yet.
>>>
>>> I suggest fixing the Maven startup problem by creating a dummy POM
>>> which only contains a modules section referring to the projects you
>>> want to build.

I was thinking in a similar way, but didnt know if it was doable or
not. I think I will try to implement this way, so i dont have to
tinker to much with the Hudson or Maven internals. If it doesnt work
out, then it shouldnt be hard to run each module separately.


>> Ah, your idea is interesting. But does it really work? When child POMs point
>> back to parent via <parentPath>../pom.xml</parentPath> don't we end up
>> seeing all the modules right there?
>>
>
> Parent references are only used for project inheritance, and never for modules.
>
>> But as Stephen likes to point out, Maven2 job type has been rather fragile,
>> and my experience is that every time we deviate from the standard CLI
>> behavior, we add more headaches.
>>
>> So I'm rather nervous about doing something creative.

I understand completely, are you still interested in accepting a patch
for it? Ive added a RFE for this suggestion,
https://hudson.dev.java.net/issues/show_bug.cgi?id=1830


> Well, the good thing about this is that you are using "pure" Maven -
> no need to fiddle with its internals.

That would be the best.

> It is also very easy for people to try out a partial build outside Hudson.

How do you mean? I was thinking the maven temp module file would be
deleted after it has built the modules.

> But yes, there will definitely be projects that depend on the entire
> project being built in its natural order.
> You're not going to like this, but you should make it optional :)

I agree with you, it could be next to the "parallell build" setting.
Then if many people uses it and there is no problem it could be used
as default.


//Erik

>
>
>
>> --
>> Kohsuke Kawaguchi
>> Sun Microsystems                   [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Only build changed modules in a maven job

Tom Huybrechts
On Tue, Jun 10, 2008 at 1:08 PM, Erik Ramfelt <[hidden email]> wrote:

> On Fri, Jun 6, 2008 at 9:07 AM, Tom Huybrechts <[hidden email]> wrote:
>> On Fri, Jun 6, 2008 at 4:02 AM, Kohsuke Kawaguchi
>> <[hidden email]> wrote:
>>> Tom Huybrechts wrote:
>>>>
>>>> On Wed, Jun 4, 2008 at 1:37 AM, Kohsuke Kawaguchi
>>>> <[hidden email]> wrote:
>>>>>
>>>>> Erik Ramfelt wrote:
>>>>>>
>>>>>> On my hudson server I have a maven job for all Hudson plugins because
>>>>>> Im too lazy to create separate jobs for each plugin and I dont really
>>>>>> see an advantage of doing that. The downside for this is that I use
>>>>>> SCM Polling for job which trigger a rebuild of all modules, even if it
>>>>>> is only one module that has changed. A full rebuild takes longer and
>>>>>> longer, (yes, im here whining about the build time again) as more and
>>>>>> more plugins are added.
>>>>>
>>>>> Yes.
>>>>>
>>>>>> Ive been thinking if it would be possible to do a little smarter
>>>>>> rebuild for maven jobs with modules. What if the maven job could use
>>>>>> the file paths from the
>>>>>> build.getChangeSet().getItems().getAffectedPaths() method, and only
>>>>>> call the maven goals for those paths? It should somehow find the
>>>>>> deepest pom.xml and use that for each path. I guess if there are
>>>>>> dependencies within the modules, that should be solved as well.
>>>>>
>>>>> We wanted to go to this direction, too. In fact, this is how the m2
>>>>> support
>>>>> was done initially. Today there's a mode in Hudson in which you can build
>>>>> modules in parallel, which is the remnant of what was done originally.
>>>>>
>>>>> Since then I think we've got the feedback that some people do want this,
>>>>> so
>>>>> we should do this.
>>>>>
>>>>> I think one of the major problem here is the initial hit in creating
>>>>> Maven
>>>>> JVM, because Hudson needs to inject a bunch of classes. I have some ideas
>>>>> to
>>>>> fix that, but haven't worked on implementing it yet.
>>>>
>>>> I suggest fixing the Maven startup problem by creating a dummy POM
>>>> which only contains a modules section referring to the projects you
>>>> want to build.
>
> I was thinking in a similar way, but didnt know if it was doable or
> not. I think I will try to implement this way, so i dont have to
> tinker to much with the Hudson or Maven internals. If it doesnt work
> out, then it shouldnt be hard to run each module separately.
>
>
>>> Ah, your idea is interesting. But does it really work? When child POMs point
>>> back to parent via <parentPath>../pom.xml</parentPath> don't we end up
>>> seeing all the modules right there?
>>>
>>
>> Parent references are only used for project inheritance, and never for modules.
>>
>>> But as Stephen likes to point out, Maven2 job type has been rather fragile,
>>> and my experience is that every time we deviate from the standard CLI
>>> behavior, we add more headaches.
>>>
>>> So I'm rather nervous about doing something creative.
>
> I understand completely, are you still interested in accepting a patch
> for it? Ive added a RFE for this suggestion,
> https://hudson.dev.java.net/issues/show_bug.cgi?id=1830
>
>
>> Well, the good thing about this is that you are using "pure" Maven -
>> no need to fiddle with its internals.
>
> That would be the best.
>
>> It is also very easy for people to try out a partial build outside Hudson.
>
> How do you mean? I was thinking the maven temp module file would be
> deleted after it has built the modules.
>

Yes, but suppose there are problems: then it isn't hard to write your
own dummy pom and try it out locally. If we would use some Maven api
to make this happen, then it would be almost impossible to emulate.

>> But yes, there will definitely be projects that depend on the entire
>> project being built in its natural order.
>> You're not going to like this, but you should make it optional :)
>
> I agree with you, it could be next to the "parallell build" setting.
> Then if many people uses it and there is no problem it could be used
> as default.
>
>
> //Erik
>>
>>
>>
>>> --
>>> Kohsuke Kawaguchi
>>> Sun Microsystems                   [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Only build changed modules in a maven job

stephenconnolly
I would rewrite the main pom to add the modules to build in profiles...

Thus

<modules>
  <module>A</module>
  <module>B</module>
</modules>

would become

<profiles>
  <profile>
    <id>hudson.A</id>
    <modules>
      <module>A</modules>
    </modules>
  </profile>
  <profile>
    <id>hudson.B</id>
    <modules>
      <module>B</modules>
    </modules>
  </profile>
</profiles>

and then just add the profiles to build to the list of active profiles

-Stephen

On Tue, Jun 10, 2008 at 1:40 PM, Tom Huybrechts <[hidden email]> wrote:
On Tue, Jun 10, 2008 at 1:08 PM, Erik Ramfelt <[hidden email]> wrote:
> On Fri, Jun 6, 2008 at 9:07 AM, Tom Huybrechts <[hidden email]> wrote:
>> On Fri, Jun 6, 2008 at 4:02 AM, Kohsuke Kawaguchi
>> <[hidden email]> wrote:
>>> Tom Huybrechts wrote:
>>>>
>>>> On Wed, Jun 4, 2008 at 1:37 AM, Kohsuke Kawaguchi
>>>> <[hidden email]> wrote:
>>>>>
>>>>> Erik Ramfelt wrote:
>>>>>>
>>>>>> On my hudson server I have a maven job for all Hudson plugins because
>>>>>> Im too lazy to create separate jobs for each plugin and I dont really
>>>>>> see an advantage of doing that. The downside for this is that I use
>>>>>> SCM Polling for job which trigger a rebuild of all modules, even if it
>>>>>> is only one module that has changed. A full rebuild takes longer and
>>>>>> longer, (yes, im here whining about the build time again) as more and
>>>>>> more plugins are added.
>>>>>
>>>>> Yes.
>>>>>
>>>>>> Ive been thinking if it would be possible to do a little smarter
>>>>>> rebuild for maven jobs with modules. What if the maven job could use
>>>>>> the file paths from the
>>>>>> build.getChangeSet().getItems().getAffectedPaths() method, and only
>>>>>> call the maven goals for those paths? It should somehow find the
>>>>>> deepest pom.xml and use that for each path. I guess if there are
>>>>>> dependencies within the modules, that should be solved as well.
>>>>>
>>>>> We wanted to go to this direction, too. In fact, this is how the m2
>>>>> support
>>>>> was done initially. Today there's a mode in Hudson in which you can build
>>>>> modules in parallel, which is the remnant of what was done originally.
>>>>>
>>>>> Since then I think we've got the feedback that some people do want this,
>>>>> so
>>>>> we should do this.
>>>>>
>>>>> I think one of the major problem here is the initial hit in creating
>>>>> Maven
>>>>> JVM, because Hudson needs to inject a bunch of classes. I have some ideas
>>>>> to
>>>>> fix that, but haven't worked on implementing it yet.
>>>>
>>>> I suggest fixing the Maven startup problem by creating a dummy POM
>>>> which only contains a modules section referring to the projects you
>>>> want to build.
>
> I was thinking in a similar way, but didnt know if it was doable or
> not. I think I will try to implement this way, so i dont have to
> tinker to much with the Hudson or Maven internals. If it doesnt work
> out, then it shouldnt be hard to run each module separately.
>
>
>>> Ah, your idea is interesting. But does it really work? When child POMs point
>>> back to parent via <parentPath>../pom.xml</parentPath> don't we end up
>>> seeing all the modules right there?
>>>
>>
>> Parent references are only used for project inheritance, and never for modules.
>>
>>> But as Stephen likes to point out, Maven2 job type has been rather fragile,
>>> and my experience is that every time we deviate from the standard CLI
>>> behavior, we add more headaches.
>>>
>>> So I'm rather nervous about doing something creative.
>
> I understand completely, are you still interested in accepting a patch
> for it? Ive added a RFE for this suggestion,
> https://hudson.dev.java.net/issues/show_bug.cgi?id=1830
>
>
>> Well, the good thing about this is that you are using "pure" Maven -
>> no need to fiddle with its internals.
>
> That would be the best.
>
>> It is also very easy for people to try out a partial build outside Hudson.
>
> How do you mean? I was thinking the maven temp module file would be
> deleted after it has built the modules.
>

Yes, but suppose there are problems: then it isn't hard to write your
own dummy pom and try it out locally. If we would use some Maven api
to make this happen, then it would be almost impossible to emulate.

>> But yes, there will definitely be projects that depend on the entire
>> project being built in its natural order.
>> You're not going to like this, but you should make it optional :)
>
> I agree with you, it could be next to the "parallell build" setting.
> Then if many people uses it and there is no problem it could be used
> as default.
>
>
> //Erik
>>
>>
>>
>>> --
>>> Kohsuke Kawaguchi
>>> Sun Microsystems                   [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Only build changed modules in a maven job

stephenconnolly
If you do the rewriting on the child pom's too then hudson can determine the profiles needed for the fast build based on the dependencies and what it knows is built already...

The only issue is those people who want to run aggregator goals (e.g. site)

If you have an aggregator goal, then you need to run on _every_ module otherwise the aggregation will be incorrect as the unchanged modules will be excluded from the reactor.

Thus if you are generating the Maven site, a quick build will only generate the links to the changed modules... not good!

On Tue, Jun 10, 2008 at 3:08 PM, Stephen Connolly <[hidden email]> wrote:
I would rewrite the main pom to add the modules to build in profiles...

Thus

<modules>
  <module>A</module>
  <module>B</module>
</modules>

would become

<profiles>
  <profile>
    <id>hudson.A</id>
    <modules>
      <module>A</modules>
    </modules>
  </profile>
  <profile>
    <id>hudson.B</id>
    <modules>
      <module>B</modules>
    </modules>
  </profile>
</profiles>

and then just add the profiles to build to the list of active profiles

-Stephen


On Tue, Jun 10, 2008 at 1:40 PM, Tom Huybrechts <[hidden email]> wrote:
On Tue, Jun 10, 2008 at 1:08 PM, Erik Ramfelt <[hidden email]> wrote:
> On Fri, Jun 6, 2008 at 9:07 AM, Tom Huybrechts <[hidden email]> wrote:
>> On Fri, Jun 6, 2008 at 4:02 AM, Kohsuke Kawaguchi
>> <[hidden email]> wrote:
>>> Tom Huybrechts wrote:
>>>>
>>>> On Wed, Jun 4, 2008 at 1:37 AM, Kohsuke Kawaguchi
>>>> <[hidden email]> wrote:
>>>>>
>>>>> Erik Ramfelt wrote:
>>>>>>
>>>>>> On my hudson server I have a maven job for all Hudson plugins because
>>>>>> Im too lazy to create separate jobs for each plugin and I dont really
>>>>>> see an advantage of doing that. The downside for this is that I use
>>>>>> SCM Polling for job which trigger a rebuild of all modules, even if it
>>>>>> is only one module that has changed. A full rebuild takes longer and
>>>>>> longer, (yes, im here whining about the build time again) as more and
>>>>>> more plugins are added.
>>>>>
>>>>> Yes.
>>>>>
>>>>>> Ive been thinking if it would be possible to do a little smarter
>>>>>> rebuild for maven jobs with modules. What if the maven job could use
>>>>>> the file paths from the
>>>>>> build.getChangeSet().getItems().getAffectedPaths() method, and only
>>>>>> call the maven goals for those paths? It should somehow find the
>>>>>> deepest pom.xml and use that for each path. I guess if there are
>>>>>> dependencies within the modules, that should be solved as well.
>>>>>
>>>>> We wanted to go to this direction, too. In fact, this is how the m2
>>>>> support
>>>>> was done initially. Today there's a mode in Hudson in which you can build
>>>>> modules in parallel, which is the remnant of what was done originally.
>>>>>
>>>>> Since then I think we've got the feedback that some people do want this,
>>>>> so
>>>>> we should do this.
>>>>>
>>>>> I think one of the major problem here is the initial hit in creating
>>>>> Maven
>>>>> JVM, because Hudson needs to inject a bunch of classes. I have some ideas
>>>>> to
>>>>> fix that, but haven't worked on implementing it yet.
>>>>
>>>> I suggest fixing the Maven startup problem by creating a dummy POM
>>>> which only contains a modules section referring to the projects you
>>>> want to build.
>
> I was thinking in a similar way, but didnt know if it was doable or
> not. I think I will try to implement this way, so i dont have to
> tinker to much with the Hudson or Maven internals. If it doesnt work
> out, then it shouldnt be hard to run each module separately.
>
>
>>> Ah, your idea is interesting. But does it really work? When child POMs point
>>> back to parent via <parentPath>../pom.xml</parentPath> don't we end up
>>> seeing all the modules right there?
>>>
>>
>> Parent references are only used for project inheritance, and never for modules.
>>
>>> But as Stephen likes to point out, Maven2 job type has been rather fragile,
>>> and my experience is that every time we deviate from the standard CLI
>>> behavior, we add more headaches.
>>>
>>> So I'm rather nervous about doing something creative.
>
> I understand completely, are you still interested in accepting a patch
> for it? Ive added a RFE for this suggestion,
> https://hudson.dev.java.net/issues/show_bug.cgi?id=1830
>
>
>> Well, the good thing about this is that you are using "pure" Maven -
>> no need to fiddle with its internals.
>
> That would be the best.
>
>> It is also very easy for people to try out a partial build outside Hudson.
>
> How do you mean? I was thinking the maven temp module file would be
> deleted after it has built the modules.
>

Yes, but suppose there are problems: then it isn't hard to write your
own dummy pom and try it out locally. If we would use some Maven api
to make this happen, then it would be almost impossible to emulate.

>> But yes, there will definitely be projects that depend on the entire
>> project being built in its natural order.
>> You're not going to like this, but you should make it optional :)
>
> I agree with you, it could be next to the "parallell build" setting.
> Then if many people uses it and there is no problem it could be used
> as default.
>
>
> //Erik
>>
>>
>>
>>> --
>>> Kohsuke Kawaguchi
>>> Sun Microsystems                   [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: Only build changed modules in a maven job

Tom Huybrechts
I don't understand what you gain by rewriting all the poms ?
Besides (and I may be wrong), but I think that default profiles in the
POM are not enabled when you manually enable other profiles.

On Tue, Jun 10, 2008 at 4:10 PM, Stephen Connolly
<[hidden email]> wrote:

> If you do the rewriting on the child pom's too then hudson can determine the
> profiles needed for the fast build based on the dependencies and what it
> knows is built already...
>
> The only issue is those people who want to run aggregator goals (e.g. site)
>
> If you have an aggregator goal, then you need to run on _every_ module
> otherwise the aggregation will be incorrect as the unchanged modules will be
> excluded from the reactor.
>
> Thus if you are generating the Maven site, a quick build will only generate
> the links to the changed modules... not good!
>
> On Tue, Jun 10, 2008 at 3:08 PM, Stephen Connolly
> <[hidden email]> wrote:
>>
>> I would rewrite the main pom to add the modules to build in profiles...
>>
>> Thus
>>
>> <modules>
>>   <module>A</module>
>>   <module>B</module>
>> </modules>
>>
>> would become
>>
>> <profiles>
>>   <profile>
>>     <id>hudson.A</id>
>>     <modules>
>>       <module>A</modules>
>>     </modules>
>>   </profile>
>>   <profile>
>>     <id>hudson.B</id>
>>     <modules>
>>       <module>B</modules>
>>     </modules>
>>   </profile>
>> </profiles>
>>
>> and then just add the profiles to build to the list of active profiles
>>
>> -Stephen
>>
>> On Tue, Jun 10, 2008 at 1:40 PM, Tom Huybrechts <[hidden email]>
>> wrote:
>>>
>>> On Tue, Jun 10, 2008 at 1:08 PM, Erik Ramfelt <[hidden email]> wrote:
>>> > On Fri, Jun 6, 2008 at 9:07 AM, Tom Huybrechts
>>> > <[hidden email]> wrote:
>>> >> On Fri, Jun 6, 2008 at 4:02 AM, Kohsuke Kawaguchi
>>> >> <[hidden email]> wrote:
>>> >>> Tom Huybrechts wrote:
>>> >>>>
>>> >>>> On Wed, Jun 4, 2008 at 1:37 AM, Kohsuke Kawaguchi
>>> >>>> <[hidden email]> wrote:
>>> >>>>>
>>> >>>>> Erik Ramfelt wrote:
>>> >>>>>>
>>> >>>>>> On my hudson server I have a maven job for all Hudson plugins
>>> >>>>>> because
>>> >>>>>> Im too lazy to create separate jobs for each plugin and I dont
>>> >>>>>> really
>>> >>>>>> see an advantage of doing that. The downside for this is that I
>>> >>>>>> use
>>> >>>>>> SCM Polling for job which trigger a rebuild of all modules, even
>>> >>>>>> if it
>>> >>>>>> is only one module that has changed. A full rebuild takes longer
>>> >>>>>> and
>>> >>>>>> longer, (yes, im here whining about the build time again) as more
>>> >>>>>> and
>>> >>>>>> more plugins are added.
>>> >>>>>
>>> >>>>> Yes.
>>> >>>>>
>>> >>>>>> Ive been thinking if it would be possible to do a little smarter
>>> >>>>>> rebuild for maven jobs with modules. What if the maven job could
>>> >>>>>> use
>>> >>>>>> the file paths from the
>>> >>>>>> build.getChangeSet().getItems().getAffectedPaths() method, and
>>> >>>>>> only
>>> >>>>>> call the maven goals for those paths? It should somehow find the
>>> >>>>>> deepest pom.xml and use that for each path. I guess if there are
>>> >>>>>> dependencies within the modules, that should be solved as well.
>>> >>>>>
>>> >>>>> We wanted to go to this direction, too. In fact, this is how the m2
>>> >>>>> support
>>> >>>>> was done initially. Today there's a mode in Hudson in which you can
>>> >>>>> build
>>> >>>>> modules in parallel, which is the remnant of what was done
>>> >>>>> originally.
>>> >>>>>
>>> >>>>> Since then I think we've got the feedback that some people do want
>>> >>>>> this,
>>> >>>>> so
>>> >>>>> we should do this.
>>> >>>>>
>>> >>>>> I think one of the major problem here is the initial hit in
>>> >>>>> creating
>>> >>>>> Maven
>>> >>>>> JVM, because Hudson needs to inject a bunch of classes. I have some
>>> >>>>> ideas
>>> >>>>> to
>>> >>>>> fix that, but haven't worked on implementing it yet.
>>> >>>>
>>> >>>> I suggest fixing the Maven startup problem by creating a dummy POM
>>> >>>> which only contains a modules section referring to the projects you
>>> >>>> want to build.
>>> >
>>> > I was thinking in a similar way, but didnt know if it was doable or
>>> > not. I think I will try to implement this way, so i dont have to
>>> > tinker to much with the Hudson or Maven internals. If it doesnt work
>>> > out, then it shouldnt be hard to run each module separately.
>>> >
>>> >
>>> >>> Ah, your idea is interesting. But does it really work? When child
>>> >>> POMs point
>>> >>> back to parent via <parentPath>../pom.xml</parentPath> don't we end
>>> >>> up
>>> >>> seeing all the modules right there?
>>> >>>
>>> >>
>>> >> Parent references are only used for project inheritance, and never for
>>> >> modules.
>>> >>
>>> >>> But as Stephen likes to point out, Maven2 job type has been rather
>>> >>> fragile,
>>> >>> and my experience is that every time we deviate from the standard CLI
>>> >>> behavior, we add more headaches.
>>> >>>
>>> >>> So I'm rather nervous about doing something creative.
>>> >
>>> > I understand completely, are you still interested in accepting a patch
>>> > for it? Ive added a RFE for this suggestion,
>>> > https://hudson.dev.java.net/issues/show_bug.cgi?id=1830
>>> >
>>> >
>>> >> Well, the good thing about this is that you are using "pure" Maven -
>>> >> no need to fiddle with its internals.
>>> >
>>> > That would be the best.
>>> >
>>> >> It is also very easy for people to try out a partial build outside
>>> >> Hudson.
>>> >
>>> > How do you mean? I was thinking the maven temp module file would be
>>> > deleted after it has built the modules.
>>> >
>>>
>>> Yes, but suppose there are problems: then it isn't hard to write your
>>> own dummy pom and try it out locally. If we would use some Maven api
>>> to make this happen, then it would be almost impossible to emulate.
>>>
>>> >> But yes, there will definitely be projects that depend on the entire
>>> >> project being built in its natural order.
>>> >> You're not going to like this, but you should make it optional :)
>>> >
>>> > I agree with you, it could be next to the "parallell build" setting.
>>> > Then if many people uses it and there is no problem it could be used
>>> > as default.
>>> >
>>> >
>>> > //Erik
>>> >>
>>> >>
>>> >>
>>> >>> --
>>> >>> Kohsuke Kawaguchi
>>> >>> Sun Microsystems                   [hidden email]
>>> >>>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: [hidden email]
>>> >> For additional commands, e-mail: [hidden email]
>>> >>
>>> >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: [hidden email]
>>> > For additional commands, e-mail: [hidden email]
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Only build changed modules in a maven job

stephenconnolly
What you gain is that any behaviour specified in the pom remains the same...

obviously you do a quick mvn -N help:active-profiles first to determine what profiles should be active...

alternatively there is some "magic" syntax when specifying profiles that makes the list additive (or maybe that's Maven 2.1 only)

On Tue, Jun 10, 2008 at 3:39 PM, Tom Huybrechts <[hidden email]> wrote:
I don't understand what you gain by rewriting all the poms ?
Besides (and I may be wrong), but I think that default profiles in the
POM are not enabled when you manually enable other profiles.

On Tue, Jun 10, 2008 at 4:10 PM, Stephen Connolly
<[hidden email]> wrote:
> If you do the rewriting on the child pom's too then hudson can determine the
> profiles needed for the fast build based on the dependencies and what it
> knows is built already...
>
> The only issue is those people who want to run aggregator goals (e.g. site)
>
> If you have an aggregator goal, then you need to run on _every_ module
> otherwise the aggregation will be incorrect as the unchanged modules will be
> excluded from the reactor.
>
> Thus if you are generating the Maven site, a quick build will only generate
> the links to the changed modules... not good!
>
> On Tue, Jun 10, 2008 at 3:08 PM, Stephen Connolly
> <[hidden email]> wrote:
>>
>> I would rewrite the main pom to add the modules to build in profiles...
>>
>> Thus
>>
>> <modules>
>>   <module>A</module>
>>   <module>B</module>
>> </modules>
>>
>> would become
>>
>> <profiles>
>>   <profile>
>>     <id>hudson.A</id>
>>     <modules>
>>       <module>A</modules>
>>     </modules>
>>   </profile>
>>   <profile>
>>     <id>hudson.B</id>
>>     <modules>
>>       <module>B</modules>
>>     </modules>
>>   </profile>
>> </profiles>
>>
>> and then just add the profiles to build to the list of active profiles
>>
>> -Stephen
>>
>> On Tue, Jun 10, 2008 at 1:40 PM, Tom Huybrechts <[hidden email]>
>> wrote:
>>>
>>> On Tue, Jun 10, 2008 at 1:08 PM, Erik Ramfelt <[hidden email]> wrote:
>>> > On Fri, Jun 6, 2008 at 9:07 AM, Tom Huybrechts
>>> > <[hidden email]> wrote:
>>> >> On Fri, Jun 6, 2008 at 4:02 AM, Kohsuke Kawaguchi
>>> >> <[hidden email]> wrote:
>>> >>> Tom Huybrechts wrote:
>>> >>>>
>>> >>>> On Wed, Jun 4, 2008 at 1:37 AM, Kohsuke Kawaguchi
>>> >>>> <[hidden email]> wrote:
>>> >>>>>
>>> >>>>> Erik Ramfelt wrote:
>>> >>>>>>
>>> >>>>>> On my hudson server I have a maven job for all Hudson plugins
>>> >>>>>> because
>>> >>>>>> Im too lazy to create separate jobs for each plugin and I dont
>>> >>>>>> really
>>> >>>>>> see an advantage of doing that. The downside for this is that I
>>> >>>>>> use
>>> >>>>>> SCM Polling for job which trigger a rebuild of all modules, even
>>> >>>>>> if it
>>> >>>>>> is only one module that has changed. A full rebuild takes longer
>>> >>>>>> and
>>> >>>>>> longer, (yes, im here whining about the build time again) as more
>>> >>>>>> and
>>> >>>>>> more plugins are added.
>>> >>>>>
>>> >>>>> Yes.
>>> >>>>>
>>> >>>>>> Ive been thinking if it would be possible to do a little smarter
>>> >>>>>> rebuild for maven jobs with modules. What if the maven job could
>>> >>>>>> use
>>> >>>>>> the file paths from the
>>> >>>>>> build.getChangeSet().getItems().getAffectedPaths() method, and
>>> >>>>>> only
>>> >>>>>> call the maven goals for those paths? It should somehow find the
>>> >>>>>> deepest pom.xml and use that for each path. I guess if there are
>>> >>>>>> dependencies within the modules, that should be solved as well.
>>> >>>>>
>>> >>>>> We wanted to go to this direction, too. In fact, this is how the m2
>>> >>>>> support
>>> >>>>> was done initially. Today there's a mode in Hudson in which you can
>>> >>>>> build
>>> >>>>> modules in parallel, which is the remnant of what was done
>>> >>>>> originally.
>>> >>>>>
>>> >>>>> Since then I think we've got the feedback that some people do want
>>> >>>>> this,
>>> >>>>> so
>>> >>>>> we should do this.
>>> >>>>>
>>> >>>>> I think one of the major problem here is the initial hit in
>>> >>>>> creating
>>> >>>>> Maven
>>> >>>>> JVM, because Hudson needs to inject a bunch of classes. I have some
>>> >>>>> ideas
>>> >>>>> to
>>> >>>>> fix that, but haven't worked on implementing it yet.
>>> >>>>
>>> >>>> I suggest fixing the Maven startup problem by creating a dummy POM
>>> >>>> which only contains a modules section referring to the projects you
>>> >>>> want to build.
>>> >
>>> > I was thinking in a similar way, but didnt know if it was doable or
>>> > not. I think I will try to implement this way, so i dont have to
>>> > tinker to much with the Hudson or Maven internals. If it doesnt work
>>> > out, then it shouldnt be hard to run each module separately.
>>> >
>>> >
>>> >>> Ah, your idea is interesting. But does it really work? When child
>>> >>> POMs point
>>> >>> back to parent via <parentPath>../pom.xml</parentPath> don't we end
>>> >>> up
>>> >>> seeing all the modules right there?
>>> >>>
>>> >>
>>> >> Parent references are only used for project inheritance, and never for
>>> >> modules.
>>> >>
>>> >>> But as Stephen likes to point out, Maven2 job type has been rather
>>> >>> fragile,
>>> >>> and my experience is that every time we deviate from the standard CLI
>>> >>> behavior, we add more headaches.
>>> >>>
>>> >>> So I'm rather nervous about doing something creative.
>>> >
>>> > I understand completely, are you still interested in accepting a patch
>>> > for it? Ive added a RFE for this suggestion,
>>> > https://hudson.dev.java.net/issues/show_bug.cgi?id=1830
>>> >
>>> >
>>> >> Well, the good thing about this is that you are using "pure" Maven -
>>> >> no need to fiddle with its internals.
>>> >
>>> > That would be the best.
>>> >
>>> >> It is also very easy for people to try out a partial build outside
>>> >> Hudson.
>>> >
>>> > How do you mean? I was thinking the maven temp module file would be
>>> > deleted after it has built the modules.
>>> >
>>>
>>> Yes, but suppose there are problems: then it isn't hard to write your
>>> own dummy pom and try it out locally. If we would use some Maven api
>>> to make this happen, then it would be almost impossible to emulate.
>>>
>>> >> But yes, there will definitely be projects that depend on the entire
>>> >> project being built in its natural order.
>>> >> You're not going to like this, but you should make it optional :)
>>> >
>>> > I agree with you, it could be next to the "parallell build" setting.
>>> > Then if many people uses it and there is no problem it could be used
>>> > as default.
>>> >
>>> >
>>> > //Erik
>>> >>
>>> >>
>>> >>
>>> >>> --
>>> >>> Kohsuke Kawaguchi
>>> >>> Sun Microsystems                   [hidden email]
>>> >>>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: [hidden email]
>>> >> For additional commands, e-mail: [hidden email]
>>> >>
>>> >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: [hidden email]
>>> > For additional commands, e-mail: [hidden email]
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]