[jboss-dev-forums] [Design of JBoss Build System] - Re: Move dependency management back into app server svn stru
"adrian(a)jboss.org" wrote : "wolfc" wrote : I've got a nice analogy
now: go back to Paul's original post and substitute 'component-matrix' with
'Hibernate' or 'jboss-logging' or any other common component.
| |
| | The arguments presented by Paul will still hold up, yet we do not want these
things in the AS trunk.
|
| That's a logical fallacy, in fact probably a few of them. :-)
So was the theory of Galileo. We're still looking for *our* center of the universe.
:-)
"adrian(a)jboss.org" wrote : I only have to do the exercise proposed to see its
not true.
| anonymous wrote : After spending some time updating dependencies in the HIBERNATE pom
while working on the build-thirdparty conversion, it seems that having ... HIBERNATE as a
separate project is somewhat error prone.
| |
| | The main issue is that whenever I make a change in ... HIBERNATE I have to make
sure that the app server is immediately updated to match, otherwise there are build
errors.
|
| Which plainly isn't true.
|
| There's a big difference between an external project that is included in JBossAS
| as a component and an external project that actually defines what
| those components should be.
Yes it's true. If I do a non-backwards compatible change on a snapshot it all breaks
apart.
"adrian(a)jboss.org" wrote : 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?
Won't happen because here we actually depend on the JTA API. :-D
Security I agree with you, that is currently a mess because we have no *common* SPI. Still
it will always be a common dominator which governs our releases.
The goal of EJB 3 project is to provide both a plugin and a stand-alone which are 100%
compatible (with an independent release-cycle!). So I don't want any other versions
than those of the latest AS.
"adrian(a)jboss.org" wrote : 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.
That is 100% correct and how I want it to be, because EJB 3 is at that point incompatible
with AS 5.0.0.CR2 and must do a refactoring upgrade.
So the AS product, at that point, is not ready for assemblage and waiting for the next EJB
3 release.
I think I've addressed 3.
"ALRubinger" wrote : "adrian(a)jboss.org" wrote : 4) Longer term EJB3
wants to go its own way anyway so shared dependencies aren't even the correct
solution.
|
| Yes, but in the interim, EJB3 requires the AS runtime and component-matrix was built
to ensure that our compile/runtime dependencies would match.
No, we don't. :-)
AS is our primary staging platform and the stand-alone is mostly a facilitator for unit
testing.
"adrian(a)jboss.org" wrote : 5) The correct way to integrate things is via
interfaces NOT implementations.
If you mean public API/SPI then I completely agree with you.
The main problem I see is that AS trunk defines facilitating components which are used by
a lot of projects (not just EJB 3) (dare I mention jboss-as-aspects ;-) ). As Andrew says,
we're just the messengers.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140359#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...