Am 09.03.15 um 15:08 schrieb Raymond Auge: > > This also isn't the goal. The goal is to automate/simplify parts which you > don't want to handle via configuration. For instance you would never use > the bundle.id because that would be foolish since uninstall and reinstall > would make the configuration invalid. > > However, there are many details for which it might be useful to be able to > apply filters on, but due to their dynamic nature its impractical to use > them because you must hard code the values currently. This is true for > almost all details of a bundle at runtime. > > It's also true that some information you don't want to duplicate. For > instance, anything that is in the manifest you probably want to keep > centralized there, and not require a developer to duplicate it since this > causes a change management problem. > > So, my thought about where the information for replacement is that it would > come from only > - bundle runtime info
What exactly do you mean with that? > - manifest How is this different from a properties file in the bundle? Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
