Re: [Issue 1032] Pluginify the dependency management

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Issue 1032] Pluginify the dependency management

Nicolas Lalevée-2
Hi,

Is that OK if I commit this ?


Le dimanche 25 novembre 2007, [hidden email] a écrit :

> https://hudson.dev.java.net/issues/show_bug.cgi?id=1032
>
>
>
> User hibou changed the following:
>
>                 What    |Old value                 |New value
> ===========================================================================
>===== Attachment is patch|                          |Created an attachment
> (id=
>
>                         |                          |136)
>
> Improved patch + impr
>
>                         |                          |oved
>                         |                          | FormFieldValidator.Wo
>                         |                          | rkspaceDirectory
>
> ---------------------------------------------------------------------------
>-----
>
>
>
>
> ------- Additional comments from [hidden email] Sun Nov 25 18:30:22
> +0000 2007 ------- Created an attachment (id=136)
> Improved patch + improved FormFieldValidator.WorkspaceDirectory
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



--
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: [Issue 1032] Pluginify the dependency management

Martin Ficker
Hello,
sorry for commenting that patch so late.

I like the idea of making the dependency management more plugable, but
there is a one thing in the implementation I don't like:
We end up with a Class called "AbstractBuildTrigger "extending
Publisher. This Class serves two purposes:
 a) It is a base class for classes that  describe dependencies between
Projects.
 b) Is is a implementation of Publisher that builds projects based on
dependencies

I would rather split this in three pieces:
 a) A Interface IDependecyDeclarer with a method
   protected void buildDependencyGraph(DependencyGraph graph)
  This methods allows the Interface to declare arbitrary Dependencies
beetween projects.

 b) A class DependencyBuildTrigger extending Publisher
  This class would trigger Build depending on the dependencies received
from the Global DependecyGraph

 c)  A place to register new Instances of  IDependencyDeclarer. I'm not
sure where this place should be. It could be a static list in
BuildStep,  like it's for the Publishers.

Project.buildDependencyGraph would then scan for implementations of the
new Interface rather than for AbstractBuildTrigger.
Sine I'm not very deep into Hudson,  perhaps some one else with more
knowledge should comment this.

I haven't tested WorkspaceFilePath, but it looks good to me.

Best regards,

Martin


Nicolas Lalevée schrieb:

> Hi,
>
> Is that OK if I commit this ?
>
>
> Le dimanche 25 novembre 2007, [hidden email] a écrit :
>  
>> https://hudson.dev.java.net/issues/show_bug.cgi?id=1032
>>
>>
>>
>> User hibou changed the following:
>>
>>                 What    |Old value                 |New value
>> ===========================================================================
>> ===== Attachment is patch|                          |Created an attachment
>> (id=
>>
>>                         |                          |136)
>>
>> Improved patch + impr
>>
>>                         |                          |oved
>>                         |                          | FormFieldValidator.Wo
>>                         |                          | rkspaceDirectory
>>
>> ---------------------------------------------------------------------------
>> -----
>>
>>
>>
>>
>> ------- Additional comments from [hidden email] Sun Nov 25 18:30:22
>> +0000 2007 ------- Created an attachment (id=136)
>> Improved patch + improved FormFieldValidator.WorkspaceDirectory
>>
>>
>> ---------------------------------------------------------------------
>> 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: [Issue 1032] Pluginify the dependency management

Nicolas Lalevée-2

Le 26 nov. 07 à 20:15, M. Ficker a écrit :

> Hello,
> sorry for commenting that patch so late.

well, thank you first for reviewing it ;)

