Jorg Heymans wrote:
I think so yes, just wasn't sure. There are 2 sides to the story IMO.
As you say its convenient for us because we have a default centralized
internal versioning scheme for our modules. However our 'customers'
will also end up with these versions, unless they ofcourse override in
their own pom (right Ralph ?).
I'm just thinking if the customer could introduce incompatibilities
between blocks by overriding certain block versions and relying on the
transitivity of others ?
Example:
<root depMgmt>
core-1.0
blockA-1.2
blockB-0.4
</root depMgmt>
now our customer does in his pom
<dependencies>
blockA-1.4 (which transitively pulls in core-1.2)
blockB (no version so he will get 0.4)
</dependencies>
If above scenario is correct and core-1.2 and blockB-0.4 are
incompatible the he's in trouble and will have to explicitly introduce
the new version of blockB. Or am i seeing ghosts ?
First, the root pom is versioned like anything else. So the user will
explicitly choose the version they want and if they extend it then what
you say is true. However, one would expect that if they are going to
explicitly override a version that they would accept the responsibility
for insuring that it is compatible and works. Basically, we are making
a guarantee that all the parts in our root pom play nice together. But
it is impossible to make that guarantee if the user just randomly picks
various blocks and third party components.
As an example, JBoss 4.0.5 comes prepackaged with log4j 1.2.8, but we
have some code that requires 1.2.13. We had to take on the
responsibility of verifying that JBoss would still run with that
version. The same is true of the 2.1 branch. We prepackage all our jars
in the lib directory and everything compiles against them. If I user
chooses to use a different version of one of the jars it is their
responsibility to test it.
Ralph
Ralph
