My 0.02€. I had an attempt to use static assemblies and had to step back
from it. There is very little documentation on how to adjust tooling and
example which was pointed earlier does not answer all questions.
Second, also important thing, is having a static feature resolution
doesn't mean that
You get me wrong.
There are actually two proposal:
1. Static distribution/resolution build time. We already have all ready,
just documentation and adding example.
2. Single classloader is winegrower. It's NOT karaf, but it brings all
Karaf features. That's a second discussion.
So, just to be
Hello
pon., 4 mar 2019 o 17:58 Serge Huber napisał(a):
> I also like the proposed solution using build-time generation.
>
> Just a question about the single classloader though: isn't that going to
> cause problems if projects want to use different versions of a library? I
> agree that they
Fully agree about the "missing" part, we have to focuse on tooling and
documentation because most of the time, end users doesn't know the
capabilities or how to deal with.
Regards,
François Papon
fpa...@apache.org
Le 04/03/2019 à 18:18, Jean-Baptiste Onofré a écrit :
> That's a very good
Hello guys
Le lun. 4 mars 2019 à 17:58, Serge Huber a écrit :
> I also like the proposed solution using build-time generation.
>
> Just a question about the single classloader though: isn't that going to
> cause problems if projects want to use different versions of a library? I
> agree that
In the demo that I pointed, there's no single classloader, it uses the real
OSGi framework, but there's no resolution of Karaf Features at runtime,
that part is done fully at build time and the runtime just has to install
the bundles that are listed in etc/startup.properties.
Le lun. 4 mars 2019
I also like the proposed solution using build-time generation.
Just a question about the single classloader though: isn't that going to
cause problems if projects want to use different versions of a library? I
agree that they shouldn't but it's also something that makes Karaf more
powerful than
+1
Am Mo., 4. März 2019 um 15:29 Uhr schrieb Guillaume Nodet :
> Right, and also, the demo is using profiles, and I think we should have a
> demo using plain features instead. That does not really change anything,
> as the assembly is all done by the plugin, but this lead to a simpler demo.
>
>
I agree. The static profile already works great by doing the resolution on
build time.
Actually it is the same model that bnd resolve also uses. They just do not
have the feature concept and only rely on a set of repositories.
Christian
Am Mo., 4. März 2019 um 15:15 Uhr schrieb Guillaume Nodet
Yes, the demo I would like to add is:
- starting from user code
- use the generate-features goal to create the features XML
- use the generated features XML as static distribution
- add jib plugin to directly create the docker image based on the
distribution
It would be a great starting point to
Right, and also, the demo is using profiles, and I think we should have a
demo using plain features instead. That does not really change anything,
as the assembly is all done by the plugin, but this lead to a simpler demo.
Le lun. 4 mars 2019 à 15:18, Jean-Baptiste Onofré a
écrit :
> That's a
By the way, the only thing missing in the example IMHO is to do all in a
row: code, assembly, jib in one module.
I'm preparing an example using this approach.
Regards
JB
On 04/03/2019 15:15, Guillaume Nodet wrote:
> I would argue that we should not use any resolver at all for such
> containers,
That's a very good argument and actually I think you are right, that's
even better.
Maybe the "missing" part if the tooling and the documentation around this.
Let me prepare a PR for that !
Regards
JB
On 04/03/2019 15:15, Guillaume Nodet wrote:
> I would argue that we should not use any
I would argue that we should not use any resolver at all for such
containers, and that's already doable with the karaf plugin.
We have a demo of that in the
examples/karaf-profile-example/karaf-profile-example-static
The resolution is done at build time and the list of bundles is written in
the
Hello
Good idea. I remember also a persistent option for resolver - so instead of
reading repos/feature/resource manifests and invoke felix resolver with
reqs/caps, there was something (written by @Guillaume Nodet
? Available in Equinox?) that just read wiring from some
json and used it as wiring
Hi guys,
During the introduction thread about "kloud initiative", we quickly
discussed about the resolver.
Today, we can see concerns about the current features resolver, especially:
- the resolution at runtime can be different than the one done during verify
- the resolution at runtime can be
16 matches
Mail list logo