> I like the idea of making the dependency management more plugable, but
> there is a one thing in the implementation I don't like:
> We end up with a Class called "AbstractBuildTrigger "extending
> Publisher. This Class serves two purposes:
> a) It is a base class for classes that  describe dependencies between
> Projects.
> b) Is is a implementation of Publisher that builds projects based on
> dependencies
>
> I would rather split this in three pieces:
> a) A Interface IDependecyDeclarer with a method
>   protected void buildDependencyGraph(DependencyGraph graph)
>  This methods allows the Interface to declare arbitrary Dependencies
> beetween projects.
>
> b) A class DependencyBuildTrigger extending Publisher
>  This class would trigger Build depending on the dependencies received
> from the Global DependecyGraph
>
> c)  A place to register new Instances of  IDependencyDeclarer. I'm not
> sure where this place should be. It could be a static list in
> BuildStep,  like it's for the Publishers.
>
> Project.buildDependencyGraph would then scan for implementations of  
> the
> new Interface rather than for AbstractBuildTrigger.
> Sine I'm not very deep into Hudson,  perhaps some one else with more
> knowledge should comment this.

I shared your point, but I prefered keeping the dependency graph and  
the build trigger independant, while making more close the build  
trigger from the dependency declarer.
For now, the dependencies are triggered depending of the result of the  
build. We can imagine that we would like to configure it by triggered  
projects. Some downstream projects will be always triggered what ever  
the build status, the others being triggered only if the build is  
successful. Then if we think of the user configure interface, I think  
of an interface that will mix both informations : the downstream  
projects and the threashold build status by downstream projects. And I  
don't think you should seperate them in the code.

And in fact the two purposes you talk about, triggering other build  
and declaring dependencies are so close that I think we can consider  
the both to be the same. We cannot have something that trigger other  
builds which will not participate to the dependency graph.
And the two concepts are in the patch : triggering other build, code  
that will be very common, is the AbstractBuildTrigger; the  
dependencies declaration will be in the subclasses of this abstract  
classes.

WDYT ?

> I haven't tested WorkspaceFilePath, but it looks good to me.

I have tested with the ivy plugin (which also need a lot of  
improvement), works like a charm :)

cheers,
Nicolas


> Best regards,
>
> Martin
>
>
> Nicolas Lalevée schrieb:
>> Hi,
>>
>> Is that OK if I commit this ?
>>
>>
>> Le dimanche 25 novembre 2007, [hidden email] a écrit :
>>
>>> https://hudson.dev.java.net/issues/show_bug.cgi?id=1032
>>>
>>>
>>>
>>> User hibou changed the following:
>>>
>>>                What    |Old value                 |New value
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> ====================================================================
>>> ===== Attachment is patch|                          |Created an  
>>> attachment
>>> (id=
>>>
>>>                        |                          |136)
>>>
>>> Improved patch + impr
>>>
>>>                        |                          |oved
>>>                        |                          |  
>>> FormFieldValidator.Wo
>>>                        |                          | rkspaceDirectory
>>>
>>> ---------------------------------------------------------------------------
>>> -----
>>>
>>>
>>>
>>>
>>> ------- Additional comments from [hidden email] Sun Nov 25  
>>> 18:30:22
>>> +0000 2007 ------- Created an attachment (id=136)
>>> Improved patch + improved FormFieldValidator.WorkspaceDirectory
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: [Issue 1032] Pluginify the dependency management

Kohsuke Kawaguchi
Administrator
In reply to this post by Nicolas Lalevée-2

I was aware of this in the inbox but couldn't get to it.  I'll really
try to get to this today.

Nicolas Lalevée wrote:

> Hi,
>
> Is that OK if I commit this ?
>
>
> Le dimanche 25 novembre 2007, [hidden email] a ??crit??:
>> https://hudson.dev.java.net/issues/show_bug.cgi?id=1032
>>
>>
>>
>> User hibou changed the following:
>>
>>                 What    |Old value                 |New value
>> ===========================================================================
>>===== Attachment is patch|                          |Created an attachment
>> (id=
>>
>>                         |                          |136)
>>
>> Improved patch + impr
>>
>>                         |                          |oved
>>                         |                          | FormFieldValidator.Wo
>>                         |                          | rkspaceDirectory
>>
>> ---------------------------------------------------------------------------
>>-----
>>
>>
>>
>>
>> ------- Additional comments from [hidden email] Sun Nov 25 18:30:22
>> +0000 2007 ------- Created an attachment (id=136)
>> Improved patch + improved FormFieldValidator.WorkspaceDirectory
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
>

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]


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

