could you open a jira issue for your feature request for the shell, that it
lists all versions available.
thanks, Achim


2013/5/13 Frank Lyaruu <[email protected]>

> 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
>>
>
>


-- 

Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
Commiter & Project Lead
blog <http://notizblog.nierbeck.de/>

Reply via email to