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 |
|
|
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. |
|
|
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 |
|
|
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) |
|
|
|
5 |
Auto-archive each module's ivy.xml file |
|
|
|
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. |
|
|
7 |
Be able to trigger builds from a multi-module ivy build |
|
|
|
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. |
|
|
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
|
This could not handle the case where failures are ignored by the ant build script. Would people do that though? |
2 |
Possible implementation 2
|
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
|
|
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 |