Found the bug (svn:externals / modules)

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

Found the bug (svn:externals / modules)

Nigel Magnay
I've found why my project doesn't build as expected.

Our project layout has a root-level pom file (describing a particular module configuration), that declares modules underneath it to be built.

Each of the modules are included in the directory structure by an svn:external definition in the directory.

Each of the modules has a parent that is NOT the root-level pom, but that of a corporate pom (this is a common m2 build structure).

When the project is examined by hudson, it reports that the root-level pom has no downstream projects (and therefore when the build is started from a detected change, very little happens).

I can't add a dependency between a module and the root-pom because there are many root-level poms with different build configurations (and there is no such dependency). I think hudson needs to add these child modules as build dependencies.


Reply | Threaded
Open this post in threaded view
|

Re: Found the bug (svn:externals / modules)

Kohsuke Kawaguchi
Administrator
2007/4/18, Nigel Magnay <[hidden email]>:

> I've found why my project doesn't build as expected.
>
> Our project layout has a root-level pom file (describing a particular module
> configuration), that declares modules underneath it to be built.
>
> Each of the modules are included in the directory structure by an
> svn:external definition in the directory.
>
> Each of the modules has a parent that is NOT the root-level pom, but that of
> a corporate pom (this is a common m2 build structure).
>
> When the project is examined by hudson, it reports that the root-level pom
> has no downstream projects (and therefore when the build is started from a
> detected change, very little happens).

Ah! Good catch. Yes, please file an issue.

--
Kohsuke Kawaguchi

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

Reply | Threaded
Open this post in threaded view
|

Re: Found the bug (svn:externals / modules)

Nigel Magnay
Filed as #485.
I'm seeing odd builds if I add a dependency from some modules to the root-level pom (it discards some downstream builds because it believes there is a longer dependency path - which there is, but it never gets there, which I think is just a byproduct of the same issue)

On 18/04/07, Kohsuke Kawaguchi <[hidden email]> wrote:
2007/4/18, Nigel Magnay <[hidden email]>:

> I've found why my project doesn't build as expected.
>
> Our project layout has a root-level pom file (describing a particular module
> configuration), that declares modules underneath it to be built.
>
> Each of the modules are included in the directory structure by an
> svn:external definition in the directory.
>
> Each of the modules has a parent that is NOT the root-level pom, but that of
> a corporate pom (this is a common m2 build structure).
>
> When the project is examined by hudson, it reports that the root-level pom
> has no downstream projects (and therefore when the build is started from a
> detected change, very little happens).

Ah! Good catch. Yes, please file an issue.

--
Kohsuke Kawaguchi

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


Reply | Threaded
Open this post in threaded view
|

Re: Found the bug (svn:externals / modules)

Nigel Magnay
I installed the snapshot Hudson ver. 1.104-SNAPSHOT (private-04/18/2007 11:46-hudson) today; it now picks up the projects in order to be built, but there's something wrong with the ordering & prioritisation.

My top level project has 5 modules, which hudson correctly detects. However, the Downstream Builds list isn't right :

I don't know how this relates to the build order, but with 1 executor, "KES Integration Tests" is being built in the wrong order - about half way into the build. KES Integration Tests must be last because it has dependencies on a child of "Workflow Guide".

a straight "mvn install" from the root gives the reactor list.


