You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Roy Teeuwen <ro...@teeuwen.be> on 2017/03/16 08:02:48 UTC
Using OSGi DS and old Apache Felix SCR together
Hey all,
I am running in a problem when trying to use OSGi DS annotations and Apache Felix annotations together. I have unit tests that depend on the service xml's being present (I am using the Apache Sling osgi-mock to run unit tests), but the problem that I am facing is that when the maven-bundle-plugin:manifest phase has been executed, the maven-scr-plugin deletes the maven-bundle-plugin xml's again created by the maven-bundle manifest phase, is there any way to avoid this and make it that they are merged togheter? All xmls are present in the JAR file when everything is compiled so in the end it works out, but I need them for the unit tests too.
The configuration I am currently using at the moment:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>3.2.0</version>
<configuration>
<instructions>
...
<_dsannotations>*</_dsannotations>
<_metatypeannotations>*</_metatypeannotations>
</instructions>
<exportScr>true</exportScr>
</configuration>
<executions>
<!--
Configure extra execution of 'manifest' in process-classes phase
to make sure SCR metadata is generated before unit test runs
-->
<execution>
<id>scr-metadata</id>
<goals>
<goal>manifest</goal>
</goals>
<configuration>
<supportIncrementalBuild>true</supportIncrementalBuild>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-scr-plugin</artifactId>
<version>1.24.0</version>
<executions>
<execution>
<id>generate-scr-reportDescriptor</id>
<goals>
<goal>scr</goal>
</goals>
</execution>
</executions>
</plugin>
Greetings,
Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Using OSGi DS and old Apache Felix SCR together
Posted by Dominik Przybysz <al...@gmail.com>.
Hi,
1) You can try to set outputDirectory parameter for felix scr plugin and
add this directory to bundle (
http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/apache-felix-maven-scr-plugin-use.html
)
2) Why do you mix these two annotations?
2017-03-16 9:02 GMT+01:00 Roy Teeuwen <ro...@teeuwen.be>:
> Hey all,
>
> I am running in a problem when trying to use OSGi DS annotations and
> Apache Felix annotations together. I have unit tests that depend on the
> service xml's being present (I am using the Apache Sling osgi-mock to run
> unit tests), but the problem that I am facing is that when the
> maven-bundle-plugin:manifest phase has been executed, the maven-scr-plugin
> deletes the maven-bundle-plugin xml's again created by the maven-bundle
> manifest phase, is there any way to avoid this and make it that they are
> merged togheter? All xmls are present in the JAR file when everything is
> compiled so in the end it works out, but I need them for the unit tests too.
>
> The configuration I am currently using at the moment:
>
> <plugin>
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-bundle-plugin</artifactId>
> <version>3.2.0</version>
> <configuration>
> <instructions>
> ...
> <_dsannotations>*</_dsannotations>
> <_metatypeannotations>*</_metatypeannotations>
> </instructions>
> <exportScr>true</exportScr>
> </configuration>
> <executions>
> <!--
> Configure extra execution of 'manifest' in process-classes
> phase
> to make sure SCR metadata is generated before unit test runs
> -->
> <execution>
> <id>scr-metadata</id>
> <goals>
> <goal>manifest</goal>
> </goals>
> <configuration>
> <supportIncrementalBuild>true</supportIncrementalBuild>
> </configuration>
> </execution>
> </executions>
> </plugin>
> <plugin>
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-scr-plugin</artifactId>
> <version>1.24.0</version>
> <executions>
> <execution>
> <id>generate-scr-reportDescriptor</id>
> <goals>
> <goal>scr</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
>
> Greetings,
> Roy
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Pozdrawiam / Regards,
Dominik Przybysz
RE: Using OSGi DS and old Apache Felix SCR together
Posted by Stefan Seifert <ss...@pro-vision.de>.
this looks to me like a classpath issue around the org.apache.commons.collections dependency oft he maven-bundle-plugin or it's plugins.
try to update to most recent versions from maven-bundle-plugin and it's dependencies (e.g. scr plugin), and perhaps it this does not help manually add a dependency to maven-bundle-plugin with the latest commons-collections version.
(i've never seen this problem in my projects)
stefan
>-----Original Message-----
>From: Roy Teeuwen [mailto:roy@teeuwen.be]
>Sent: Friday, March 17, 2017 10:09 AM
>To: users@felix.apache.org
>Subject: Re: Using OSGi DS and old Apache Felix SCR together
>
>Hey Stefan,
>
>I used the plugin in the maven-bundle-plugin, but it seems that some of my
>bundles give following exception, any idea what might be causing this?
>
>[ERROR] Manifest mygroupId:myartifactId:bundle:30.0-SNAPSHOT : Got
>unexpected exception while
>analyzing:org.apache.felix.scrplugin.SCRDescriptorException: Unable to load
>compiled class: org.apache.commons.collections.DoubleOrderedMap$1$1
> at
>org.apache.felix.scrplugin.helper.ClassScanner.scanSources(ClassScanner.jav
>a:156)
> at
>org.apache.felix.scrplugin.SCRDescriptorGenerator.execute(SCRDescriptorGene
>rator.java:146)
> at
>org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin.analyzeJar(SCRDescrip
>torBndPlugin.java:178)
> at aQute.bnd.osgi.Analyzer.doPlugins(Analyzer.java:656)
> at aQute.bnd.osgi.Analyzer.analyze(Analyzer.java:209)
> at aQute.bnd.osgi.Builder.analyze(Builder.java:389)
> at aQute.bnd.osgi.Analyzer.calcManifest(Analyzer.java:687)
> at aQute.bnd.osgi.Builder.build(Builder.java:105)
> at
>org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer(ManifestPlugin.jav
>a:291)
> at
>org.apache.felix.bundleplugin.ManifestPlugin.execute(ManifestPlugin.java:98
>)
> at
>org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:384)
> at
>org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:375)
> at
>org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildP
>luginManager.java:134)
> at
>org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:
>207)
> at
>org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:
>153)
> at
>org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:
>145)
> at
>org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(Lif
>ecycleModuleBuilder.java:116)
> at
>org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(Lif
>ecycleModuleBuilder.java:80)
> at
>org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBu
>ilder.build(SingleThreadedBuilder.java:51)
> at
>org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStart
>er.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:6
>2)
> at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
>l.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
>org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.j
>ava:289)
> at
>org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
>org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher
>.java:415)
> at
>org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:6
>2)
> at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
>l.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
>com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
>Caused by: java.lang.IllegalAccessError: class
>org.apache.commons.collections.DoubleOrderedMap$1$1 cannot access its
>superclass
>org.apache.commons.collections.DoubleOrderedMap$DoubleOrderedMapIterator
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
> at
>java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
>org.apache.felix.scrplugin.helper.ClassScanner.scanSources(ClassScanner.jav
>a:144)
> ... 39 more
>
>Thanks!
>Roy
>
>> On 16 Mar 2017, at 17:49, Stefan Seifert <ss...@pro-vision.de> wrote:
>>
>>
>>> I think the bnd support is for the proprietary bnd annotations, not the
>>> proprietary felix annotations. AFAIR bnd never supported the proprietary
>>> felix scr annotations.
>>
>> no, org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin really hooks in
>the support for the proprietary felix SCR annotations.
>>
>>
>>> I also think that bnd (and thus the maven-bundle-plugin) runs and
>>> generates the xml after the unit tests run, so that you will never be
>able
>>> to get the xml’s in time for unit tests. I don’t know if integration
>>> tests (failsafe plugin) run before or after the bundle is assembled, but
>I
>>> think after, so perhaps that would be worth looking into.
>>
>> it works if you additionally configure a "manifest" goal in your pom. and
>if "supportIncrementalBuild" is added as well it even works within eclipse
>incremental builds. see [1] for an example.
>>
>> stefan
>>
>> [1] https://github.com/wcm-io/wcm-io-tooling/blob/develop/maven/aem-
>global-parent/pom.xml
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>For additional commands, e-mail: users-help@felix.apache.org
>
Re: Using OSGi DS and old Apache Felix SCR together
Posted by Roy Teeuwen <ro...@teeuwen.be>.
Hey Stefan,
I used the plugin in the maven-bundle-plugin, but it seems that some of my bundles give following exception, any idea what might be causing this?
[ERROR] Manifest mygroupId:myartifactId:bundle:30.0-SNAPSHOT : Got unexpected exception while analyzing:org.apache.felix.scrplugin.SCRDescriptorException: Unable to load compiled class: org.apache.commons.collections.DoubleOrderedMap$1$1
at org.apache.felix.scrplugin.helper.ClassScanner.scanSources(ClassScanner.java:156)
at org.apache.felix.scrplugin.SCRDescriptorGenerator.execute(SCRDescriptorGenerator.java:146)
at org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin.analyzeJar(SCRDescriptorBndPlugin.java:178)
at aQute.bnd.osgi.Analyzer.doPlugins(Analyzer.java:656)
at aQute.bnd.osgi.Analyzer.analyze(Analyzer.java:209)
at aQute.bnd.osgi.Builder.analyze(Builder.java:389)
at aQute.bnd.osgi.Analyzer.calcManifest(Analyzer.java:687)
at aQute.bnd.osgi.Builder.build(Builder.java:105)
at org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer(ManifestPlugin.java:291)
at org.apache.felix.bundleplugin.ManifestPlugin.execute(ManifestPlugin.java:98)
at org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:384)
at org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:375)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
Caused by: java.lang.IllegalAccessError: class org.apache.commons.collections.DoubleOrderedMap$1$1 cannot access its superclass org.apache.commons.collections.DoubleOrderedMap$DoubleOrderedMapIterator
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at org.apache.felix.scrplugin.helper.ClassScanner.scanSources(ClassScanner.java:144)
... 39 more
Thanks!
Roy
> On 16 Mar 2017, at 17:49, Stefan Seifert <ss...@pro-vision.de> wrote:
>
>
>> I think the bnd support is for the proprietary bnd annotations, not the
>> proprietary felix annotations. AFAIR bnd never supported the proprietary
>> felix scr annotations.
>
> no, org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin really hooks in the support for the proprietary felix SCR annotations.
>
>
>> I also think that bnd (and thus the maven-bundle-plugin) runs and
>> generates the xml after the unit tests run, so that you will never be able
>> to get the xml’s in time for unit tests. I don’t know if integration
>> tests (failsafe plugin) run before or after the bundle is assembled, but I
>> think after, so perhaps that would be worth looking into.
>
> it works if you additionally configure a "manifest" goal in your pom. and if "supportIncrementalBuild" is added as well it even works within eclipse incremental builds. see [1] for an example.
>
> stefan
>
> [1] https://github.com/wcm-io/wcm-io-tooling/blob/develop/maven/aem-global-parent/pom.xml
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Using OSGi DS and old Apache Felix SCR together
Posted by Stefan Seifert <ss...@pro-vision.de>.
>I think the bnd support is for the proprietary bnd annotations, not the
>proprietary felix annotations. AFAIR bnd never supported the proprietary
>felix scr annotations.
no, org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin really hooks in the support for the proprietary felix SCR annotations.
>I also think that bnd (and thus the maven-bundle-plugin) runs and
>generates the xml after the unit tests run, so that you will never be able
>to get the xml’s in time for unit tests. I don’t know if integration
>tests (failsafe plugin) run before or after the bundle is assembled, but I
>think after, so perhaps that would be worth looking into.
it works if you additionally configure a "manifest" goal in your pom. and if "supportIncrementalBuild" is added as well it even works within eclipse incremental builds. see [1] for an example.
stefan
[1] https://github.com/wcm-io/wcm-io-tooling/blob/develop/maven/aem-global-parent/pom.xml
Re: Using OSGi DS and old Apache Felix SCR together
Posted by David Jencks <da...@gmail.com>.
I think the bnd support is for the proprietary bnd annotations, not the proprietary felix annotations. AFAIR bnd never supported the proprietary felix scr annotations.
I also think that bnd (and thus the maven-bundle-plugin) runs and generates the xml after the unit tests run, so that you will never be able to get the xml’s in time for unit tests. I don’t know if integration tests (failsafe plugin) run before or after the bundle is assembled, but I think after, so perhaps that would be worth looking into.
david jencks
> On Mar 16, 2017, at 2:09 AM, Stefan Seifert <ss...@pro-vision.de> wrote:
>
> you should not use the maven-scr-plugin at all in this case - there is a bnd plugin for the old felix SCR annotations that does the same job.
> so use only maven-bundle-plugin and add an instruction
> <_plugin>org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin;destdir=${project.build.outputDirectory}</plugin>
>
> for a full example see [1]
>
> on the long run you should migrate to the OSGi annotations and remove the felix scr annotations.
>
> stefan
>
> [1] https://github.com/wcm-io/wcm-io-tooling/blob/develop/maven/aem-global-parent/pom.xml
>
>
>> -----Original Message-----
>> From: Roy Teeuwen [mailto:roy@teeuwen.be]
>> Sent: Thursday, March 16, 2017 9:03 AM
>> To: users@felix.apache.org
>> Subject: Using OSGi DS and old Apache Felix SCR together
>>
>> Hey all,
>>
>> I am running in a problem when trying to use OSGi DS annotations and Apache
>> Felix annotations together. I have unit tests that depend on the service
>> xml's being present (I am using the Apache Sling osgi-mock to run unit
>> tests), but the problem that I am facing is that when the maven-bundle-
>> plugin:manifest phase has been executed, the maven-scr-plugin deletes the
>> maven-bundle-plugin xml's again created by the maven-bundle manifest phase,
>> is there any way to avoid this and make it that they are merged togheter?
>> All xmls are present in the JAR file when everything is compiled so in the
>> end it works out, but I need them for the unit tests too.
>>
>> The configuration I am currently using at the moment:
>>
>> <plugin>
>> <groupId>org.apache.felix</groupId>
>> <artifactId>maven-bundle-plugin</artifactId>
>> <version>3.2.0</version>
>> <configuration>
>> <instructions>
>> ...
>> <_dsannotations>*</_dsannotations>
>> <_metatypeannotations>*</_metatypeannotations>
>> </instructions>
>> <exportScr>true</exportScr>
>> </configuration>
>> <executions>
>> <!--
>> Configure extra execution of 'manifest' in process-classes
>> phase
>> to make sure SCR metadata is generated before unit test runs
>> -->
>> <execution>
>> <id>scr-metadata</id>
>> <goals>
>> <goal>manifest</goal>
>> </goals>
>> <configuration>
>> <supportIncrementalBuild>true</supportIncrementalBuild>
>> </configuration>
>> </execution>
>> </executions>
>> </plugin>
>> <plugin>
>> <groupId>org.apache.felix</groupId>
>> <artifactId>maven-scr-plugin</artifactId>
>> <version>1.24.0</version>
>> <executions>
>> <execution>
>> <id>generate-scr-reportDescriptor</id>
>> <goals>
>> <goal>scr</goal>
>> </goals>
>> </execution>
>> </executions>
>> </plugin>
>>
>> Greetings,
>> Roy
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Using OSGi DS and old Apache Felix SCR together
Posted by Roy Teeuwen <ro...@teeuwen.be>.
Hey Stefan,
Thanks, thats exactly what I need! And yes, we are in the process of making all the new services in OSGi DS annotations and gradually migrating the Apache Felix SCR annotations to the new OSGi DS, but this will help to make it an incremental process instead of having to do everything at once.
Greets,
Roy
> On 16 Mar 2017, at 10:09, Stefan Seifert <ss...@pro-vision.de> wrote:
>
> you should not use the maven-scr-plugin at all in this case - there is a bnd plugin for the old felix SCR annotations that does the same job.
> so use only maven-bundle-plugin and add an instruction
> <_plugin>org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin;destdir=${project.build.outputDirectory}</plugin>
>
> for a full example see [1]
>
> on the long run you should migrate to the OSGi annotations and remove the felix scr annotations.
>
> stefan
>
> [1] https://github.com/wcm-io/wcm-io-tooling/blob/develop/maven/aem-global-parent/pom.xml
>
>
>> -----Original Message-----
>> From: Roy Teeuwen [mailto:roy@teeuwen.be]
>> Sent: Thursday, March 16, 2017 9:03 AM
>> To: users@felix.apache.org
>> Subject: Using OSGi DS and old Apache Felix SCR together
>>
>> Hey all,
>>
>> I am running in a problem when trying to use OSGi DS annotations and Apache
>> Felix annotations together. I have unit tests that depend on the service
>> xml's being present (I am using the Apache Sling osgi-mock to run unit
>> tests), but the problem that I am facing is that when the maven-bundle-
>> plugin:manifest phase has been executed, the maven-scr-plugin deletes the
>> maven-bundle-plugin xml's again created by the maven-bundle manifest phase,
>> is there any way to avoid this and make it that they are merged togheter?
>> All xmls are present in the JAR file when everything is compiled so in the
>> end it works out, but I need them for the unit tests too.
>>
>> The configuration I am currently using at the moment:
>>
>> <plugin>
>> <groupId>org.apache.felix</groupId>
>> <artifactId>maven-bundle-plugin</artifactId>
>> <version>3.2.0</version>
>> <configuration>
>> <instructions>
>> ...
>> <_dsannotations>*</_dsannotations>
>> <_metatypeannotations>*</_metatypeannotations>
>> </instructions>
>> <exportScr>true</exportScr>
>> </configuration>
>> <executions>
>> <!--
>> Configure extra execution of 'manifest' in process-classes
>> phase
>> to make sure SCR metadata is generated before unit test runs
>> -->
>> <execution>
>> <id>scr-metadata</id>
>> <goals>
>> <goal>manifest</goal>
>> </goals>
>> <configuration>
>> <supportIncrementalBuild>true</supportIncrementalBuild>
>> </configuration>
>> </execution>
>> </executions>
>> </plugin>
>> <plugin>
>> <groupId>org.apache.felix</groupId>
>> <artifactId>maven-scr-plugin</artifactId>
>> <version>1.24.0</version>
>> <executions>
>> <execution>
>> <id>generate-scr-reportDescriptor</id>
>> <goals>
>> <goal>scr</goal>
>> </goals>
>> </execution>
>> </executions>
>> </plugin>
>>
>> Greetings,
>> Roy
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Using OSGi DS and old Apache Felix SCR together
Posted by Stefan Seifert <ss...@pro-vision.de>.
you should not use the maven-scr-plugin at all in this case - there is a bnd plugin for the old felix SCR annotations that does the same job.
so use only maven-bundle-plugin and add an instruction
<_plugin>org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin;destdir=${project.build.outputDirectory}</plugin>
for a full example see [1]
on the long run you should migrate to the OSGi annotations and remove the felix scr annotations.
stefan
[1] https://github.com/wcm-io/wcm-io-tooling/blob/develop/maven/aem-global-parent/pom.xml
>-----Original Message-----
>From: Roy Teeuwen [mailto:roy@teeuwen.be]
>Sent: Thursday, March 16, 2017 9:03 AM
>To: users@felix.apache.org
>Subject: Using OSGi DS and old Apache Felix SCR together
>
>Hey all,
>
>I am running in a problem when trying to use OSGi DS annotations and Apache
>Felix annotations together. I have unit tests that depend on the service
>xml's being present (I am using the Apache Sling osgi-mock to run unit
>tests), but the problem that I am facing is that when the maven-bundle-
>plugin:manifest phase has been executed, the maven-scr-plugin deletes the
>maven-bundle-plugin xml's again created by the maven-bundle manifest phase,
>is there any way to avoid this and make it that they are merged togheter?
>All xmls are present in the JAR file when everything is compiled so in the
>end it works out, but I need them for the unit tests too.
>
>The configuration I am currently using at the moment:
>
><plugin>
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-bundle-plugin</artifactId>
> <version>3.2.0</version>
> <configuration>
> <instructions>
> ...
> <_dsannotations>*</_dsannotations>
> <_metatypeannotations>*</_metatypeannotations>
> </instructions>
> <exportScr>true</exportScr>
> </configuration>
> <executions>
> <!--
> Configure extra execution of 'manifest' in process-classes
>phase
> to make sure SCR metadata is generated before unit test runs
> -->
> <execution>
> <id>scr-metadata</id>
> <goals>
> <goal>manifest</goal>
> </goals>
> <configuration>
> <supportIncrementalBuild>true</supportIncrementalBuild>
> </configuration>
> </execution>
> </executions>
></plugin>
><plugin>
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-scr-plugin</artifactId>
> <version>1.24.0</version>
> <executions>
> <execution>
> <id>generate-scr-reportDescriptor</id>
> <goals>
> <goal>scr</goal>
> </goals>
> </execution>
> </executions>
></plugin>
>
>Greetings,
>Roy
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org