Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

[Jürgen Albert via osgi-dev]

Hi Ray,

I love this reply, we should frame it somewhere! :-)

Amen to that and a happy new year to you and Pam.

Jürgen.

Am 03/01/2020 um 17:02 schrieb Raymond Auge via osgi-dev:



On Fri, Jan 3, 2020 at 10:29 AM Martin Petzold > wrote:


IMHO: Manifest-first is best. p2 is hell. maven-bundle-plugin and
bnd "hate" Eclipse. It was never easy. The worst ever was not to
find together!

Sounds like you may not have tried bndtools.m2e integration in a long 
time or ever. OSGi, bnd, bndtools.m2e + Eclipse are a happy team that 
I use every single day on about 15 projects, including in IDE 
integration testing and live coding!


Furthermore, the bnd team (disclosure: of which I am part) are very 
active [1] in improving the IDE experience and are more than happy to 
address any issues you encounter.


Anyway, if you like what you have then more power to you :) but it 
seems like you might be alone on an island which can be awesome!... 
but it can also be bad.


Sincerely,
- Ray

[1] https://github.com/bndtools/bnd/pulse/monthly *(Activity - 1 
month: 49 merged pull requests, 68 commits, 29 closed issues, 3 new 
issues)*


=> My approach works well, I have a lot under my control and am
able to migrate to plain Java (with or without modules) if it is
required

I still love the OSGi specifications and framework, use a lot of
them, and learned a lot of them and all people involved!

Am 03.01.20 um 16:22 schrieb Dirk Fauth:


I also think that the chosen approach is not the best. Actually
it is a mixture of Tycho and plain maven that mostly works but
can lead to resolution issues like the one discussed.

For plain OSGi and Maven I agree with Ray. But you need to
migrate to bnd of course and get rid of the manual manifest
configuration (which is good IMHO).

If you really want to stick with manual manifest management, you
should use Tycho in its intended way by using repositories or a
target definition so the dependencies can be resolved
automatically via p2. pomDependencies consider is intended for
adding dependencies that are not available via p2 update sites.

But of course this is only my personal opinion based on my
experience.

Greez,
Dirk

Raymond Auge mailto:raymond.a...@liferay.com>> schrieb am Fr., 3. Jan. 2020,
15:49:

I would recommend, since you are using maven, not really
using tycho for much AND in order to future proof your OSGi
application you should probably migrate to
bnd-*-maven-plugin(s) [1]

These are better integrated with maven, maven scopes and give
you a full cycle of tools to go from building to running.
Also it's the most cutting edge OSGi build support under the
hood and will reduce your MANIFEST editing to its most minimal.

- Ray

[1] https://github.com/bndtools/bnd/blob/master/maven/README.md

On Fri, Jan 3, 2020 at 9:35 AM Martin Petzold via osgi-dev
mailto:osgi-dev@mail.osgi.org>> wrote:

I'm using:


consider


It is working now with the following dependencies in my
POM for build/compile time. At runtime I use
org.eclipse.osgi (without the service and util bundle)
and implementations of cm (apache felix), event (apache
felix), and log (within org.eclipse.osgi an my own).




org.eclipse.platform
org.eclipse.osgi
${dependency.org.eclipse.osgi}





org.osgi
    org.osgi.service.cm

    ${dependency.org.osgi.service.cm
}


org.osgi
org.osgi.service.event
${dependency.org.osgi.service.event}


org.osgi
org.osgi.service.log
${dependency.org.osgi.service.log}


Am 03.01.20 um 15:29 schrieb Dirk Fauth:

Well afaik Tycho has its own reactor for resolving
dependencies. That's why I am a bit confused about your
message. If you build via Tycho you need to have a
working target definition or repositories configuration.
POM dependencies are not considered by default. If you
update to R7 you need to update to a current Eclipse
update site and ensure that all related bundles and/or
features are included.

But of course I am not sure if I understand your issue
completely. If you are not building using Tycho but
plain Maven probably some dependencies are not
resolvable. But the previous answers already covered
most topics. I just stepped in because of 

Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

[Jürgen Albert via osgi-dev]

Hallo Martin,

ich verfolge gerade deine Diskussion in der OSGi Dev Group (mein Kollege 
Mark Hoffmann hatte sich da auch schon einmal zu Wort gemeldet). 
Ähnliche Problemem wie du sie beschreibst hatten wir früher auch, als 
wir noch die PDE und Tycho verwendet haben. Mit dem Umstieg auf BND 
haben die sich alle in Luft aufgelöst. Rückblickend haben wir 
festegestellt, dass die PDE und Tycho fundamental falsche Ansätze 
verfolgen. Manifest First ist einer davon. Bis wir umgestiegen sind 
konnten wir uns auch nicht vorstellen wie falsch der ist, da wir es nie 
anders kannten. Viele Konzepte von OSGi sind uns dadruch aber immer 
verwehrt geblieben und werden es auch langfristig bleiben, da z.B. die 
PDE die aktuelle Version der Component Annotations gar nicht unterstützt.


Wir haben im letzten Jahr verschiedenen Firmen und Projekte beim Umstieg 
zu BND unterstützt und das Eesultat war immer ein wesentlich 
effizienterer Entwicklungsprozess und sauberere Bundles. Ich schreibe 
dir ausserhalb der Mailing List, da ich dir unsere Untersützung anbieten 
möchte. Wir haben exakt die von dir beschriebenen Probleme schon in 
verschiedenen Kontexten gelöst.


Falls du interesse an unserer Hilfe hast, melde dich einfach.

Gesundes neues noch,

Jürgen Albert.

Am 03/01/2020 um 16:29 schrieb Martin Petzold via osgi-dev:


IMHO: Manifest-first is best. p2 is hell. maven-bundle-plugin and bnd 
"hate" Eclipse. It was never easy. The worst ever was not to find 
together!


=> My approach works well, I have a lot under my control and am able 
to migrate to plain Java (with or without modules) if it is required


I still love the OSGi specifications and framework, use a lot of them, 
and learned a lot of them and all people involved!


Am 03.01.20 um 16:22 schrieb Dirk Fauth:

I also think that the chosen approach is not the best. Actually it is 
a mixture of Tycho and plain maven that mostly works but can lead to 
resolution issues like the one discussed.


For plain OSGi and Maven I agree with Ray. But you need to migrate to 
bnd of course and get rid of the manual manifest configuration (which 
is good IMHO).


If you really want to stick with manual manifest management, you 
should use Tycho in its intended way by using repositories or a 
target definition so the dependencies can be resolved automatically 
via p2. pomDependencies consider is intended for adding dependencies 
that are not available via p2 update sites.


But of course this is only my personal opinion based on my experience.

Greez,
Dirk

Raymond Auge > schrieb am Fr., 3. Jan. 2020, 15:49:


I would recommend, since you are using maven, not really using
tycho for much AND in order to future proof your OSGi application
you should probably migrate to bnd-*-maven-plugin(s) [1]

These are better integrated with maven, maven scopes and give you
a full cycle of tools to go from building to running. Also it's
the most cutting edge OSGi build support under the hood and will
reduce your MANIFEST editing to its most minimal.

- Ray

[1] https://github.com/bndtools/bnd/blob/master/maven/README.md

On Fri, Jan 3, 2020 at 9:35 AM Martin Petzold via osgi-dev
mailto:osgi-dev@mail.osgi.org>> wrote:

I'm using:


consider


It is working now with the following dependencies in my POM
for build/compile time. At runtime I use org.eclipse.osgi
(without the service and util bundle) and implementations of
cm (apache felix), event (apache felix), and log (within
org.eclipse.osgi an my own).




org.eclipse.platform
org.eclipse.osgi
${dependency.org.eclipse.osgi}





    org.osgi
    org.osgi.service.cm

    ${dependency.org.osgi.service.cm
}


    org.osgi
org.osgi.service.event
${dependency.org.osgi.service.event}


    org.osgi
org.osgi.service.log
${dependency.org.osgi.service.log}


Am 03.01.20 um 15:29 schrieb Dirk Fauth:

Well afaik Tycho has its own reactor for resolving
dependencies. That's why I am a bit confused about your
message. If you build via Tycho you need to have a working
target definition or repositories configuration. POM
dependencies are not considered by default. If you update to
R7 you need to update to a current Eclipse update site and
ensure that all related bundles and/or features are included.

But of course I am not sure if I understand your issue
completely. If you are not building using Tycho but plain
Maven probably some dependencies are not resolvable. But the
previous answers already covered most topics. I just stepped
in because of 

Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

[Raymond Auge via osgi-dev]

On Fri, Jan 3, 2020 at 10:29 AM Martin Petzold  wrote:

> IMHO: Manifest-first is best. p2 is hell. maven-bundle-plugin and bnd
> "hate" Eclipse. It was never easy. The worst ever was not to find together!
>
Sounds like you may not have tried bndtools.m2e integration in a long time
or ever. OSGi, bnd, bndtools.m2e + Eclipse are a happy team that I use
every single day on about 15 projects, including in IDE integration testing
and live coding!

Furthermore, the bnd team (disclosure: of which I am part) are very active
[1] in improving the IDE experience and are more than happy to address any
issues you encounter.

Anyway, if you like what you have then more power to you :) but it seems
like you might be alone on an island which can be awesome!... but it can
also be bad.

Sincerely,
- Ray

[1] https://github.com/bndtools/bnd/pulse/monthly *(Activity - 1 month: 49
merged pull requests, 68 commits, 29 closed issues, 3 new issues)*