Re: [Issue 1032] Pluginify the dependency management

Kohsuke Kawaguchi
Administrator
In reply to this post by Martin Ficker

What I had in mind was closer to what Martin is explaining below, so I
committed the change along that line.

I also made a little modification to the WorkspaceFilePath form
validator code, but that's also checked in.


M. Ficker wrote:

> Hello,
> sorry for commenting that patch so late.
>
> I like the idea of making the dependency management more plugable, but
> there is a one thing in the implementation I don't like:
> We end up with a Class called "AbstractBuildTrigger "extending
> Publisher. This Class serves two purposes:
>  a) It is a base class for classes that  describe dependencies between
> Projects.
>  b) Is is a implementation of Publisher that builds projects based on
> dependencies
>
> I would rather split this in three pieces:
>  a) A Interface IDependecyDeclarer with a method
>    protected void buildDependencyGraph(DependencyGraph graph)
>   This methods allows the Interface to declare arbitrary Dependencies
> beetween projects.
>
>  b) A class DependencyBuildTrigger extending Publisher
>   This class would trigger Build depending on the dependencies received
> from the Global DependecyGraph
>
>  c)  A place to register new Instances of  IDependencyDeclarer. I'm not
> sure where this place should be. It could be a static list in
> BuildStep,  like it's for the Publishers.
>
> Project.buildDependencyGraph would then scan for implementations of the
> new Interface rather than for AbstractBuildTrigger.
> Sine I'm not very deep into Hudson,  perhaps some one else with more
> knowledge should comment this.
>
> I haven't tested WorkspaceFilePath, but it looks good to me.
>
> Best regards,
>
> Martin
>
>
> Nicolas Lalev??e schrieb:
>> Hi,
>>
>> Is that OK if I commit this ?
>>
>>
>> Le dimanche 25 novembre 2007, [hidden email] a ??crit :
>>  
>>> https://hudson.dev.java.net/issues/show_bug.cgi?id=1032
>>>
>>>
>>>
>>> User hibou changed the following:
>>>
>>>                 What    |Old value                 |New value
>>> ===========================================================================
>>> ===== Attachment is patch|                          |Created an attachment
>>> (id=
>>>
>>>                         |                          |136)
>>>
>>> Improved patch + impr
>>>
>>>                         |                          |oved
>>>                         |                          | FormFieldValidator.Wo
>>>                         |                          | rkspaceDirectory
>>>
>>> ---------------------------------------------------------------------------
>>> -----
>>>
>>>
>>>
>>>
>>> ------- Additional comments from [hidden email] Sun Nov 25 18:30:22
>>> +0000 2007 ------- Created an attachment (id=136)
>>> Improved patch + improved FormFieldValidator.WorkspaceDirectory
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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]
>
>

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

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

Re: [Issue 1032] Pluginify the dependency management

Nicolas Lalevée-2
Le mardi 27 novembre 2007, Kohsuke Kawaguchi a écrit :
> What I had in mind was closer to what Martin is explaining below, so I
> committed the change along that line.
>
> I also made a little modification to the WorkspaceFilePath form
> validator code, but that's also checked in.

OK, I have then use this new code in the ivy plugin, did sevral fix and
commited it.

cheers,
Nicolas

