[jboss-dev] Shared component-matrix

Paul Gier pgier at redhat.com
Fri Jan 23 10:37:49 EST 2009 

Dimitris Andreadis wrote:
> Paul Gier wrote:
>> The way I imagine it would work kind of like this.
>>
>> The component-matrix would be set with each component version that 
>> will be used in the app server target release (and not with the latest 
>> release, alpha, beta, etc), even if those component releases don't 
>> exist yet.  So for example we could release a component-matrix version 
>> 5.0.1.GA that contains all the GA releases of the components that will 
>> be available when the GA of the app server is ready.
> 
> I don't see how this solves the problem. First, in many cases the target 
> version of a component for inclusion in the AS changes (e.g. initial 
> plan says JBxxx 1.2.3 but then we go with 1.2.4.SP1), second everyone 
> will have to specify the intermediate JBxxx versions and then remember 
> to un-specify them so the default takes over.

We could do something like release 5.0.0.GA-1 of the component matrix, and then 
if there are changes along the way release component-matrix 5.0.0.GA-2.  But I 
don't know if it makes things any easier.  I was just trying to think about how 
the component-matrix could work if separated from the AS build.

You're right component projects would also have to remember to remove the 
versions from their poms before doing a release.

>>
>> It's not a true cyclic dependency because in the component matrix, the 
>> dependencies are just listed in depManagement, so they are just 
>> default/suggested versions.  So the maven release plugin shouldn't 
>> have any problem allowing this to be released.  Each component project 
>> like would have to override any non-existent version numbers until 
>> they are actually released.
>>
>> Can you give me more details about the plugin that you are thinking 
>> about?  So it would just read the pom at the URL and then tell you if 
>> there are versions in your tree that differ from the one at the URL?
> 
> Exactly! It would have to answer the question which of my overlapping 
> dependencies with that other project are over a different version. And 
> if this plugin runs by default, you'll know real soon when your 
> dependencies start to divert so you can fix it.
> 

I created a jira issue to keep track of this:
http://jira.jboss.org/jira/browse/JBBUILD-512

>>
>> Dimitris Andreadis wrote:
>>> It's only ejb3 that would want to sync dependencies with AS but the 
>>> other projects too (aop, metadata, naming, mc, ws, ...) in which case 
>>> sooner or later we'll have a cyclical dependency issue: i.e. you'd 
>>> have to decide which are "leaf" projects and which are "higher" level 
>>> projects sharing the component-matrix.
>>>
>>> Why not write a custom plugin that you would configure with a URL of 
>>> a pom.xml 
>>> (http://anonsvn.jboss.org/repos/jbossas/trunk/component-matrix/pom.xml) 
>>> and at build time it would flag conflicting dependencies? You would 
>>> then decide whether to manually update a dependency or not.
>>>
>>> Paul Gier wrote:
>>>> I think the reason we moved it back into AS was because of the 
>>>> circular dependencies.  So if EJB3 uses version 5.1 of the component 
>>>> matrix and the component matrix points to version 1.0 GA of EJB3, 
>>>> which one gets released first?  Also, the component matrix doesn't 
>>>> work well as a snapshot, because if you make a groupId or 
>>>> componentId change it breaks the build.
>>>>
>>>> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=132452
>>>>
>>>> But I think it could still work even if separated from the app 
>>>> server.  But we'll have to release it pretty often and probably only 
>>>> use snapshot versions of it locally.
>>>>
>>>> Maven won't download all the dependencies as long as we keep them in 
>>>> <dependencyManagement> like they are now.  Maven will only download 
>>>> the dependencies listed in <dependencies> and all the trasitive deps 
>>>> in the tree.
>>>>
>>>>
>>>>
>>>> Dimitris Andreadis wrote:
>>>>> A very practical problem is if you move component-matrix out of AS, 
>>>>> you need to tag a new version of it with every change, and this 
>>>>> file changes quite often.
>>>>>
>>>>> Then every project that depends on it, will download all the 
>>>>> dependencies, even if it's not using them (I think that's how maven 
>>>>> works).
>>>>>
>>>>> Carlo de Wolf wrote:
>>>>>> 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 at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>> _______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>

More information about the jboss-development mailing list