Managing Multiple Dependencies
From CitconWiki
Revision as of 05:07, 6 November 2010 by Tumbarumba (talk | contribs) (New page: Ivy * Ant/Java based dependency management tool * Flexible back end artifact repository Maven * Large build/dependency/project managment tool * Fig - on github * Small tool for managin...)
Ivy
- Ant/Java based dependency management tool
- Flexible back end artifact repository
Maven
- Large build/dependency/project managment tool
Fig - on github
- Small tool for managing dependencies
- Able to manage classpath, library path, etc for executable being managed
- Matt G/Chris Read
Gradle
- Build tool
- Build in dependency management (uses Ivy internally)
Versioning/Configuration management
- Have a good policy of how to introduce api changes
- Dependencies should always compile against you
- Chris: there doesn't seem to be any tool that can automatically prevent api breaking changes
Tom D question:
- Module A has some production code, as well as some unit tests, integration tests and scenario tests.
- If there are some useful *testing* utilities, should they be packaged for use externally
- Chris R: generally OK, Consider the test code as a different target environment (e.g. prod vs test)
Is this a design smell?
- module B depends on test code from module A, therefore get module A to publish separate test utility artifact
- comment: break out the test utility into its own module
- however, this will cause a cyclic dependency between B and A test utils
Question:
- How to express dependencies of modules with different languages/artefact types?
- Dependency information should be independent of any specific CI system