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