Suggestions for big Client/Server project layout and Ivy setup

Question

Hi all,

I have a reasonably large (thousands of files) project which is divided between client (100% C#) and server (95% Java with a bit of C#).

I have recently introduced Ivy as a test into the server only and it works fine, fetching dependencies and publishing. I could have another ivy config/setup for the client but I should really be publishing the whole server+client together which means there should be one set of Ivy config and one publication step.

I don't see any major roadblocks with using Ivy for the client side, although Ivy is written in Java most of the concepts are general. And I'm happy enough calling nant from ant to do C# builds (MSBuild).

So with that said does anyone have an experience/suggestions for doing the following

• Using Ivy with a multi-language project
• Using Ivy to pull down multi-language dependencies
• Using Ivy to do multi-language publications under a single version

And any examples would be most useful.

Answer 1

Ivy as a generic dependency manager

You're quite correct, ivy is a generic dependency manager that can manage any artifact.

I've previously provided an example of creating an ivy repository using ivy:

http://stackoverflow.com/questions/1200762/good-ivy-tutorial-for-local-repository/2279596#2279596

And here's an example of publishing a zip file to Nexus

http://stackoverflow.com/questions/3662465/its-possible-to-put-binary-files-on-nexus-repository/3676013#3676013

Client and server

My recommendation would be to keep client and server development separated. The client team could have dependencies on libraries produced by the server team, keeping the modules separated allows the teams to work on the latest stable binaries that each published to your repository.

There's nothing stopping you from creating a parent module that has a dependency on both client and server modules.

Repositories

Ivy is great for managing small repos, however I'd recommend considering a full blown repository manager like Nexus, Artifactory or Archiva. This enables the local proxying of jars available from the internet (improving performance and reliability) and also provide interfaces for uploading binaries for storage.

On that final point, it is a not so well known fact that Maven repositories can also store artifacts of any type. Maven module POMs contain an optional "packaging" tag that defaults to "jar", but can be any file extension.

So use the best of both worlds! :-)