I just released the wildfly agent (0.13.7.Final) and I just realized I may not have moved things up to the latest releases of its dependencies. It would be really nice now if we had something (even if its just versions in the parent pom) that defines the latest releases that components should be using because right now, how many of our pom.xml files have things like this: <version.org.hawkular.accounts>1.1.1.Final</version.org.hawkular.accounts> <version.org.hawkular.bus>0.7.3.Final</version.org.hawkular.bus> <version.org.hawkular.cmdgw>0.10.4.Final</version.org.hawkular.cmdgw> <version.org.hawkular.commons>0.2.3.Final</version.org.hawkular.commons> <version.org.hawkular.inventory>0.9.0.Final</version.org.hawkular.inventory> <version.org.hawkular.metrics>0.10.0.Final</version.org.hawkular.metrics>

It would be nice if we aren't required to set these (but we could override them, right? if we want to try out a different version than what the parent pom defines). This would make releasing easier. We just comment out all the <version...> entries in all our pom.xml files (if they are there at all), thus falling back to what the parent-pom has defined. Or maybe we build a bom?? I dunno - all I know is, there is going to come a time when something breaks because "uh-oh, this component built on version x.y.z of metrics, but THIS component built on version a.b.c of metrics". _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

To avoid improper deps, I have no better idea than opening the components dependency graph [1] before releasing and asking the colleagues working on components I depend on, whether they have (or plant to release) something new. @all Please make sure that the deps in the graph are correct so that components you depend upon know that you might be interested in their updates.

On 2015-12-15 17:11, Peter Palaga wrote: > Hi Mazz, inline... > > On 2015-12-15 16:12, John Mazzitelli wrote: >> I just released the wildfly agent (0.13.7.Final) and I just realized I may >> not have moved things up to the latest releases of its dependencies. To avoid improper deps, I have no better idea than opening the components dependency graph [1] before releasing and asking the colleagues working on components I depend on, whether they have (or plant to release) something new. @all Please make sure that the deps in the graph are correct so that components you depend upon know that you might be interested in their updates. The the source of the graph lives in [2] [1] http://www.hawkular.org/docs/dev/development.html#component-dependencies [2] https://github.com/hawkular/hawkular.github.io/blob/pages/src/main/manual... -- P >> >> It would be really nice now if we had something (even if its just versions >> in the parent pom) that defines the latest releases that components >> should be using because right now, how many of our pom.xml files have >> things like this: >> >> <version.org.hawkular.accounts>1.1.1.Final</version.org.hawkular.accounts> >> <version.org.hawkular.bus>0.7.3.Final</version.org.hawkular.bus> >> <version.org.hawkular.cmdgw>0.10.4.Final</version.org.hawkular.cmdgw> >> <version.org.hawkular.commons>0.2.3.Final</version.org.hawkular.commons> >> <version.org.hawkular.inventory>0.9.0.Final</version.org.hawkular.inventory> >> <version.org.hawkular.metrics>0.10.0.Final</version.org.hawkular.metrics> > > Yes, every component in Hawkular has such a section of > version.org.hawkular.* properties, but in each of the components the > list is different, containing only the direct dependencies and nothing > else. > I cannot imagine how *all* these componets props could live in a single > pom (hawkular-parent or a separate hawkular-bom) - such a BoM would > inevitably bring circular dependency to most of places where it would be > used. > > Say, the BoM version 0.0.1 would contain exactly the versions you listed > above. Now, I want to use the BoM version 0.0.1 in Inventory, so that I > do not have to maintain commons and accounts. What do I do? I'll import > dependencyManagement/dependency/BoM version 0.0.1. But then I have > released Inventory 0.9.1.Final and I need to upgrade the prop in the > BoM, release BoM and ehm... upgrade the BoM version in Inventory and so on? > > Maybe I misunderstood your idea? > > -- P > >> It would be nice if we aren't required to set these (but we could override >> them, right? if we want to try out a different version than what the >> parent pom defines). >> >> This would make releasing easier. We just comment out all the <version...> >> entries in all our pom.xml files (if they are there at all), thus falling >> back to what the parent-pom has defined. Or maybe we build a bom?? I >> dunno - all I know is, there is going to come a time when something >> breaks because "uh-oh, this component built on version x.y.z of metrics, >> but THIS component built on version a.b.c of metrics". >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

