Hi, glad to hear you appreciate it

I hadn't actually thought about using the Ivy Projects in that way. For my use, one of our products consists of up to 20 or so different Ivy modules (with different module names) and our various branches contain copies of all these modules. So, we end up having a separate Ivy Project job in Hudson for each branch, which means that within a certain Ivy Project all the module names are unique. I can't remember off the top of my head what the code will end up doing if you have a bunch of modules in the project with identical names, but just different versions. I guess it obviously works, but it's not what I had in mind

Anyway, I'll see what I can do. It should be pretty easy to just add another column to the modules view showing the relative path to the module.

If you wish to use the comment text you have typed (shown below), please copy it now. This text will be lost when you leave this screen.
Hi!

Since the mention in your way you structure your branches, and the thoughts of how to use it, it might not be a good idea to implement it. I think i can live without it.

Thought if you would like to comment on our approach i would like to hear some.

Root (this is the actually product)

Project (Module group)
-trunk
-ivy.xml
– Module1
– Module2
-branches
--1.0.1
-tags

Project2
-trunk
-ivy.xml
– Module1
– Module2
-branches
-tags

At first we probably would like to move down ivy.xml into each module since we want to build these independent.

But to make a long story short,

To be able to build project 1's trunk and branch, i would need to setup in hudson, Project1 Trunk and a Project1 1.0.1.
I don't think that's a big issue, its pretty easily done.

Even thought its off topic. You point with product. What is actually that. An Ivy project, is hard to define by me.
Is that a set or/and a a single ivy module?

I mean, you could have a Product with just one module. And again it goes back to what you call a module.

So the conclusion, i don't think you should do this feature request since it probably inter fear with the original idea of the use!

Also another offtopic, are you using multiple executors in your enviroment? Since before there has been an issue with the builds are not performed in the correct order when using multiple executors, would be nice to know if this works now or not.

Thanks alot.

Ok cool, I'll leave it as-is then.

For an example of how we set up our Ivy branches where i work, you can have a look at this:

https://svn.dev.java.net/svn/hudson/trunk/hudson/plugins/ivy/src/test/resources/example-project/

Username: guest
empty password

Hopefully they still work (just made some changes to them right now to show a better example of a multi-module Ivy branch that ends up creating a final "product" to be released "my-product").

It's quite a simplistic example compared to what we've got set up here, but hopefully it'll be useful. You can ignore the stuff about the custom revision strategies, etc... that's just in there to help me cover some more cases in my plugin release testing.

For those examples, you'd have 3 Ivy Project jobs in Hudson like this: Modules-Trunk-Auto, My-Product-Trunk-Auto, My-Product-1.0-Auto (or whatever you like to name your Hudson jobs like )

cheers,
Timo

Regarding your off-topic question about multiple executors...

We use several Hudson slaves, one per machine, with one executor each (simply because most of our builds are too resource-intensive for our build boxes to handle concurrent builds).

I have tested the Ivy Projects locally with multiple executors though and they worked quite well as I recall. Even if you open the Advanced section of the Ivy Project configuration and check "build modules as separate jobs" it still builds them all in the right order, and it can build several modules in parallel, one per executor on the slave as long as they don't depend on each other.

Resolving as won't fix since this only becomes a problem in non-standard use cases and can be avoided by creating a separate Ivy Project for each branch.