[Hawkular-dev] is it time for a bom? or for version definitions in parent pom?

John Mazzitelli mazz at redhat.com
Tue Dec 15 17:19:11 EST 2015 

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