Adjust and clean-up/simplify sisu-OSGi-connect

[HannesWell]

This PR is split in two commits.

1. A few minor clean-ups/simplifications for the code of sisu-osgi-connect that I noticed while working on Add PDE API Tools Mojo for Tycho #1328.

2. The path for the connect.bundles file is fixed in the release-notes and the path of the connect.properties is changed from META-INF/sisu-connect.properties to META-INF/sisu/connect.properties, to correspond to META-INF/sisu/connect.bundles.
   @laeubi I assume that was the actual intention, wasn't it?

[github-actions]

Test Results

328 files  328 suites   2h 13m 49s ⏱️
292 tests 288 ✔️ 4 💤 0 ❌
584 runs  575 ✔️ 9 💤 0 ❌

Results for commit 34712da.

♻️ This comment has been updated with latest results.

[laeubi]

Yeah the path part was changed at the development phase a bit, an I'm not completely happy with the way to configure this but I think we need to get some experience with that :-)

[HannesWell]

Yeah the path part was changed at the development phase a bit, an I'm not completely happy with the way to configure this but I think we need to get some experience with that :-)

No problem, its a new thing and it is really hard to know from the beginning how to use it/configure it in all cases. :)

Two other things I noticed (that maybe should be addressed separately if we know we need it):

• A EquinoxServiceFactory with hint="connect" cannot be injected into Mojo but into a Plexus-Component, but a factory with hint "tycho-core" can be injected into a Mojo. I have no clue why, but at least I was not able to do that in Add PDE API Tools Mojo for Tycho #1328 and therefore created a separated component.
• EquinoxServiceFactory only launches a framework when querying a service, but in some cases one only wants to launch the framework without querying a service, because the desired class is not available as OSGi-Service and has to be instantiated directly. At least that is the case in Add PDE API Tools Mojo for Tycho #1328 (given that it uses/works with osgi-connect finally).
  But we can discuss that in Add PDE API Tools Mojo for Tycho #1328.

[laeubi]

• A EquinoxServiceFactory with hint="connect" cannot be injected into Mojo but into a Plexus-Component, but a factory with hint "tycho-core" can be injected into a Mojo.

Please be carefull that Mojo + Plexus Component use different annotations (@Component versus @Requirement) and one can't mix both!

• EquinoxServiceFactory only launches a framework when querying a service, but in some cases one only wants to launch the framework without querying a service, because the desired class is not available as OSGi-Service and has to be instantiated directly.

Yes, OSGi is all about services, so you should use them. Anyways you can query any service if you think you can do better without it even getService(Object.class)

[HannesWell]

• A EquinoxServiceFactory with hint="connect" cannot be injected into Mojo but into a Plexus-Component, but a factory with hint "tycho-core" can be injected into a Mojo.

Please be carefull that Mojo + Plexus Component use different annotations (@Component versus @Requirement) and one can't mix both!

🤦🏽‍♂️ looks like I indeed blindly copied it and didn't notice @Component versus @Requirement. Thanks for the hint! That should be it.

• EquinoxServiceFactory only launches a framework when querying a service, but in some cases one only wants to launch the framework without querying a service, because the desired class is not available as OSGi-Service and has to be instantiated directly.

Yes, OSGi is all about services, so you should use them. Anyways you can query any service if you think you can do better without it even getService(Object.class)

In the mentioned case there was simply no useful service that I could query, but yes I just queried some unused service to launch the osgi-instance. But using Object probably indicates the intend of not using it better.

[laeubi]

In the mentioned case there was simply no useful service that I could query

Then probably there should be one!

Just keep in mind that the whole purpose of connect is to interact with the OSGi framework (otherwise you might better instantiate the classes directly without any OSGi), so you can ave you a lot of trouble if there is a service you can call and that do the dirty bits without you knowing. I also used something similar anyways but more as a legacy way, so you should be able to directly use any class up to a point where one service will be required. And yes Eclipse is nasty in its usage of static activator access... a good opportunity to fix that and using real service/ds instead :-)

[HannesWell]

In the mentioned case there was simply no useful service that I could query

Then probably there should be one!

Just keep in mind that the whole purpose of connect is to interact with the OSGi framework (otherwise you might better instantiate the classes directly without any OSGi), so you can ave you a lot of trouble if there is a service you can call and that do the dirty bits without you knowing. I also used something similar anyways but more as a legacy way, so you should be able to directly use any class up to a point where one service will be required. And yes Eclipse is nasty in its usage of static activator access... a good opportunity to fix that and using real service/ds instead :-)

Fully agree, but that is a huge task since that pattern is used very often in the Eclipse eco-system.

[laeubi]

Fully agree, but that is a huge task since that pattern is used very often in the Eclipse eco-system.

Every little piece counts :-) As DS now days even require less setup I don't see a reason to not use it ...

[HannesWell]

Fully agree, but that is a huge task since that pattern is used very often in the Eclipse eco-system.

Every little piece counts :-) As DS now days even require less setup I don't see a reason to not use it ...

That's right. I just meant it is too much to wait for it now. :)

Besides that, do you have any more remarks? If not I think this is ready.

[laeubi]

Sounds reasonable!