Writing a IBM Jazz SCM Plugin - where and how to hook into the Hudson build lifecycle?

[Andrew Harmel-Law]

Hi,

I'm currently writing what I think will be a set of plugins so that
Hudson can be used as a Build Engine for IBM's Rational Team Concert
(aka "Jazz") server.  I've started with an SCM plugin as this is where
most of the meat will be and am working my way through the
pollChanges( ) checkout( ) and createChangeLogParser( ) methods.
However, there is lot more I need to do to integrate things in a
meaningful way and get the most out of both Jazz and Hudson.  To do
this I need get to the bottom of a few things and hope someone can
help.

My first question is around the standard Hudson build steps. I've had
a look on the wiki and searched the mailing list archives and can't
find a simple description / diagra, of the steps a build goes through.
I'm hoping to understand this so I can integrate Jazz with Hudson as
closely as possible.

This then leads onto my second question. Jazz has the concepts of a
Build Request queue. Builds can be requested by a developer (a
"personal build" which means their code is built on the build server)
or schdeuled (as defined in a Build Definition on the Jazz server).
Both are logged and tracked on the Jazz Build Request Queue for a
given Build Definition.  Build engines (such as Hudson) then poll this
queue (my impression is that this will be via the Hudson pollChanges(
) method) and, if a request is found proceed as follows:

1. inform the Jazz server the requested build is starting - this
updates the build request in question so its status moves from
"Pending" to "Started"
2. set the build label (in Jazz and also stored for later use in the
build - i.e. for labelling results, tagging the SCM, etc.)
3. inform the Jazz server the "fetch" activity is starting - again
this updates the build request status
4. "accept" any incoming changes into the Build users workspace (on
the Jazz server - this is not a checkout. Yet)
5. perform tidy up tasks such as deleting the local workspace if required
6. fetch (checkout) the latest code from the Jazz server to the build
server workspace
7. inform the server the "fetch" activity is complete - again this
updates the build request status
8. inform the Jazz server the "compile" activity is starting - again
this updates the build request status
9. compile the project(s)
10. inform the server the "compile" activity is complete - again this
updates the build request status
11. inform the Jazz server the "test" activity is starting - again
this updates the build request status
12. test the project(s)
13. inform the server the "test" activity is complete - again this
updates the build request status
14. publish any links (e.g. the Hudson build result URL) to the build
result on the Jazz server
15. inform the Jazz server the requested build is completeed - again
this updates the build request status

I want to be able to keep the staus for each build as up to date as
possible in this Jazz build request queue. Partially because it is how
Jazz works but also because it is such a good feedback mechanism for
developers.  I've had a look at the various extension points available
in Hudson but I'm not sure which I should use. I guess that this
extension should be quite simple, but I'm hoping someone can tell me
where to start.

I hope this isn't too much detail and that someone can help.  If you
need more information on how the Jazz server works or anything else I
may have forgotten or not made clear please drop me a line.

I hope this all makes sense.

Thanks in advance.

Cheers, Andrew

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

[stephenconnolly]

you arenot going to be able to keep the status correct wrt test and  
compile, as in many builds things get compiled, tested, more stuff  
compiled, more stuff tested, more stuff compiled, etc

this is especially the case with maven builds

Sent from my [rhymes with tryPod] ;-)

On 26 Sep 2009, at 17:40, Andrew Harmel-Law  
<[hidden email]> wrote:

