I think the threads are getting mixed up ;-) I've created this feature about listing all the versions of features:
https://issues.apache.org/jira/browse/KARAF-2313 On Mon, May 13, 2013 at 1:47 PM, Jean-Baptiste Onofré <[email protected]>wrote: > features:list |grep -i spring ;) > > > On 05/13/2013 01:25 PM, Achim Nierbeck wrote: > >> 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] <mailto:[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]> <mailto:[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]> >> <mailto:[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]> >> <mailto:[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/> >> >> >> <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> >> >> >> <http://team.ops4j.org/wiki/**display/PAXVAADIN/Home<http://team.ops4j.org/wiki/display/PAXVAADIN/Home> >> >> >> Commiter & Project Lead >> blog >> <http://notizblog.nierbeck.de/**__<http://notizblog.nierbeck.de/__> >> > >> >> >> >> -- >> 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 >