[this is a long email - the summary of it is - we need to stop allowing individual components (agent, inventory, alerts, etc) to release with their own set of version properties defined in their pom.xml files - we need to pick up a common set of version properties from parent pom. Otherwise, we are forced to manually go through some dependency document (that may or may not be up to date) so we know which version properties in which pom.xml files to manually update so they are all the same value. We already have parent-pom that can do this kind of thing for us. Here's the long email:] > To avoid improper deps, I have no better idea than opening the > components dependency graph [1] before releasing and asking the > colleagues working on components I depend on, whether they have (or > plant to release) something new. > > @all Please make sure that the deps in the graph are correct so that > components you depend upon know that you might be interested in their updates. There has to be a better way than this. Forget a BOM for the moment, and consider this idea: In parent-pom, we already have a <properties> section with all our third party lib versions defined: https://github.com/hawkular/hawkular-parent-pom/blob/master/pom.xml#L231-... Can't we have a list of all our hawkular component versions in here too? Set them to the last stable release versions. For example, we could say, "These version properties in parent-pom define the latest versions (.Final or srcdeps) that we know the hawkular dist build (aka kettle) needs and therefore all components should be using": <version.org.hawkular.accounts>... <version.org.hawkular.agent>... <version.org.hawkular.alerts>... <version.org.hawkular.bus>... <version.org.hawkular.cmdgw>... <version.org.hawkular.commons>... <version.org.hawkular.inventory>... <version.org.hawkular.metrics>... ...and the rest... Now, notice this doesn't mean every hawkular component is pulling in EVERY other component as a dependency. This is just defining version properties, that's all (just like every other version property in here). It is up to the individual components to define their <dependencies> as usual, but now they don't have to hardcode all their version properties in their poms, they can just fallback to using the properties as found in parent-pom and just make sure their parent-pom version is the latest. So, for example, the wildfly agent pom.xml already has this: <dependency> <groupId>org.hawkular.inventory</groupId> <artifactId>hawkular-inventory-json-helper</artifactId> <version>${version.org.hawkular.inventory}</version> </dependency> <dependency> <groupId>org.hawkular.metrics</groupId> <artifactId>hawkular-metrics-clients-common</artifactId> <version>${version.org.hawkular.metrics}</version> </dependency> .... and the rest of my hawkualr deps, like accounts, bus, etc... The difference is now my agent doesn't have to define those properties - I'll just use what parent pom has. I can delete all the <version.org.hawkular...> properties defined in the agent pom. Alerts can do the same thing - in their pom, they don't define ${version.org.hawkular.bus} and all the rest, they just use what parent-pom defines. If agent and alerts are on the same parent pom, we immediately know they are using all the same hawkular component versions as well. Now the only thing we have to update across all components is just the parent pom version. Each component should be on the same parent-pom before we do a full hawkular release. No need to ask people to keep some dependency document up to date, no need to manually go through that dependency document (that may or may not be up to date) in order to know what to change in what component. Just make sure everyone is on the same parent pom and we will know everyone is using the same accounts, alerts, inventory, metrics, blah blah blah. During development time, if a component DOES want to use a different version, they can still define their own version properties in their own pom.xml temporarily, but this should be rare. Most times, all of us should be using the SAME stable release across all components ("stable release" could be a srcdep if we want) and that is what parent pom defines for us. In short, we should all be using the same versions unless during development we need a different version. But how do we ensure everyone is using the same version? Rely on parent-pom. The only thing we should then have to worry about when we release is everyone is using the same parent-pom (with the assumption no component is overriding the version properties; if they are, they need to comment them out before releasing). Personally, I think it is a major problem that we are all releasing our components individually with no way to ensure we are all releasing with the same component dependencies. We've all got <version.org.hawkular...> properties defined in all our pom.xmls, and they are all wildly different sometimes (this one is using srcdep, this one is using 1.Final, this one 2.Final, etc...) And when we go to release, someone has to go to every pom.xml and look at every <version.org.hawkular...> and make sure they are the same. Of course, all the time prior to that, we've been testing with old versions, mixed versions (agent is using inventory a.b.c, alerts is using x.y.x) and once we move to the new ones, we hit failures we weren't expecting (and you know this always happens the day before we do a major Hawkular release :) Instead, I say we rely more on parent-pom. If we all say, "Move to parent pom 27" - that's a one line change in our poms, and once we do we immediately know we are all on the same versions for all components. Don't want to move to 27 yet? Fall back to 26 and pick up the previous stuff. Want to override a particular component during development, pass in -Dversion.org.hawkular... or set that temporarily in your pom.xml file. ----- Original Message ----- > On 2015-12-15 17:11, Peter Palaga wrote: >> Hi Mazz, inline... >> >> On 2015-12-15 16:12, John Mazzitelli wrote: >>> I just released the wildfly agent (0.13.7.Final) and I just realized I may >>> not have moved things up to the latest releases of its dependencies. > > To avoid improper deps, I have no better idea than opening the > components dependency graph [1] before releasing and asking the > colleagues working on components I depend on, whether they have (or > plant to release) something new. > > @all Please make sure that the deps in the graph are correct so that > components you depend upon know that you might be interested in their > updates. The the source of the graph lives in [2] > > [1] http://www.hawkular.org/docs/dev/development.html#component-dependencies > [2] > https://github.com/hawkular/hawkular.github.io/blob/pages/src/main/manual... > > -- P > >>> >>> It would be really nice now if we had something (even if its just versions >>> in the parent pom) that defines the latest releases that components >>> should be using because right now, how many of our pom.xml files have >>> things like this: >>> >>> <version.org.hawkular.accounts>1.1.1.Final</version.org.hawkular.accounts> >>> <version.org.hawkular.bus>0.7.3.Final</version.org.hawkular.bus> >>> <version.org.hawkular.cmdgw>0.10.4.Final</version.org.hawkular.cmdgw> >>> <version.org.hawkular.commons>0.2.3.Final</version.org.hawkular.commons> >>> <version.org.hawkular.inventory>0.9.0.Final</version.org.hawkular.inventory> >>> <version.org.hawkular.metrics>0.10.0.Final</version.org.hawkular.metrics> >> >> Yes, every component in Hawkular has such a section of >> version.org.hawkular.* properties, but in each of the components the >> list is different, containing only the direct dependencies and nothing >> else. >> I cannot imagine how *all* these componets props could live in a single >> pom (hawkular-parent or a separate hawkular-bom) - such a BoM would >> inevitably bring circular dependency to most of places where it would be >> used. >> >> Say, the BoM version 0.0.1 would contain exactly the versions you listed >> above. Now, I want to use the BoM version 0.0.1 in Inventory, so that I >> do not have to maintain commons and accounts. What do I do? I'll import >> dependencyManagement/dependency/BoM version 0.0.1. But then I have >> released Inventory 0.9.1.Final and I need to upgrade the prop in the >> BoM, release BoM and ehm... upgrade the BoM version in Inventory and so on? >> >> Maybe I misunderstood your idea? >> >> -- P >> >>> It would be nice if we aren't required to set these (but we could override >>> them, right? if we want to try out a different version than what the >>> parent pom defines). >>> >>> This would make releasing easier. We just comment out all the <version...> >>> entries in all our pom.xml files (if they are there at all), thus falling >>> back to what the parent-pom has defined. Or maybe we build a bom?? I >>> dunno - all I know is, there is going to come a time when something >>> breaks because "uh-oh, this component built on version x.y.z of metrics, >>> but THIS component built on version a.b.c of metrics". >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

Ahh... yes, circular. Hmmmm.... There has to be a better way than how we are doing it today. I can't believe there isn't some easier way to do this rather than having to manually synchronize every individual component so all of their version properties match each other. ----- Original Message ----- > Hi Mazz, no, it cannot work. To consume the props from parent, you'd > have to (1) release parent and (2) propagate the new parent version to > all components. And once you (3) release any of the components, you'd > have to (4) update the version prop in parent. But so that other > components can consume it via parent you'd have to go to (1) and so on. > If this is not clear enough, just try it for a dummy parent, three dummy > components and a couple of releases of each component -- P > > On 2015-12-15 20:41, John Mazzitelli wrote: > > [this is a long email - the summary of it is - we need to stop allowing > > individual components (agent, inventory, alerts, etc) to release with > > their own set of version properties defined in their pom.xml files - we > > need to pick up a common set of version properties from parent pom. > > Otherwise, we are forced to manually go through some dependency document > > (that may or may not be up to date) so we know which version properties > > in > > which pom.xml files to manually update so they are all the same value. > > We > > already have parent-pom that can do this kind of thing for us. Here's > > the > > long email:] > > > >> To avoid improper deps, I have no better idea than opening the > >> components dependency graph [1] before releasing and asking the > >> colleagues working on components I depend on, whether they have (or > >> plant to release) something new. > >> > >> @all Please make sure that the deps in the graph are correct so that > >> components you depend upon know that you might be interested in their > >> updates. > > > > There has to be a better way than this. Forget a BOM for the moment, and > > consider this idea: > > > > In parent-pom, we already have a <properties> section with all our third > > party lib versions defined: > > https://github.com/hawkular/hawkular-parent-pom/blob/master/pom.xml#L231 > > -L255 > > > > Can't we have a list of all our hawkular component versions in here too? > > Set them to the last stable release versions. For example, we could say, > > "These version properties in parent-pom define the latest versions > > (.Final > > or srcdeps) that we know the hawkular dist build (aka kettle) needs and > > > > therefore all components should be using": > > <version.org.hawkular.accounts>... > > <version.org.hawkular.agent>... > > <version.org.hawkular.alerts>... > > <version.org.hawkular.bus>... > > <version.org.hawkular.cmdgw>... > > <version.org.hawkular.commons>... > > <version.org.hawkular.inventory>... > > <version.org.hawkular.metrics>... > > ...and the rest... > > > > Now, notice this doesn't mean every hawkular component is pulling in > > EVERY > > other component as a dependency. This is just defining version > > properties, > > that's all (just like every other version property in here). It is up to > > the individual components to define their <dependencies> as usual, but > > now > > they don't have to hardcode all their version properties in their poms, > > they can just fallback to using the properties as found in parent-pom > > and > > just make sure their parent-pom version is the latest. So, for example, > > > > the wildfly agent pom.xml already has this: > > <dependency> > > > > <groupId>org.hawkular.inventory</groupId> > > <artifactId>hawkular-inventory-json-helper</artifactId> > > <version>${version.org.hawkular.inventory}</version> > > > > </dependency> > > <dependency> > > > > <groupId>org.hawkular.metrics</groupId> > > <artifactId>hawkular-metrics-clients-common</artifactId> > > <version>${version.org.hawkular.metrics}</version> > > > > </dependency> > > .... and the rest of my hawkualr deps, like accounts, bus, etc... > > > > The difference is now my agent doesn't have to define those properties - > > I'll just use what parent pom has. I can delete all the > > <version.org.hawkular...> properties defined in the agent pom. > > > > Alerts can do the same thing - in their pom, they don't define > > ${version.org.hawkular.bus} and all the rest, they just use what > > parent-pom defines. If agent and alerts are on the same parent pom, we > > immediately know they are using all the same hawkular component versions > > as well. > > > > Now the only thing we have to update across all components is just the > > parent pom version. Each component should be on the same parent-pom > > before > > we do a full hawkular release. No need to ask people to keep some > > dependency document up to date, no need to manually go through that > > dependency document (that may or may not be up to date) in order to know > > what to change in what component. Just make sure everyone is on the same > > parent pom and we will know everyone is using the same accounts, alerts, > > inventory, metrics, blah blah blah. > > > > During development time, if a component DOES want to use a different > > version, they can still define their own version properties in their own > > pom.xml temporarily, but this should be rare. Most times, all of us > > should > > be using the SAME stable release across all components ("stable release" > > could be a srcdep if we want) and that is what parent pom defines for > > us. > > > > In short, we should all be using the same versions unless during > > development we need a different version. But how do we ensure everyone > > is > > using the same version? Rely on parent-pom. The only thing we should > > then > > have to worry about when we release is everyone is using the same > > parent-pom (with the assumption no component is overriding the version > > properties; if they are, they need to comment them out before > > releasing). > > > > Personally, I think it is a major problem that we are all releasing our > > components individually with no way to ensure we are all releasing with > > the same component dependencies. We've all got <version.org.hawkular...> > > properties defined in all our pom.xmls, and they are all wildly > > different > > sometimes (this one is using srcdep, this one is using 1.Final, this one > > 2.Final, etc...) And when we go to release, someone has to go to every > > pom.xml and look at every <version.org.hawkular...> and make sure they > > are > > the same. Of course, all the time prior to that, we've been testing with > > old versions, mixed versions (agent is using inventory a.b.c, alerts is > > using x.y.x) and once we move to the new ones, we hit failures we > > weren't > > expecting (and you know this always happens the day before we do a major > > Hawkular release :) > > > > Instead, I say we rely more on parent-pom. If we all say, "Move to > > parent > > pom 27" - that's a one line change in our poms, and once we do we > > immediately know we are all on the same versions for all components. > > Don't > > want to move to 27 yet? Fall back to 26 and pick up the previous stuff. > > Want to override a particular component during development, pass in > > -Dversion.org.hawkular... or set that temporarily in your pom.xml file. > > > > ----- Original Message ----- > > > >> On 2015-12-15 17:11, Peter Palaga wrote: > >>> Hi Mazz, inline... > >>> > >>> On 2015-12-15 16:12, John Mazzitelli wrote: > >>>> I just released the wildfly agent (0.13.7.Final) and I just realized > >>>> I > >>>> may > >>>> not have moved things up to the latest releases of its dependencies. > >> > >> To avoid improper deps, I have no better idea than opening the > >> components dependency graph [1] before releasing and asking the > >> colleagues working on components I depend on, whether they have (or > >> plant to release) something new. > >> > >> @all Please make sure that the deps in the graph are correct so that > >> components you depend upon know that you might be interested in their > >> updates. The the source of the graph lives in [2] > >> > >> [1] > >> http://www.hawkular.org/docs/dev/development.html#component-dependencie > >> s > >> [2] > >> https://github.com/hawkular/hawkular.github.io/blob/pages/src/main/manu > >> ally-generated/assets/img/docs/dev/components-dependencies.dot > >> > >> -- P > >> > >>>> It would be really nice now if we had something (even if its just > >>>> versions > >>>> in the parent pom) that defines the latest releases that components > >>>> should be using because right now, how many of our pom.xml files have > >>>> > >>>> things like this: > >>>> <version.org.hawkular.accounts>1.1.1.Final</version.org.hawkul > >>>> ar.accounts> > >>>> <version.org.hawkular.bus>0.7.3.Final</version.org.hawkular.bu > >>>> s> > >>>> <version.org.hawkular.cmdgw>0.10.4.Final</version.org.hawkular > >>>> .cmdgw> > >>>> <version.org.hawkular.commons>0.2.3.Final</version.org.hawkula > >>>> r.commons> > >>>> <version.org.hawkular.inventory>0.9.0.Final</version.org.hawku > >>>> lar.inventory> > >>>> <version.org.hawkular.metrics>0.10.0.Final</version.org.hawku > >>>> lar.metrics>> >>> > >>> Yes, every component in Hawkular has such a section of > >>> version.org.hawkular.* properties, but in each of the components the > >>> list is different, containing only the direct dependencies and nothing > >>> else. > >>> I cannot imagine how *all* these componets props could live in a > >>> single > >>> pom (hawkular-parent or a separate hawkular-bom) - such a BoM would > >>> inevitably bring circular dependency to most of places where it would > >>> be > >>> used. > >>> > >>> Say, the BoM version 0.0.1 would contain exactly the versions you > >>> listed > >>> above. Now, I want to use the BoM version 0.0.1 in Inventory, so that > >>> I > >>> do not have to maintain commons and accounts. What do I do? I'll > >>> import > >>> dependencyManagement/dependency/BoM version 0.0.1. But then I have > >>> released Inventory 0.9.1.Final and I need to upgrade the prop in the > >>> BoM, release BoM and ehm... upgrade the BoM version in Inventory and > >>> so > >>> on? > >>> > >>> Maybe I misunderstood your idea? > >>> > >>> -- P > >>> > >>>> It would be nice if we aren't required to set these (but we could > >>>> override > >>>> them, right? if we want to try out a different version than what the > >>>> parent pom defines). > >>>> > >>>> This would make releasing easier. We just comment out all the > >>>> <version...> > >>>> entries in all our pom.xml files (if they are there at all), thus > >>>> falling > >>>> back to what the parent-pom has defined. Or maybe we build a bom?? I > >>>> dunno - all I know is, there is going to come a time when something > >>>> breaks because "uh-oh, this component built on version x.y.z of > >>>> metrics, > >>>> but THIS component built on version a.b.c of metrics". > >>>> _______________________________________________ > >>>> hawkular-dev mailing list > >>>> hawkular-dev(a)lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >>> > >>> _______________________________________________ > >>> hawkular-dev mailing list > >>> hawkular-dev(a)lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev > >> > >> _______________________________________________ > >> hawkular-dev mailing list > >> hawkular-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

