On Mon, Mar 9, 2015 at 10:29 AM, Carsten Ziegeler <cziege...@apache.org> wrote:
> 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? > It's most often calculated during the build and you can't really see the result until the bundle is running. > > 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 > > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
