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
<raymond.a...@liferay.com <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 <mpetz...@gmx.net
<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
<osgi-dev@mail.osgi.org <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:
<dependency>
<groupId>org.eclipse.platform</groupId>
<artifactId>org.eclipse.osgi</artifactId>
<version>3.x.0</version>
<scope>runtime</scope>
</dependency>
// of course use tycho mechanism for above.
*What is going wrong? How can I resolve this problem?*
Stack Overflow:
https://stackoverflow.com/questions/59563368/maven-tycho-cannot-resolve-osgi-core-bundle
I'll answer there in a moment.
- Ray
Thanks and kind regards,
Martin
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org <mailto: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)
--
*Raymond Augé*
<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect *Liferay, Inc.*
<http://www.liferay.com> (@Liferay)
--
*Raymond Augé*
<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect *Liferay, Inc.*
<http://www.liferay.com> (@Liferay)
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Mark Hoffmann
M.A. Dipl.-Betriebswirt (FH)
CEO/CTO
Phone: +49 3641 384 910 0
Mobile: +49 175 701 2201
E-Mail: m.hoffm...@data-in-motion.biz
Web: www.datainmotion.de
Data In Motion Consulting GmbH
Kahlaische Strasse 4
07745 Jena
Germany
Geschäftsführer/CEO
Mark Hoffmann
Jürgen Albert
Jena HRB 513025
Steuernummer 162/107/05779
USt-Id DE310002614
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
