Re: Karaf 4.0 : new behaviour of the feature resolver

[Guillaume Nodet]

2015-02-12 21:55 GMT+01:00 Guillaume Nodet :

>
>
> 2015-02-12 19:56 GMT+01:00 Achim Nierbeck :
>
>> Hi,
>>
>> if it could be possible to add this feature back again, this clearly would
>> help. (the -c option)
>>
>
> Well, it it's just about trying to install the bundles listed in a feature
> and its dependencies, that could be done, but then you'll expect everything
> to work, such as conditionals, configurations, etc...  Now, features can
> also define capabilities and requirements, so while this is doable, we need
> to clearly define which subset of things we would support in such a mode.
>
> Another better way would be to do it in a very different way.  It may be
> possible to have a mode where the resolution would be done in a loop while
> it succeeds.  If it fails, we collect the missing requirement, add a dummy
> capability to solve it, and run again, or something similar.  We could then
> print the missing requirements and install the bundles.
> There's already a simulatation mode which runs the resolution and prints
> the action that needs to be performed without actually modifying the
> framework, so that could be another mode.  I don't foresee any technical
> impossibility here, so it may be worth a try if there's a consensus.
>

Well, there's one problem though, and it's similar to adding a flag to not
take effective:="active" metadata into account.  The next resolution will
fail the same way.  One possibility could be to install the bundles into
"non managed" bundles, i.e. to not persist the fact that the feature was
required, so that the feature won't cause any problem during the next
resolution.


>
>
>> Another interesting fact here, the Require-Capability is only added for
>> bundles using DS by the maven-bundle-plugin.
>> Blueprint Bundles don't have it even though that could be generated easily
>> from the reference-tag.
>>
>
> They are.  You're either using an old maven plugin, or you have disabled
> the generation of the metadata.
>
>
>>
>> Regarding the feature validation goal, I doubt it would have shown that
>> the
>> pax-url-aether bundle was neglecting the providing capabilities manifest
>> entries. Though I need to verify that with a test-case.
>>
>
> No, you're right, it could not have figured the pax-url-aether bundle was
> wrong, because there's no way to know that a capability should have been
> provided.  It's like if you forgot to export a package, no one could tell
> you.
> But it would have failed to validate the feature that was using it, i.e.
> the one you want to install and which currently fail.
>
>
>>
>> regards, Achim
>>
>>
>> 2015-02-12 0:39 GMT+01:00 Christian Schneider :
>>
>> > Am 11.02.2015 um 22:02 schrieb Guillaume Nodet:
>> >
>> >> The breaking change is that features are now verified before being
>> >> installed.
>> >> In karaf < 4, there was no verification step, and the installation of
>> the
>> >> feature was simply trying to install the bundles and start those.
>> >>
>> >
>> > In most cases I like the verification. In some cases though especially
>> > when I build the deployment I sometimes want the bundles to be installed
>> > even if they do not even resolve.
>> > The reason is that it is easier to debug what is wrong when the bundles
>> > are in the system. So I would like to have an option to install even if
>> the
>> > verification fails. Kind of like the option in karaf
>> > 2 and 3 where you leave the bundles installed in case of a failure.
>> >
>> > Doe that make sense?
>> >
>> > Christian
>> >
>> > --
>> >  Christian Schneider
>> > http://www.liquid-reality.de
>> >
>> > Open Source Architect
>> > Talend Application Integration Division http://www.talend.com
>> >
>> >
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf  Committer & PMC
>> OPS4J Pax Web  Committer &
>> Project Lead
>> blog 
>> Co-Author of Apache Karaf Cookbook 
>>
>> Software Architect / Project Manager / Scrum Master
>>
>
>

Re: Karaf 4.0 : new behaviour of the feature resolver

[Guillaume Nodet]

2015-02-12 19:56 GMT+01:00 Achim Nierbeck :

> Hi,
>
> if it could be possible to add this feature back again, this clearly would
> help. (the -c option)
>

