On 6/05/2020 7:38 am, Łukasz Dywicki wrote:
On the resolver thingy.
I believe that the main problem we need to address is a format of error
messages spit from our code.
+1
I was going to suggest this myself.
At present I copy to text editor and format to ease understanding in some cases.
Paul Fraser
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>
