Advice on component layout & dependency mgmt
Is there any guidance available for structuring source code for a large project (many components)? I would like to have tight control and monitoring of dependencies (more granular than the package level), particularly between jazz components, and without building jar files (just class files that are later collected into bundles). Is 'ivy' the right way to go, or does its repository concept conflict with jazz in some way?
2 answers
The best guidance I can provide is to partition your files/folders into components with the following in mind:
1. You can always move folders between components, so if you get it wrong you can refactor.
2. If you know that you'll want to release, develop, and share a set of files with different projects/teams, then put those in their own Jazz SCM component.
That is pretty much it for guidance. Again, the main point is that you can try different things out as your team grows.
As for Ivy, it should coexists just fine with Jazz SCM (of course I've never used it on a real project before, so I'm just talking from what I've read about Ivy on their website). In fact, you could imagine having an Ivy component repository published into a Jazz Scm Component so that other teams can consume the build artifacts instead of the source.
Jean-Michel Lemieux
Jazz Source Control Team
1. You can always move folders between components, so if you get it wrong you can refactor.
2. If you know that you'll want to release, develop, and share a set of files with different projects/teams, then put those in their own Jazz SCM component.
That is pretty much it for guidance. Again, the main point is that you can try different things out as your team grows.
As for Ivy, it should coexists just fine with Jazz SCM (of course I've never used it on a real project before, so I'm just talking from what I've read about Ivy on their website). In fact, you could imagine having an Ivy component repository published into a Jazz Scm Component so that other teams can consume the build artifacts instead of the source.
Jean-Michel Lemieux
Jazz Source Control Team
WRT moving files/folders between components, note that (unless something
has changed since last time this was discussed) although you can move
files/folders to another component, you cannot apply change sets from
the old component to the new component, so if you subsequently make
changes to those files/folders in a "pre-move" stream, those changes
cannot be applied to the files/folders in their "post-move" location.
Cheers,
Geoff
jlemieux wrote:
has changed since last time this was discussed) although you can move
files/folders to another component, you cannot apply change sets from
the old component to the new component, so if you subsequently make
changes to those files/folders in a "pre-move" stream, those changes
cannot be applied to the files/folders in their "post-move" location.
Cheers,
Geoff
jlemieux wrote:
The best guidance I can provide is to partition your files/folders
into components with the following in mind:
1. You can always move folders between components, so if you get it
wrong you can refactor.
2. If you know that you'll want to release, develop, and share a set
of files with different projects/teams, then put those in their own
Jazz SCM component.
That is pretty much it for guidance. Again, the main point is that you
can try different things out as your team grows.
As for Ivy, it should coexists just fine with Jazz SCM (of course I've
never used it on a real project before, so I'm just talking from what
I've read about Ivy on their website). In fact, you could imagine
having an Ivy component repository published into a Jazz Scm
Component so that other teams can consume the build artifacts instead
of the source.
Jean-Michel Lemieux
Jazz Source Control Team