Let's root cause separate then, this means 1b and 2b from the options
below. To not have a hard dependency from generalchecks to the rootcause
bundle, I'd make the package import to org.apache.felix.rootcause
optional. But to be able to release generalchecks with the dependency
(optional or not), we need a release of rootcause. @Christian Would you
mind starting the release process for it?
-Georg
On 2019-03-04 23:05, Christian Schneider wrote:
I agree to move the systemready checks into felix health checks and
deprecate the system ready module. I can do the migration.
For root cause I prefer to leave it as its own module for now. We can
still
move it at a later time if we find a better home for it.
Christian
Am Mo., 4. März 2019 um 17:19 Uhr schrieb Georg Henzler
<[email protected]>:
Hi all,
I have created a patch to implement system ready with HCs some time
ago
[1] and I would like to continue with this now that the API/core is
released. There are different options on how to move on:
1a. Leave system ready as own module and just use
the HC API (that's what the current patch does)
(+) There was an adaptTo talk about it, people
might search for the name "systemready"
1b. Move the three system ready checks (it is just
three classes/500 LOC now) to HC module
generalchecks
(+) Users installing the generalchecks module
get automatically a good set of HCs to start
with, if they are spread across two bundles
most of the time, people would have to install
both (for mostly history reasons in the end)
Also regarding the root cause module there are different options (as
far
as I understand it is about finding first component in a chain of
unsatisfied components):
2a. We could move the package to the scr module
since root cause is (at least currently) really
only related to scr
(+) I think it's good practice to have code of
the same problem domain close together
(-) It might take some time until the HC with
the dependency to a future SCR version can
actually be used (but this is short term)
2b. Root cause could be left independent where it
is now
(+) If there are other root cause analysis
mechanisms (e.g. if there will be one for
iPOJO) all analysis tasks could be left in
one place
(-) There probably could not be a common
interface between root cause analysis tasks
of different
2c. The root cause module could be moved back the
the bundle of the DsComponentsCheck (depending
on 1a. or 1b. which one exactly)
(+) The KISS solution
I think my favorite would be 1b. and 2c. (without having a strong
opinion here) - but what do others think?
Best Regards
Georg
[1] https://issues.apache.org/jira/browse/FELIX-6014
--