> Actually, this does not imply circular workflow, just a painful one :) > > 1) I want to release a new version of inventory and decide what its > version > is > gonna be. > > 2) I update parent POM with the new inventory version and release the > parent POM. Note that at this point in time no one is using this version > of parent and that inventory hasn't been released yet. > > 3) I update inventory with the new parent POM version and release it with > the intended version. > > So to break the circle outlined by Peter, you have to basically introduce > a > race condition and also double the number of releases we do. > > Note that the above workflow would work with a BOM, too. Out of curiosity, then how other projects works ? Can we adopt some best practice to reduce our complexity ? There are projects using bom and parent, and they have versions on both. If at the end of the story, there is a manual step of synchronization (i.e. I have to go to a place a look which version I need), I would like to see if we can get benefit in someway without adding circular dependencies or painful process. With the srcdeps plugin, we added an additional feature that helped in a sense. Is there a possibility to sync some property versions without entering on the circular dependency ? I am brainstorming, but what about a repo where we put these versions, and we can have just a plugin to warn if we are using correct ones ? (without having to place it on parent). I.e. In alerts I'm using a parent X and bus Y, and this plugin can check from the repo that my versions are not updated. So, manual step is not avoid but we are warned that for alpha8 target versions are a,b,c. When I release a new alerts, I can update that in the repo. Thoughts ? _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

