Allow PluginStrategy implementations complete control over finding components

28 views
Skip to first unread message

Stuart McCulloch

unread,
Feb 27, 2011, 2:41:08 PM2/27/11
to jenkin...@googlegroups.com
Hi,

FYI, I've opened a Jenkins feature request for the same small patch I submitted to Hudson that gives custom PluginStrategies complete control over the component finding process:


We use this feature to swap in JSR330/Guice in place of sezpoz - but regardless of which IoC or service locator framework you prefer, I think this patch is useful and not intrusive. 

One thing I'd like to stress is that just because this change has been merged into Hudson definitely doesn't mean that the design is frozen - personally I'm always open to constructive criticism and if there's a better way to achieve the same functionality I would be interested to hear about it. I also think maintaining core compatibility is in the interests of everyone, which is my primary motivation for submitting this feature request.

-- 
Thanks in advance, Stuart

Kohsuke Kawaguchi

unread,
Feb 28, 2011, 9:40:29 PM2/28/11
to jenkin...@googlegroups.com, Stuart McCulloch

The change looks good to me, so I'll merge it.

The only thing I need to ask you is if you'd be willing to sign CLA when
we have our final home --- as you may know, we are seeking a neutral
foundation to assign CLA to, but that's not finalized yet.

So at this point we don't have the final concrete CLA ready, but it'll
be something very close to what we used to use [1], except it won't be
assigned to a corporation. So for the time being, we are just checking
if contributers are generally OK with this.


And finally, if I'm not mistaken, you work for Sonatype, are you not? Is
this a sign that we'll be seeing more contributions from you guys? If
that is the case. I guess I'm just curious what your intentions are...


[1] http://oss.oracle.com/oca.pdf


--
Kohsuke Kawaguchi http://kohsuke.org/

Olivier Lamy

unread,
Mar 1, 2011, 4:18:48 AM3/1/11
to jenkin...@googlegroups.com
Tested and +1 too.

Thanks,
--
Olivier Lamy
http://twitter.com/olamy
http://www.linkedin.com/in/olamy

2011/3/1 Kohsuke Kawaguchi <k...@kohsuke.org>:

Stuart McCulloch

unread,
Mar 1, 2011, 8:58:45 AM3/1/11
to jenkin...@googlegroups.com
On 1 March 2011 02:40, Kohsuke Kawaguchi <k...@kohsuke.org> wrote:

The change looks good to me, so I'll merge it.

Excellent, thanks for reviewing it
 
The only thing I need to ask you is if you'd be willing to sign CLA when we have our final home --- as you may know, we are seeking a neutral foundation to assign CLA to, but that's not finalized yet.

So at this point we don't have the final concrete CLA ready, but it'll be something very close to what we used to use [1], except it won't be assigned to a corporation. So for the time being, we are just checking if contributers are generally OK with this.

Yes I've previously signed the OCA - I'll need to see the final CLA before signing it, but if it's basically the same as the OCA then I don't foresee a problem.
 
And finally, if I'm not mistaken, you work for Sonatype, are you not? Is this a sign that we'll be seeing more contributions from you guys? If that is the case. I guess I'm just curious what your intentions are...

[ disclaimer: these views are my own and do not necessarily reflect the views of my employer ]

I work for Sonatype so my main focus will be on the Hudson codebase rather than Jenkins. But I'm also trying to look out for the plugin developer who wants some level of portability between the two projects. I've been personally championing the use of JSR330 because it's a standard way to annotate dependencies, you're not forced to choose an IoC framework up-front. So it would be rather ironic if introducing JSR330 forced plugin developers to choose between Hudson or Jenkins :)

This particular patch provides a way to use our JSR330 plugin strategy on top of Jenkins, plugin developers can then try out JSR330 without having to worry whether users have Jenkins or Hudson installed. This patch also lets people experiment with alternative strategies such as Spring or Jexmec without having to modify the core (just in case our particular solution is not to everyone's taste!).

As for future contributions, I never like to make predictions. But our additions to Hudson can be seen on github, so if there's anything (especially wrt. JSR330 and our new Guice based plugin strategy) that people want to know more about I'm happy to discuss technical details. And if anything else comes up that might affect plugin portability between the two projects I'll try to make sure it gets mentioned here.

--
Thanks again, Stuart

do...@fortysix.ch

unread,
Mar 2, 2011, 4:22:02 PM3/2/11
to jenkin...@googlegroups.com, Stuart McCulloch
+1, thanks for this!


Zitat von Stuart McCulloch <mcc...@gmail.com>:

Reply all
Reply to author
Forward
0 new messages