Hi Steve, my answer inline:
1.) A container has a Feature installed, “example-app”, at version 1.0. Now let’s say I decide I want to run version 1.1 at some point down the road. Would the best practice be to first uninstall the Feature at version 1.0 and then install version 1.1, or to just install version 1.1 directly (skipping the explicit uninstall step)? Currently I use the FeaturesService programmatically to uninstall the old version prior to install the new. While this seems to work fine, I thought it wise to inquire if there was an existing best practice around this or, perhaps, potential pitfalls to be avoided.
We don't provide features:update or equivalent mechanism because it's not so trivial, especially for transitive features.
Generally speaking, the best practice is to uninstall the "example-app" feature first, and install using the new feature version. Actually, it depends of the components shared between the two features. As I guess that you share most of the components, it's better to uninstall/install.
features:update is on my TODO list.
2.) The provisioning agent itself is installed as part of a Feature. I currently let the agent install a new version of its encapsulating Feature. With other Features not associated with the agent, as I mentioned in question #1, I explicitly uninstall the old version prior to installing the new. For the agent I don’t do this to prevent a “bundle-suicide” type of situation. When the agent installs a new version of its encapsulating Feature this triggers an implicit framework restart after which the new version is installed and the older version uninstalled. Interestingly enough, if I try to go the other direction, say from 1.1 back to 1.0, I get unfulfilled dependencies that prevent the older version of the Feature from installing (and both features end up uninstalled). The dependency in question (commons-lang 3.x) is actually embedded in both version 1.0 and 1.1 of the bundle containing the application (both bundles are identical except in version number for testing). I suspect the old version is attempting to import packages from the new version’s bundle, but fails to do so because the latter is then invalid. Should I allow my agent to install a new version of its encapsulating Feature or is this going down the wrong road? Is there a best practice (or any advice) around a Feature self-update scenario?
The best way is probably to define a kind of "my-common" feature, with dependency="true" on their bundles (defining commons-lang, etc). Like this, even if you update the next agent feature, it won't change the common part (if I right understood ;)).
Regards JB
I will greatly appreciate any information/advice that can be given (even “RTFM” if you can point me to the right manual). Thanks! -Steve
-- Jean-Baptiste Onofré [email protected] http://blog.nanthrax.net Talend - http://www.talend.com
