-Pdev build is broken
by John Mazzitelli
FYI: if you try to build kettle with -Pdev (to get a dev build) the build will fail.
To workaround, do not build with -Pdev.
10 years, 3 months
CanonicalPath should go to Commons
by Peter Palaga
Hi *, esp. Lukáš,
Having org.hawkular.inventory.api.model.CanonicalPath in a separate
maven module inside Hawkular Commons git repo would make the life easier
for both Alerts and Command Gateway.
For both Alerts and Command Gateway, CanonicalPath is the only class
they need from Inventory. If CanonicalPath was hosted in Commons, both
Alerts and Command Gateway could stop maintaining any dependency on
Inventory and the overall dependency graph [1] could thus be made simpler.
Lukáš, I remember I asked about this earlier, but do not precisely
remember what was your reason for the denial?
[1] http://www.hawkular.org/docs/dev/development.html#component-dependencies
Thanks,
Peter
10 years, 3 months
Moving Nest and Bus to Hawkular Commons git repository
by Peter Palaga
Hi *,
this was already discussed on several calls. Although I know of no
objections, I am putting it also here to give you all the last chance to
protest or discuss.
The plan is to move the Maven modules from Nest [1] and Bus [2] git
repositories to Commons repository [3].
Details:
* Nest and Bus Maven modules will be moved to Hawkular Commons git
repository
* Nest and Bus Maven modules will belong to groupId org.hawkular.commons
* All modules of the org.hawkular.commons incl. Nest and Bus will be
released together
* The new and old subcomponents of Commons (such as Nest, Bus,
Templates, c* driver, ...) will be allowed to depend on each other,
but clearly, they may not introduce circular dependencies.
* To help to keep control on which subcomponent depends on which other
subcomponents, the dependency management will happen on
the subcomponent level rather than in hawkular-commons-parent
* Components consuming Nest, Bus or any of the other subcomponents of
Hawkular Commons will have to declare just one version property
version.org.hawkular.commons to manage all the the artifacts they
need from commons
* As noted by Stefan, only such subcomponents should be allowed to be
hosted in Commons that are generic enough -i.e. that do not contain
any deep and specific domain knowledge. Move of Bus and Nest to
commons satisfies this.
Pros:
* Decrease the maintenance overhead by decreasing the number of git
repositories and by decreasing the number of Hawkular components
having independent release cycles - e.g. after a new release of
Hawkular Parent there is two component less to upgrade, two componets
less to release and n components less to upgrade that depend on Bus
and Nest
Cons:
* Loose some amount of design cleanness - Hawkular Commons hosts Maven
modules with clean logical borders that could be hosted and released
independently.
* Esp. the independent release cycle could be seen as an
advantage when fixing bugs and CVEs
Pseudo-con:
* Note that the new home of Nest and Bus does not prescribe any
component that consumed Commons so far to consume also Nest and Bus
from now on. Dependent components can still choose the artifacts to
depend on with an unchanged granularity: Who dependeded on embedded
c* so far can stay with it without depending on Bus or Nest.
I am going to work on this change now.
[1] https://github.com/hawkular/hawkular-nest
[2] https://github.com/hawkular/hawkular-bus
[3] https://github.com/hawkular/hawkular-commons
Thanks,
Peter
10 years, 3 months