Well, it it's just about trying to install the bundles listed in a feature
and its dependencies, that could be done, but then you'll expect everything
to work, such as conditionals, configurations, etc...  Now, features can
also define capabilities and requirements, so while this is doable, we need
to clearly define which subset of things we would support in such a mode.

Another better way would be to do it in a very different way.  It may be
possible to have a mode where the resolution would be done in a loop while
it succeeds.  If it fails, we collect the missing requirement, add a dummy
capability to solve it, and run again, or something similar.  We could then
print the missing requirements and install the bundles.
There's already a simulatation mode which runs the resolution and prints
the action that needs to be performed without actually modifying the
framework, so that could be another mode.  I don't foresee any technical
impossibility here, so it may be worth a try if there's a consensus.


> Another interesting fact here, the Require-Capability is only added for
> bundles using DS by the maven-bundle-plugin.
> Blueprint Bundles don't have it even though that could be generated easily
> from the reference-tag.
>

They are.  You're either using an old maven plugin, or you have disabled
the generation of the metadata.


>
> Regarding the feature validation goal, I doubt it would have shown that the
> pax-url-aether bundle was neglecting the providing capabilities manifest
> entries. Though I need to verify that with a test-case.
>

No, you're right, it could not have figured the pax-url-aether bundle was
wrong, because there's no way to know that a capability should have been
provided.  It's like if you forgot to export a package, no one could tell
you.
But it would have failed to validate the feature that was using it, i.e.
the one you want to install and which currently fail.


>
> regards, Achim
>
>
> 2015-02-12 0:39 GMT+01:00 Christian Schneider :
>
> > Am 11.02.2015 um 22:02 schrieb Guillaume Nodet:
> >
> >> The breaking change is that features are now verified before being
> >> installed.
> >> In karaf < 4, there was no verification step, and the installation of
> the
> >> feature was simply trying to install the bundles and start those.
> >>
> >
> > In most cases I like the verification. In some cases though especially
> > when I build the deployment I sometimes want the bundles to be installed
> > even if they do not even resolve.
> > The reason is that it is easier to debug what is wrong when the bundles
> > are in the system. So I would like to have an option to install even if
> the
> > verification fails. Kind of like the option in karaf
> > 2 and 3 where you leave the bundles installed in case of a failure.
> >
> > Doe that make sense?
> >
> > Christian
> >
> > --
> >  Christian Schneider
> > http://www.liquid-reality.de
> >
> > Open Source Architect
> > Talend Application Integration Division http://www.talend.com
> >
> >
>
>
> --
>
> Apache Member
> Apache Karaf  Committer & PMC
> OPS4J Pax Web  Committer &
> Project Lead
> blog 
> Co-Author of Apache Karaf Cookbook 
>
> Software Architect / Project Manager / Scrum Master
>

Re: [DISCUSSION] Karaf docker.io

[Achim Nierbeck]

Just some thoughts from the peanut-gallery here :-)

Besides that I like both ideas. Sometimes it would be nice to create a
docker image of the Karaf I just prepared to have all bundles/features
installed, especially when one wants to tinker with that image a bit more.
On the other hand I like the idea of building a docker image from a maven
build.

regards, Achim


2015-02-12 7:06 GMT+01:00 Jean-Baptiste Onofré :