>
> M. Ficker wrote:
> > Hello,
> > sorry for commenting that patch so late.
> >
> > I like the idea of making the dependency management more plugable, but
> > there is a one thing in the implementation I don't like:
> > We end up with a Class called "AbstractBuildTrigger "extending
> > Publisher. This Class serves two purposes:
> >  a) It is a base class for classes that  describe dependencies between
> > Projects.
> >  b) Is is a implementation of Publisher that builds projects based on
> > dependencies
> >
> > I would rather split this in three pieces:
> >  a) A Interface IDependecyDeclarer with a method
> >    protected void buildDependencyGraph(DependencyGraph graph)
> >   This methods allows the Interface to declare arbitrary Dependencies
> > beetween projects.
> >
> >  b) A class DependencyBuildTrigger extending Publisher
> >   This class would trigger Build depending on the dependencies received
> > from the Global DependecyGraph
> >
> >  c)  A place to register new Instances of  IDependencyDeclarer. I'm not
> > sure where this place should be. It could be a static list in
> > BuildStep,  like it's for the Publishers.
> >
> > Project.buildDependencyGraph would then scan for implementations of the
> > new Interface rather than for AbstractBuildTrigger.
> > Sine I'm not very deep into Hudson,  perhaps some one else with more
> > knowledge should comment this.
> >
> > I haven't tested WorkspaceFilePath, but it looks good to me.
> >
> > Best regards,
> >
> > Martin
> >
> > Nicolas Lalev??e schrieb:
> >> Hi,
> >>
> >> Is that OK if I commit this ?
> >>
> >> Le dimanche 25 novembre 2007, [hidden email] a ??crit :
> >>> https://hudson.dev.java.net/issues/show_bug.cgi?id=1032
> >>>
> >>>
> >>>
> >>> User hibou changed the following:
> >>>
> >>>                 What    |Old value                 |New value
> >>> =======================================================================
> >>>==== ===== Attachment is patch|                          |Created an
> >>> attachment (id=
> >>>
> >>>                         |                          |136)
> >>>
> >>> Improved patch + impr
> >>>
> >>>                         |                          |oved
> >>>                         |                          | FormFieldValidator
> >>>                         |                          |.Wo
> >>>                         |                          | rkspaceDirectory
> >>>
> >>> -----------------------------------------------------------------------
> >>>---- -----
> >>>
> >>>
> >>>
> >>>
> >>> ------- Additional comments from [hidden email] Sun Nov 25 18:30:22
> >>> +0000 2007 ------- Created an attachment (id=136)
> >>> Improved patch + improved FormFieldValidator.WorkspaceDirectory
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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]



--
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: [Issue 1032] Pluginify the dependency management

Martin Ficker
Hello,

I've finally found the time to have a look at the new plugin. Thanks to
Nicolas and Kohsuke for there work.
I've got a  few comments/ideas:

1. The plugin threw an "UnsupportedOperationException" in
BuildStepCompatibilityLayer. I've added (in my working copy)
a  "perform(AbstractBuild<?, ?> build, Launcher launcher,  BuildListener
listener)" (doing nothing) in IvyBuildTrigger to solve this.

2. The Plugin tries to resolve dependencies transitive. As I understand
the Interface  DependencyDeclarer, one needs only to declare only direct
dependencies, since the dependencies will be asked for their
dependencies anyway. This may become a performance issue for for users
with many "ivy projects". (I think its O(n^3) vs. O(n^2)). I propose to
remove the recursion from "processFilterNodeFromLeaf"

3. Currently the dependencyGraph ist only updated on configuration
changes. A typical use case may be a ivy.xml under SCM - Control. We
should monitor this file for changes on every build and trigger a update
of DependencyGraph if necessary. I'm not sure whats the best way to do
this. Store the date? A Checksum? Or could the SCM tell us if the file
changed?

4.I'm knew to maven and have some problems understanding the pom. I had
to apply following changes to be able to build:
 - change Pluginversion from 1.156 to 1.160. Is there a way to use the
