I still haven't had a chance to look deeply into HC yet so please take my
comments with that consideration.

What about all the whiteboards; and CDI (akin to DS)? How are their status'
handled here and how would it affect your suggested breakdown?

Sincerely,
- Ray

On Mon, Mar 4, 2019 at 11:19 AM Georg Henzler <[email protected]> wrote:

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


-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)

Reply via email to