"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#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...