On Mon, Mar 9, 2015 at 10:48 AM, Felix Meschberger <fmesc...@adobe.com>
wrote:
> Hi
>
> What prevents you from doing this with your build tooling ? This should,
> apart from the bundle.id part, be rather easy.
>
You can't see runtime info from the build!
This is the main point!
>
> E.g. leveraging the resource filtering feature of Maven
>
> Regards
> Felix
>
> > Am 09.03.2015 um 15:08 schrieb Raymond Auge <raymond.a...@liferay.com>:
> >
> > On Mon, Mar 9, 2015 at 6:18 AM, Carsten Ziegeler <cziege...@apache.org>
> > 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
> >> 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)
>
>
> ---------------------------------------------------------------------
> 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)
