[Hawkular-dev] is it time for a bom? or for version definitions in parent pom?
Peter Palaga
ppalaga at redhat.com
Wed Dec 16 04:18:58 EST 2015
On 2015-12-15 23:38, Lukas Krejci 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.
As side note about BoM vs Parent: Properties defined in a BoM are not
imported. Artifacts have to managed in BoMs so that the BoMs make any
sense. -- P
> 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 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
>>
>> _______________________________________________
>> 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