If you were logged in you would be able to see more operations.
|
|
|
QuickBuild
Created: 19/Feb/08 09:51 AM
Updated: 19/Feb/08 09:51 AM
|
|
Component/s: |
None
|
Affects Version/s: |
None
|
Fix Version/s: |
None
|
|
Original Estimate:
|
Unknown
|
Remaining Estimate:
|
Unknown
|
Time Spent:
|
Unknown
|
|
We chose IVY to handle our dependencies and publishing of artifacts so that every developer in the company can build with dynamically downloaded dependencies. We are seeing that a lot of automated build tools out there are adding dependency, publishing, and promoting mechanisms. This is great except when you already have IVY as the base build system to handle all of that. We don't want to implement those features twice, once with IVY for the standalong developer and once for QB for automated (nightly, continuous) builds. Therefore, it would be nice if QB2.0 would more tightly integrate with IVY by somehow handling the following issues:
1. build numbers: IVY generates a build number based on what is out in its repository of dependencies. QB generates a build number based on its own criteria. It would be confusing if a given QB build with one number has artifacts from an IVY build which uses a different number. They should be the same. I have solved this problem with the current version of QB by making QB send its build number to my IVY build scripts through env variable. It seems to work fine.
2. dependency management consolidation: IVY whole purpose in life is to manage dependencies so having QB not utilize that seems like a waste. Sure QB can have dependency management for those that don't use IVY underneath, but for those that do, it would be nice for QB to delegate to IVY when handling dependencies.
3. repository management consolidation: IVY has a concept of a repository which stores all of the artifacts from all published modules to later be retrieved when looking for dependencies. QB has a concept of publishing artifacts accessible from the QB web app. It would be nice for both repositories to be one in the same so that the QB web site can retrieve artifacts from the same repository that IVY retrieves dependencies. Otherwise, we have duplicate storage for both repos.
|
Description
|
We chose IVY to handle our dependencies and publishing of artifacts so that every developer in the company can build with dynamically downloaded dependencies. We are seeing that a lot of automated build tools out there are adding dependency, publishing, and promoting mechanisms. This is great except when you already have IVY as the base build system to handle all of that. We don't want to implement those features twice, once with IVY for the standalong developer and once for QB for automated (nightly, continuous) builds. Therefore, it would be nice if QB2.0 would more tightly integrate with IVY by somehow handling the following issues:
1. build numbers: IVY generates a build number based on what is out in its repository of dependencies. QB generates a build number based on its own criteria. It would be confusing if a given QB build with one number has artifacts from an IVY build which uses a different number. They should be the same. I have solved this problem with the current version of QB by making QB send its build number to my IVY build scripts through env variable. It seems to work fine.
2. dependency management consolidation: IVY whole purpose in life is to manage dependencies so having QB not utilize that seems like a waste. Sure QB can have dependency management for those that don't use IVY underneath, but for those that do, it would be nice for QB to delegate to IVY when handling dependencies.
3. repository management consolidation: IVY has a concept of a repository which stores all of the artifacts from all published modules to later be retrieved when looking for dependencies. QB has a concept of publishing artifacts accessible from the QB web app. It would be nice for both repositories to be one in the same so that the QB web site can retrieve artifacts from the same repository that IVY retrieves dependencies. Otherwise, we have duplicate storage for both repos. |
Show » |
There are no entries against this issue.
|
|