On Fri, Jan 3, 2020 at 10:29 AM Martin Petzold <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> 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: >>> >>> <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</artifactId> >>> <version>${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> 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> 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> 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> 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 < >>>>>>>> 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> >>>>>>>>> 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 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 >>>>>>>>>>> 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 >>>>>>>> listosgi-...@mail.osgi.orghttps://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 GmbHKahlaische 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 >>>>>>>> listosgi-...@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OSGi Developer Mail List >>>>>>>> osgi-dev@mail.osgi.org >>>>>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OSGi Developer Mail List >>>>>>> osgi-dev@mail.osgi.org >>>>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>>>> >>>>>> _______________________________________________ >>> OSGi Developer Mail List >>> 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
