[Design of JBoss Build System] - Re: Move dependency management back into app server svn stru
by adrian＠jboss.org
"wolfc" wrote :
| 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.
Snapshots are worse. I ignored snapshot issues because that's even more broken.
I wanted to give you the benefit of the doubt, I'm talking about sane version control.
anonymous wrote :
| 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.
|
Which part are you not getting?
You can't have an independent release cycle
if you have to synch with the AS and vice versa. They may as well be under the
same version control, at least then non-ejb3 contributors would have some
understanding of whats going on.
To use a bad analogy:
You want to have your cake and eat it. But I (as a none-ejb3 contributor)
am just going to stand on it because I don't know it's there. ;-)
anonymous wrote :
| "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.
|
So we do 10 candidate releases of component matrix between each AS candidate release
one for each thirdparty update that's needed during the development process.
Please don't say snapshots in your reply.
anonymous wrote :
| I think I've addressed 3.
|
Not unless you advocating an "infinite number" of component-matix releases.
anonymous wrote :
| "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.
|
See, you just said EJB3 is NOT really independent. In fact it is, because you
have to satisfy at least two different integration decisions. JBossAS and JBoss Embeded.
There's more if JBoss Embedded really wants to support other platforms.
[qoute]
"adrian(a)jboss.org" wrote : 5) The correct way to integrate things is via interfaces NOT implementations.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140366#4140366
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140366
16 years, 9 months
[Design of JBoss Build System] - Re: Move dependency management back into app server svn stru
by adrian＠jboss.org
"wolfc" wrote :
| 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.
Snapshots are worse. I ignored snapshot issues because that's even more broken.
I wanted to give you the benefit of the doubt, I'm talking about sane version control.
anonymous wrote :
| 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.
|
Which part are you not getting?
You can't have an independent release cycle
if you have to synch with the AS and vice versa. They may as well be under the
same version control, at least then non-ejb3 contributors would have some
understanding of whats going on.
To use a bad analogy:
You want to have your cake and eat it. But I (as a none-ejb3 contributor)
am just going to stand on it because I don't know it's there. ;-)
anonymous wrote :
| "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.
|
So we do 10 candidate releases of component matrix between each AS candidate release
one for each thirdparty update that's needed during the development process.
Please don't say snapshots in your reply.
anonymous wrote :
| I think I've addressed 3.
|
Not unless you advocating an "infinite number" of component-matix releases.
anonymous wrote :
| "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.
|
See, you just said EJB3 is NOT really independent. In fact it is, because you
have to satisfy at least two different integration decisions. JBossAS and JBoss Embeded.
There's more if JBoss Embedded really wants to support other platforms.
anonymous wrote :
| "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=4140363#4140363
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140363
16 years, 9 months
[Design of JBoss Build System] - Re: Move dependency management back into app server svn stru
by wolfc
"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#4140359
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140359
16 years, 9 months
[Design the new POJO MicroContainer] - Circular dependency error msg problem
by scott.stark＠jboss.org
I'm seeing two problems with the IncompleteDeploymentException msg that results when the problem is due to circular references.
1. The processing of AbstractDependencyInfo.resolveDependencies aborts as soon as there is an unresolved dependency. This leaves spurious unresolved dependencies in the missing dependency list.
2. When the IncompleteDeployments.calculateContextsError tries to calculate the underlying context in error by removing contexts with missing dependencies, it ends up claiming one of the spurious dependencies is the cause. If there were no spurious dependencies it would report that there were no contexts in error. It needs to be checking for circular refs to properly report the problem.
Here is an example of the incorrect error msg. Here,
jboss.j2ee:ear=refs-ejb3-ejblink.ear,jar=refs-one-ejb.jar,name=EjbLink1Bean,service=EJB3 depends on:
jboss.j2ee:ear=refs-ejb3-ejblink.ear,jar=refs-one-ejb.jar,name=EjbLink2Bean,service=EJB3 which depends on:
jboss.j2ee:ear=refs-ejb3-ejblink.ear,jar=refs-one-ejb.jar,name=EjbLink1Bean,service=EJB3.
Both also depend on jboss.ejb:service=EJBTimerService, and the *EjbLink2Bean* also depends on jboss.j2ee:ear=refs-ejb3-ejblink.ear,name=EjbLink3Bean,service=EJB3 which is ultimately incorrectly reported to be the root error context.
| org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
|
| *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
|
| jboss.j2ee:ear=refs-ejb3-ejblink.ear,jar=refs-one-ejb.jar,name=EjbLink1Bean,service=EJB3
| -> <UNKNOWN>{Described:** UNRESOLVED Demands 'jboss.j2ee:ear=refs-ejb3-ejblink.ear,jar=refs-two-ejb.jar,name=EjbLink2Bean,service=EJB3 **}
| -> <UNKNOWN>{Described:** UNRESOLVED Demands 'jboss.ejb:service=EJBTimerService **}
|
| jboss.j2ee:ear=refs-ejb3-ejblink.ear,jar=refs-two-ejb.jar,name=EjbLink2Bean,service=EJB3
| -> <UNKNOWN>{Described:** UNRESOLVED Demands 'jboss.j2ee:ear=refs-ejb3-ejblink.ear,jar=refs-one-ejb,name=EjbLink1Bean,service=EJB3 **}
| -> <UNKNOWN>{Described:** UNRESOLVED Demands 'jboss.ejb:service=EJBTimerService **}
| -> <UNKNOWN>{Described:** UNRESOLVED Demands 'jboss.j2ee:ear=refs-ejb3-ejblink.ear,name=EjbLink3Bean,service=EJB3,* **}
|
|
| *** CONTEXTS IN ERROR: Name -> Error
|
| <UNKNOWN> -> ** UNRESOLVED Demands 'jboss.j2ee:ear=refs-ejb3-ejblink.ear,name=EjbLink3Bean,service=EJB3,* **
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140307#4140307
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140307
16 years, 9 months