Hi What prevents you from doing this with your build tooling ? This should, apart from the bundle.id part, be rather easy.
E.g. leveraging the resource filtering feature of Maven Regards Felix > Am 09.03.2015 um 15:08 schrieb Raymond Auge <[email protected]>: > > On Mon, Mar 9, 2015 at 6:18 AM, Carsten Ziegeler <[email protected]> > wrote: > >> Am 08.03.15 um 16:24 schrieb Raymond Auge: >>> Would people be opposed to felix scr supporting property replacement >>> something like (à la spring PropertyPlaceholderConfigurer): >>> >>> // implied from bundle runtime details >>> @Reference(target = "(service.bundleid=${bundle.id})") >>> >>> // implied from bundle headers >>> @Reference(target = "(context.path=${Web-ContextPath})") >>> >>> etc. >>> >>> One might overload the KXml2SAXParser.getAttributeValue(i) method which >>> scans for replaceable tokens where KXml2SAXParser is passed the bundle in >>> it's constructor. >>> >> I think this one will be troublesome. Apart from having a proprietary >> extension where do those values come from? >> > > Bundle headers, and bundle details. > > >> Then you have the "properties" element which you could use to point to >> a properties file in your bundle overriding the values - I guess that's >> not working for your case. >> > > This can't work. You can only get information which exists before coming > into the runtime which is not the goal. > > >> And finally you can change the values through a configuration, so >> instead of coming up with a new way to get a value for the placeholders >> you create a configuration that set the [reference].target property to >> the appropriate value. >> > > 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 > - manifest > > Sincerely, > - Ray > > > >> >> Regards >> Carsten >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> [email protected] >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > *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) --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
