Yes, that's exactly why I haven't done that in the first place.
On Sun, May 22, 2011 at 08:27, David Jencks wrote:
> If we do this I think this is how to do it but I'm not at all convinced the
> code complexity is worth the possible convenience.
>
> thanks
> david jencks
>
> On May 21, 2011, at
Thanks for the clarification :-) These are supported in trunk. I think I'd
call them a feature dependency.
thanks
david jencks
On May 21, 2011, at 12:16 AM, Ioannis Canellos wrote:
> Forgive me if I didn't express my self right. By inner feature I mean the
> reuse of a top-level feature insid
If we do this I think this is how to do it but I'm not at all convinced the
code complexity is worth the possible convenience.
thanks
david jencks
On May 21, 2011, at 12:55 AM, Guillaume Nodet wrote:
> Maybe an easier way would be to track features that have been
> explicitely installed differe
On a related note, I think it is also more intuitive if configurations
installed with a feature are deleted when the feature is uninstalled.
On Sat, May 21, 2011 at 5:09 AM, Andreas Pieber wrote:
> Tbh i a also like the idea this would be imho the most intuitive behavior
> user expect anyhow :-)
+1
-Original Message-
From: Guillaume Nodet
Date: Sat, 21 May 2011 09:55:03
To:
Reply-To: dev@karaf.apache.org
Subject: Re: Uninstall of inner features
Maybe an easier way would be to track features that have been
explicitely installed differently than features than have been
Tbh i a also like the idea this would be imho the most intuitive behavior
user expect anyhow :-)
Kind regards Andreas
On May 21, 2011 10:07 AM, "Ioannis Canellos" wrote:
>>
>> When those dependant features are no longer used by currently
>> installed features, they could be uninstalled automatica
>
> When those dependant features are no longer used by currently
> installed features, they could be uninstalled automatically.
> Imho, that would be fully transparent from a user pov (and i think it
> should be that way).
>
That would be the best possible solution.
--
*Ioannis Canellos*
*
ht
Maybe an easier way would be to track features that have been
explicitely installed differently than features than have been
selected automatically because they are dependencies.
When those dependant features are no longer used by currently
installed features, they could be uninstalled automaticall
>
> It could be dangerous to uninstall a top level feature which could be used
> in others features.
Indeed. This is why I am trying to find a solution around it. To recap
possible solutions:
a) When uninstalling a feature, check if it contains references to other top
level features and for each
ok got it :)
I was thinking features like:
...
where other is defined only as an inner feature.
It could be dangerous to uninstall a top level feature which could be
used in others features.
Regards
JB
On 05/21/2011 09:16 AM, Ioannis Canellos wrote:
Forgive me if I didn't expr
Forgive me if I didn't express my self right. By inner feature I mean the
reuse of a top-level feature inside an other feature.
To reuse JB's example:
other
in this case if I do
features:install my
features:uninstall my
feature other will remain installed.
--
*Ioannis Canellos*
*
http://
Yes,
but the users can set:
other
And other is defined as a top level feature.
Regards
JB
On 05/21/2011 09:04 AM, Ioannis Canellos wrote:
I don't understand how using an inner feature promotes reuse. I would
think it would tend to prevent reuse. So far I don't think inner features
are
Hi Ioannis,
I don't understand the usage of an inner feature. Basically, what the
differences between a top level feature and an inner feature ?
If the assumption is that the inner feature life cycle (install,
uninstall, start, stop) is the same as its parent feature, why not
putting directl
>
> I don't understand how using an inner feature promotes reuse. I would
> think it would tend to prevent reuse. So far I don't think inner features
> are a good idea.
It promotes reuse because it allows you to "reuse" existing features as
inner features.
--
*Ioannis Canellos*
*
http://ioc
"inner features" aren't consistent with the features schema in trunk. You can
only have a reference to another top level feature.
I don't understand how using an inner feature promotes reuse. I would think it
would tend to prevent reuse. So far I don't think inner features are a good
idea.
An other option would be the ability to create "abstract features". Abstract
features could be feature that cannot be installed on their own, but only as
inner features and have features:unistall automatically remove them if there
is no feature using them.
--
*Ioannis Canellos*
*
http://iocanel.
A week ago I saw a question in the user list regarding uninstalling inner
features.
Our reply was that when a feature gets uninstalled its inner feature remain
there (which is how things currently work).
Wouldn't be great if we could implement a mechanism that would uninstall
inner features too,
17 matches
Mail list logo