latest, or do we have to keep changing every few days?
- I removed
      <dependency>
       <groupId>org.jvnet.hudson.main</groupId>
       <artifactId>hudson-core</artifactId>
       <version>1.160-SNAPSHOT</version>
     </dependency>
     <dependency>
       <groupId>org.jvnet.hudson.main</groupId>
       <artifactId>hudson-war</artifactId>
       <version>1.160-SNAPSHOT</version>
       <type>war</type>
     </dependency>

 it seems this wasn't necessary.

Best regards,

Martin




Nicolas Lalevée schrieb:

> Le mardi 27 novembre 2007, Kohsuke Kawaguchi a écrit :
>  
>> What I had in mind was closer to what Martin is explaining below, so I
>> committed the change along that line.
>>
>> I also made a little modification to the WorkspaceFilePath form
>> validator code, but that's also checked in.
>>    
>
> OK, I have then use this new code in the ivy plugin, did sevral fix and
> commited it.
>
> cheers,
> Nicolas
>
>  
>> M. Ficker wrote:
>>    
>>> Hello,
>>> sorry for commenting that patch so late.
>>>
>>> I like the idea of making the dependency management more plugable, but
>>> there is a one thing in the implementation I don't like:
>>> We end up with a Class called "AbstractBuildTrigger "extending
>>> Publisher. This Class serves two purposes:
>>>  a) It is a base class for classes that  describe dependencies between
>>> Projects.
>>>  b) Is is a implementation of Publisher that builds projects based on
>>> dependencies
>>>
>>> I would rather split this in three pieces:
>>>  a) A Interface IDependecyDeclarer with a method
>>>    protected void buildDependencyGraph(DependencyGraph graph)
>>>   This methods allows the Interface to declare arbitrary Dependencies
>>> beetween projects.
>>>
>>>  b) A class DependencyBuildTrigger extending Publisher
>>>   This class would trigger Build depending on the dependencies received
>>> from the Global DependecyGraph
>>>
>>>  c)  A place to register new Instances of  IDependencyDeclarer. I'm not
>>> sure where this place should be. It could be a static list in
>>> BuildStep,  like it's for the Publishers.
>>>
>>> Project.buildDependencyGraph would then scan for implementations of the
>>> new Interface rather than for AbstractBuildTrigger.
>>> Sine I'm not very deep into Hudson,  perhaps some one else with more
>>> knowledge should comment this.
>>>
>>> I haven't tested WorkspaceFilePath, but it looks good to me.
>>>
>>> Best regards,
>>>
>>> Martin
>>>
>>> Nicolas Lalev??e schrieb:
>>>      
>>>> Hi,
>>>>
>>>> Is that OK if I commit this ?
>>>>
>>>> Le dimanche 25 novembre 2007, [hidden email] a ??crit :
>>>>        
>>>>> https://hudson.dev.java.net/issues/show_bug.cgi?id=1032
>>>>>
>>>>>
>>>>>
>>>>> User hibou changed the following:
>>>>>
>>>>>                 What    |Old value                 |New value
>>>>> =======================================================================
>>>>> ==== ===== Attachment is patch|                          |Created an
>>>>> attachment (id=
>>>>>
>>>>>                         |                          |136)
>>>>>
>>>>> Improved patch + impr
>>>>>
>>>>>                         |                          |oved
>>>>>                         |                          | FormFieldValidator
>>>>>                         |                          |.Wo
>>>>>                         |                          | rkspaceDirectory
>>>>>
>>>>> -----------------------------------------------------------------------
>>>>> ---- -----
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------- Additional comments from [hidden email] Sun Nov 25 18:30:22
>>>>> +0000 2007 ------- Created an attachment (id=136)
>>>>> Improved patch + improved FormFieldValidator.WorkspaceDirectory
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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: [Issue 1032] Pluginify the dependency management

Nicolas Lalevée-2

Le 4 déc. 07 à 22:34, M. Ficker a écrit :

