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