Pluginify the dependency management

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

Pluginify the dependency management

Nicolas Lalevée-2
Hi everyone,

I have developped an ivy plugin which has been recently imported into the
source tree of Hudson. Ivy [1] is a dependency manager. So this plugin is
using ivy to trigger builds of every ivy-aware projects, just like the maven
project trigger other maven projects.
This ivy plugin is a "publisher" of a project so it can be added to a free
style project. So it can also be combined with a simple build trigger. But
this plugin cannot contribute to the dependency graph, because for the
Project is building the dependency graph only with the build trigger.
So some change are needed to make it work. There are two solutions I think.

First we can mark the publishers that also contribute to the dependency graph
with an interface :
interface AbstractProjectTrigger {
  List<AbstractProject> getChildProjects();
}
And then the Project class will search for every publisher that is also an
AbstractProjectTrigger, more that just search for the unique BuildTrigger.

Or we can make a new class of BuildStep : an AbstractProjectTrigger. The
Project class will handle a new set : some AbstractProjectTriggers. And then
the Project class will just iterate over its registered
AbstractProjectTriggers while building the dependency graph.
Some other change will be needed : the current BuildTrigger will register
itself as a AbstractProjectTriggers more than a Publisher. And the jelly
about a project configuration will contain a new set of entries :
   <p:config-buildWrappers />
   <p:config-builders />
   <p:config-publishers />
+  <p:config-buildTriggers />

The former seems simpler to setup, but the second seems to me cleaner :
triggering a build is not a publishing action as it doesn't publish anything,
it is another kind of build step.

WDYT ?

Nicolas

[1] http://ant.apache.org/ivy/

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

Reply | Threaded
Open this post in threaded view
|

Re: Pluginify the dependency management

Jean-Baptiste Quenot
Hi Nicolas,

Thanks for your Ivy plugin, this is a great first step.  I also faced
problems with Hudson's dependency graph, I couldn't manage to change
it dynamically, some API improvements would be great in this area.

However I can't comment much on your proposal (as I stepped out a bit
from Hudson and Java in general in my current job), but I'm sure
others will chime in to help you shed some light on this obscure part
of Hudson and hopefully new extension points will be available for
plugins to modify the dependency graph at runtime.

Cheers,
--
Jean-Baptiste Quenot
http://caraldi.com/jbq/

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

Reply | Threaded
Open this post in threaded view
|

Re: Pluginify the dependency management

Kohsuke Kawaguchi
Administrator
In reply to this post by Nicolas Lalevée-2
Nicolas Lalevée wrote:
> Hi everyone,
>
> I have developped an ivy plugin which has been recently imported into the
> source tree of Hudson. Ivy [1] is a dependency manager. So this plugin is
> using ivy to trigger builds of every ivy-aware projects, just like the maven
> project trigger other maven projects.

I tried to refresh my memory on the Ivy plugin and so headed for
http://hudson.gotdns.com/wiki/display/HUDSON/Plugins but I didn't find
it. I think it would be great if you could add a page about it in the wiki.

> This ivy plugin is a "publisher" of a project so it can be added to a free
> style project. So it can also be combined with a simple build trigger. But
> this plugin cannot contribute to the dependency graph, because for the
> Project is building the dependency graph only with the build trigger.
> So some change are needed to make it work. There are two solutions I think.

IIRC, Ivy plugin allows a developer to tell Hudson where is the ivy
configuration file, and you use that information to automatically
trigger a new build whenever one of the upstream changes? Is that accurate?

In that case, perhaps it would be more appropriate for it to extend from
Trigger? (even though it's not timer related.)


> First we can mark the publishers that also contribute to the dependency graph
> with an interface :
> interface AbstractProjectTrigger {
>   List<AbstractProject> getChildProjects();
> }
> And then the Project class will search for every publisher that is also an
> AbstractProjectTrigger, more that just search for the unique BuildTrigger.

I think this is easily doable, so I'm favoring this.

> Or we can make a new class of BuildStep : an AbstractProjectTrigger. The
> Project class will handle a new set : some AbstractProjectTriggers. And then
> the Project class will just iterate over its registered
> AbstractProjectTriggers while building the dependency graph.
> Some other change will be needed : the current BuildTrigger will register
> itself as a AbstractProjectTriggers more than a Publisher. And the jelly
> about a project configuration will contain a new set of entries :
>    <p:config-buildWrappers />
>    <p:config-builders />
>    <p:config-publishers />
> +  <p:config-buildTriggers />
>
> The former seems simpler to setup, but the second seems to me cleaner :
> triggering a build is not a publishing action as it doesn't publish anything,
> it is another kind of build step.
Perhaps the term 'publisher' was not very good, but it's intended to be
everything that happens after a build. I don't think I see sufficient
difference between Publisher and ProjectTrigger to justify introducing a
new type.

There's a lot of other examples where the standard extension points like
Publisher are queried for additional capabilities by means of an
interface (HealthReportingAction, etc), so I think it's a reasonable
practice.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]


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