> Hi,
>
> I'm currently writing what I think will be a set of plugins so that
> Hudson can be used as a Build Engine for IBM's Rational Team Concert
> (aka "Jazz") server.  I've started with an SCM plugin as this is where
> most of the meat will be and am working my way through the
> pollChanges( ) checkout( ) and createChangeLogParser( ) methods.
> However, there is lot more I need to do to integrate things in a
> meaningful way and get the most out of both Jazz and Hudson.  To do
> this I need get to the bottom of a few things and hope someone can
> help.
>
> My first question is around the standard Hudson build steps. I've had
> a look on the wiki and searched the mailing list archives and can't
> find a simple description / diagra, of the steps a build goes through.
> I'm hoping to understand this so I can integrate Jazz with Hudson as
> closely as possible.
>
> This then leads onto my second question. Jazz has the concepts of a
> Build Request queue. Builds can be requested by a developer (a
> "personal build" which means their code is built on the build server)
> or schdeuled (as defined in a Build Definition on the Jazz server).
> Both are logged and tracked on the Jazz Build Request Queue for a
> given Build Definition.  Build engines (such as Hudson) then poll this
> queue (my impression is that this will be via the Hudson pollChanges(
> ) method) and, if a request is found proceed as follows:
>
> 1. inform the Jazz server the requested build is starting - this
> updates the build request in question so its status moves from
> "Pending" to "Started"
> 2. set the build label (in Jazz and also stored for later use in the
> build - i.e. for labelling results, tagging the SCM, etc.)
> 3. inform the Jazz server the "fetch" activity is starting - again
> this updates the build request status
> 4. "accept" any incoming changes into the Build users workspace (on
> the Jazz server - this is not a checkout. Yet)
> 5. perform tidy up tasks such as deleting the local workspace if  
> required
> 6. fetch (checkout) the latest code from the Jazz server to the build
> server workspace
> 7. inform the server the "fetch" activity is complete - again this
> updates the build request status
> 8. inform the Jazz server the "compile" activity is starting - again
> this updates the build request status
> 9. compile the project(s)
> 10. inform the server the "compile" activity is complete - again this
> updates the build request status
> 11. inform the Jazz server the "test" activity is starting - again
> this updates the build request status
> 12. test the project(s)
> 13. inform the server the "test" activity is complete - again this
> updates the build request status
> 14. publish any links (e.g. the Hudson build result URL) to the build
> result on the Jazz server
> 15. inform the Jazz server the requested build is completeed - again
> this updates the build request status
>
> I want to be able to keep the staus for each build as up to date as
> possible in this Jazz build request queue. Partially because it is how
> Jazz works but also because it is such a good feedback mechanism for
> developers.  I've had a look at the various extension points available
> in Hudson but I'm not sure which I should use. I guess that this
> extension should be quite simple, but I'm hoping someone can tell me
> where to start.
>
> I hope this isn't too much detail and that someone can help.  If you
> need more information on how the Jazz server works or anything else I
> may have forgotten or not made clear please drop me a line.
>
> I hope this all makes sense.
>
> Thanks in advance.
>
> Cheers, Andrew
>
> ---------------------------------------------------------------------
> 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]

[James Synge]

Andrew,

I'm intrigued by this idea, but I can't help wonder why someone would
using Rational Team Concert
wouldn't just use the native Jazz build engine.  Can you elaborate on this?

For context, I currently use Hudson at my current job, and help a bit
with the Perforce plugin, but
previously spent ~3 years working on the Jazz development team at IBM
(focused on the SCM
and repository components).

James

On Sat, Sep 26, 2009 at 12:40 PM, Andrew Harmel-Law
<[hidden email]> wrote:

> Hi,
>
> I'm currently writing what I think will be a set of plugins so that
> Hudson can be used as a Build Engine for IBM's Rational Team Concert
> (aka "Jazz") server.  I've started with an SCM plugin as this is where
> most of the meat will be and am working my way through the
> pollChanges( ) checkout( ) and createChangeLogParser( ) methods.
> However, there is lot more I need to do to integrate things in a
> meaningful way and get the most out of both Jazz and Hudson.  To do
> this I need get to the bottom of a few things and hope someone can
> help.

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

[Kohsuke Kawaguchi]

Andrew Harmel-Law wrote:

> Hi,
>
> I'm currently writing what I think will be a set of plugins so that
> Hudson can be used as a Build Engine for IBM's Rational Team Concert
> (aka "Jazz") server.  I've started with an SCM plugin as this is where
> most of the meat will be and am working my way through the
> pollChanges( ) checkout( ) and createChangeLogParser( ) methods.
> However, there is lot more I need to do to integrate things in a
> meaningful way and get the most out of both Jazz and Hudson.  To do
> this I need get to the bottom of a few things and hope someone can
> help.
>
> My first question is around the standard Hudson build steps. I've had
> a look on the wiki and searched the mailing list archives and can't
> find a simple description / diagra, of the steps a build goes through.
> I'm hoping to understand this so I can integrate Jazz with Hudson as
> closely as possible.

I've improved the javadoc of the Build class as follows:

>  * <h2>Steps of a build</h2>
>  * <p>
>  * Roughly speaking, a {@link Build} goes through the following stages:
>  *
>  * <dl>
>  * <dt>SCM checkout
>  * <dd>Hudson decides which directory to use for a build, then the source code is checked out
>  *
>  * <dt>Pre-build steps
>  * <dd>Everyone gets their {@link BuildStep#prebuild(AbstractBuild, BuildListener)} invoked
>  * to indicate that the build is starting
>  *
>  * <dt>Build wrapper set up
>  * <dd>{@link BuildWrapper#setUp(AbstractBuild, Launcher, BuildListener)} is invoked. This is normally
>  * to prepare an environment for the build.
>  *
>  * <dt>Builder runs
>  * <dd>{@link Builder#perform(AbstractBuild, Launcher, BuildListener)} is invoked. This is where
>  * things that are useful to users happen, like calling Ant, Make, etc.
>  *
>  * <dt>Recorder runs
>  * <dd>{@link Recorder#perform(AbstractBuild, Launcher, BuildListener)} is invoked. This is normally
>  * to record the output from the build, such as test results.
>  *
>  * <dt>Notifier runs
>  * <dd>{@link Notifier#perform(AbstractBuild, Launcher, BuildListener)} is invoked. This is normally
>  * to send out notifications, based on the results determined so far.
>  * </dl>
>  *
>  * <p>
>  * And beyond that, the build is considered complete, and from then on {@link Build} object is there to
>  * keep the record of what happened in this build.

> This then leads onto my second question. Jazz has the concepts of a
> Build Request queue. Builds can be requested by a developer (a
> "personal build" which means their code is built on the build server)
> or schdeuled (as defined in a Build Definition on the Jazz server).
> Both are logged and tracked on the Jazz Build Request Queue for a
> given Build Definition.  Build engines (such as Hudson) then poll this
> queue (my impression is that this will be via the Hudson pollChanges(
> ) method) and, if a request is found proceed as follows:
>
> 1. inform the Jazz server the requested build is starting - this
> updates the build request in question so its status moves from
> "Pending" to "Started"
> 2. set the build label (in Jazz and also stored for later use in the
> build - i.e. for labelling results, tagging the SCM, etc.)
> 3. inform the Jazz server the "fetch" activity is starting - again
> this updates the build request status
> 4. "accept" any incoming changes into the Build users workspace (on
> the Jazz server - this is not a checkout. Yet)
> 5. perform tidy up tasks such as deleting the local workspace if required
> 6. fetch (checkout) the latest code from the Jazz server to the build
> server workspace
> 7. inform the server the "fetch" activity is complete - again this
> updates the build request status
> 8. inform the Jazz server the "compile" activity is starting - again
> this updates the build request status
> 9. compile the project(s)
> 10. inform the server the "compile" activity is complete - again this
> updates the build request status
> 11. inform the Jazz server the "test" activity is starting - again
> this updates the build request status
> 12. test the project(s)
> 13. inform the server the "test" activity is complete - again this
> updates the build request status
> 14. publish any links (e.g. the Hudson build result URL) to the build
> result on the Jazz server
> 15. inform the Jazz server the requested build is completeed - again
> this updates the build request status
>
> I want to be able to keep the staus for each build as up to date as
> possible in this Jazz build request queue. Partially because it is how
> Jazz works but also because it is such a good feedback mechanism for
> developers.  I've had a look at the various extension points available
> in Hudson but I'm not sure which I should use. I guess that this
> extension should be quite simple, but I'm hoping someone can tell me
> where to start.

1-7 can be done in your SCM implementation. compile/test distinction is
hard to make, though, not because there's some deficiencies in Hudson,
but because build tools that people use normally don't offer such a
distinction.

For example, when users tell you to invoke Ant with such and such
target, you don't know when things switch from compile to test.

Ditto for Maven --- it interleaves builds and tests per module, so it's
not like it compiles everything first and then tests everything later.

> I hope this isn't too much detail and that someone can help.  If you
> need more information on how the Jazz server works or anything else I
> may have forgotten or not made clear please drop me a line.
>
> I hope this all makes sense.
>
> Thanks in advance.
>
> Cheers, Andrew
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Kohsuke Kawaguchi
Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/

[Andrew Harmel-Law]

Hi Stephen,

You're totally right. Once I posted this I realised I'd been a little over-zealous. I will be able to break it into "fetching" and "compiling/unit testing/packaging" and even as far as "deploying" I hope. We'll see...

Regs, Andrew

Stephen Connolly-2 wrote:

you arenot going to be able to keep the status correct wrt test and  
compile, as in many builds things get compiled, tested, more stuff  
compiled, more stuff tested, more stuff compiled, etc

this is especially the case with maven builds

Sent from my [rhymes with tryPod] ;-)

On 26 Sep 2009, at 17:40, Andrew Harmel-Law  
<[e-mail]> wrote:

> Hi,
>
> I'm currently writing what I think will be a set of plugins so that
> Hudson can be used as a Build Engine for IBM's Rational Team Concert
> (aka "Jazz") server.  I've started with an SCM plugin as this is where
> most of the meat will be and am working my way through the
> pollChanges( ) checkout( ) and createChangeLogParser( ) methods.
> However, there is lot more I need to do to integrate things in a
> meaningful way and get the most out of both Jazz and Hudson.  To do
> this I need get to the bottom of a few things and hope someone can
> help.
>
> My first question is around the standard Hudson build steps. I've had
> a look on the wiki and searched the mailing list archives and can't
> find a simple description / diagra, of the steps a build goes through.
> I'm hoping to understand this so I can integrate Jazz with Hudson as
> closely as possible.
>
> This then leads onto my second question. Jazz has the concepts of a
> Build Request queue. Builds can be requested by a developer (a
> "personal build" which means their code is built on the build server)
> or schdeuled (as defined in a Build Definition on the Jazz server).
> Both are logged and tracked on the Jazz Build Request Queue for a
> given Build Definition.  Build engines (such as Hudson) then poll this
> queue (my impression is that this will be via the Hudson pollChanges(
> ) method) and, if a request is found proceed as follows:
>
> 1. inform the Jazz server the requested build is starting - this
> updates the build request in question so its status moves from
> "Pending" to "Started"
> 2. set the build label (in Jazz and also stored for later use in the
> build - i.e. for labelling results, tagging the SCM, etc.)
> 3. inform the Jazz server the "fetch" activity is starting - again
> this updates the build request status
> 4. "accept" any incoming changes into the Build users workspace (on
> the Jazz server - this is not a checkout. Yet)
> 5. perform tidy up tasks such as deleting the local workspace if  
> required
> 6. fetch (checkout) the latest code from the Jazz server to the build
> server workspace
> 7. inform the server the "fetch" activity is complete - again this
> updates the build request status
> 8. inform the Jazz server the "compile" activity is starting - again
> this updates the build request status
> 9. compile the project(s)
> 10. inform the server the "compile" activity is complete - again this
> updates the build request status
> 11. inform the Jazz server the "test" activity is starting - again
> this updates the build request status
> 12. test the project(s)
> 13. inform the server the "test" activity is complete - again this
> updates the build request status
> 14. publish any links (e.g. the Hudson build result URL) to the build
> result on the Jazz server
> 15. inform the Jazz server the requested build is completeed - again
> this updates the build request status
>
> I want to be able to keep the staus for each build as up to date as
> possible in this Jazz build request queue. Partially because it is how
> Jazz works but also because it is such a good feedback mechanism for
> developers.  I've had a look at the various extension points available
> in Hudson but I'm not sure which I should use. I guess that this
> extension should be quite simple, but I'm hoping someone can tell me
> where to start.
>
> I hope this isn't too much detail and that someone can help.  If you
> need more information on how the Jazz server works or anything else I
> may have forgotten or not made clear please drop me a line.
>
> I hope this all makes sense.
>
> Thanks in advance.
>
> Cheers, Andrew
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [e-mail]
> For additional commands, e-mail: [e-mail]
>

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

[Andrew Harmel-Law]

Hi James,

Good question. There are two reasons really:

One, its an itch I've got (see later) and Hudson is a nice way to scratch it. Its also good practice to keep my dev skills up while I'm the build guy on my current project.  

Two, my project has a pretty complicated architecture - .NET front end and Java back end. We've got feature teams with an RTC stream apiece and I want to have quite a clever build which makes sure the relevant compiles are done on the target OS (Windows / Linux) , that we deploy the results to VMs, and then run automated integration smoke tests from the front end right to the back.  

We've got half of this working with RTC build engine at the moment but we have to do messy things like calling MSBuild from bat files which the build engine pokes and we can't do VM manipulation automatically at all. Hudson will give us this as well as build promotion, handlers for things like Findbugs, Cobertura, NCover, NDepend, etc. And for free.

Hope this makes sense.

James Synge wrote:

Andrew,

I'm intrigued by this idea, but I can't help wonder why someone would
using Rational Team Concert
wouldn't just use the native Jazz build engine.  Can you elaborate on this?

For context, I currently use Hudson at my current job, and help a bit
with the Perforce plugin, but
previously spent ~3 years working on the Jazz development team at IBM
(focused on the SCM
and repository components).

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

[Andrew Harmel-Law]

Hi Kohsuke,

Thanks again. Comments inline...

Regs, Andrew

kohsuke wrote:

Andrew Harmel-Law wrote:
> My first question is around the standard Hudson build steps. I've had
> a look on the wiki and searched the mailing list archives and can't
> find a simple description / diagra, of the steps a build goes through.
> I'm hoping to understand this so I can integrate Jazz with Hudson as
> closely as possible.

I've improved the javadoc of the Build class as follows:

>  * <h2>Steps of a build</h2>
>  * <p>
>  * Roughly speaking, a {@link Build} goes through the following stages:
>  *
>  * <dl>
>  * <dt>SCM checkout
>  * <dd>Hudson decides which directory to use for a build, then the source code is checked out
>  *
>  * <dt>Pre-build steps
>  * <dd>Everyone gets their {@link BuildStep#prebuild(AbstractBuild, BuildListener)} invoked
>  * to indicate that the build is starting
>  *
>  * <dt>Build wrapper set up
>  * <dd>{@link BuildWrapper#setUp(AbstractBuild, Launcher, BuildListener)} is invoked. This is normally
>  * to prepare an environment for the build.
>  *
>  * <dt>Builder runs
>  * <dd>{@link Builder#perform(AbstractBuild, Launcher, BuildListener)} is invoked. This is where
>  * things that are useful to users happen, like calling Ant, Make, etc.
>  *
>  * <dt>Recorder runs
>  * <dd>{@link Recorder#perform(AbstractBuild, Launcher, BuildListener)} is invoked. This is normally
>  * to record the output from the build, such as test results.
>  *
>  * <dt>Notifier runs
>  * <dd>{@link Notifier#perform(AbstractBuild, Launcher, BuildListener)} is invoked. This is normally
>  * to send out notifications, based on the results determined so far.
>  * </dl>
>  *
>  * <p>
>  * And beyond that, the build is considered complete, and from then on {@link Build} object is there to
>  * keep the record of what happened in this build.

Superb. This is just what I was looking for. It seems that as well as the SCM bits, I'll also need to write a Notifier.

What is the best practice for bundling plugins which extend multiple points of Hudson? In my case they are closely related. The Jazz server likes to know when a builds both starts (as soon as the SCM "fetch" begins) and ends (once the build script has completed). Should I add my Notifier extension to the same plugin as my SCM extension?  I guess so.

kohsuke wrote:

> This then leads onto my second question. Jazz has the concepts of a
> Build Request queue. Builds can be requested by a developer (a
> "personal build" which means their code is built on the build server)
> or schdeuled (as defined in a Build Definition on the Jazz server).
> Both are logged and tracked on the Jazz Build Request Queue for a
> given Build Definition.  Build engines (such as Hudson) then poll this
> queue (my impression is that this will be via the Hudson pollChanges(
> ) method) and, if a request is found proceed as follows:
>
> 1. inform the Jazz server the requested build is starting - this
> updates the build request in question so its status moves from
> "Pending" to "Started"
> 2. set the build label (in Jazz and also stored for later use in the
> build - i.e. for labelling results, tagging the SCM, etc.)
> 3. inform the Jazz server the "fetch" activity is starting - again
> this updates the build request status
> 4. "accept" any incoming changes into the Build users workspace (on
> the Jazz server - this is not a checkout. Yet)
> 5. perform tidy up tasks such as deleting the local workspace if required
> 6. fetch (checkout) the latest code from the Jazz server to the build
> server workspace
> 7. inform the server the "fetch" activity is complete - again this
> updates the build request status
> 8. inform the Jazz server the "compile" activity is starting - again
> this updates the build request status
> 9. compile the project(s)
> 10. inform the server the "compile" activity is complete - again this
> updates the build request status
> 11. inform the Jazz server the "test" activity is starting - again
> this updates the build request status
> 12. test the project(s)
> 13. inform the server the "test" activity is complete - again this
> updates the build request status
> 14. publish any links (e.g. the Hudson build result URL) to the build
> result on the Jazz server
> 15. inform the Jazz server the requested build is completeed - again
> this updates the build request status
>
> I want to be able to keep the staus for each build as up to date as
> possible in this Jazz build request queue. Partially because it is how
> Jazz works but also because it is such a good feedback mechanism for
> developers.  I've had a look at the various extension points available
> in Hudson but I'm not sure which I should use. I guess that this
> extension should be quite simple, but I'm hoping someone can tell me
> where to start.

1-7 can be done in your SCM implementation. compile/test distinction is
hard to make, though, not because there's some deficiencies in Hudson,
but because build tools that people use normally don't offer such a
distinction.

For example, when users tell you to invoke Ant with such and such
target, you don't know when things switch from compile to test.

Ditto for Maven --- it interleaves builds and tests per module, so it's
not like it compiles everything first and then tests everything later.

You're right. I was getting carried away. I'll just need to merge the next lot together and do a "completed" update at the end.

kohsuke wrote:

> I hope this isn't too much detail and that someone can help.  If you
> need more information on how the Jazz server works or anything else I
> may have forgotten or not made clear please drop me a line.
>
> I hope this all makes sense.
>
> Thanks in advance.
>
> Cheers, Andrew
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [e-mail]
> For additional commands, e-mail: [e-mail]
>
>


--
Kohsuke Kawaguchi
Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/

 

[Andrew Harmel-Law]

Hi Kohsuke,

Andrew Harmel-Law wrote:

What is the best practice for bundling plugins which extend multiple points of Hudson? In my case they are closely related. The Jazz server likes to know when a builds both starts (as soon as the SCM "fetch" begins) and ends (once the build script has completed). Should I add my Notifier extension to the same plugin as my SCM extension?  I guess so.

I've been doing more digging and I think that I do want to somehow bundle these together. I'm writing a new Notifier, but I'd like to bind it to three of the same configuration parameters I set for the SCM extension (Jazz Server URL, username and password).  I'm guessing in the same plugin this should be quite straight forward. Is there an example of two extensions plugging their @DataBoundConstructor's into the same set of properties that i could look at?

Or, alternatively, am I off completely on the wrong track?

Thanks in advance.

Cheers, Andrew

[Kohsuke Kawaguchi]

Andrew Harmel-Law wrote:
> What is the best practice for bundling plugins which extend multiple points
> of Hudson? In my case they are closely related. The Jazz server likes to
> know when a builds both starts (as soon as the SCM "fetch" begins) and ends
> (once the build script has completed). Should I add my Notifier extension to
> the same plugin as my SCM extension?  I guess so.

Yes, you can have multiple implementations of extension points packaged
in a single plugin. Most non-trivial plugins do this.

--
Kohsuke Kawaguchi
Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/

[Andrew Bayer]

The ClearCase plugin, for example, has at least 4 extensions in it.

A.

On Wed, Oct 28, 2009 at 2:29 PM, Kohsuke Kawaguchi <[hidden email]> wrote:

Andrew Harmel-Law wrote:
> What is the best practice for bundling plugins which extend multiple points
> of Hudson? In my case they are closely related. The Jazz server likes to
> know when a builds both starts (as soon as the SCM "fetch" begins) and ends
> (once the build script has completed). Should I add my Notifier extension to
> the same plugin as my SCM extension?  I guess so.

Yes, you can have multiple implementations of extension points packaged
in a single plugin. Most non-trivial plugins do this.

--
Kohsuke Kawaguchi
Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/

[Andrew Harmel-Law]

Great. thanks guys.  I'll take a look at the CC plugin.  Looks as if I need 3 - SCM, Notifier, and Action (to pass a string between the first two)

Regs, Andrew

Andrew Bayer wrote:

The ClearCase plugin, for example, has at least 4 extensions in it.

A.

On Wed, Oct 28, 2009 at 2:29 PM, Kohsuke Kawaguchi <
[e-mail]> wrote:

> Andrew Harmel-Law wrote:
> > What is the best practice for bundling plugins which extend multiple
> points
> > of Hudson? In my case they are closely related. The Jazz server likes to
> > know when a builds both starts (as soon as the SCM "fetch" begins) and
> ends
> > (once the build script has completed). Should I add my Notifier extension
> to
> > the same plugin as my SCM extension?  I guess so.
>
> Yes, you can have multiple implementations of extension points packaged
> in a single plugin. Most non-trivial plugins do this.
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/
>

[romain.seguy]

Hello Andrew,

I've seen the other day an Hudson/RTC article on jazz.net. I've not read it at all, but it might give ideas on how the two can work together: http://jazz.net/library/article/350

Regards,
Romain

Le , Andrew Harmel-Law <[hidden email]> a écrit :

>
>
> Great. thanks guys.  I'll take a look at the CC plugin.  Looks as if I need 3
>
> - SCM, Notifier, and Action (to pass a string between the first two)
>
>
>
> Regs, Andrew
>
>
>
>
>
> Andrew Bayer wrote:
>
> >
>
> > The ClearCase plugin, for example, has at least 4 extensions in it.
>
> >
>
> > A.
>
> >
>
> > On Wed, Oct 28, 2009 at 2:29 PM, Kohsuke Kawaguchi
> > [hidden email]> wrote:
>
> >
>
> >> Andrew Harmel-Law wrote:
>
> >> > What is the best practice for bundling plugins which extend multiple
>
> >> points
>
> >> > of Hudson? In my case they are closely related. The Jazz server likes
>
> >> to
>
> >> > know when a builds both starts (as soon as the SCM "fetch" begins) and
>
> >> ends
>
> >> > (once the build script has completed). Should I add my Notifier
>
> >> extension
>
> >> to
>
> >> > the same plugin as my SCM extension?  I guess so.
>
> >>
>
> >> Yes, you can have multiple implementations of extension points packaged
>
> >> in a single plugin. Most non-trivial plugins do this.
>
> >>
>
> >> --
>
> >> Kohsuke Kawaguchi
>
> >> Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/
>
> >>
>
> >
>
> >
>
>
>
> --
>
> View this message in context: http://www.nabble.com/Writing-a-IBM-Jazz-SCM-Plugin---where-and-how-to-hook-into-the-Hudson--build-lifecycle--tp25626859p26109440.html
>
> Sent from the Hudson dev mailing list archive at Nabble.com.
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: [hidden email]
>
> For additional commands, e-mail: [hidden email]
>
>
>

[Andrew Harmel-Law]

Cheers Romain,

Already seen it and working on a "Pimped..." update blog with the blessing of IBM.  The plugin will hopefully take things a lot further and make the integration even tighter.

Regs, Andrew

romain.seguy wrote:

Hello Andrew,

I've seen the other day an Hudson/RTC article on jazz.net. I've not read it  
at all, but it might give ideas on how the two can work together:  
http://jazz.net/library/article/350

Regards,
Romain

Le , Andrew Harmel-Law <[e-mail]> a écrit :


> Great. thanks guys. I'll take a look at the CC plugin. Looks as if I need  
> 3

> - SCM, Notifier, and Action (to pass a string between the first two)



> Regs, Andrew





> Andrew Bayer wrote:

> >

> > The ClearCase plugin, for example, has at least 4 extensions in it.

> >

> > A.

> >

> > On Wed, Oct 28, 2009 at 2:29 PM, Kohsuke Kawaguchi
> > [e-mail]> wrote:

> >

> >> Andrew Harmel-Law wrote:

> >> > What is the best practice for bundling plugins which extend multiple

> >> points

> >> > of Hudson? In my case they are closely related. The Jazz server likes

> >> to

> >> > know when a builds both starts (as soon as the SCM "fetch" begins)  
> and

> >> ends

> >> > (once the build script has completed). Should I add my Notifier

> >> extension

> >> to

> >> > the same plugin as my SCM extension? I guess so.

> >>

> >> Yes, you can have multiple implementations of extension points packaged

> >> in a single plugin. Most non-trivial plugins do this.

> >>

> >> --

> >> Kohsuke Kawaguchi

> >> Sun Microsystems http://weblogs.java.net/blog/kohsuke/

> >>

> >

> >



> --

> View this message in context:  
> http://www.nabble.com/Writing-a-IBM-Jazz-SCM-Plugin---where-and-how-to-hook-into-the-Hudson--build-lifecycle--tp25626859p26109440.html

> Sent from the Hudson dev mailing list archive at Nabble.com.





> ---------------------------------------------------------------------

> To unsubscribe, e-mail: [e-mail]

> For additional commands, e-mail: [e-mail]