=> My approach works well, I have a lot under my control and am able to
> migrate to plain Java (with or without modules) if it is required
>
> I still love the OSGi specifications and framework, use a lot of them, and
> learned a lot of them and all people involved!
>
> Am 03.01.20 um 16:22 schrieb Dirk Fauth:
>
> I also think that the chosen approach is not the best. Actually it is a
> mixture of Tycho and plain maven that mostly works but can lead to
> resolution issues like the one discussed.
>
> For plain OSGi and Maven I agree with Ray. But you need to migrate to bnd
> of course and get rid of the manual manifest configuration (which is good
> IMHO).
>
> If you really want to stick with manual manifest management, you should
> use Tycho in its intended way by using repositories or a target definition
> so the dependencies can be resolved automatically via p2. pomDependencies
> consider is intended for adding dependencies that are not available via p2
> update sites.
>
> But of course this is only my personal opinion based on my experience.
>
> Greez,
> Dirk
>
> Raymond Auge  schrieb am Fr., 3. Jan. 2020,
> 15:49:
>
>> I would recommend, since you are using maven, not really using tycho for
>> much AND in order to future proof your OSGi application you should probably
>> migrate to bnd-*-maven-plugin(s) [1]
>>
>> These are better integrated with maven, maven scopes and give you a full
>> cycle of tools to go from building to running. Also it's the most cutting
>> edge OSGi build support under the hood and will reduce your MANIFEST
>> editing to its most minimal.
>>
>> - Ray
>>
>> [1] https://github.com/bndtools/bnd/blob/master/maven/README.md
>>
>> On Fri, Jan 3, 2020 at 9:35 AM Martin Petzold via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>>> I'm using:
>>>
>>> 
>>> consider
>>> 
>>>
>>> It is working now with the following dependencies in my POM for
>>> build/compile time. At runtime I use org.eclipse.osgi (without the service
>>> and util bundle) and implementations of cm (apache felix), event (apache
>>> felix), and log (within org.eclipse.osgi an my own).
>>>
>>> 
>>>
>>> 
>>> org.eclipse.platform
>>> org.eclipse.osgi
>>> ${dependency.org.eclipse.osgi}
>>> 
>>>
>>> 
>>>
>>> 
>>> org.osgi
>>> org.osgi.service.cm
>>> ${dependency.org.osgi.service.cm}
>>> 
>>> 
>>> org.osgi
>>> org.osgi.service.event
>>> ${dependency.org.osgi.service.event}
>>> 
>>> 
>>> org.osgi
>>> org.osgi.service.log
>>> ${dependency.org.osgi.service.log}
>>> 
>>> Am 03.01.20 um 15:29 schrieb Dirk Fauth:
>>>
>>> Well afaik Tycho has its own reactor for resolving dependencies. That's
>>> why I am a bit confused about your message. If you build via Tycho you need
>>> to have a working target definition or repositories configuration. POM
>>> dependencies are not considered by default. If you update to R7 you need to
>>> update to a current Eclipse update site and ensure that all related bundles
>>> and/or features are included.
>>>
>>> But of course I am not sure if I understand your issue completely. If
>>> you are not building using Tycho but plain Maven probably some dependencies
>>> are not resolvable. But the previous answers already covered most topics. I
>>> just stepped in because of mentioning Tycho and pom dependencies.
>>>
>>> Greez,
>>> Dirk
>>>
>>> Martin Petzold  schrieb am Fr., 3. Jan. 2020, 15:16:
>>>
 Because I want to manage my package dependencies in the MANIFEST.MF and
 I want to be able to run my application in an PDE environment with a
 separate target platform within Eclipse. However, this post is only related
 to my build and not to my development environment.
 Am 03.01.20 um 15:11 schrieb Dirk Fauth:

 And why are you using Tycho when there is no PDE involved?

 Martin Petzold  schrieb am Fr., 3. Jan. 2020, 15:05:

> Only Maven repositories. No PDE. Plain OSGi application with my own
> launcher at runtime. At runtime there is no problem. This application is
> running for 

Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

[Dirk Fauth via osgi-dev]

Manifest-first is best.

- opinionated

p2 is hell

- well, also opinionated but yes, not easy

maven-bundle-plugin and bnd "hate" Eclipse

- disagree, they hate pde and manifest-first for several reasons

Martin Petzold  schrieb am Fr., 3. Jan. 2020, 16:29:

> IMHO: Manifest-first is best. p2 is hell. maven-bundle-plugin and bnd
> "hate" Eclipse. It was never easy. The worst ever was not to find together!
>
> => My approach works well, I have a lot under my control and am able to
> migrate to plain Java (with or without modules) if it is required
>
> I still love the OSGi specifications and framework, use a lot of them, and
> learned a lot of them and all people involved!
>
> Am 03.01.20 um 16:22 schrieb Dirk Fauth:
>
> I also think that the chosen approach is not the best. Actually it is a
> mixture of Tycho and plain maven that mostly works but can lead to
> resolution issues like the one discussed.
>
> For plain OSGi and Maven I agree with Ray. But you need to migrate to bnd
> of course and get rid of the manual manifest configuration (which is good
> IMHO).
>
> If you really want to stick with manual manifest management, you should
> use Tycho in its intended way by using repositories or a target definition
> so the dependencies can be resolved automatically via p2. pomDependencies
> consider is intended for adding dependencies that are not available via p2
> update sites.
>
> But of course this is only my personal opinion based on my experience.
>
> Greez,
> Dirk
>
> Raymond Auge  schrieb am Fr., 3. Jan. 2020,
> 15:49:
>
>> I would recommend, since you are using maven, not really using tycho for
>> much AND in order to future proof your OSGi application you should probably
>> migrate to bnd-*-maven-plugin(s) [1]
>>
>> These are better integrated with maven, maven scopes and give you a full
>> cycle of tools to go from building to running. Also it's the most cutting
>> edge OSGi build support under the hood and will reduce your MANIFEST
>> editing to its most minimal.
>>
>> - Ray
>>
>> [1] https://github.com/bndtools/bnd/blob/master/maven/README.md
>>
>> On Fri, Jan 3, 2020 at 9:35 AM Martin Petzold via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>>> I'm using:
>>>
>>> 
>>> consider
>>> 
>>>
>>> It is working now with the following dependencies in my POM for
>>> build/compile time. At runtime I use org.eclipse.osgi (without the service
>>> and util bundle) and implementations of cm (apache felix), event (apache
>>> felix), and log (within org.eclipse.osgi an my own).
>>>
>>> 
>>>
>>> 
>>> org.eclipse.platform
>>> org.eclipse.osgi
>>> ${dependency.org.eclipse.osgi}
>>> 
>>>
>>> 
>>>
>>> 
>>> org.osgi
>>> org.osgi.service.cm
>>> ${dependency.org.osgi.service.cm}
>>> 
>>> 
>>> org.osgi
>>> org.osgi.service.event
>>> ${dependency.org.osgi.service.event}
>>> 
>>> 
>>> org.osgi
>>> org.osgi.service.log
>>> ${dependency.org.osgi.service.log}
>>> 
>>> Am 03.01.20 um 15:29 schrieb Dirk Fauth:
>>>
>>> Well afaik Tycho has its own reactor for resolving dependencies. That's
>>> why I am a bit confused about your message. If you build via Tycho you need
>>> to have a working target definition or repositories configuration. POM
>>> dependencies are not considered by default. If you update to R7 you need to
>>> update to a current Eclipse update site and ensure that all related bundles
>>> and/or features are included.
>>>
>>> But of course I am not sure if I understand your issue completely. If
>>> you are not building using Tycho but plain Maven probably some dependencies
>>> are not resolvable. But the previous answers already covered most topics. I
>>> just stepped in because of mentioning Tycho and pom dependencies.
>>>
>>> Greez,
>>> Dirk
>>>
>>> Martin Petzold  schrieb am Fr., 3. Jan. 2020, 15:16:
>>>
 Because I want to manage my package dependencies in the MANIFEST.MF and
 I want to be able to run my application in an PDE environment with a
 separate target platform within Eclipse. However, this post is only related
 to my build and not to my development environment.
 Am 03.01.20 um 15:11 schrieb Dirk Fauth:

 And why are you using Tycho when there is no PDE involved?

 Martin Petzold  schrieb am Fr., 3. Jan. 2020, 15:05:

> Only Maven repositories. No PDE. Plain OSGi application with my own
> launcher at runtime. At runtime there is no problem. This application is
> running for years and I have worked with OSGi for years now. I just have
> this trouble migrating to OSGi 7.0.0 and at compile / build time with
> Maven+Tycho.
> Am 03.01.20 um 15:02 schrieb Dirk Fauth:
>
> And do you get the error at build time or when running your result?
>
> With Tycho you typically use PDE mechanisms to resolve dependencies,
> not maven dependencies.
>
> And what is your result? A plain OSGi application or a RCP application?
>
> Greez,
> Dirk
>
> Dirk Fauth  

Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

[Martin Petzold via osgi-dev]

IMHO: Manifest-first is best. p2 is hell. maven-bundle-plugin and bnd
"hate" Eclipse. It was never easy. The worst ever was not to find together!

=> My approach works well, I have a lot under my control and am able to
migrate to plain Java (with or without modules) if it is required

I still love the OSGi specifications and framework, use a lot of them,
and learned a lot of them and all people involved!

