Difference between revisions of "Managing Multiple Dependencies"
From CitconWiki
Jump to navigationJump to searchTumbarumba (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...) |
Tumbarumba (talk | contribs) |
||
Line 1: | Line 1: | ||
− | |||
Ivy | Ivy | ||
* Ant/Java based dependency management tool | * Ant/Java based dependency management tool | ||
Line 6: | Line 5: | ||
Maven | Maven | ||
* Large build/dependency/project managment tool | * Large build/dependency/project managment tool | ||
− | * | + | * Does much more than dependency management, which can make it overkill if that's all you want |
− | Fig | + | Fig |
+ | * Can be found on github | ||
* Small tool for managing dependencies | * Small tool for managing dependencies | ||
* Able to manage classpath, library path, etc for executable being managed | * Able to manage classpath, library path, etc for executable being managed | ||
− | * Matt | + | * Matt Foemmel (original co-author of Continuous Integration paper)/Chris Read |
Gradle | Gradle | ||
* Build tool | * Build tool | ||
* Build in dependency management (uses Ivy internally) | * Build in dependency management (uses Ivy internally) | ||
− | |||
Versioning/Configuration management | Versioning/Configuration management | ||
Line 36: | Line 35: | ||
* How to express dependencies of modules with different languages/artefact types? | * How to express dependencies of modules with different languages/artefact types? | ||
* Dependency information should be independent of any specific CI system | * Dependency information should be independent of any specific CI system | ||
+ | * Ivy or Fig look like good candidates for these problems |
Latest revision as of 03:16, 1 December 2010
Ivy
- Ant/Java based dependency management tool
- Flexible back end artifact repository
Maven
- Large build/dependency/project managment tool
- Does much more than dependency management, which can make it overkill if that's all you want
Fig
- Can be found on github
- Small tool for managing dependencies
- Able to manage classpath, library path, etc for executable being managed
- Matt Foemmel (original co-author of Continuous Integration paper)/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
- Ivy or Fig look like good candidates for these problems