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
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
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
I think you have prematurely decided on a solution and have not analyzed your
requirements from a sufficiently abstract level.
There are a ton of ways to specify wiring that don't augment the ds spec.
From a more conceptual level, what is determining which Fum a particular Foo is
wired to?
Am 09.03.15 um 16:10 schrieb Raymond Auge:
In fact, I would be satisfied it there were placeholders ONLY for the
service properties which can only be known at runtime.
Thanks Ray, I understand your use case now.
You have to somehow - at runtime - provide your mapping, so for all your
Foo
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 raymond.a...@liferay.com:
On Mon, Mar 9, 2015 at
In fact, I would be satisfied it there were placeholders ONLY for the
service properties which can only be known at runtime.
On Mon, Mar 9, 2015 at 11:07 AM, Raymond Auge raymond.a...@liferay.com
wrote:
Allow me to demonstrate using a real world scenario we have right now.
There is an API
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
Allow me to demonstrate using a real world scenario we have right now.
There is an API comprised of at least two parts - Foo Fum
There are many implementations of Foo and Fum coming from many bundles
However, the typical case is also that a Foo impl uses it's own Fum impl.
So, your first
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
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 =
11 matches
Mail list logo