[INFO] Reactor build order:
[INFO]   Common Modules
[INFO]   Common Utilities
[INFO]   Common Services
[INFO]   Common Messages
[INFO]   Message Builder
[INFO]   KES Messages
[INFO]   Ant Tasks
[INFO]   Maven MOJOs
[INFO]   SafeHarbour Server Monitoring and Configuration Tool
[INFO]   ServerMonitor Core
[INFO]   SafeHarbour Web Application
[INFO]   SafeHarbour Command Line Tool
[INFO]   SafeHarbour Server
[INFO]   ServerMonitor Core
[INFO]   SafeHarbour Bootstrapper
[INFO]   Knowledge Engineering System
[INFO]   KES Modules
[INFO]   KMS Model
[INFO]   KMS Application Programming Interface
[INFO]   KMS Help Module
[INFO]   KMS Core Platform Implementation
[INFO]   KMS Services
[INFO]   KMS Application Code
[INFO]   KMS Application User Interface
[INFO]   KMS Workflow Core
[INFO]   KMS Workflow User Interface
[INFO]   KMS Applications
[INFO]   KMS Deployable Application (WAR)
[INFO]   KMS Config for SafeHarbour
[INFO]   SafeHarbour Configurators for KMS
[INFO]   KMS Configuration User Interface
[INFO]   KES Databases
[INFO]   HSQLDB database
[INFO]   Oracle database
[INFO]   SQL*Server database
[INFO]   KES Installer
[INFO]   KES Installation package
[INFO]   KMS Test Project
[INFO]   KMS Build Settings
[INFO]   KES Sample Publication - Workflow Guide
[INFO]   Workflow Guide - Content
[INFO]   Workflow Guide - Installer Package
[INFO]   Workflow Guide - Config
[INFO]   KES Integration Tests
[INFO]   Top Level Knowledge Engineering System Build

On 18/04/07, Nigel Magnay <[hidden email]> wrote:
Filed as #485.
I'm seeing odd builds if I add a dependency from some modules to the root-level pom (it discards some downstream builds because it believes there is a longer dependency path - which there is, but it never gets there, which I think is just a byproduct of the same issue)


On 18/04/07, Kohsuke Kawaguchi <[hidden email]> wrote:
2007/4/18, Nigel Magnay <[hidden email]>:

> I've found why my project doesn't build as expected.
>
> Our project layout has a root-level pom file (describing a particular module
> configuration), that declares modules underneath it to be built.
>
> Each of the modules are included in the directory structure by an
> svn:external definition in the directory.
>
> Each of the modules has a parent that is NOT the root-level pom, but that of
> a corporate pom (this is a common m2 build structure).
>
> When the project is examined by hudson, it reports that the root-level pom
> has no downstream projects (and therefore when the build is started from a
> detected change, very little happens).

Ah! Good catch. Yes, please file an issue.

--
Kohsuke Kawaguchi

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



Reply | Threaded
Open this post in threaded view
|

Re: Found the bug (svn:externals / modules)

Kohsuke Kawaguchi
Administrator
This list is not really following the build order, although it probably should.

So I suspect Hudson is building things in the right order --- we just
need to fix up the UI.

Could you file an issue for this?

2007/4/19, Nigel Magnay <[hidden email]>:

