Hello
I wasn't aware I should comment - silent consensus ;) Looks good - thanks!
regards
Grzegorz Grzybek
wt., 5 mar 2019 o 07:09 Jean-Baptiste Onofré napisał(a):
> Hi guys,
>
> I would like to submit the report asap, no comment ?
>
> Thanks,
> Regards
> JB
>
> On 02/03/2019 06:52, Jean-Baptis
Hi guys,
I would like to submit the report asap, no comment ?
Thanks,
Regards
JB
On 02/03/2019 06:52, Jean-Baptiste Onofré wrote:
> Hi guys,
>
> I prepared the board report for this month:
>
> https://cwiki.apache.org/confluence/display/KARAF/Board+Reports
>
> Please take a look and let me kn
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 cle
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 shoul
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 argumen
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 the
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 Sp
+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 v
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 resolve
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 im
On 04/03/2019 11:37, Jean-Baptiste Onofré wrote:
> Hi Vikram,
Hello JB,
>
> When using Blueprint, you don't directly relay on the service, but
> Blueprint creates a proxy for the reference.
>
> The "timeout" is what we name the grace period and it happens at startup.
> Once the startup is done,
Hi Vikram,
When using Blueprint, you don't directly relay on the service, but
Blueprint creates a proxy for the reference.
The "timeout" is what we name the grace period and it happens at startup.
Once the startup is done, and the actual service is not there, the proxy
can fail with such kind of
Hi Team
Our application is using Blueprint to inject the services exposed by a bean to
the other bean and in some application runs, we see below exceptions. After
browsing online articles, the highlighted exception indicates that the
backend service implementation is not available in the OSGi re
20 matches
Mail list logo