Re: Pluginify the dependency management

Nicolas Lalevée-2
Le lundi 12 novembre 2007, Kohsuke Kawaguchi a écrit :

> Nicolas Lalevée wrote:
> > Hi everyone,
> >
> > I have developped an ivy plugin which has been recently imported into the
> > source tree of Hudson. Ivy [1] is a dependency manager. So this plugin is
> > using ivy to trigger builds of every ivy-aware projects, just like the
> > maven project trigger other maven projects.
>
> I tried to refresh my memory on the Ivy plugin and so headed for
> http://hudson.gotdns.com/wiki/display/HUDSON/Plugins but I didn't find
> it. I think it would be great if you could add a page about it in the wiki.

yep, there is no page yet. I will add one.
The issue about it :
https://hudson.dev.java.net/issues/show_bug.cgi?id=955

>
> > This ivy plugin is a "publisher" of a project so it can be added to a
> > free style project. So it can also be combined with a simple build
> > trigger. But this plugin cannot contribute to the dependency graph,
> > because for the Project is building the dependency graph only with the
> > build trigger. So some change are needed to make it work. There are two
> > solutions I think.
>
> IIRC, Ivy plugin allows a developer to tell Hudson where is the ivy
> configuration file, and you use that information to automatically
> trigger a new build whenever one of the upstream changes? Is that accurate?

Yep, that's it.

> In that case, perhaps it would be more appropriate for it to extend from
> Trigger? (even though it's not timer related.)
>
> > First we can mark the publishers that also contribute to the dependency
> > graph with an interface :
> > interface AbstractProjectTrigger {
> >   List<AbstractProject> getChildProjects();
> > }
> > And then the Project class will search for every publisher that is also
> > an AbstractProjectTrigger, more that just search for the unique
> > BuildTrigger.
>
> I think this is easily doable, so I'm favoring this.
>
> > Or we can make a new class of BuildStep : an AbstractProjectTrigger. The
> > Project class will handle a new set : some AbstractProjectTriggers. And
> > then the Project class will just iterate over its registered
> > AbstractProjectTriggers while building the dependency graph.
> > Some other change will be needed : the current BuildTrigger will register
> > itself as a AbstractProjectTriggers more than a Publisher. And the jelly
> > about a project configuration will contain a new set of entries :
> >    <p:config-buildWrappers />
> >    <p:config-builders />
> >    <p:config-publishers />
> > +  <p:config-buildTriggers />
> >
> > The former seems simpler to setup, but the second seems to me cleaner :
> > triggering a build is not a publishing action as it doesn't publish
> > anything, it is another kind of build step.
>
> Perhaps the term 'publisher' was not very good, but it's intended to be
> everything that happens after a build. I don't think I see sufficient
> difference between Publisher and ProjectTrigger to justify introducing a
> new type.
>
> There's a lot of other examples where the standard extension points like
> Publisher are queried for additional capabilities by means of an
> interface (HealthReportingAction, etc), so I think it's a reasonable
> practice.

OK. And in fact the javadoc of Publisher tells what you just explained. :)
I will do a patch for the former simpler proposal.


--
Nicolas LALEVÉE
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

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

Reply | Threaded
Open this post in threaded view
|

Re: Pluginify the dependency management

Kohsuke Kawaguchi
Administrator
Nicolas Lalevée wrote:
> OK. And in fact the javadoc of Publisher tells what you just explained. :)
> I will do a patch for the former simpler proposal.

Great! Thank you!

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]


smime.p7s (4K) Download Attachment