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/>> 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] <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/> Committer
& Project Lead
OPS4J Pax for Vaadin <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