> Hello,
>
> I've finally found the time to have a look at the new plugin. Thanks  
> to
> Nicolas and Kohsuke for there work.
> I've got a  few comments/ideas:
>
> 1. The plugin threw an "UnsupportedOperationException" in
> BuildStepCompatibilityLayer. I've added (in my working copy)
> a  "perform(AbstractBuild<?, ?> build, Launcher launcher,  
> BuildListener
> listener)" (doing nothing) in IvyBuildTrigger to solve this.

I think there is something wrong on the API.
Kohsuke, some API have been deprecated, but shouldn't be kept working ?
See the folowing patch :

Index: src/main/java/hudson/tasks/BuildStepCompatibilityLayer.java
===================================================================
RCS file: /cvs/hudson/hudson/main/core/src/main/java/hudson/tasks/
BuildStepCompatibilityLayer.java,v
retrieving revision 1.1
diff -u -r1.1 BuildStepCompatibilityLayer.java
--- src/main/java/hudson/tasks/BuildStepCompatibilityLayer.java 28 Oct  
2007 23:20:01 -0000 1.1
+++ src/main/java/hudson/tasks/BuildStepCompatibilityLayer.java 5 Dec  
2007 20:23:43 -0000
@@ -57,7 +57,7 @@
       *      Use {@link #perform(AbstractBuild, Launcher,  
BuildListener)} instead.
       */
      public boolean perform(Build<?,?> build, Launcher launcher,  
BuildListener listener) throws InterruptedException, IOException {
-        throw new UnsupportedOperationException();
+        return true;
      }

      /**


> 2. The Plugin tries to resolve dependencies transitive. As I  
> understand
> the Interface  DependencyDeclarer, one needs only to declare only  
> direct
> dependencies, since the dependencies will be asked for their
> dependencies anyway. This may become a performance issue for for users
> with many "ivy projects". (I think its O(n^3) vs. O(n^2)). I propose  
> to
> remove the recursion from "processFilterNodeFromLeaf"

good point !
and fixed in the cvs

> 3. Currently the dependencyGraph ist only updated on configuration
> changes. A typical use case may be a ivy.xml under SCM - Control. We
> should monitor this file for changes on every build and trigger a  
> update
> of DependencyGraph if necessary. I'm not sure whats the best way to do
> this. Store the date? A Checksum? Or could the SCM tell us if the file
> changed?

good point too !

to rebuild the dependencies, there is

         Hudson.getInstance().rebuildDependencyGraph();

So I have added it into the ivy trigger. And about recomputing only on  
file change, I made it relying on the last modification date.
committed in cvs.


>
> 4.I'm knew to maven and have some problems understanding the pom. I  
> had
> to apply following changes to be able to build:
> - change Pluginversion from 1.156 to 1.160. Is there a way to use the
> latest, or do we have to keep changing every few days?
> - I removed
>      <dependency>
>       <groupId>org.jvnet.hudson.main</groupId>
>       <artifactId>hudson-core</artifactId>
>       <version>1.160-SNAPSHOT</version>
>     </dependency>
>     <dependency>
>       <groupId>org.jvnet.hudson.main</groupId>
>       <artifactId>hudson-war</artifactId>
>       <version>1.160-SNAPSHOT</version>
>       <type>war</type>
>     </dependency>
>
> it seems this wasn't necessary.

I put this to use the new API which was not released. As it is  
released now, we can remove them, you're right.
fixed in the cvs

cheers,
Nicolas

>
> Nicolas Lalevée schrieb:
>> Le mardi 27 novembre 2007, Kohsuke Kawaguchi a écrit :
>>
>>> What I had in mind was closer to what Martin is explaining below,  
>>> so I
>>> committed the change along that line.
>>>
>>> I also made a little modification to the WorkspaceFilePath form
>>> validator code, but that's also checked in.
>>>
>>
>> OK, I have then use this new code in the ivy plugin, did sevral fix  
>> and
>> commited it.
>>
>> cheers,
>> Nicolas
>>
>>
>>> M. Ficker wrote:
>>>
>>>> Hello,
>>>> sorry for commenting that patch so late.
>>>>
>>>> I like the idea of making the dependency management more  
>>>> plugable, but
>>>> there is a one thing in the implementation I don't like:
>>>> We end up with a Class called "AbstractBuildTrigger "extending
>>>> Publisher. This Class serves two purposes:
>>>> a) It is a base class for classes that  describe dependencies  
>>>> between
>>>> Projects.
>>>> b) Is is a implementation of Publisher that builds projects based  
>>>> on
>>>> dependencies
>>>>
>>>> I would rather split this in three pieces:
>>>> a) A Interface IDependecyDeclarer with a method
>>>>   protected void buildDependencyGraph(DependencyGraph graph)
>>>>  This methods allows the Interface to declare arbitrary  
>>>> Dependencies
>>>> beetween projects.
>>>>
>>>> b) A class DependencyBuildTrigger extending Publisher
>>>>  This class would trigger Build depending on the dependencies  
>>>> received
>>>> from the Global DependecyGraph
>>>>
>>>> c)  A place to register new Instances of  IDependencyDeclarer.  
>>>> I'm not
>>>> sure where this place should be. It could be a static list in
>>>> BuildStep,  like it's for the Publishers.
>>>>
>>>> Project.buildDependencyGraph would then scan for implementations  
>>>> of the
>>>> new Interface rather than for AbstractBuildTrigger.
>>>> Sine I'm not very deep into Hudson,  perhaps some one else with  
>>>> more
>>>> knowledge should comment this.
>>>>
>>>> I haven't tested WorkspaceFilePath, but it looks good to me.
>>>>
>>>> Best regards,
>>>>
>>>> Martin
>>>>
>>>> Nicolas Lalev??e schrieb:
>>>>
>>>>> Hi,
>>>>>
>>>>> Is that OK if I commit this ?
>>>>>
>>>>> Le dimanche 25 novembre 2007, [hidden email] a ??crit :
>>>>>
>>>>>> https://hudson.dev.java.net/issues/show_bug.cgi?id=1032
>>>>>>
>>>>>>
>>>>>>
>>>>>> User hibou changed the following:
>>>>>>
>>>>>>                What    |Old value                 |New value
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =================================================================
>>>>>> ==== ===== Attachment is patch|                          |
>>>>>> Created an
>>>>>> attachment (id=
>>>>>>
>>>>>>                        |                          |136)
>>>>>>
>>>>>> Improved patch + impr
>>>>>>
>>>>>>                        |                          |oved
>>>>>>                        |                          |  
>>>>>> FormFieldValidator
>>>>>>                        |                          |.Wo
>>>>>>                        |                          |  
>>>>>> rkspaceDirectory
>>>>>>
>>>>>> -----------------------------------------------------------------------
>>>>>> ---- -----
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------- Additional comments from [hidden email] Sun Nov 25  
>>>>>> 18:30:22
>>>>>> +0000 2007 ------- Created an attachment (id=136)
>>>>>> Improved patch + improved FormFieldValidator.WorkspaceDirectory
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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: [Issue 1032] Pluginify the dependency management

Kohsuke Kawaguchi
Administrator

The thing is, the perform method is a mandatory method. In its old
version it used to be an abstract method, so anyone implementing this
before 1.150 must have had the perform(Build) method implemented.

And new code > 1.150 should implement perform(AbstractBuild), and if
that's done this UOE shall never happen.

I think IvyBuildTrigger should implement the empty perform() method.


Nicolas Lalevée wrote:

> Le 4 d?c. 07 ? 22:34, M. Ficker a ?crit :
>
>> Hello,
>>
>> I've finally found the time to have a look at the new plugin. Thanks  
>> to
>> Nicolas and Kohsuke for there work.
>> I've got a  few comments/ideas:
>>
>> 1. The plugin threw an "UnsupportedOperationException" in
>> BuildStepCompatibilityLayer. I've added (in my working copy)
>> a  "perform(AbstractBuild<?, ?> build, Launcher launcher,  
>> BuildListener
>> listener)" (doing nothing) in IvyBuildTrigger to solve this.
>
> I think there is something wrong on the API.
> Kohsuke, some API have been deprecated, but shouldn't be kept working ?
> See the folowing patch :
>
> Index: src/main/java/hudson/tasks/BuildStepCompatibilityLayer.java
> ===================================================================
> RCS file: /cvs/hudson/hudson/main/core/src/main/java/hudson/tasks/
> BuildStepCompatibilityLayer.java,v
> retrieving revision 1.1
> diff -u -r1.1 BuildStepCompatibilityLayer.java
> --- src/main/java/hudson/tasks/BuildStepCompatibilityLayer.java 28 Oct  
> 2007 23:20:01 -0000 1.1
> +++ src/main/java/hudson/tasks/BuildStepCompatibilityLayer.java 5 Dec  
> 2007 20:23:43 -0000
> @@ -57,7 +57,7 @@
>        *      Use {@link #perform(AbstractBuild, Launcher,  
> BuildListener)} instead.
>        */
>       public boolean perform(Build<?,?> build, Launcher launcher,  
> BuildListener listener) throws InterruptedException, IOException {
> -        throw new UnsupportedOperationException();
> +        return true;
>       }