> I installed the snapshot Hudson ver. 1.104-SNAPSHOT (private-04/18/2007
> 11:46-hudson) today; it now picks up the projects in order to be built, but
> there's something wrong with the ordering & prioritisation.
>
> My top level project has 5 modules, which hudson correctly detects. However,
> the Downstream Builds list isn't right :
>
>
> SafeHarbour Server Monitoring and Configuration Tool (none)
> Knowledge Engineering System (none)
> KES Integration Tests (none)
> Common Modules (none)
> KES Sample Publication - Workflow Guide (none) I don't know how this relates
> to the build order, but with 1 executor, "KES Integration Tests" is being
> built in the wrong order - about half way into the build. KES Integration
> Tests must be last because it has dependencies on a child of "Workflow
> Guide".
>
> a straight "mvn install" from the root gives the reactor list.
>
>
> [INFO] Reactor build order:
> [INFO]   Common Modules
> [INFO]   Common Utilities
> [INFO]   Common Services
> [INFO]   Common Messages
> [INFO]   Message Builder
> [INFO]   KES Messages
> [INFO]   Ant Tasks
> [INFO]   Maven MOJOs
> [INFO]   SafeHarbour Server Monitoring and Configuration Tool
> [INFO]   ServerMonitor Core
> [INFO]   SafeHarbour Web Application
> [INFO]   SafeHarbour Command Line Tool
> [INFO]   SafeHarbour Server
> [INFO]   ServerMonitor Core
> [INFO]   SafeHarbour Bootstrapper
> [INFO]   Knowledge Engineering System
> [INFO]   KES Modules
> [INFO]   KMS Model
> [INFO]   KMS Application Programming Interface
> [INFO]   KMS Help Module
> [INFO]   KMS Core Platform Implementation
> [INFO]   KMS Services
> [INFO]   KMS Application Code
> [INFO]   KMS Application User Interface
> [INFO]   KMS Workflow Core
> [INFO]   KMS Workflow User Interface
> [INFO]   KMS Applications
> [INFO]   KMS Deployable Application (WAR)
> [INFO]   KMS Config for SafeHarbour
> [INFO]   SafeHarbour Configurators for KMS
> [INFO]   KMS Configuration User Interface
> [INFO]   KES Databases
> [INFO]   HSQLDB database
> [INFO]   Oracle database
> [INFO]   SQL*Server database
> [INFO]   KES Installer
> [INFO]   KES Installation package
> [INFO]   KMS Test Project
> [INFO]   KMS Build Settings
> [INFO]   KES Sample Publication - Workflow Guide
> [INFO]   Workflow Guide - Content
> [INFO]   Workflow Guide - Installer Package
> [INFO]   Workflow Guide - Config
> [INFO]   KES Integration Tests
> [INFO]   Top Level Knowledge Engineering System Build
>
>
> On 18/04/07, Nigel Magnay < [hidden email]> wrote:
> > Filed as #485.
> > I'm seeing odd builds if I add a dependency from some modules to the
> root-level pom (it discards some downstream builds because it believes there
> is a longer dependency path - which there is, but it never gets there, which
> I think is just a byproduct of the same issue)
> >
> >
> >
> > On 18/04/07, Kohsuke Kawaguchi < [hidden email]> wrote:
> > > 2007/4/18, Nigel Magnay <[hidden email]>:
> > > > I've found why my project doesn't build as expected.
> > > >
> > > > Our project layout has a root-level pom file (describing a particular
> module
> > > > configuration), that declares modules underneath it to be built.
> > > >
> > > > Each of the modules are included in the directory structure by an
> > > > svn:external definition in the directory.
> > > >
> > > > Each of the modules has a parent that is NOT the root-level pom, but
> that of
> > > > a corporate pom (this is a common m2 build structure).
> > > >
> > > > When the project is examined by hudson, it reports that the root-level
> pom
> > > > has no downstream projects (and therefore when the build is started
> from a
> > > > detected change, very little happens).
> > >
> > > Ah! Good catch. Yes, please file an issue.
> > >
> > > --
> > > Kohsuke Kawaguchi
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> >
>
>


--
Kohsuke Kawaguchi

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

Reply | Threaded
Open this post in threaded view
|

Re: Found the bug (svn:externals / modules)

Kohsuke Kawaguchi
Administrator
Maybe I wasn't very clear.

What I meant was that the order of builds and the order in which
builds are listed in the UI are independent right now.

2007/4/25, Kohsuke Kawaguchi <[hidden email]>:

> This list is not really following the build order, although it probably should.
>
> So I suspect Hudson is building things in the right order --- we just
> need to fix up the UI.
>
> Could you file an issue for this?
>
> 2007/4/19, Nigel Magnay <[hidden email]>:
> > I installed the snapshot Hudson ver. 1.104-SNAPSHOT (private-04/18/2007
> > 11:46-hudson) today; it now picks up the projects in order to be built, but
> > there's something wrong with the ordering & prioritisation.
> >
> > My top level project has 5 modules, which hudson correctly detects. However,
> > the Downstream Builds list isn't right :
> >
> >
> > SafeHarbour Server Monitoring and Configuration Tool (none)
> > Knowledge Engineering System (none)
> > KES Integration Tests (none)
> > Common Modules (none)
> > KES Sample Publication - Workflow Guide (none) I don't know how this relates
> > to the build order, but with 1 executor, "KES Integration Tests" is being
> > built in the wrong order - about half way into the build. KES Integration
> > Tests must be last because it has dependencies on a child of "Workflow
> > Guide".
> >
> > a straight "mvn install" from the root gives the reactor list.
> >
> >
> > [INFO] Reactor build order:
> > [INFO]   Common Modules
> > [INFO]   Common Utilities
> > [INFO]   Common Services
> > [INFO]   Common Messages
> > [INFO]   Message Builder
> > [INFO]   KES Messages
> > [INFO]   Ant Tasks
> > [INFO]   Maven MOJOs
> > [INFO]   SafeHarbour Server Monitoring and Configuration Tool
> > [INFO]   ServerMonitor Core
> > [INFO]   SafeHarbour Web Application
> > [INFO]   SafeHarbour Command Line Tool
> > [INFO]   SafeHarbour Server
> > [INFO]   ServerMonitor Core
> > [INFO]   SafeHarbour Bootstrapper
> > [INFO]   Knowledge Engineering System
> > [INFO]   KES Modules
> > [INFO]   KMS Model
> > [INFO]   KMS Application Programming Interface
> > [INFO]   KMS Help Module
> > [INFO]   KMS Core Platform Implementation
> > [INFO]   KMS Services
> > [INFO]   KMS Application Code
> > [INFO]   KMS Application User Interface
> > [INFO]   KMS Workflow Core
> > [INFO]   KMS Workflow User Interface
> > [INFO]   KMS Applications
> > [INFO]   KMS Deployable Application (WAR)
> > [INFO]   KMS Config for SafeHarbour
> > [INFO]   SafeHarbour Configurators for KMS
> > [INFO]   KMS Configuration User Interface
> > [INFO]   KES Databases
> > [INFO]   HSQLDB database
> > [INFO]   Oracle database
> > [INFO]   SQL*Server database
> > [INFO]   KES Installer
> > [INFO]   KES Installation package
> > [INFO]   KMS Test Project
> > [INFO]   KMS Build Settings
> > [INFO]   KES Sample Publication - Workflow Guide
> > [INFO]   Workflow Guide - Content
> > [INFO]   Workflow Guide - Installer Package
> > [INFO]   Workflow Guide - Config
> > [INFO]   KES Integration Tests
> > [INFO]   Top Level Knowledge Engineering System Build
> >
> >
> > On 18/04/07, Nigel Magnay < [hidden email]> wrote:
> > > Filed as #485.
> > > I'm seeing odd builds if I add a dependency from some modules to the
> > root-level pom (it discards some downstream builds because it believes there
> > is a longer dependency path - which there is, but it never gets there, which
> > I think is just a byproduct of the same issue)
> > >
> > >
> > >
> > > On 18/04/07, Kohsuke Kawaguchi < [hidden email]> wrote:
> > > > 2007/4/18, Nigel Magnay <[hidden email]>:
> > > > > I've found why my project doesn't build as expected.
> > > > >
> > > > > Our project layout has a root-level pom file (describing a particular
> > module
> > > > > configuration), that declares modules underneath it to be built.
> > > > >
> > > > > Each of the modules are included in the directory structure by an
> > > > > svn:external definition in the directory.
> > > > >
> > > > > Each of the modules has a parent that is NOT the root-level pom, but
> > that of
> > > > > a corporate pom (this is a common m2 build structure).
> > > > >
> > > > > When the project is examined by hudson, it reports that the root-level
> > pom
> > > > > has no downstream projects (and therefore when the build is started
> > from a
> > > > > detected change, very little happens).
> > > >
> > > > Ah! Good catch. Yes, please file an issue.
> > > >
> > > > --
> > > > Kohsuke Kawaguchi
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
> > >
> > >
> >
> >
>
>
> --
> Kohsuke Kawaguchi
>


--
Kohsuke Kawaguchi

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