Hi Tim,
I added this plugin repository and change the bnd.version property to
4.2.0-SNAPSHOT, but still get errors during the build with eroor message
"No plugin found for prefix 'bnd-indexer' ..."
Maven complains about several metadata being invalid, e.g.:
The metadata
/home/gitpod/.m2/repository/biz/aQute/bnd/bnd-maven-plugin/4.2.0-SNAPSHOT/maven-metadata-Bnd
Snapshots.xml is invalid
The metadata
/home/gitpod/.m2/repository/biz/aQute/bnd/bnd-maven-plugin/4.2.0-SNAPSHOT/maven-metadata-Bnd
Snapshots.xml is invalid
The POM for biz.aQute.bnd:bnd-maven-plugin:jar:4.2.0-20190215.224729-106
is invalid
...
You can have a look at the workspace and try it for yourself if you
want: https://gitpod.io#snapshot/9f4e97ad-0dd3-4360-8702-de0fedf9e51f
Just type "resolve app" in the command line.
Kind regards,
Thomas
------ Originalnachricht ------
Von: "Tim Ward" <tim.w...@paremus.com>
An: "Thomas Driessen" <thomas.driessen...@gmail.com>
Cc: "Neil Bartlett" <njbartl...@gmail.com>; "OSGi Developer Mail List"
<osgi-dev@mail.osgi.org>
Gesendet: 18.02.2019 10:53:23
Betreff: Re: [osgi-dev] Clarification on reference behavior regarding
field injection
When I change the version number of bnd to 4.2.0 in the standard
enRoute setup, then some of the bnd-plugins can not be found by
maven.
That’s because and 4.2.0 isn’t released yet - you need to add a plugin
repository containing 4.2.0-SNAPSHOT (which is also the version you
should be using. If you look at the readme for the bnd repo on GitHub
you can see the repo url is
https://bndtools.jfrog.io/bndtools/libs-snapshot/
Tim
On 18 Feb 2019, at 10:51, Thomas Driessen
<thomas.driessen...@gmail.com> wrote:
Hi Neil,
thanks for this small history lesson on OSGi. You live, you learn. The
why is in most cases so much more interesting than the what :)
I will open an issue on Github then for bnd.
Kind regards,
Thomas
------ Originalnachricht ------
Von: "Neil Bartlett" <njbartl...@gmail.com>
An: "Thomas Driessen" <thomas.driessen...@gmail.com>; "OSGi Developer
Mail List" <osgi-dev@mail.osgi.org>
Cc: "Tim Ward" <tim.w...@paremus.com>
Gesendet: 18.02.2019 10:44:14
Betreff: Re: [osgi-dev] Clarification on reference behavior regarding
field injection
On Mon, Feb 18, 2019 at 9:39 AM Thomas Driessen via osgi-dev
<osgi-dev@mail.osgi.org> wrote:
Hi Tim,
as always thanks for your super detailed answer!
Just two more questions on this topic:
1) Out of curiosity: do you know why the decision was made to make
the default for @Reference List<ITest> static, reluctant? For 0/1..1
this makes sense to me, but for me an expected default behavior for
0/1..n references would have been dynamic, greedy, so that I end up
with some services isntead of probably none.
The default is reluctant because "greedy" did not exist until DS 1.2.
If the default had been made greedy at that time, components coded
before DS 1.2 would have seen a substantial change in behaviour that
could be considered non-backwards-compatible.
Static has *always* been the default over dynamic, because dynamic
forces the developer to understand thread safety and to code the
component much more cautiously. Static is simple and safe.
2) The observed Exception for optional/dynamic/reluctant: Is it
intended? I tried to switch to bnd 4.2.0 to see if this exxception
occurs there too, but was unable to do so. When I change the version
number of bnd to 4.2.0 in the standard enRoute setup, then some of
the bnd-plugins can not be found by maven.
Probably not expected, this smells like a bug.
Kind regards,
Thomas
------ Originalnachricht ------
Von: "Tim Ward" <tim.w...@paremus.com>
An: "Thomas Driessen" <thomas.driessen...@gmail.com>; "OSGi
Developer Mail List" <osgi-dev@mail.osgi.org>
Cc: "Raymond Auge" <raymond.a...@liferay.com>
Gesendet: 18.02.2019 10:15:54
Betreff: Re: [osgi-dev] Clarification on reference behavior
regarding field injection
Hi Thomas,
Just to clarify, the behaviour that you see with static reluctant
services will always look “odd” for cardinalities other than
mandatory, and what you’ve recorded is 100% correct behaviour.
Static references force the component to be re-created if the value
of the reference changesReluctant references avoid rebinding the
service unless it is required
Therefore:
An optional reference bound to nothing will never bind to anything
again (unless the component is re-created for another reason)
because having zero references is valid and you are reluctant to
re-create the component instanceAn optional reference bound to a
service will not change until that service is unregistered
(ignoring all new services), at which point it will either:Pick up
the highest ranked of any matching registered servicesBind to
nothing if no matching services are availableA multiple reference
bound to nothing will behave exactly like an optional componentA
multiple reference bound to one or more services will not change
until any of the bound services are unregistered (ignoring all new
services), at which point it will either:Pick up all the available
registered servicesBind to nothing if no matching services are
availableAn “at least one" reference bound to one or more services
will not change until any of the bound services are unregistered
(ignoring all new services), at which point it will either:Pick up
all the available registered servicesMake the component unsatisfied
The end result of this is that references that can accept zero will
tend to zero over time, and then tend to stay with zero bound
references. At least one references will tend to a small number of
“stable” services with new services ignored.
In general references of these types should be dynamic or greedy
(or both).
Best Regards,
Tim
On 18 Feb 2019, at 09:38, Thomas Driessen via osgi-dev
<osgi-dev@mail.osgi.org> wrote:
Oh Sorry :/
Those combinations with cardinalities optional/mandatory have been
assigned to ITest, those with multiple/at_least_one have been
assigned to List<ITest>.
I didn't think it makes sense to assign them vice versa, e.g.,
ITest with multiple or List<ITest> with mandatory? Or am I wrong?
If so, in what case would you use such a combination?
Kind regards,
Thomas
------ Originalnachricht ------
Von: "Raymond Auge" <raymond.a...@liferay.com>
An: "Thomas Driessen" <thomas.driessen...@gmail.com>; "OSGi
Developer Mail List" <osgi-dev@mail.osgi.org>
Gesendet: 16.02.2019 17:42:19
Betreff: Re: [osgi-dev] Clarification on reference behavior
regarding field injection
You're chart doesn't appear to list _which_ field (Reference) was
associated with any given line (collection vs. scalar). It makes
a difference.
- Ray
On Sat, Feb 16, 2019 at 9:15 AM Thomas Driessen via osgi-dev
<osgi-dev@mail.osgi.org> wrote:
Hi,
I'm trying to get an overview over the effects of different
combinations of cardinality, policy and policyOption within a
@Reference annotation for a field.
My Example looks like this:
@Component
public class MyComp{
@Reference(...)
ITest myTest;
@Reference(...)
List<ITest> myTests;
}
and the observed behavior for this setup with different
combinations of the above named properties is:
<image.png>
I'm especially interested in the yellow marked cases: Is this an
intended behavior?
Kind regards,
Thomas
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
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)
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