Am 03.01.20 um 16:22 schrieb Dirk Fauth:


I also think that the chosen approach is not the best. Actually it is
a mixture of Tycho and plain maven that mostly works but can lead to
resolution issues like the one discussed.

For plain OSGi and Maven I agree with Ray. But you need to migrate to
bnd of course and get rid of the manual manifest configuration (which
is good IMHO).

If you really want to stick with manual manifest management, you
should use Tycho in its intended way by using repositories or a target
definition so the dependencies can be resolved automatically via p2.
pomDependencies consider is intended for adding dependencies that are
not available via p2 update sites.

But of course this is only my personal opinion based on my experience.

Greez,
Dirk

Raymond Auge mailto:raymond.a...@liferay.com>> schrieb am Fr., 3. Jan. 2020, 15:49:

I would recommend, since you are using maven, not really using
tycho for much AND in order to future proof your OSGi application
you should probably migrate to bnd-*-maven-plugin(s) [1]

These are better integrated with maven, maven scopes and give you
a full cycle of tools to go from building to running. Also it's
the most cutting edge OSGi build support under the hood and will
reduce your MANIFEST editing to its most minimal.

- Ray

[1] https://github.com/bndtools/bnd/blob/master/maven/README.md

On Fri, Jan 3, 2020 at 9:35 AM Martin Petzold via osgi-dev
mailto:osgi-dev@mail.osgi.org>> wrote:

I'm using:


consider


It is working now with the following dependencies in my POM
for build/compile time. At runtime I use org.eclipse.osgi
(without the service and util bundle) and implementations of
cm (apache felix), event (apache felix), and log (within
org.eclipse.osgi an my own).




org.eclipse.platform
org.eclipse.osgi
${dependency.org.eclipse.osgi}





    org.osgi
    org.osgi.service.cm

    ${dependency.org.osgi.service.cm
}


    org.osgi
org.osgi.service.event
${dependency.org.osgi.service.event}


    org.osgi
org.osgi.service.log
${dependency.org.osgi.service.log}


Am 03.01.20 um 15:29 schrieb Dirk Fauth:

Well afaik Tycho has its own reactor for resolving
dependencies. That's why I am a bit confused about your
message. If you build via Tycho you need to have a working
target definition or repositories configuration. POM
dependencies are not considered by default. If you update to
R7 you need to update to a current Eclipse update site and
ensure that all related bundles and/or features are included.

But of course I am not sure if I understand your issue
completely. If you are not building using Tycho but plain
Maven probably some dependencies are not resolvable. But the
previous answers already covered most topics. I just stepped
in because of mentioning Tycho and pom dependencies.

Greez,
Dirk

Martin Petzold mailto:mpetz...@gmx.net>>
schrieb am Fr., 3. Jan. 2020, 15:16:

Because I want to manage my package dependencies in the
MANIFEST.MF and I want to be able to run my application
in an PDE environment with a separate target platform
within Eclipse. However, this post is only related to my
build and not to my development environment.

Am 03.01.20 um 15:11 schrieb Dirk Fauth:

And why are you using Tycho when there is no PDE involved?

Martin Petzold mailto:mpetz...@gmx.net>> schrieb am Fr., 3. Jan. 2020,
15:05:

Only Maven repositories. No PDE. Plain OSGi
application with my own launcher at runtime. At
runtime there is no problem. This application is
running for years and I have worked with OSGi for
years now. I just have this trouble migrating to
OSGi 7.0.0 and at compile / build time with Maven+Tycho.

Am 03.01.20 um 15:02 schrieb Dirk Fauth:

And do you get the error at build time or when
running your result?

With Tycho you typically use PDE mechanisms to

Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

[Raymond Auge via osgi-dev]

I would recommend, since you are using maven, not really using tycho for
much AND in order to future proof your OSGi application you should probably
migrate to bnd-*-maven-plugin(s) [1]

These are better integrated with maven, maven scopes and give you a full
cycle of tools to go from building to running. Also it's the most cutting
edge OSGi build support under the hood and will reduce your MANIFEST
editing to its most minimal.

- Ray

[1] https://github.com/bndtools/bnd/blob/master/maven/README.md

On Fri, Jan 3, 2020 at 9:35 AM Martin Petzold via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> I'm using:
>
> 
> consider
> 
>
> It is working now with the following dependencies in my POM for
> build/compile time. At runtime I use org.eclipse.osgi (without the service
> and util bundle) and implementations of cm (apache felix), event (apache
> felix), and log (within org.eclipse.osgi an my own).
>
> 
>
> 
> org.eclipse.platform
> org.eclipse.osgi
> ${dependency.org.eclipse.osgi}
> 
>
> 
>
> 
> org.osgi
> org.osgi.service.cm
> ${dependency.org.osgi.service.cm}
> 
> 
> org.osgi
> org.osgi.service.event
> ${dependency.org.osgi.service.event}
> 
> 
> org.osgi
> org.osgi.service.log
> ${dependency.org.osgi.service.log}
> 
> Am 03.01.20 um 15:29 schrieb Dirk Fauth:
>
> Well afaik Tycho has its own reactor for resolving dependencies. That's
> why I am a bit confused about your message. If you build via Tycho you need
> to have a working target definition or repositories configuration. POM
> dependencies are not considered by default. If you update to R7 you need to
> update to a current Eclipse update site and ensure that all related bundles
> and/or features are included.
>
> But of course I am not sure if I understand your issue completely. If you
> are not building using Tycho but plain Maven probably some dependencies are
> not resolvable. But the previous answers already covered most topics. I
> just stepped in because of mentioning Tycho and pom dependencies.
>
> Greez,
> Dirk
>
> Martin Petzold  schrieb am Fr., 3. Jan. 2020, 15:16:
>
>> Because I want to manage my package dependencies in the MANIFEST.MF and I
>> want to be able to run my application in an PDE environment with a separate
>> target platform within Eclipse. However, this post is only related to my
>> build and not to my development environment.
>> Am 03.01.20 um 15:11 schrieb Dirk Fauth:
>>
>> And why are you using Tycho when there is no PDE involved?
>>
>> Martin Petzold  schrieb am Fr., 3. Jan. 2020, 15:05:
>>
>>> Only Maven repositories. No PDE. Plain OSGi application with my own
>>> launcher at runtime. At runtime there is no problem. This application is
>>> running for years and I have worked with OSGi for years now. I just have
>>> this trouble migrating to OSGi 7.0.0 and at compile / build time with
>>> Maven+Tycho.
>>> Am 03.01.20 um 15:02 schrieb Dirk Fauth:
>>>
>>> And do you get the error at build time or when running your result?
>>>
>>> With Tycho you typically use PDE mechanisms to resolve dependencies, not
>>> maven dependencies.
>>>
>>> And what is your result? A plain OSGi application or a RCP application?
>>>
>>> Greez,
>>> Dirk
>>>
>>> Dirk Fauth  schrieb am Fr., 3. Jan. 2020, 14:37:
>>>
 Hi,

 If you are using Tycho, which repository are you using for dependency
 resolution? Or do you build using a target definition? If so, which eclipse
 software site have you configured?

 Greez,
 Dirk

 Martin Petzold via osgi-dev  schrieb am Fr.,
 3. Jan. 2020, 14:20:

> Dear Neil,
>
> thanks, but now we start again at the beginning at my first message
> (endless loop): I cannot set a dependency to "org.osgi:osgi.core" in Maven
> (with Tycho) because it requires 'osgi.unresolvable;
> (&(!(must.not.resolve=*))(must.not.resolve=*))'.
>
> Kind regards,
>
> Martin
> Am 03.01.20 um 14:12 schrieb Neil Bartlett:
>
>
>
> On Fri, 3 Jan 2020 at 13:08, Martin Petzold via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> Okay, thanks. This is clear now.
>>
>> However, Ray told me to set the dependency for "org.eclipse.osgi" to
>> "runtime" scope. But how can my implementation then depend on
>> "org.osgi.framework" package during compile time? Either there is a
>> separate API bundle from OSGi Alliance containing "org.osgi.framework"
>> (which one is it?)
>>
>
> Yes, this is the org.osgi:osgi.core dependency. That contains the pure
> api and no implementation, whereas org.eclipse.osgi is an implementation.
>
> Or you could just use org.eclipse.osgi at both compile time and
> runtime, but then you should be careful to avoid using equinox internal
> packages.
>
> or I should set the scope to compile instead of runtime?
>>
>> I am using the BundleContext and need access to this package.
>>
>> Thanks and kind 

Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

[Neil Bartlett via osgi-dev]

I'm also extremely confused by your setup! But if you can get things
working using Tycho and the org.eclipse.osgi then I guess that will have to
do.

My understanding was that Tycho didn't even look at the Maven dependencies
specified in the POM using a  section, and also it does not
distinguish between compile, test, runtime and provided scopes.

For those using plain Maven, the proper practice is to use the dependency
osgi.core with provided scope, and then an OSGi implementation JAR such as
Equinox (org.eclipse.osgi) or Felix (org.apache.felix.framework) with
runtime scope.

Neil

On Fri, 3 Jan 2020 at 14:29, Dirk Fauth via osgi-dev 
wrote:

