[jboss-dev] Shared component-matrix

[Carlo de Wolf]

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
>