I really don't see what the disconnect is here or why it is so hard to understand.
There's an integration project called JBossAS that is used to aggregate
other components. One of those components is EJB3 which isn't an integration project
and therefore shouldn't be making assumptions about what JBossAS will actually use.
You only have to go through a few simple use cases to see it doesn't work.
1) Suppose JBossAS wants to integrate the latest version of the TM but EJB3 doesn't
want to do that. Similarly EJB3 wants to use the latest snapshot of security, but
JBossAS doesn't because its not ready.
How do you define a component-matrix that would satisfy both?
2) Suppose JBossAS/Component Matrix is at 5.0.0.CR1 and wants to update
the security project. It can't change the 5.0.0.CR1 release so it has to do
a new release of Component Matrix (5.0.0.CR2). JBossAS trunk then
changes its parent to 5.0.0.CR2. But EJB3 is still on 5.0.0.CR1
Defeating the whole point.
Of course you could use snapshots, but then why have version control at all
if the only way to move things forward is ignore it?
3) Pauls point. You can't synchronously update a component and do the work
the integrate it in one commit. Of course you can play around with local builds
in your local maven repository, but
* that doesn't really test it works with the real build
* there's a gap between the two commits
* two people can't work on it at the same time - how do you create a branch?
4) Longer term EJB3 wants to go its own way anyway so shared dependencies
aren't even the correct solution.
5) The correct way to integrate things is via interfaces NOT implementations.
In my view EJB3 is just being lazy (can't be bothered creating a version
of EJB3 that isn't so brittle to thirdparty implementation details and versions)
and forcing JBossAS to jump through hoops because of that.
View the original post :
Reply to the post :