Ivy fits naturally with Ant, Xslt, Xprocs, and can handle easily graphic resource packages. Our experience reinforces the perception that it blends well in this context.

It certainly adds a some complexity to the build process, as we need to manage additional files and configurations. In some cases, where the number of files or components is small it may not be worth it. There may be cases, where shared resources managed with discipline may be more than enough.

The solution has a learning curve, and the number of training materials are limited.

Even thought, the point where the benefits overcome the initial difficulties can be reached easily. The dependency management helps to maintain the code well structured and organized. Also, since each functionality can be managed in an isolated project, with test data, the code can be easily organized and maintained.

As an advice it is better to consider the adoption design in advance on environments with certain complexity. It is better than make corrections once there are several dependencies and developed projects.

In general, the number of dependencies managed and the benefits from the practice exceeded our initial expectations. It helps to avoid non DRY practices and there’s the tendency to segregate the functionalities. In general, after some initial training it is fairly easy to add more components.

We have increased the initial folder depth (from two levels to three), adding the project name to the exploded folder, as the number of dependencies started to make difficult to trace which file came from which component.

Ivy flexibility is remarkable, we’ve looked for potential problems in during the preparation of the examples or flaws that made this approach not appropriate. All the proposed examples and capabilities worked fine and the integration were easier and faster than expected.