> > I think this might be it: > > http://www.mojohaus.org/versions-maven-plugin/display-property-updates-mo... > It is interesting. But perhaps we might need something ad-hoc, in the srcdeps spirit. For example, in the versions repo we can target the Alpha8 versions, i.e. accounts 1.1.4.Final, perhaps, accounts might have other upper releases 2.0.0.Final for WF10, but the plugin can warn me that I'm not using the 1.1.4.Final. Accounts would be responsible (or someone else) to put the right version on the "versions repo" (which can be just a properties file on github). So, we would work as today, but this non-intrusive plugin could help us to coordinate in some degree. > On Tuesday, December 15, 2015 17:50:59 Lucas Ponce wrote: >>> Actually, this does not imply circular workflow, just a painful one :) >>> >>> 1) I want to release a new version of inventory and decide what its >>> version >>> is >>> gonna be. >>> >>> 2) I update parent POM with the new inventory version and release the >>> parent POM. Note that at this point in time no one is using this version >>> of parent and that inventory hasn't been released yet. >>> >>> 3) I update inventory with the new parent POM version and release it with >>> the intended version. >>> >>> So to break the circle outlined by Peter, you have to basically introduce >>> a >>> race condition and also double the number of releases we do. >>> >>> Note that the above workflow would work with a BOM, too. >> >> Out of curiosity, then how other projects works ? Can we adopt some best >> practice to reduce our complexity ? >> >> There are projects using bom and parent, and they have versions on both. >> >> If at the end of the story, there is a manual step of synchronization (i.e. >> I have to go to a place a look which version I need), I would like to see >> if we can get benefit in someway without adding circular dependencies or >> painful process. >> >> With the srcdeps plugin, we added an additional feature that helped in a >> sense. >> >> Is there a possibility to sync some property versions without entering on >> the circular dependency ? >> >> I am brainstorming, but what about a repo where we put these versions, and >> we can have just a plugin to warn if we are using correct ones ? (without >> having to place it on parent). >> >> I.e. In alerts I'm using a parent X and bus Y, and this plugin can check >> from the repo that my versions are not updated. >> >> So, manual step is not avoid but we are warned that for alpha8 target >> versions are a,b,c. >> >> When I release a new alerts, I can update that in the repo. >> >> Thoughts ? >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

