On the resolver thingy.
I believe that the main problem we need to address is a format of error
messages spit from our code.
In quite many cases error takes half of the screen. Failure reason is at
the end. Going over spaghetti causation in between is a challenge.
Making that readable in a tree form like below can make it simpler to
read, easier to understand, making developer solve the problem faster.
```
Failed to complete provisioning operation, here is a reason:
- Resolution of feature X failed, because:
- Resolution of feature Y failed, because:
- Resolution of feature Z failed, because:
- Resolution of bundle A failed, because:
- Missing requirement 1-2-3
```
I think I even attempted to format error in such a way, however message
coming back from resolver is already a in a string form which makes it
hard to navigate over resolution path.
>From my observation the big change with introduction of resolver is
already passed, our users got used to it. There might be a slight
discomfort, I had it myself when migrating to 4.x, but that's a price
for extra safety resolver brings. I would say that the only way I would
see is no resolver at all (the 2.x and 3.x mode), turning features into
a list of bundles as it was decade ago.
With regard to failure scenario from Grzegorz - I think I've ran into
one. Lately I migrated some features and resolver blew up - it did
because conditional feature was defined in two feature sets causing
stack overflow. I solved it by removal of duplicated feature.
The faulty condition is this one:
https://github.com/apache/karaf/blob/master/features/core/src/main/java/org/apache/karaf/features/internal/region/Subsystem.java#L385
I wasn't sure if that's a bug or not, so I didn't register it and didn't
test against it.
Cheers,
Łukasz
On 05.05.2020 14:06, Christian Schneider wrote:
> I agree with Achim.
> The problem I see with a simple resolver is especially that it will come to
> a different result than the current resolver.
> So the features shipped with karaf might behave differently with a simple
> resolver. So maybe this can work if people do all feature on their own but
> this is not how people use karaf.
>
> Christian
>
>
> Am Di., 5. Mai 2020 um 11:50 Uhr schrieb Achim Nierbeck
> <bcanh...@googlemail.com.invalid>:
>
>> +1 for most.
>> only objection to the "Simple" Resolver, therefore -1 on that.
>> I fear we do more harm then improvement.
>> As Grzegorz already said, it's the way it is, not because we love complex
>> stuff, but because bundle resolving is complex.
>> Especially due to the new req/cap inside bundles.
>> Actually to work around some of the "crappy" req/cap with bundles, with
>> features did help in the past.
>>
>> regards, Achim
>>
>>
>> Am Mo., 4. Mai 2020 um 09:44 Uhr schrieb Francois Papon <
>> francois.pa...@openobject.fr>:
>>
>>> +1 for all
>>>
>>> regards,
>>>
>>> François
>>> fpa...@apache.org
>>>
>>> Le 04/05/2020 à 09:26, Grzegorz Grzybek a écrit :
>>>> Hello
>>>>
>>>> ad1) About JAXB. Currently,
>>>> `org.apache.karaf.features.internal.model.processing` package contains
>>> not
>>>> that complex model for "Feature override and blacklisting", which reads
>>>> etc/org.apache.karaf.features.xml file to _alter_ features model using
>>>> `org.apache.karaf.features.internal.service.FeaturesProcessor`.
>>>> Nothing that can't be done without JAXB. But I'd have to rewrite some
>>> code
>>>> to use StAX/SAX instead.
>>>>
>>>> ad2) as long as the _model_ read from JSON feature files is still
>> rooted
>>> at
>>>> org.apache.karaf.features.internal.model.Features class, it's fine wrt
>>>> _feature processing_ ;)
>>>>
>>>> ad3) +1 for simpler resolver. But I remember it's complex not for the
>>> sake
>>>> of complexity, but due to complexity of bundle model and reqs/caps
>>> model. I
>>>> have a _strange case_ in
>>>> https://github.com/apache/karaf/commits/ggrzybek-conditionals, where
>>>> resolution depends on whether (or not) a feature is in
>>>> <conditional>/<condition>.
>>>>
>>>> ad4) +1
>>>>
>>>> ad5) +2
>>>>
>>>> regards
>>>> Grzegorz Grzybek
>>>>
>>>> pon., 4 maj 2020 o 07:30 Jean-Baptiste Onofre <j...@nanthrax.net>
>>> napisał(a):
>>>>
>>>>> Hi guys,
>>>>>
>>>>> I’m working on several improvements this week where I would need your
>>>>> review and thoughts.
>>>>>
>>>>> 1. JAXB remove
>>>>> We have a JAXB dependency in Karaf core just for the features service.
>>> As
>>>>> the features model is "static" (we don’t change features model at
>>> runtime),
>>>>> I would like to remove the JAXB dependency and generate the parser at
>>> build
>>>>> time with SXC for instance. I will add a build profile to generate the
>>>>> parse when the model change (it doesn’t happen very often to be
>> honest).
>>>>> The purpose is to provide a even lighter Karaf runtime. About that, I
>>>>> would like also to promote a bit the minimal distribution and do it
>> even
>>>>> lighter. I propose to push minimal as official docker image, allowing
>>>>> people to start from minimal to create their own docker image (we will
>>>>> provide improved tools about that).
>>>>>
>>>>> 2. Features JSON
>>>>> As an alternative to features XML repo, I’ve working on features JSON
>>>>> repo. It’s similar in term of content, but you will now have the
>> choice
>>>>> between XML and JSON.
>>>>>
>>>>> 3. Simple resolver
>>>>> Several users complained about the features resolver: it might be seen
>>> as
>>>>> complex (you have to understand req/caps, etc), it’s not always
>>> predictable
>>>>> (due to refresh with optional import, etc). I would like to propose an
>>>>> alternative: the simple resolver. It’s pretty simple: it just takes
>> what
>>>>> you have in features definition. It’s an optional resolver, meaning
>> that
>>>>> the default will be still the regular resolver. The simple resolver
>> can
>>> be
>>>>> enabled in etc/org.apache.karaf.features.cfg.
>>>>>
>>>>> 4. Spec features and cleanup
>>>>> As already discussed, I would like to remove the lib/jdk9plus folder
>> and
>>>>> all spec packages from etc/jre.properties to use spec features
>> instead.
>>>>> That will give us more control in the specs version and support of
>> JDK.
>>>>>
>>>>> 5. ConfigAdmin persistence repository overwrite with env var
>>>>> It will be possible now to overwrite configuration with env var. For
>>>>> instance, if you have a property foo in my.config pid, you will be
>> able
>>> to
>>>>> overwrite this property with -Dmy.config:foo=bar at bootstrap.
>>>>>
>>>>> If you agree, I would like to include those improvements in coming
>>> release
>>>>> (4.2.9 and 4.3.0.RC2).
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>>
>>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
>> Project Lead
>> blog <http://notizblog.nierbeck.de/>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>
>
>
