Skip to end of metadata
Go to start of metadata

Ivy Project Support for Hudson

This feature has now been merged into the main Ivy plugin as of release 1.0

Goal

To create a new Hudson project type with similar functionality to the maven project type. I think it makes sense to add this into the existing Ivy plugin as that is how the maven plugin is packaged (project type, build trigger, etc. all in one plugin).

Requirements (in no particular order)

Requirement #

Description

Issues

Proof of Concept Done

Implementation Complete

1

Able to create a project based on a single module or multiple modules

Ivy has no notion of "parent" modules, so we need some way to specify multiple ivy.xml files

(tick)

(tick)

2

Monitor building of modules

The build uses ant and is not in our control, so we need some way to register and receive events during the build process.

(error)

(error)

3

Provide a viewable list of all modules

Since Ivy has no "parent" module notion, we probably can't do a nice tree-view like in a Maven project

(tick)

(tick)

4

Expose some of the Ivy reports in the UI (I'm not even sure what reports Ivy can do, but if it can generate a dependency graph image or some such thing that'd be cool to see)

 

(error)

(error)

5

Auto-archive each module's ivy.xml file

 

(error)

(error)

6

Auto-detect and auto-archive artifacts

Not sure if Ivy provides any hooks that we can use for this. Even if it did, this would only work if the modules were published. We can't just look at the ivy.xml for the artifacts since it doesn't tell us where to find them.

(error)

(error)

7

Be able to trigger builds from a multi-module ivy build

 

(tick)

(tick)

8

Separate the list of SCM changes for each module

No standard location of ivy.xml file in a module, so no way to figure out the base directory of the module for matching against changed paths.

(tick)

(tick)

Implementation Ideas

Requirement #

Implementation Idea

Issues

1

Provide a field for an ant-style include pattern to scan workspace for module descriptor files (eg. **/ivy.xml)

 

2

Ivy does have some events and triggers which can be extended, but it looks like this is only for pre/post resolve. Maybe this is sufficient to say that a module is building.

 

2

Possible implementation 1

  1. On the first pre-resolve we can start the build progress of that module
  2. On every other pre-resolve we can stop the progress of the previous module and then start the progress of the current module
  3. On the build completion we can stop the progress of the last module

    This should result in every successfully built module showing as blue and any modules that were never built (never triggered an Ivy resolve) showing as grey, just like in the Maven project. If the build fails at a certain point then we can mark the currently building module as red.

This could not handle the case where failures are ignored by the ant build script. Would people do that though?

2

Possible implementation 2

  • Does ant itself provide callbacks for monitoring the process? Being able to monitor the full build of each module would be a lot better.

Even if ant can do this, how would we know when we enter/leave a module build? Ant is too flexible to make any assumptions

2

Implementation which might actually work

  • load an embedded version of Ant from the ant home specified
  • register a custom listener for build events
  • call the specified ant targets on each module's build file and monitor the output

 

3

We have all the ivy descriptors, so we can get all the module names and then ask Ivy to sort them in dependency order. (just a list, not a tree-view)

 

5

This should be easy since we already have the list of ivy.xml files based on the ant include specified in the job config

 

6

Ask for a relative path to the artifacts directory from the ivy.xml file in each module. Then use the artifacts specified in the ivy.xml to match up with these and auto-archive, auto-fingerprint them. If this is possible, then it'd work even if the modules are only built and not published.

Can we assume this will be the same for every module in a project?

6

See if there is a publish-hook in Ivy or if we can add one and then grab the artifacts as they are published.

Wouldn't be able to do anything if the modules were not published.

7

Modify the current Ivy build trigger to take multiple Ivy files into account. When the build finishes, trigger any builds in Hudson with dependent modules. We'd need to take into account every module in the current project as well as every module in every other Hudson project (or maybe just every other Ivy-type project?).

If we only check for triggers amongst the Ivy projects in Hudson, this wouldn't be backwards-compatible. Can we have two different trigger implementations then, one for freestyle projects and one for Ivy projects? And would there be any benefit to doing that?

8

Ask for a relative path to the module basedir from the ivy.xml file, allowing overrides in each module-specific config page if certain modules deviate from this. We should then be able to grab the changes affecting these paths (Is this how the Maven projects figure it out?)

 

8

Alternatively, instead of having an ant pattern for ivy.xml files, we could switch it around and have a pattern for module dirs and a relative path to the ivy.xml file (also overridable per module)

Won't work... we need the ivy.xml files first to generate the modules

  • No labels