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 <raymond.a...@liferay.com
<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
<osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>> wrote:
I'm using:
<configuration>
<pomDependencies>consider</pomDependencies>
</configuration>
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).
<!-- Eclipse -->
<dependency>
<groupId>org.eclipse.platform</groupId>
<artifactId>org.eclipse.osgi</artifactId>
<version>${dependency.org.eclipse.osgi}</version>
</dependency>
<!-- OSGi -->
<dependency>
<groupId>org.osgi</groupId>
<artifactId>org.osgi.service.cm
<http://org.osgi.service.cm></artifactId>
<version>${dependency.org.osgi.service.cm
<http://dependency.org.osgi.service.cm>}</version>
</dependency>
<dependency>
<groupId>org.osgi</groupId>
<artifactId>org.osgi.service.event</artifactId>
<version>${dependency.org.osgi.service.event}</version>
</dependency>
<dependency>
<groupId>org.osgi</groupId>
<artifactId>org.osgi.service.log</artifactId>
<version>${dependency.org.osgi.service.log}</version>
</dependency>
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 <mpetz...@gmx.net <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 <mpetz...@gmx.net
<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 <dirk.fa...@gmail.com
<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
<osgi-dev@mail.osgi.org
<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
<osgi-dev@mail.osgi.org
<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
<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
<mailto: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
<mailto:m.hoffm...@data-in-motion.biz>
Web:www.datainmotion.de
<http://www.datainmotion.de>
Data In Motion Consulting GmbH
Kahlaische Strasse 4 07745 Jena Germany
<https://www.google.com/maps/search/Kahlaische+Strasse+4%0D%0A07745+Jena%0D%0AGermany?entry=gmail&source=g>
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
<mailto:osgi-dev@mail.osgi.org>
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
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
<mailto:osgi-dev@mail.osgi.org>
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
--
*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