Re: [jboss-dev] Shared component-matrix

Almost practical example: AS -> EJB3 -> JPA -> Hibernate -> Logging (let's assume the Logging component is jboss-logging for this scenario) Which component(s) compromise the shared base? Carlo Andrew Lee Rubinger wrote: > Back in March, I introduced the idea of a "Shared Component Matrix" to > be the authority over which versions AS would use. > > JIRA - > https://jira.jboss.org/jira/browse/JBAS-5324 > > Forum - > http://www.jboss.com/index.html?module=bb&op=viewtopic&t=131748 > > The intention was for this to be a component scoped outside of the > Application Server such that it could be relied upon by outside > projects. In other words, both AS and jbossas/projects/* could rely > upon the same 3rdparty components. > > The Threads stop and don't explain why it was decided that > component-matrix should live inside AS, therefore ineligible to be > consumed outside due to cyclic dependencies. I believe the reason was > "it makes it easier to tag AS altogether". > > I was opposed to this at the time, and it's still unacceptable. :) > > Concrete example of why: > > The last update to jboss-ejb3-proxy defined a dependency upon > jboss-metadata:1.0.0.CR8. At the time, this was in sync between AS > and ejb3-proxy. > > Over the past few months, AS has updated jboss-metadata, now at > 1.0.0.CR14. The dependency declared in ejb3-proxy is orphaned, and > has stayed constant. > > We've therefore been unit testing ejb3-proxy against stale > jboss-metadata. > > Tonight I go to update in preparation for a GA *RELEASE*, and guess > what? Regression was introduced sometime in the past 4 months, I'm > just seeing it now, and this blocks the whole release process until I > can find and fix this bug. > > Please, let's re-open the discussion about a shared dependency policy. > > S, > ALR > _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development