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

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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

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.

> > 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.

> > 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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>> _______________________________________________ >>>> jboss-development mailing list >>>> jboss-development(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>> >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development >

Exactly, so it doesn't matter which component you choose as a starting point for the shared base. It'll always be the wrong one. Short example: - component-matrix CR1 has EJB 3 CR1 and Logging CR1 - EJB3 goes GA with component-matrix CR1 (there is no GA for that one yet) - component-matrix goes GA with EJB 3 GA and Logging GA - see EJB3 fail (because of some weird change in Logging GA) So in effect AS can't dictate the version of Logging in any way. It can only consume its dependencies and spot inconsistencies, where it not that Maven fails horribly here. Now suppose the version of Logging in all components would be set to: [1.0,1.1). And we add an extra component here: AS -> Web -> Logging Then I would like to see two builds: one with snapshots (continuous integration) and one with released artifacts (latest greatest stable). But this requires two conditions: 1. Snapshot artifacts must be static ( http://jira.codehaus.org/browse/MDEPLOY-77 ) and might be reproducible. 2. All other artifacts (Alpha, Beta, CR, GA) must be static and must be reproducible ( http://jira.codehaus.org/browse/MDEPLOY-82 ). It also requires me to be able to choose whether snapshots can be part of my build. (related: http://jira.codehaus.org/browse/MNG-3092 ) Not to mention the fact that all JBoss version numbers (except JBoss EJB3) are incompatible with Maven. So all in all I think we've reached the end of the line with Maven. Unless someone can think of anything else to try, we should start using a tool that addresses our needs, not the hype. Carlo 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development