[Hawkular-dev] is it time for a bom? or for version definitions in parent pom?
Lukas Krejci
lkrejci at redhat.com
Tue Dec 15 17:38:22 EST 2015
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 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