I still think that speaking with one's upstream before releasing is the most flexible and reliable way of solving the present problem.

Actually, this does not imply circular workflow, just a painful one :) 1) I want to release a new version of inventory and decide what its version is gonna be. 2) I update parent POM with the new inventory version and release the parent POM. Note that at this point in time no one is using this version of parent and that inventory hasn't been released yet. 3) I update inventory with the new parent POM version and release it with the intended version. So to break the circle outlined by Peter, you have to basically introduce a race condition and also double the number of releases we do. Note that the above workflow would work with a BOM, too.

On Tuesday, December 15, 2015 17:19:11 John Mazzitelli wrote: > Ahh... yes, circular. Hmmmm.... > > There has to be a better way than how we are doing it today. I can't believe > there isn't some easier way to do this rather than having to manually > synchronize every individual component so all of their version properties > match each other. > > ----- Original Message ----- > >> Hi Mazz, no, it cannot work. To consume the props from parent, you'd >> have to (1) release parent and (2) propagate the new parent version to >> all components. And once you (3) release any of the components, you'd >> have to (4) update the version prop in parent. But so that other >> components can consume it via parent you'd have to go to (1) and so on. >> If this is not clear enough, just try it for a dummy parent, three dummy >> components and a couple of releases of each component -- P >> >> On 2015-12-15 20:41, John Mazzitelli wrote: >>> [this is a long email - the summary of it is - we need to stop allowing >>> individual components (agent, inventory, alerts, etc) to release with >>> their own set of version properties defined in their pom.xml files - we >>> need to pick up a common set of version properties from parent pom. >>> Otherwise, we are forced to manually go through some dependency document >>> (that may or may not be up to date) so we know which version properties >>> in >>> which pom.xml files to manually update so they are all the same value. >>> We >>> already have parent-pom that can do this kind of thing for us. Here's >>> the >>> long email:] >>> >>>> To avoid improper deps, I have no better idea than opening the >>>> components dependency graph [1] before releasing and asking the >>>> colleagues working on components I depend on, whether they have (or >>>> plant to release) something new. >>>> >>>> @all Please make sure that the deps in the graph are correct so that >>>> components you depend upon know that you might be interested in their >>>> updates. >>> >>> There has to be a better way than this. Forget a BOM for the moment, and >>> consider this idea: >>> >>> In parent-pom, we already have a <properties> section with all our third >>> party lib versions defined: >>> https://github.com/hawkular/hawkular-parent-pom/blob/master/pom.xml#L231 >>> -L255 >>> >>> Can't we have a list of all our hawkular component versions in here too? >>> Set them to the last stable release versions. For example, we could say, >>> "These version properties in parent-pom define the latest versions >>> (.Final >>> or srcdeps) that we know the hawkular dist build (aka kettle) needs and >>> >>> therefore all components should be using": >>> <version.org.hawkular.accounts>... >>> <version.org.hawkular.agent>... >>> <version.org.hawkular.alerts>... >>> <version.org.hawkular.bus>... >>> <version.org.hawkular.cmdgw>... >>> <version.org.hawkular.commons>... >>> <version.org.hawkular.inventory>... >>> <version.org.hawkular.metrics>... >>> ...and the rest... >>> >>> Now, notice this doesn't mean every hawkular component is pulling in >>> EVERY >>> other component as a dependency. This is just defining version >>> properties, >>> that's all (just like every other version property in here). It is up to >>> the individual components to define their <dependencies> as usual, but >>> now >>> they don't have to hardcode all their version properties in their poms, >>> they can just fallback to using the properties as found in parent-pom >>> and >>> just make sure their parent-pom version is the latest. So, for example, >>> >>> the wildfly agent pom.xml already has this: >>> <dependency> >>> >>> <groupId>org.hawkular.inventory</groupId> >>> <artifactId>hawkular-inventory-json-helper</artifactId> >>> <version>${version.org.hawkular.inventory}</version> >>> >>> </dependency> >>> <dependency> >>> >>> <groupId>org.hawkular.metrics</groupId> >>> <artifactId>hawkular-metrics-clients-common</artifactId> >>> <version>${version.org.hawkular.metrics}</version> >>> >>> </dependency> >>> .... and the rest of my hawkualr deps, like accounts, bus, etc... >>> >>> The difference is now my agent doesn't have to define those properties - >>> I'll just use what parent pom has. I can delete all the >>> <version.org.hawkular...> properties defined in the agent pom. >>> >>> Alerts can do the same thing - in their pom, they don't define >>> ${version.org.hawkular.bus} and all the rest, they just use what >>> parent-pom defines. If agent and alerts are on the same parent pom, we >>> immediately know they are using all the same hawkular component versions >>> as well. >>> >>> Now the only thing we have to update across all components is just the >>> parent pom version. Each component should be on the same parent-pom >>> before >>> we do a full hawkular release. No need to ask people to keep some >>> dependency document up to date, no need to manually go through that >>> dependency document (that may or may not be up to date) in order to know >>> what to change in what component. Just make sure everyone is on the same >>> parent pom and we will know everyone is using the same accounts, alerts, >>> inventory, metrics, blah blah blah. >>> >>> During development time, if a component DOES want to use a different >>> version, they can still define their own version properties in their own >>> pom.xml temporarily, but this should be rare. Most times, all of us >>> should >>> be using the SAME stable release across all components ("stable release" >>> could be a srcdep if we want) and that is what parent pom defines for >>> us. >>> >>> In short, we should all be using the same versions unless during >>> development we need a different version. But how do we ensure everyone >>> is >>> using the same version? Rely on parent-pom. The only thing we should >>> then >>> have to worry about when we release is everyone is using the same >>> parent-pom (with the assumption no component is overriding the version >>> properties; if they are, they need to comment them out before >>> releasing). >>> >>> Personally, I think it is a major problem that we are all releasing our >>> components individually with no way to ensure we are all releasing with >>> the same component dependencies. We've all got <version.org.hawkular...> >>> properties defined in all our pom.xmls, and they are all wildly >>> different >>> sometimes (this one is using srcdep, this one is using 1.Final, this one >>> 2.Final, etc...) And when we go to release, someone has to go to every >>> pom.xml and look at every <version.org.hawkular...> and make sure they >>> are >>> the same. Of course, all the time prior to that, we've been testing with >>> old versions, mixed versions (agent is using inventory a.b.c, alerts is >>> using x.y.x) and once we move to the new ones, we hit failures we >>> weren't >>> expecting (and you know this always happens the day before we do a major >>> Hawkular release :) >>> >>> Instead, I say we rely more on parent-pom. If we all say, "Move to >>> parent >>> pom 27" - that's a one line change in our poms, and once we do we >>> immediately know we are all on the same versions for all components. >>> Don't >>> want to move to 27 yet? Fall back to 26 and pick up the previous stuff. >>> Want to override a particular component during development, pass in >>> -Dversion.org.hawkular... or set that temporarily in your pom.xml file. >>> >>> ----- Original Message ----- >>> >>>> On 2015-12-15 17:11, Peter Palaga wrote: >>>>> Hi Mazz, inline... >>>>> >>>>> On 2015-12-15 16:12, John Mazzitelli wrote: >>>>>> I just released the wildfly agent (0.13.7.Final) and I just realized >>>>>> I >>>>>> may >>>>>> not have moved things up to the latest releases of its dependencies. >>>> >>>> To avoid improper deps, I have no better idea than opening the >>>> components dependency graph [1] before releasing and asking the >>>> colleagues working on components I depend on, whether they have (or >>>> plant to release) something new. >>>> >>>> @all Please make sure that the deps in the graph are correct so that >>>> components you depend upon know that you might be interested in their >>>> updates. The the source of the graph lives in [2] >>>> >>>> [1] >>>> http://www.hawkular.org/docs/dev/development.html#component-dependencie >>>> s >>>> [2] >>>> https://github.com/hawkular/hawkular.github.io/blob/pages/src/main/manu >>>> ally-generated/assets/img/docs/dev/components-dependencies.dot >>>> >>>> -- P >>>> >>>>>> It would be really nice now if we had something (even if its just >>>>>> versions >>>>>> in the parent pom) that defines the latest releases that components >>>>>> should be using because right now, how many of our pom.xml files have >>>>>> >>>>>> things like this: >>>>>> <version.org.hawkular.accounts>1.1.1.Final</version.org.hawkul >>>>>> ar.accounts> >>>>>> <version.org.hawkular.bus>0.7.3.Final</version.org.hawkular.bu >>>>>> s> >>>>>> <version.org.hawkular.cmdgw>0.10.4.Final</version.org.hawkular >>>>>> .cmdgw> >>>>>> <version.org.hawkular.commons>0.2.3.Final</version.org.hawkula >>>>>> r.commons> >>>>>> <version.org.hawkular.inventory>0.9.0.Final</version.org.hawku >>>>>> lar.inventory> >>>>>> <version.org.hawkular.metrics>0.10.0.Final</version.org.hawku >>>>>> lar.metrics>> >>> >>>>> Yes, every component in Hawkular has such a section of >>>>> version.org.hawkular.* properties, but in each of the components the >>>>> list is different, containing only the direct dependencies and nothing >>>>> else. >>>>> I cannot imagine how *all* these componets props could live in a >>>>> single >>>>> pom (hawkular-parent or a separate hawkular-bom) - such a BoM would >>>>> inevitably bring circular dependency to most of places where it would >>>>> be >>>>> used. >>>>> >>>>> Say, the BoM version 0.0.1 would contain exactly the versions you >>>>> listed >>>>> above. Now, I want to use the BoM version 0.0.1 in Inventory, so that >>>>> I >>>>> do not have to maintain commons and accounts. What do I do? I'll >>>>> import >>>>> dependencyManagement/dependency/BoM version 0.0.1. But then I have >>>>> released Inventory 0.9.1.Final and I need to upgrade the prop in the >>>>> BoM, release BoM and ehm... upgrade the BoM version in Inventory and >>>>> so >>>>> on? >>>>> >>>>> Maybe I misunderstood your idea? >>>>> >>>>> -- P >>>>> >>>>>> It would be nice if we aren't required to set these (but we could >>>>>> override >>>>>> them, right? if we want to try out a different version than what the >>>>>> parent pom defines). >>>>>> >>>>>> This would make releasing easier. We just comment out all the >>>>>> <version...> >>>>>> entries in all our pom.xml files (if they are there at all), thus >>>>>> falling >>>>>> back to what the parent-pom has defined. Or maybe we build a bom?? I >>>>>> dunno - all I know is, there is going to come a time when something >>>>>> breaks because "uh-oh, this component built on version x.y.z of >>>>>> metrics, >>>>>> but THIS component built on version a.b.c of metrics". >>>>>> _______________________________________________ >>>>>> hawkular-dev mailing list >>>>>> hawkular-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>>> >>>>> _______________________________________________ >>>>> hawkular-dev mailing list >>>>> hawkular-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>> >>>> _______________________________________________ >>>> hawkular-dev mailing list >>>> hawkular-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev