[Hawkular-dev] is it time for a bom? or for version definitions in parent pom?
Peter Palaga
ppalaga at redhat.com
Tue Dec 15 17:05:20 EST 2015
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-dependencies
>> [2]
>> https://github.com/hawkular/hawkular.github.io/blob/pages/src/main/manually-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.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 at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>>
>>>
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
More information about the hawkular-dev
mailing list