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 <mpetz...@gmx.net
<mailto:mpetz...@gmx.net>> 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 <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)
--
*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
--
Jürgen Albert
Geschäftsführer
Data In Motion Consulting GmbH
Kahlaische Str. 4
07745 Jena
Mobil: 0157-72521634
E-Mail: j.alb...@datainmotion.de
Web: www.datainmotion.de
XING: https://www.xing.com/profile/Juergen_Albert5
Rechtliches
Jena HBR 513025
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