> Well afaik Tycho has its own reactor for resolving dependencies. That's
> why I am a bit confused about your message. If you build via Tycho you need
> to have a working target definition or repositories configuration. POM
> dependencies are not considered by default. If you update to R7 you need to
> update to a current Eclipse update site and ensure that all related bundles
> and/or features are included.
>
> But of course I am not sure if I understand your issue completely. If you
> are not building using Tycho but plain Maven probably some dependencies are
> not resolvable. But the previous answers already covered most topics. I
> just stepped in because of mentioning Tycho and pom dependencies.
>
> Greez,
> Dirk
>
> Martin Petzold  schrieb am Fr., 3. Jan. 2020, 15:16:
>
>> Because I want to manage my package dependencies in the MANIFEST.MF and I
>> want to be able to run my application in an PDE environment with a separate
>> target platform within Eclipse. However, this post is only related to my
>> build and not to my development environment.
>> Am 03.01.20 um 15:11 schrieb Dirk Fauth:
>>
>> And why are you using Tycho when there is no PDE involved?
>>
>> Martin Petzold  schrieb am Fr., 3. Jan. 2020, 15:05:
>>
>>> Only Maven repositories. No PDE. Plain OSGi application with my own
>>> launcher at runtime. At runtime there is no problem. This application is
>>> running for years and I have worked with OSGi for years now. I just have
>>> this trouble migrating to OSGi 7.0.0 and at compile / build time with
>>> Maven+Tycho.
>>> Am 03.01.20 um 15:02 schrieb Dirk Fauth:
>>>
>>> And do you get the error at build time or when running your result?
>>>
>>> With Tycho you typically use PDE mechanisms to resolve dependencies, not
>>> maven dependencies.
>>>
>>> And what is your result? A plain OSGi application or a RCP application?
>>>
>>> Greez,
>>> Dirk
>>>
>>> Dirk Fauth  schrieb am Fr., 3. Jan. 2020, 14:37:
>>>
 Hi,

 If you are using Tycho, which repository are you using for dependency
 resolution? Or do you build using a target definition? If so, which eclipse
 software site have you configured?

 Greez,
 Dirk

 Martin Petzold via osgi-dev  schrieb am Fr.,
 3. Jan. 2020, 14:20:

> Dear Neil,
>
> thanks, but now we start again at the beginning at my first message
> (endless loop): I cannot set a dependency to "org.osgi:osgi.core" in Maven
> (with Tycho) because it requires 'osgi.unresolvable;
> (&(!(must.not.resolve=*))(must.not.resolve=*))'.
>
> Kind regards,
>
> Martin
> Am 03.01.20 um 14:12 schrieb Neil Bartlett:
>
>
>
> On Fri, 3 Jan 2020 at 13:08, Martin Petzold via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> Okay, thanks. This is clear now.
>>
>> However, Ray told me to set the dependency for "org.eclipse.osgi" to
>> "runtime" scope. But how can my implementation then depend on
>> "org.osgi.framework" package during compile time? Either there is a
>> separate API bundle from OSGi Alliance containing "org.osgi.framework"
>> (which one is it?)
>>
>
> Yes, this is the org.osgi:osgi.core dependency. That contains the pure
> api and no implementation, whereas org.eclipse.osgi is an implementation.
>
> Or you could just use org.eclipse.osgi at both compile time and
> runtime, but then you should be careful to avoid using equinox internal
> packages.
>
> or I should set the scope to compile instead of runtime?
>>
>> I am using the BundleContext and need access to this package.
>>
>> Thanks and kind regards,
>>
>> Martin
>> Am 03.01.20 um 10:51 schrieb Mark Hoffmann via osgi-dev:
>>
>> Hi Martin,
>>
>> see comments inline.
>>
>> Regards,
>>
>> Mark
>> Am 02.01.20 um 19:19 schrieb Martin Petzold via osgi-dev:
>>
>> Thanks, Raymond! Does this also relate to "org.osgi:osgi.cmpn"?
>> Should I remove this dependency too? Should I add
>> "org.eclipse.osgi.services" or the individual "org.osgi.service.*" to my
>> (parent) POM? Are the individual "org.osgi.service.*" also required at
>> runtime (on classpath or installed to osgi?). Will "org.eclipse.osgi" 
>> start
>> without 

Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

[Dirk Fauth via osgi-dev]

Well afaik Tycho has its own reactor for resolving dependencies. That's why
I am a bit confused about your message. If you build via Tycho you need to
have a working target definition or repositories configuration. POM
dependencies are not considered by default. If you update to R7 you need to
update to a current Eclipse update site and ensure that all related bundles
and/or features are included.

But of course I am not sure if I understand your issue completely. If you
are not building using Tycho but plain Maven probably some dependencies are
not resolvable. But the previous answers already covered most topics. I
just stepped in because of mentioning Tycho and pom dependencies.

Greez,
Dirk

Martin Petzold  schrieb am Fr., 3. Jan. 2020, 15:16:

> Because I want to manage my package dependencies in the MANIFEST.MF and I
> want to be able to run my application in an PDE environment with a separate
> target platform within Eclipse. However, this post is only related to my
> build and not to my development environment.
> Am 03.01.20 um 15:11 schrieb Dirk Fauth:
>
> And why are you using Tycho when there is no PDE involved?
>
> Martin Petzold  schrieb am Fr., 3. Jan. 2020, 15:05:
>
>> Only Maven repositories. No PDE. Plain OSGi application with my own
>> launcher at runtime. At runtime there is no problem. This application is
>> running for years and I have worked with OSGi for years now. I just have
>> this trouble migrating to OSGi 7.0.0 and at compile / build time with
>> Maven+Tycho.
>> Am 03.01.20 um 15:02 schrieb Dirk Fauth:
>>
>> And do you get the error at build time or when running your result?
>>
>> With Tycho you typically use PDE mechanisms to resolve dependencies, not
>> maven dependencies.
>>
>> And what is your result? A plain OSGi application or a RCP application?
>>
>> Greez,
>> Dirk
>>
>> Dirk Fauth  schrieb am Fr., 3. Jan. 2020, 14:37:
>>
>>> Hi,
>>>
>>> If you are using Tycho, which repository are you using for dependency
>>> resolution? Or do you build using a target definition? If so, which eclipse
>>> software site have you configured?
>>>
>>> Greez,
>>> Dirk
>>>
>>> Martin Petzold via osgi-dev  schrieb am Fr., 3.
>>> Jan. 2020, 14:20:
>>>
 Dear Neil,

 thanks, but now we start again at the beginning at my first message
 (endless loop): I cannot set a dependency to "org.osgi:osgi.core" in Maven
 (with Tycho) because it requires 'osgi.unresolvable;
 (&(!(must.not.resolve=*))(must.not.resolve=*))'.

 Kind regards,

 Martin
 Am 03.01.20 um 14:12 schrieb Neil Bartlett:



 On Fri, 3 Jan 2020 at 13:08, Martin Petzold via osgi-dev <
 osgi-dev@mail.osgi.org> wrote:

> Okay, thanks. This is clear now.
>
> However, Ray told me to set the dependency for "org.eclipse.osgi" to
> "runtime" scope. But how can my implementation then depend on
> "org.osgi.framework" package during compile time? Either there is a
> separate API bundle from OSGi Alliance containing "org.osgi.framework"
> (which one is it?)
>

 Yes, this is the org.osgi:osgi.core dependency. That contains the pure
 api and no implementation, whereas org.eclipse.osgi is an implementation.

 Or you could just use org.eclipse.osgi at both compile time and
 runtime, but then you should be careful to avoid using equinox internal
 packages.

 or I should set the scope to compile instead of runtime?
