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
>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com

Reply via email to