JB, Thank you very much for the quick reply; you definitely answered my questions. I appreciate you taking the time to assist me in this matter. I feel much more confident that I'm proceeding appropriately.
Best Regards, -Steve On Fri, Nov 15, 2013 at 12:19 PM, Jean-Baptiste Onofré <[email protected]> wrote: > 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
