Feedback on developing against the BuildWrapper extension point

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

Feedback on developing against the BuildWrapper extension point

Hayes, Peter
I have finished the first pass on the release plugin I'm developing and
had some feedback on the BuildWrapper extension point (This is my first
plugin so I most likely missed some things).  

I would have liked to be able to interrogate the status of the build in
the tearDown callback.  It doesn't seem possible based on the current
implementation, but I could be wrong.

In order to make a couple build environment variables available to the
builders that I ran in setup and teardown method, I had to wrap the the
AbstractBuild before passing it to the builder to perform their build
step.  If the AbstractBuild offered an API that allowed me to set custom
environment variables that would have been easier.

In order to indicate to the build wrapper that a "release" build was
being performed, it would have been convenient if the Project API
supported a scheduleBuild that accepted a map of build properties or
something like that.  I had to have the project action set a flag on the
build wrapper to pass that context but it seemed a bit hacky.  

I've attached the java source files of the plugin as reference if
interested.

 <<PluginImpl.java>>  <<WrappedBuild.java>>  <<ReleaseWrapper.java>>

Thanks,

Peter Hayes
Architecture & Shared Technology Services | Fidelity Investments
Management Technology


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

PluginImpl.java (794 bytes) Download Attachment
WrappedBuild.java (13K) Download Attachment
ReleaseWrapper.java (12K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Feedback on developing against the BuildWrapper extension point

Michael Donohue-2
It's probably boilerplate, but does this statement apply to the code
attached?
"Fidelity Confidential Information."

-Michael

> -----Original Message-----
> From: Hayes, Peter [mailto:[hidden email]]
> Sent: Wednesday, June 18, 2008 4:02 PM
> To: [hidden email]
> Subject: Feedback on developing against the BuildWrapper extension
point
>
> I have finished the first pass on the release plugin I'm developing
and
> had some feedback on the BuildWrapper extension point (This is my
first
> plugin so I most likely missed some things).
>
> I would have liked to be able to interrogate the status of the build
in
> the tearDown callback.  It doesn't seem possible based on the current
> implementation, but I could be wrong.
>
> In order to make a couple build environment variables available to the
> builders that I ran in setup and teardown method, I had to wrap the
the
> AbstractBuild before passing it to the builder to perform their build
> step.  If the AbstractBuild offered an API that allowed me to set
custom
> environment variables that would have been easier.
>
> In order to indicate to the build wrapper that a "release" build was
> being performed, it would have been convenient if the Project API
> supported a scheduleBuild that accepted a map of build properties or
> something like that.  I had to have the project action set a flag on
the

> build wrapper to pass that context but it seemed a bit hacky.
>
> I've attached the java source files of the plugin as reference if
> interested.
>
>  <<PluginImpl.java>>  <<WrappedBuild.java>>  <<ReleaseWrapper.java>>
>
> Thanks,
>
> Peter Hayes
> Architecture & Shared Technology Services | Fidelity Investments
> Management Technology


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

Reply | Threaded
Open this post in threaded view
|

RE: RE: Feedback on developing against the BuildWrapper extension point

Hayes, Peter
It is boiler plate.  This code has no proprietary information but it is
the disclaimer we put on all code. I should have removed it before
sending along.

-Pete

-----Original Message-----
From: Donohue, Michael [mailto:[hidden email]]
Sent: Wednesday, June 18, 2008 10:14 PM
To: [hidden email]
Subject: RE: Feedback on developing against the BuildWrapper extension
point

It's probably boilerplate, but does this statement apply to the code
attached?
"Fidelity Confidential Information."

-Michael

> -----Original Message-----
> From: Hayes, Peter [mailto:[hidden email]]
> Sent: Wednesday, June 18, 2008 4:02 PM
> To: [hidden email]
> Subject: Feedback on developing against the BuildWrapper extension
point
>
> I have finished the first pass on the release plugin I'm developing
and
> had some feedback on the BuildWrapper extension point (This is my
first
> plugin so I most likely missed some things).
>
> I would have liked to be able to interrogate the status of the build
in
> the tearDown callback.  It doesn't seem possible based on the current
> implementation, but I could be wrong.
>
> In order to make a couple build environment variables available to the
> builders that I ran in setup and teardown method, I had to wrap the
the
> AbstractBuild before passing it to the builder to perform their build
> step.  If the AbstractBuild offered an API that allowed me to set
custom
> environment variables that would have been easier.
>
> In order to indicate to the build wrapper that a "release" build was
> being performed, it would have been convenient if the Project API
> supported a scheduleBuild that accepted a map of build properties or
> something like that.  I had to have the project action set a flag on
the

> build wrapper to pass that context but it seemed a bit hacky.
>
> I've attached the java source files of the plugin as reference if
> interested.
>
>  <<PluginImpl.java>>  <<WrappedBuild.java>>  <<ReleaseWrapper.java>>
>
> Thanks,
>
> Peter Hayes
> Architecture & Shared Technology Services | Fidelity Investments
> Management Technology


---------------------------------------------------------------------
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]