> By the way, IMHO, it's also very convenient to take a running instance
> (where users installed features, changed config) and create a image with
> it. It's like the docker tag but from a Karaf perspective.
> Like this, users can "prepare" different instance state and "store" in
> docker image. That's the purpose of the Karaf docks.
>
> My 0.02 Pesos (ready for my Mexican vacation ;))
>
> Regards
> JB
>
> On 02/11/2015 10:06 PM, Guillaume Nodet wrote:
>
>> What I've been working on those past days is a way to build docker images
>> based on a "static distribution" of karaf generated from profiles.
>> So starting from profiles, one can easily generate a docker image and push
>> it to a registry.  The image would contain all the needed bundles and
>> would
>> not have to be further "provisioned".  I think this is more in line with
>> the "static container" idea which is the basis for docker.
>>
>> 2015-02-11 20:43 GMT+01:00 Jean-Baptiste Onofré :
>>
>>  Hi all,
>>>
>>> In order to provide an alternative to the instances, I started to work on
>>> a small PoC providing simple and convenient docker.io support in Karaf.
>>>
>>> The purpose is to easily manage images, containers, and be able to
>>> provision/create container with Karaf instances.
>>>
>>> For instance, this is a current available use case:
>>>
>>> 1/ You can create a docker.io container in two ways:
>>> 1.1/ karaf@root()> docker:bootstrap mydock
>>> creates a fresh docker.io container using karaf:3.0.3 image. I prepared
>>> different ready to use docker.io images for Karaf. I'm working on an
>>> embedded docker hub, with the appropriate commands to administrate it.
>>> 1.2/ karaf@root()> docker:provision mydock
>>> creates a docker.io container (using a karaf image) and copy the current
>>> running instance in the dock.
>>> 1.3/ It's also possible to start from a dockerfile.
>>> 2/ Once the dock (I named it dock meaning docker.io container where a
>>> karaf instance is living) is ready, you can control it using
>>> docker:start,
>>> docker:stop, docker:delete commands.
>>> 3/ it's possible to connect to a running dock using docker:connect
>>> command
>>>
>>> I'm working on docker:image*, docker:hub, and improve the existing
>>> docker*
>>> features.
>>>
>>> However, before moving forward on this, I would like to know if it makes
>>> sense and if people are interested by it.
>>>
>>> By the way, the code is on my github: http://github.com/jbonofre/
>>> karaf-docker.
>>>
>>> I will push my last changes tomorrow morning.
>>>
>>> Any comment is welcome.
>>>
>>> Thanks,
>>> Regards
>>> JB
>>> --
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master

Re: Karaf 4.0 : new behaviour of the feature resolver

[Achim Nierbeck]

Hi,

if it could be possible to add this feature back again, this clearly would
help. (the -c option)
Another interesting fact here, the Require-Capability is only added for
bundles using DS by the maven-bundle-plugin.
Blueprint Bundles don't have it even though that could be generated easily
from the reference-tag.

Regarding the feature validation goal, I doubt it would have shown that the
pax-url-aether bundle was neglecting the providing capabilities manifest
entries. Though I need to verify that with a test-case.

regards, Achim


2015-02-12 0:39 GMT+01:00 Christian Schneider :

> Am 11.02.2015 um 22:02 schrieb Guillaume Nodet:
>
>> The breaking change is that features are now verified before being
>> installed.
>> In karaf < 4, there was no verification step, and the installation of the
>> feature was simply trying to install the bundles and start those.
>>
>
> In most cases I like the verification. In some cases though especially
> when I build the deployment I sometimes want the bundles to be installed
> even if they do not even resolve.
> The reason is that it is easier to debug what is wrong when the bundles
> are in the system. So I would like to have an option to install even if the
> verification fails. Kind of like the option in karaf
> 2 and 3 where you leave the bundles installed in case of a failure.
>
> Doe that make sense?
>
> Christian
>
> --
>  Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>


-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master

Re: [VOTE] Release Apache Karaf 4.0.0.M2 technology preview.

[Heath Kesler]

+1 (non-binding)


Freeman Fang 
February 11, 2015 at 11:05 PM
+1
－
Freeman(Yue) Fang

Red Hat, Inc.
FuseSource is now part of Red Hat





Jamie G. 
February 10, 2015 at 4:02 AM
Hi,

We have 196 issues resolved on our way towards Apache Karaf 4.0.0 GA
release. This is a technology preview, as such there will be features
and other functionality not yet implemented. Please refrain from using
this particular RC in production.
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12329322

Staging repository:
https://repository.apache.org/content/repositories/orgapachekaraf-1023/

Release git tags:
4.0.0.M2

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.