JB,
not about the features:update but about the new requirement to list all
versions available :-)

regards, Achim


2013/5/13 Jean-Baptiste Onofré <[email protected]>

> AFAIR, we already have a Jira about features:update "alias".
>
> Regards
> JB
>
>
> On 05/13/2013 01:00 PM, Achim Nierbeck wrote:
>
>> 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] <mailto:[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] <mailto:[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] <mailto:[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/<http://wiki.ops4j.org/display/paxweb/Pax+Web/>>
>> Committer
>> & Project Lead
>> OPS4J Pax for Vaadin 
>> <http://team.ops4j.org/wiki/**display/PAXVAADIN/Home<http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
>> >
>> Commiter & Project Lead
>> blog <http://notizblog.nierbeck.de/**>
>>
>
> --
> 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