Thanks for the replies, guys.

I did some more research, and I have figured out some improvements over my
last workflow:

I was under the impression that Karaf did not support multiple versions of
the same feature, forcing me to uninstall + remove the old repository
first. My biggest concern with that was that I needed to *know* which
features would change.

As it turns out, it's more of a Karaf shell problem. I can add the new repo
first, but when I do a feature:list I will see only the latest version, and
it will show it as uninstalled. The previous installed feature is
completely hidden.

If I do feature:uninstall + feature:install it does an upgrade to the
latest version. So it works, but in the shell I'm kind of flying blind.

The webconsole works better than the command line: If I add the new
repository first, as expected the webconsole shows both the new and the old
features. From there I can see the different versions, uninstall the old,
install the new version and finally remove the old repo. A feature update
button would be nice but that is just convenience.

So all and all: A feature:update would be nice as a convenience, I think it
would make sense if feature:list would show all versions of the features,
like the feature tab in the web console does, that would ease most of my
pain.

regards, Frank



On Sun, May 12, 2013 at 9:26 PM, Jean-Baptiste Onofré <[email protected]>wrote:

> Hi guys,
>
> Currently, we have to distinguish features and features repositories.
>
> For features repositories, you have refresh-url (or add-url again) that
> reload a features XML descriptor.
>
> The update of a feature is more tricky. Now, the update is features
> uninstall/install.
> The point is that features update is not so simple, especially about
> transitive features. If it would be so simple, features update would exist
> since a long time.
> I remember a lot of discussions with Guillaume about features update.
>
> Basically, we can provide feature:update as an alias to
> feature:uninstall/features:**install (it's a first step).
>
> A largely more complex logic should be implemented if we want to talk
> about "real" features update.
>
> Regards
> JB
>
>
> On 05/12/2013 06:13 PM, Christian Schneider wrote:
>
>> Currently there is no such update functionality in karaf. The list of
>> commands you supplied is the current best practice when updating features.
>>
>> What I could imagine is a command like.
>>
>> feature:update <repo-name> <new-version>
>>
>> It should update all currently installed features from the repo to the
>> new version.
>>
>> As long as the new feature repo has all the features that are currently
>> installed such a command should be doable. Some problems arise for
>> special cases:
>> - Like the new feature has changed feature dependencies that require
>> other feature updates
>> - Some features are deleted or added that are needed
>> - Config files have changed in an incompatible way.
>>
>> I think these things are the reason why it has not been implemented. We
>> could try to implement the simple case first of course. I think it would
>> be a good thing for 3.1.
>>
>> Christian
>>
>> Am 12.05.2013 12:52, schrieb Frank Lyaruu:
>>
>>> Hello people of Karaf,
>>>
>>> I'm looking for a way to update Karaf features in my application.
>>>
>>> We have an application, of about 140 bundles, spread over about 10
>>> Karaf features, currently on Karaf 3.0.0 RC1.
>>>
>>> For example, when I release a new bundle version, I'd like to update
>>> our servers to use that new version, with a minimum of downtime. What
>>> I do now, is:
>>> 1) Release the bundle to a Maven repository
>>> 2) Update the features.xml file, update the feature version and deploy
>>> it to Maven (with a new version number)
>>> 3) Uninstall the feature from the servers
>>> 4) Remove the old mvn: feature repo from the server instance
>>> 5) Add the new mvn: feature repo to the server instance
>>> 6) Install the new feature
>>>
>>> Mind you, this works fine, but it seems more complicated than
>>> necessary, and it 'creates more waves' in the application as the whole
>>> feature has to be uninstalled first.
>>>
>>> Is there a way to 'update' a repo (determine the features that have
>>> been updated, and for each feature determine the bundles that have
>>> changed, and update just those)
>>>
>>> Is anything like this possible? Or a completely different way to do
>>> this? If not, and you think this makes sense, I'm willing to help out
>>> if someone can point me in the right direction.
>>>
>>> regards, Frank
>>>
>>
>>
>>
> --
> Jean-Baptiste Onofré
> [email protected]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Reply via email to