>
> I am using the BundleContext and need access to this package.
>
> Thanks and kind regards,
>
> Martin
> Am 03.01.20 um 10:51 schrieb Mark Hoffmann via osgi-dev:
>
> Hi Martin,
>
> see comments inline.
>
> Regards,
>
> Mark
> Am 02.01.20 um 19:19 schrieb Martin Petzold via osgi-dev:
>
> Thanks, Raymond! Does this also relate to "org.osgi:osgi.cmpn"? Should
> I remove this dependency too? Should I add "org.eclipse.osgi.services" or
> the individual "org.osgi.service.*" to my (parent) POM? Are the individual
> "org.osgi.service.*" also required at runtime (on classpath or installed 
> to
> osgi?). Will "org.eclipse.osgi" start without "org.eclipse.osgi.services"
> on the classpath or installation as bundle?
>
> You have to distinguish between the packages you want to resolve and
> the artifacts/bundles that contain the the packages/implementations.
>
> In your case org.eclipse.osgi.services is the bundle that exports the
> packages org.osgi.service.* packages.
>
> Because Maven just resolves artifacts, you need to provide the bundle
> org.eclipse.osgi.services as dependency.
>
> Yes, org.eclipse.osgi will start without org.eclipse.osgi.services
>
> I have now added "org.eclipse.osgi.services". However, it now cannot
> requires "org.osgi.util.promise". What should I add to my POM in order to
> resolve the core Eclipse OSGi implementation (only OSGi core
> 

Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

[Martin Petzold via osgi-dev]

Because I want to manage my package dependencies in the MANIFEST.MF and
I want to be able to run my application in an PDE environment with a
separate target platform within Eclipse. However, this post is only
related to my build and not to my development environment.

Am 03.01.20 um 15:11 schrieb Dirk Fauth:

And why are you using Tycho when there is no PDE involved?

Martin Petzold mailto:mpetz...@gmx.net>> schrieb am
Fr., 3. Jan. 2020, 15:05:

Only Maven repositories. No PDE. Plain OSGi application with my
own launcher at runtime. At runtime there is no problem. This
application is running for years and I have worked with OSGi for
years now. I just have this trouble migrating to OSGi 7.0.0 and at
compile / build time with Maven+Tycho.

Am 03.01.20 um 15:02 schrieb Dirk Fauth:

And do you get the error at build time or when running your result?

With Tycho you typically use PDE mechanisms to resolve
dependencies, not maven dependencies.

And what is your result? A plain OSGi application or a RCP
application?

Greez,
Dirk

Dirk Fauth mailto:dirk.fa...@gmail.com>>
schrieb am Fr., 3. Jan. 2020, 14:37:

Hi,

If you are using Tycho, which repository are you using for
dependency resolution? Or do you build using a target
definition? If so, which eclipse software site have you
configured?

Greez,
Dirk

Martin Petzold via osgi-dev mailto:osgi-dev@mail.osgi.org>> schrieb am Fr., 3. Jan.
2020, 14:20:

Dear Neil,

thanks, but now we start again at the beginning at my
first message (endless loop): I cannot set a dependency
to "org.osgi:osgi.core" in Maven (with Tycho) because it
requires 'osgi.unresolvable;
(&(!(must.not.resolve=*))(must.not.resolve=*))'.

Kind regards,

Martin

Am 03.01.20 um 14:12 schrieb Neil Bartlett:



On Fri, 3 Jan 2020 at 13:08, Martin Petzold via osgi-dev
mailto:osgi-dev@mail.osgi.org>>
wrote:

Okay, thanks. This is clear now.

However, Ray told me to set the dependency for
"org.eclipse.osgi" to "runtime" scope. But how can
my implementation then depend on
"org.osgi.framework" package during compile time?
Either there is a separate API bundle from OSGi
Alliance containing "org.osgi.framework" (which one
is it?)


Yes, this is the org.osgi:osgi.core dependency. That
contains the pure api and no implementation, whereas
org.eclipse.osgi is an implementation.

Or you could just use org.eclipse.osgi at both compile
time and runtime, but then you should be careful to
avoid using equinox internal packages.

or I should set the scope to compile instead of runtime?

I am using the BundleContext and need access to this
package.

Thanks and kind regards,

Martin

Am 03.01.20 um 10:51 schrieb Mark Hoffmann via osgi-dev:


Hi Martin,

see comments inline.

Regards,

Mark

Am 02.01.20 um 19:19 schrieb Martin Petzold via
osgi-dev:


Thanks, Raymond! Does this also relate to
"org.osgi:osgi.cmpn"? Should I remove this
dependency too? Should I add
"org.eclipse.osgi.services" or the individual
"org.osgi.service.*" to my (parent) POM? Are the
individual "org.osgi.service.*" also required at
runtime (on classpath or installed to osgi?). Will
"org.eclipse.osgi" start without
"org.eclipse.osgi.services" on the classpath or
installation as bundle?


You have to distinguish between the packages you
want to resolve and the artifacts/bundles that
contain the the packages/implementations.

In your case org.eclipse.osgi.services is the
bundle that exports the packages org.osgi.service.*
packages.

Because Maven just resolves artifacts, you need to
provide the bundle org.eclipse.osgi.services as
dependency.

Yes, org.eclipse.osgi will start without
org.eclipse.osgi.services


I have now added "org.eclipse.osgi.services".
However, it now cannot requires
"org.osgi.util.promise". What should I add to my
POM in order to resolve the core Eclipse OSGi
implementation (only OSGi core implementation)?


You should find the promises and functions in 

Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

[Dirk Fauth via osgi-dev]

And why are you using Tycho when there is no PDE involved?

Martin Petzold  schrieb am Fr., 3. Jan. 2020, 15:05:

> Only Maven repositories. No PDE. Plain OSGi application with my own
> launcher at runtime. At runtime there is no problem. This application is
> running for years and I have worked with OSGi for years now. I just have
> this trouble migrating to OSGi 7.0.0 and at compile / build time with
> Maven+Tycho.
> Am 03.01.20 um 15:02 schrieb Dirk Fauth:
>
> And do you get the error at build time or when running your result?
>
> With Tycho you typically use PDE mechanisms to resolve dependencies, not
> maven dependencies.
>
> And what is your result? A plain OSGi application or a RCP application?
>
> Greez,
> Dirk
>
> Dirk Fauth  schrieb am Fr., 3. Jan. 2020, 14:37:
>
>> Hi,
>>
>> If you are using Tycho, which repository are you using for dependency
>> resolution? Or do you build using a target definition? If so, which eclipse
>> software site have you configured?
>>
>> Greez,
>> Dirk
>>
>> Martin Petzold via osgi-dev  schrieb am Fr., 3.
>> Jan. 2020, 14:20:
>>
>>> Dear Neil,
>>>
>>> thanks, but now we start again at the beginning at my first message
>>> (endless loop): I cannot set a dependency to "org.osgi:osgi.core" in Maven
>>> (with Tycho) because it requires 'osgi.unresolvable;
>>> (&(!(must.not.resolve=*))(must.not.resolve=*))'.
>>>
>>> Kind regards,
>>>
>>> Martin
>>> Am 03.01.20 um 14:12 schrieb Neil Bartlett:
>>>
>>>
>>>
>>> On Fri, 3 Jan 2020 at 13:08, Martin Petzold via osgi-dev <
>>> osgi-dev@mail.osgi.org> wrote:
>>>
 Okay, thanks. This is clear now.

 However, Ray told me to set the dependency for "org.eclipse.osgi" to
 "runtime" scope. But how can my implementation then depend on
 "org.osgi.framework" package during compile time? Either there is a
 separate API bundle from OSGi Alliance containing "org.osgi.framework"
 (which one is it?)

>>>
>>> Yes, this is the org.osgi:osgi.core dependency. That contains the pure
>>> api and no implementation, whereas org.eclipse.osgi is an implementation.
>>>
>>> Or you could just use org.eclipse.osgi at both compile time and runtime,
>>> but then you should be careful to avoid using equinox internal packages.
>>>
>>> or I should set the scope to compile instead of runtime?

 I am using the BundleContext and need access to this package.

 Thanks and kind regards,

 Martin
 Am 03.01.20 um 10:51 schrieb Mark Hoffmann via osgi-dev:

 Hi Martin,

 see comments inline.

 Regards,

 Mark
 Am 02.01.20 um 19:19 schrieb Martin Petzold via osgi-dev:

 Thanks, Raymond! Does this also relate to "org.osgi:osgi.cmpn"? Should
 I remove this dependency too? Should I add "org.eclipse.osgi.services" or
 the individual "org.osgi.service.*" to my (parent) POM? Are the individual
 "org.osgi.service.*" also required at runtime (on classpath or installed to
 osgi?). Will "org.eclipse.osgi" start without "org.eclipse.osgi.services"
 on the classpath or installation as bundle?

 You have to distinguish between the packages you want to resolve and
 the artifacts/bundles that contain the the packages/implementations.

 In your case org.eclipse.osgi.services is the bundle that exports the
 packages org.osgi.service.* packages.

 Because Maven just resolves artifacts, you need to provide the bundle
 org.eclipse.osgi.services as dependency.

 Yes, org.eclipse.osgi will start without org.eclipse.osgi.services

 I have now added "org.eclipse.osgi.services". However, it now cannot
 requires "org.osgi.util.promise". What should I add to my POM in order to
 resolve the core Eclipse OSGi implementation (only OSGi core
 implementation)?

 You should find the promises and functions in the bundle
 org.eclipse.osgi.util

 btw I have removed the runtime scope for "org.eclipse.osgi".
 Am 02.01.20 um 19:00 schrieb Raymond Auge:

 A bit of rational about why companion jars are unresolvable:

 The OSGi specs are to a very high degree independent from each other.
 There's no reason for you to be forced to use all R5 specs, or all R6 or
 whatever. Those are simply marketing versions.

 What you are really using are the individual specs at a given version.

 For example using DS 1.4, Event 1.0, and logging 1.2 is perfectly fine
 combination given you can find providers of each that work together well.
 The APIs themselves won't care.

 However some providers actually package OSGi spec APIs which they
 provide implementations for, which means if you include the aggregate
 companion jars also at runtime you may have two API versions to contend
 with.

 You may inadvertently expose yourself to a wrong API version, hence why
 they will no longer resolve.

 - Ray

 On Thu, Jan 2, 2020 at 12:36 PM 

Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

[Martin Petzold via osgi-dev]

Only Maven repositories. No PDE. Plain OSGi application with my own
launcher at runtime. At runtime there is no problem. This application is
running for years and I have worked with OSGi for years now. I just have
this trouble migrating to OSGi 7.0.0 and at compile / build time with
Maven+Tycho.

Am 03.01.20 um 15:02 schrieb Dirk Fauth:

And do you get the error at build time or when running your result?

With Tycho you typically use PDE mechanisms to resolve dependencies,
not maven dependencies.

And what is your result? A plain OSGi application or a RCP application?

Greez,
Dirk

Dirk Fauth mailto:dirk.fa...@gmail.com>>
schrieb am Fr., 3. Jan. 2020, 14:37:

Hi,

If you are using Tycho, which repository are you using for
dependency resolution? Or do you build using a target definition?
If so, which eclipse software site have you configured?

Greez,
Dirk

Martin Petzold via osgi-dev mailto:osgi-dev@mail.osgi.org>> schrieb am Fr., 3. Jan. 2020, 14:20:

Dear Neil,

thanks, but now we start again at the beginning at my first
message (endless loop): I cannot set a dependency to
"org.osgi:osgi.core" in Maven (with Tycho) because it requires
'osgi.unresolvable;
(&(!(must.not.resolve=*))(must.not.resolve=*))'.

Kind regards,

Martin

Am 03.01.20 um 14:12 schrieb Neil Bartlett:



On Fri, 3 Jan 2020 at 13:08, Martin Petzold via osgi-dev
mailto:osgi-dev@mail.osgi.org>> wrote:

Okay, thanks. This is clear now.

However, Ray told me to set the dependency for
"org.eclipse.osgi" to "runtime" scope. But how can my
implementation then depend on "org.osgi.framework"
package during compile time? Either there is a separate
API bundle from OSGi Alliance containing
"org.osgi.framework" (which one is it?)


Yes, this is the org.osgi:osgi.core dependency. That contains
the pure api and no implementation, whereas org.eclipse.osgi
is an implementation.

Or you could just use org.eclipse.osgi at both compile time
and runtime, but then you should be careful to avoid using
equinox internal packages.

or I should set the scope to compile instead of runtime?

I am using the BundleContext and need access to this package.

Thanks and kind regards,

Martin

Am 03.01.20 um 10:51 schrieb Mark Hoffmann via osgi-dev:


Hi Martin,

see comments inline.

Regards,

Mark

Am 02.01.20 um 19:19 schrieb Martin Petzold via osgi-dev:


Thanks, Raymond! Does this also relate to
"org.osgi:osgi.cmpn"? Should I remove this dependency
too? Should I add "org.eclipse.osgi.services" or the
individual "org.osgi.service.*" to my (parent) POM? Are
the individual "org.osgi.service.*" also required at
runtime (on classpath or installed to osgi?). Will
"org.eclipse.osgi" start without
"org.eclipse.osgi.services" on the classpath or
installation as bundle?


You have to distinguish between the packages you want to
resolve and the artifacts/bundles that contain the the
packages/implementations.

In your case org.eclipse.osgi.services is the bundle
that exports the packages org.osgi.service.* packages.

Because Maven just resolves artifacts, you need to
provide the bundle org.eclipse.osgi.services as dependency.

Yes, org.eclipse.osgi will start without
org.eclipse.osgi.services


I have now added "org.eclipse.osgi.services". However,
it now cannot requires "org.osgi.util.promise". What
should I add to my POM in order to resolve the core
Eclipse OSGi implementation (only OSGi core
implementation)?


You should find the promises and functions in the bundle
org.eclipse.osgi.util


btw I have removed the runtime scope for
"org.eclipse.osgi".

Am 02.01.20 um 19:00 schrieb Raymond Auge:

A bit of rational about why companion jars are
unresolvable:

The OSGi specs are to a very high degree independent
from each other. There's no reason for you to be
forced to use all R5 specs, or all R6 or whatever.
Those are simply marketing versions.

What you are really using are the individual specs at
a given version.

For example using DS 1.4, Event 1.0, and logging 1.2
is perfectly fine combination given you can find
providers of each that work together well. The APIs
themselves won't care.

However some providers actually package OSGi 

Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

[Dirk Fauth via osgi-dev]

And do you get the error at build time or when running your result?

With Tycho you typically use PDE mechanisms to resolve dependencies, not
maven dependencies.

And what is your result? A plain OSGi application or a RCP application?

Greez,
Dirk

Dirk Fauth  schrieb am Fr., 3. Jan. 2020, 14:37:

> Hi,
>
> If you are using Tycho, which repository are you using for dependency
> resolution? Or do you build using a target definition? If so, which eclipse
> software site have you configured?
>
> Greez,
> Dirk
>
> Martin Petzold via osgi-dev  schrieb am Fr., 3.
> Jan. 2020, 14:20:
>
>> Dear Neil,
>>
>> thanks, but now we start again at the beginning at my first message
>> (endless loop): I cannot set a dependency to "org.osgi:osgi.core" in Maven
>> (with Tycho) because it requires 'osgi.unresolvable;
>> (&(!(must.not.resolve=*))(must.not.resolve=*))'.
>>
>> Kind regards,
>>
>> Martin
>> Am 03.01.20 um 14:12 schrieb Neil Bartlett:
>>
>>
>>
>> On Fri, 3 Jan 2020 at 13:08, Martin Petzold via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>>> Okay, thanks. This is clear now.
>>>
>>> However, Ray told me to set the dependency for "org.eclipse.osgi" to
>>> "runtime" scope. But how can my implementation then depend on
>>> "org.osgi.framework" package during compile time? Either there is a
>>> separate API bundle from OSGi Alliance containing "org.osgi.framework"
>>> (which one is it?)
>>>
>>
>> Yes, this is the org.osgi:osgi.core dependency. That contains the pure
>> api and no implementation, whereas org.eclipse.osgi is an implementation.
>>
>> Or you could just use org.eclipse.osgi at both compile time and runtime,
>> but then you should be careful to avoid using equinox internal packages.
>>
>> or I should set the scope to compile instead of runtime?
>>>
>>> I am using the BundleContext and need access to this package.
>>>
>>> Thanks and kind regards,
>>>
>>> Martin
>>> Am 03.01.20 um 10:51 schrieb Mark Hoffmann via osgi-dev:
>>>
>>> Hi Martin,
>>>
>>> see comments inline.
>>>
>>> Regards,
>>>
>>> Mark
>>> Am 02.01.20 um 19:19 schrieb Martin Petzold via osgi-dev:
>>>
>>> Thanks, Raymond! Does this also relate to "org.osgi:osgi.cmpn"? Should I
>>> remove this dependency too? Should I add "org.eclipse.osgi.services" or the
>>> individual "org.osgi.service.*" to my (parent) POM? Are the individual
>>> "org.osgi.service.*" also required at runtime (on classpath or installed to
>>> osgi?). Will "org.eclipse.osgi" start without "org.eclipse.osgi.services"
>>> on the classpath or installation as bundle?
>>>
>>> You have to distinguish between the packages you want to resolve and the
>>> artifacts/bundles that contain the the packages/implementations.
>>>
>>> In your case org.eclipse.osgi.services is the bundle that exports the
>>> packages org.osgi.service.* packages.
>>>
>>> Because Maven just resolves artifacts, you need to provide the bundle
>>> org.eclipse.osgi.services as dependency.
>>>
>>> Yes, org.eclipse.osgi will start without org.eclipse.osgi.services
>>>
>>> I have now added "org.eclipse.osgi.services". However, it now cannot
>>> requires "org.osgi.util.promise". What should I add to my POM in order to
>>> resolve the core Eclipse OSGi implementation (only OSGi core
>>> implementation)?
>>>
>>> You should find the promises and functions in the bundle
>>> org.eclipse.osgi.util
>>>
>>> btw I have removed the runtime scope for "org.eclipse.osgi".
>>> Am 02.01.20 um 19:00 schrieb Raymond Auge:
>>>
>>> A bit of rational about why companion jars are unresolvable:
>>>
>>> The OSGi specs are to a very high degree independent from each other.
>>> There's no reason for you to be forced to use all R5 specs, or all R6 or
>>> whatever. Those are simply marketing versions.
>>>
>>> What you are really using are the individual specs at a given version.
>>>
>>> For example using DS 1.4, Event 1.0, and logging 1.2 is perfectly fine
>>> combination given you can find providers of each that work together well.
>>> The APIs themselves won't care.
>>>
>>> However some providers actually package OSGi spec APIs which they
>>> provide implementations for, which means if you include the aggregate
>>> companion jars also at runtime you may have two API versions to contend
>>> with.
>>>
>>> You may inadvertently expose yourself to a wrong API version, hence why
>>> they will no longer resolve.
>>>
>>> - Ray
>>>
>>> On Thu, Jan 2, 2020 at 12:36 PM Raymond Auge 
>>> wrote:
>>>
 Yes and yes.

 OSGi started adding the unresolveable requirement at release 6 IIRC. So
 if you are using a prior releases of the companion jars (including cmpn,
 enterprise) they won't give you this failure, so you should upgrade.

 *Replacements:* Replace the compendium APIs with their respective
 individual api jars available on maven central, like this one [1].

 [1]
 https://search.maven.org/artifact/org.osgi/org.osgi.service.component.annotations/1.4.0/jar

 - Ray


 On Thu, Jan 2, 2020 at 12:31 

Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

[Dirk Fauth via osgi-dev]

Hi,

If you are using Tycho, which repository are you using for dependency
resolution? Or do you build using a target definition? If so, which eclipse
software site have you configured?

Greez,
Dirk

Martin Petzold via osgi-dev  schrieb am Fr., 3.
Jan. 2020, 14:20:

> Dear Neil,
>
> thanks, but now we start again at the beginning at my first message
> (endless loop): I cannot set a dependency to "org.osgi:osgi.core" in Maven
> (with Tycho) because it requires 'osgi.unresolvable;
> (&(!(must.not.resolve=*))(must.not.resolve=*))'.
>
> Kind regards,
>
> Martin
> Am 03.01.20 um 14:12 schrieb Neil Bartlett:
>
>
>
> On Fri, 3 Jan 2020 at 13:08, Martin Petzold via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> Okay, thanks. This is clear now.
>>
>> However, Ray told me to set the dependency for "org.eclipse.osgi" to
>> "runtime" scope. But how can my implementation then depend on
>> "org.osgi.framework" package during compile time? Either there is a
>> separate API bundle from OSGi Alliance containing "org.osgi.framework"
>> (which one is it?)
>>
>
> Yes, this is the org.osgi:osgi.core dependency. That contains the pure api
> and no implementation, whereas org.eclipse.osgi is an implementation.
>
> Or you could just use org.eclipse.osgi at both compile time and runtime,
> but then you should be careful to avoid using equinox internal packages.
>
> or I should set the scope to compile instead of runtime?
>>
>> I am using the BundleContext and need access to this package.
>>
>> Thanks and kind regards,
>>
>> Martin
>> Am 03.01.20 um 10:51 schrieb Mark Hoffmann via osgi-dev:
>>
>> Hi Martin,
>>
>> see comments inline.
>>
>> Regards,
>>
>> Mark
>> Am 02.01.20 um 19:19 schrieb Martin Petzold via osgi-dev:
>>
>> Thanks, Raymond! Does this also relate to "org.osgi:osgi.cmpn"? Should I
>> remove this dependency too? Should I add "org.eclipse.osgi.services" or the
>> individual "org.osgi.service.*" to my (parent) POM? Are the individual
>> "org.osgi.service.*" also required at runtime (on classpath or installed to
>> osgi?). Will "org.eclipse.osgi" start without "org.eclipse.osgi.services"
>> on the classpath or installation as bundle?
>>
>> You have to distinguish between the packages you want to resolve and the
>> artifacts/bundles that contain the the packages/implementations.
>>
>> In your case org.eclipse.osgi.services is the bundle that exports the
>> packages org.osgi.service.* packages.
>>
>> Because Maven just resolves artifacts, you need to provide the bundle
>> org.eclipse.osgi.services as dependency.
>>
>> Yes, org.eclipse.osgi will start without org.eclipse.osgi.services
>>
>> I have now added "org.eclipse.osgi.services". However, it now cannot
>> requires "org.osgi.util.promise". What should I add to my POM in order to
>> resolve the core Eclipse OSGi implementation (only OSGi core
>> implementation)?
>>
>> You should find the promises and functions in the bundle
>> org.eclipse.osgi.util
>>
>> btw I have removed the runtime scope for "org.eclipse.osgi".
>> Am 02.01.20 um 19:00 schrieb Raymond Auge:
>>
>> A bit of rational about why companion jars are unresolvable:
>>
>> The OSGi specs are to a very high degree independent from each other.
>> There's no reason for you to be forced to use all R5 specs, or all R6 or
>> whatever. Those are simply marketing versions.
>>
>> What you are really using are the individual specs at a given version.
>>
>> For example using DS 1.4, Event 1.0, and logging 1.2 is perfectly fine
>> combination given you can find providers of each that work together well.
>> The APIs themselves won't care.
>>
>> However some providers actually package OSGi spec APIs which they provide
>> implementations for, which means if you include the aggregate companion
>> jars also at runtime you may have two API versions to contend with.
>>
>> You may inadvertently expose yourself to a wrong API version, hence why
>> they will no longer resolve.
>>
>> - Ray
>>
>> On Thu, Jan 2, 2020 at 12:36 PM Raymond Auge 
>> wrote:
>>
>>> Yes and yes.
>>>
>>> OSGi started adding the unresolveable requirement at release 6 IIRC. So
>>> if you are using a prior releases of the companion jars (including cmpn,
>>> enterprise) they won't give you this failure, so you should upgrade.
>>>
>>> *Replacements:* Replace the compendium APIs with their respective
>>> individual api jars available on maven central, like this one [1].
>>>
>>> [1]
>>> https://search.maven.org/artifact/org.osgi/org.osgi.service.component.annotations/1.4.0/jar
>>>
>>> - Ray
>>>
>>>
>>> On Thu, Jan 2, 2020 at 12:31 PM Martin Petzold  wrote:
>>>
 Thanks, Raymond! Does this also relate to "org.osgi:osgi.cmpn"? Should
 I remove this dependency too?
 Am 02.01.20 um 18:23 schrieb Raymond Auge:



 On Thu, Jan 2, 2020 at 12:17 PM Martin Petzold via osgi-dev <
 osgi-dev@mail.osgi.org> wrote:

> Dear OSGi gurus,
> I have a dependency on "org.osgi:osgi.core" (7.0.0) in my POM. The
> reason is that I need 

Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

[Martin Petzold via osgi-dev]

Dear Neil,

thanks, but now we start again at the beginning at my first message
(endless loop): I cannot set a dependency to "org.osgi:osgi.core" in
Maven (with Tycho) because it requires 'osgi.unresolvable;
(&(!(must.not.resolve=*))(must.not.resolve=*))'.

Kind regards,

Martin

Am 03.01.20 um 14:12 schrieb Neil Bartlett:



On Fri, 3 Jan 2020 at 13:08, Martin Petzold via osgi-dev
mailto:osgi-dev@mail.osgi.org>> wrote:

Okay, thanks. This is clear now.

However, Ray told me to set the dependency for "org.eclipse.osgi"
to "runtime" scope. But how can my implementation then depend on
"org.osgi.framework" package during compile time? Either there is
a separate API bundle from OSGi Alliance containing
"org.osgi.framework" (which one is it?)


Yes, this is the org.osgi:osgi.core dependency. That contains the pure
api and no implementation, whereas org.eclipse.osgi is an implementation.

Or you could just use org.eclipse.osgi at both compile time and
runtime, but then you should be careful to avoid using equinox
internal packages.

or I should set the scope to compile instead of runtime?

I am using the BundleContext and need access to this package.

Thanks and kind regards,

Martin

Am 03.01.20 um 10:51 schrieb Mark Hoffmann via osgi-dev:


Hi Martin,

see comments inline.

Regards,

Mark

Am 02.01.20 um 19:19 schrieb Martin Petzold via osgi-dev:


Thanks, Raymond! Does this also relate to "org.osgi:osgi.cmpn"?
Should I remove this dependency too? Should I add
"org.eclipse.osgi.services" or the individual
"org.osgi.service.*" to my (parent) POM? Are the individual
"org.osgi.service.*" also required at runtime (on classpath or
installed to osgi?). Will "org.eclipse.osgi" start without
"org.eclipse.osgi.services" on the classpath or installation as
bundle?


You have to distinguish between the packages you want to resolve
and the artifacts/bundles that contain the the
packages/implementations.

In your case org.eclipse.osgi.services is the bundle that exports
the packages org.osgi.service.* packages.

Because Maven just resolves artifacts, you need to provide the
bundle org.eclipse.osgi.services as dependency.

Yes, org.eclipse.osgi will start without org.eclipse.osgi.services


I have now added "org.eclipse.osgi.services". However, it now
cannot requires "org.osgi.util.promise". What should I add to my
POM in order to resolve the core Eclipse OSGi implementation
(only OSGi core implementation)?


You should find the promises and functions in the bundle
org.eclipse.osgi.util


btw I have removed the runtime scope for "org.eclipse.osgi".

Am 02.01.20 um 19:00 schrieb Raymond Auge:

A bit of rational about why companion jars are unresolvable:

The OSGi specs are to a very high degree independent from each
other. There's no reason for you to be forced to use all R5
specs, or all R6 or whatever. Those are simply marketing versions.

What you are really using are the individual specs at a given
version.

For example using DS 1.4, Event 1.0, and logging 1.2 is
perfectly fine combination given you can find providers of each
that work together well. The APIs themselves won't care.

However some providers actually package OSGi spec APIs which
they provide implementations for, which means if you include
the aggregate companion jars also at runtime you may have two
API versions to contend with.

You may inadvertently expose yourself to a wrong API version,
hence why they will no longer resolve.

- Ray

On Thu, Jan 2, 2020 at 12:36 PM Raymond Auge
mailto:raymond.a...@liferay.com>> wrote:

Yes and yes.

OSGi started adding the unresolveable requirement at
release 6 IIRC. So if you are using a prior releases of the
companion jars (including cmpn, enterprise) they won't give
you this failure, so you should upgrade.

*Replacements:* Replace the compendium APIs with their
respective individual api jars available on maven central,
like this one [1].

[1]

https://search.maven.org/artifact/org.osgi/org.osgi.service.component.annotations/1.4.0/jar

- Ray


On Thu, Jan 2, 2020 at 12:31 PM Martin Petzold
mailto:mpetz...@gmx.net>> wrote:

Thanks, Raymond! Does this also relate to
"org.osgi:osgi.cmpn"? Should I remove this dependency too?

Am 02.01.20 um 18:23 schrieb Raymond Auge:



On Thu, Jan 2, 2020 at 12:17 PM Martin Petzold via
osgi-dev mailto:osgi-dev@mail.osgi.org>> wrote:

Dear OSGi gurus,

I have a dependency on "org.osgi:osgi.core"
(7.0.0) in my POM. The reason is that I need
access to the "org.osgi.framework" package. I am
using Maven (3.6) and Tycho 

Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

[Neil Bartlett via osgi-dev]

On Fri, 3 Jan 2020 at 13:08, Martin Petzold via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Okay, thanks. This is clear now.
>
> However, Ray told me to set the dependency for "org.eclipse.osgi" to
> "runtime" scope. But how can my implementation then depend on
> "org.osgi.framework" package during compile time? Either there is a
> separate API bundle from OSGi Alliance containing "org.osgi.framework"
> (which one is it?)
>

Yes, this is the org.osgi:osgi.core dependency. That contains the pure api
and no implementation, whereas org.eclipse.osgi is an implementation.

Or you could just use org.eclipse.osgi at both compile time and runtime,
but then you should be careful to avoid using equinox internal packages.

or I should set the scope to compile instead of runtime?
>
> I am using the BundleContext and need access to this package.
>
> Thanks and kind regards,
>
> Martin
> Am 03.01.20 um 10:51 schrieb Mark Hoffmann via osgi-dev:
>
> Hi Martin,
>
> see comments inline.
>
> Regards,
>
> Mark
> Am 02.01.20 um 19:19 schrieb Martin Petzold via osgi-dev:
>
> Thanks, Raymond! Does this also relate to "org.osgi:osgi.cmpn"? Should I
> remove this dependency too? Should I add "org.eclipse.osgi.services" or the
> individual "org.osgi.service.*" to my (parent) POM? Are the individual
> "org.osgi.service.*" also required at runtime (on classpath or installed to
> osgi?). Will "org.eclipse.osgi" start without "org.eclipse.osgi.services"
> on the classpath or installation as bundle?
>
> You have to distinguish between the packages you want to resolve and the
> artifacts/bundles that contain the the packages/implementations.
>
> In your case org.eclipse.osgi.services is the bundle that exports the
> packages org.osgi.service.* packages.
>
> Because Maven just resolves artifacts, you need to provide the bundle
> org.eclipse.osgi.services as dependency.
>
> Yes, org.eclipse.osgi will start without org.eclipse.osgi.services
>
> I have now added "org.eclipse.osgi.services". However, it now cannot
> requires "org.osgi.util.promise". What should I add to my POM in order to
> resolve the core Eclipse OSGi implementation (only OSGi core
> implementation)?
>
> You should find the promises and functions in the bundle
> org.eclipse.osgi.util
>
> btw I have removed the runtime scope for "org.eclipse.osgi".
> Am 02.01.20 um 19:00 schrieb Raymond Auge:
>
> A bit of rational about why companion jars are unresolvable:
>
> The OSGi specs are to a very high degree independent from each other.
> There's no reason for you to be forced to use all R5 specs, or all R6 or
> whatever. Those are simply marketing versions.
>
> What you are really using are the individual specs at a given version.
>
> For example using DS 1.4, Event 1.0, and logging 1.2 is perfectly fine
> combination given you can find providers of each that work together well.
> The APIs themselves won't care.
>
> However some providers actually package OSGi spec APIs which they provide
> implementations for, which means if you include the aggregate companion
> jars also at runtime you may have two API versions to contend with.
>
> You may inadvertently expose yourself to a wrong API version, hence why
> they will no longer resolve.
>
> - Ray
>
> On Thu, Jan 2, 2020 at 12:36 PM Raymond Auge 
> wrote:
>
>> Yes and yes.
>>
>> OSGi started adding the unresolveable requirement at release 6 IIRC. So
>> if you are using a prior releases of the companion jars (including cmpn,
>> enterprise) they won't give you this failure, so you should upgrade.
>>
>> *Replacements:* Replace the compendium APIs with their respective
>> individual api jars available on maven central, like this one [1].
>>
>> [1]
>> https://search.maven.org/artifact/org.osgi/org.osgi.service.component.annotations/1.4.0/jar
>>
>> - Ray
>>
>>
>> On Thu, Jan 2, 2020 at 12:31 PM Martin Petzold  wrote:
>>
>>> Thanks, Raymond! Does this also relate to "org.osgi:osgi.cmpn"? Should I
>>> remove this dependency too?
>>> Am 02.01.20 um 18:23 schrieb Raymond Auge:
>>>
>>>
>>>
>>> On Thu, Jan 2, 2020 at 12:17 PM Martin Petzold via osgi-dev <
>>> osgi-dev@mail.osgi.org> wrote:
>>>
 Dear OSGi gurus,
 I have a dependency on "org.osgi:osgi.core" (7.0.0) in my POM. The
 reason is that I need access to the "org.osgi.framework" package. I am
 using Maven (3.6) and Tycho (1.5.1) for building. The build platform runs
 Debian 10 and Java 11.

 *I get the following error:*

 Missing requirement: osgi.core 7.0.0.201802012106 requires
 'osgi.unresolvable; (&(!(must.not.resolve=*))(must.not.resolve=*))' but it
 could not be found

>>>
>>> The "companion jars" are not meant for runtime and since resolving is a
>>> runtime operation (even when performed during build, i.e. deployment
>>> purposes) should not be included.
>>>
>>>
 *However, if I remove the dependency I get the following error:*
 Missing requirement: my.bundle 0.0.0.qualifier requires 'java.package;
 org.osgi.framework 

Re: [osgi-dev] Maven (Tycho) cannot resolve OSGi Core bundle

[Martin Petzold via osgi-dev]

Okay, thanks. This is clear now.

However, Ray told me to set the dependency for "org.eclipse.osgi" to
"runtime" scope. But how can my implementation then depend on
"org.osgi.framework" package during compile time? Either there is a
separate API bundle from OSGi Alliance containing "org.osgi.framework"
(which one is it?) or I should set the scope to compile instead of runtime?

I am using the BundleContext and need access to this package.

Thanks and kind regards,

Martin

Am 03.01.20 um 10:51 schrieb Mark Hoffmann via osgi-dev:


Hi Martin,

see comments inline.

Regards,

Mark

Am 02.01.20 um 19:19 schrieb Martin Petzold via osgi-dev:


Thanks, Raymond! Does this also relate to "org.osgi:osgi.cmpn"?
Should I remove this dependency too? Should I add
"org.eclipse.osgi.services" or the individual "org.osgi.service.*" to
my (parent) POM? Are the individual "org.osgi.service.*" also
required at runtime (on classpath or installed to osgi?). Will
"org.eclipse.osgi" start without "org.eclipse.osgi.services" on the
classpath or installation as bundle?


You have to distinguish between the packages you want to resolve and
the artifacts/bundles that contain the the packages/implementations.

In your case org.eclipse.osgi.services is the bundle that exports the
packages org.osgi.service.* packages.

Because Maven just resolves artifacts, you need to provide the bundle
org.eclipse.osgi.services as dependency.

Yes, org.eclipse.osgi will start without org.eclipse.osgi.services


I have now added "org.eclipse.osgi.services". However, it now cannot
requires "org.osgi.util.promise". What should I add to my POM in
order to resolve the core Eclipse OSGi implementation (only OSGi core
implementation)?


You should find the promises and functions in the bundle
org.eclipse.osgi.util


btw I have removed the runtime scope for "org.eclipse.osgi".

Am 02.01.20 um 19:00 schrieb Raymond Auge:

A bit of rational about why companion jars are unresolvable:

The OSGi specs are to a very high degree independent from each
other. There's no reason for you to be forced to use all R5 specs,
or all R6 or whatever. Those are simply marketing versions.

What you are really using are the individual specs at a given version.

For example using DS 1.4, Event 1.0, and logging 1.2 is perfectly
fine combination given you can find providers of each that work
together well. The APIs themselves won't care.

However some providers actually package OSGi spec APIs which they
provide implementations for, which means if you include the
aggregate companion jars also at runtime you may have two API
versions to contend with.

You may inadvertently expose yourself to a wrong API version, hence
why they will no longer resolve.

- Ray

On Thu, Jan 2, 2020 at 12:36 PM Raymond Auge
mailto:raymond.a...@liferay.com>> wrote:

Yes and yes.

OSGi started adding the unresolveable requirement at release 6
IIRC. So if you are using a prior releases of the companion jars
(including cmpn, enterprise) they won't give you this failure,
so you should upgrade.

*Replacements:* Replace the compendium APIs with their
respective individual api jars available on maven central, like
this one [1].

[1]

https://search.maven.org/artifact/org.osgi/org.osgi.service.component.annotations/1.4.0/jar

- Ray


On Thu, Jan 2, 2020 at 12:31 PM Martin Petzold mailto:mpetz...@gmx.net>> wrote:

Thanks, Raymond! Does this also relate to
"org.osgi:osgi.cmpn"? Should I remove this dependency too?

Am 02.01.20 um 18:23 schrieb Raymond Auge:



On Thu, Jan 2, 2020 at 12:17 PM Martin Petzold via osgi-dev
mailto:osgi-dev@mail.osgi.org>> wrote:

Dear OSGi gurus,

I have a dependency on "org.osgi:osgi.core" (7.0.0) in
my POM. The reason is that I need access to the
"org.osgi.framework" package. I am using Maven (3.6)
and Tycho (1.5.1) for building. The build platform runs
Debian 10 and Java 11.

*I get the following error:*

Missing requirement: osgi.core 7.0.0.201802012106
requires 'osgi.unresolvable;
(&(!(must.not.resolve=*))(must.not.resolve=*))' but it
could not be found


The "companion jars" are not meant for runtime and since
resolving is a runtime operation (even when performed
during build, i.e. deployment purposes) should not be included.

*However, if I remove the dependency I get the
following error:*

Missing requirement: my.bundle 0.0.0.qualifier requires
'java.package; org.osgi.framework 1.7.0' but it could
not be found


This means you have no runtime framework available! Add a
runtime dependency on the equinox framework:


org.eclipse.platform
org.eclipse.osgi
    3.x.0
    runtime

// of course use tycho mechanism