--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]


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

Re: [Issue 1032] Pluginify the dependency management

Nicolas Lalevée-2

Le 6 déc. 07 à 03:51, Kohsuke Kawaguchi a écrit :

>
> The thing is, the perform method is a mandatory method. In its old  
> version it used to be an abstract method, so anyone implementing  
> this before 1.150 must have had the perform(Build) method implemented.
>
> And new code > 1.150 should implement perform(AbstractBuild), and if  
> that's done this UOE shall never happen.
>
> I think IvyBuildTrigger should implement the empty perform() method.

OK thanks.
So fixed and committed.

Nicolas


>
> Nicolas Lalevée wrote:
>> Le 4 d?c. 07 ? 22:34, M. Ficker a ?crit :
>>> Hello,
>>>
>>> I've finally found the time to have a look at the new plugin.  
>>> Thanks  to
>>> Nicolas and Kohsuke for there work.
>>> I've got a  few comments/ideas:
>>>
>>> 1. The plugin threw an "UnsupportedOperationException" in
>>> BuildStepCompatibilityLayer. I've added (in my working copy)
>>> a  "perform(AbstractBuild<?, ?> build, Launcher launcher,    
>>> BuildListener
>>> listener)" (doing nothing) in IvyBuildTrigger to solve this.
>> I think there is something wrong on the API.
>> Kohsuke, some API have been deprecated, but shouldn't be kept  
>> working ?
>> See the folowing patch :
>> Index: src/main/java/hudson/tasks/BuildStepCompatibilityLayer.java
>> ===================================================================
>> RCS file: /cvs/hudson/hudson/main/core/src/main/java/hudson/tasks/  
>> BuildStepCompatibilityLayer.java,v
>> retrieving revision 1.1
>> diff -u -r1.1 BuildStepCompatibilityLayer.java
>> --- src/main/java/hudson/tasks/BuildStepCompatibilityLayer.java 28  
>> Oct  2007 23:20:01 -0000 1.1
>> +++ src/main/java/hudson/tasks/BuildStepCompatibilityLayer.java 5  
>> Dec  2007 20:23:43 -0000
>> @@ -57,7 +57,7 @@
>>    *      Use {@link #perform(AbstractBuild, Launcher,  
>> BuildListener)} instead.
>>    */
>>   public boolean perform(Build<?,?> build, Launcher launcher,  
>> BuildListener listener) throws InterruptedException, IOException {
>> -        throw new UnsupportedOperationException();
>> +        return true;
>>   }
>
>
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems                   [hidden email]
>

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