[jboss-dev-forums] [Design of JBoss Build System] - Re: Move dependency management back into app server svn stru

[wolfc]

"adrian at 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 at 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 at 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 at 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 at 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 at 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#4140359

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140359