Hi, The build works fine for me in GitPod. You probably have corrupt things in your local repo, either delete them or force an update of snapshots (-U on the command line). Note that you also get a nice error message for the case that you claim didn’t work:
[ERROR] Failed to execute goal biz.aQute.bnd:bnd-maven-plugin:4.2.0-SNAPSHOT:bnd-process (default) on project impl: In component io.jatoms.osgi.refs.ComponentImpl, field tests policy is 'dynamic' and field is not volatile. -> [Help 1] Best Regards, Tim > On 18 Feb 2019, at 13:45, Thomas Driessen <thomas.driessen...@gmail.com> > wrote: > > 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 > <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 <mailto:tim.w...@paremus.com>> > An: "Thomas Driessen" <thomas.driessen...@gmail.com > <mailto:thomas.driessen...@gmail.com>> > Cc: "Neil Bartlett" <njbartl...@gmail.com <mailto:njbartl...@gmail.com>>; > "OSGi Developer Mail List" <osgi-dev@mail.osgi.org > <mailto: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/ >> <https://bndtools.jfrog.io/bndtools/libs-snapshot/> >> >> Tim >> >>> On 18 Feb 2019, at 10:51, Thomas Driessen <thomas.driessen...@gmail.com >>> <mailto: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 <mailto:njbartl...@gmail.com>> >>> An: "Thomas Driessen" <thomas.driessen...@gmail.com >>> <mailto:thomas.driessen...@gmail.com>>; "OSGi Developer Mail List" >>> <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>> >>> Cc: "Tim Ward" <tim.w...@paremus.com <mailto: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 <mailto: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 <mailto:tim.w...@paremus.com>> >>>> An: "Thomas Driessen" <thomas.driessen...@gmail.com >>>> <mailto:thomas.driessen...@gmail.com>>; "OSGi Developer Mail List" >>>> <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>> >>>> Cc: "Raymond Auge" <raymond.a...@liferay.com >>>> <mailto: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 changes >>>>> Reluctant 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 >>>>> instance >>>>> An 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 services >>>>> Bind to nothing if no matching services are available >>>>> A multiple reference bound to nothing will behave exactly like an >>>>> optional component >>>>> A 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 services >>>>> Bind to nothing if no matching services are available >>>>> An “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 services >>>>> Make 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 <mailto: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 >>>>>> <mailto:raymond.a...@liferay.com>> >>>>>> An: "Thomas Driessen" <thomas.driessen...@gmail.com >>>>>> <mailto:thomas.driessen...@gmail.com>>; "OSGi Developer Mail List" >>>>>> <osgi-dev@mail.osgi.org <mailto: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 <mailto: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 <mailto:osgi-dev@mail.osgi.org> >>>>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>>>>> <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 <mailto:osgi-dev@mail.osgi.org> >>>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev> >>>> _______________________________________________ >>>> OSGi Developer Mail List >>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> <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
