You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@felix.apache.org by bu...@apache.org on 2016/09/26 09:55:46 UTC
svn commit: r998278 - in /websites/staging/felix/trunk/content: ./
documentation/faqs/apache-felix-bundle-plugin-faq.html
Author: buildbot
Date: Mon Sep 26 09:55:46 2016
New Revision: 998278
Log:
Staging update by buildbot for felix
Modified:
websites/staging/felix/trunk/content/ (props changed)
websites/staging/felix/trunk/content/documentation/faqs/apache-felix-bundle-plugin-faq.html
Propchange: websites/staging/felix/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Mon Sep 26 09:55:46 2016
@@ -1 +1 @@
-1762306
+1762308
Modified: websites/staging/felix/trunk/content/documentation/faqs/apache-felix-bundle-plugin-faq.html
==============================================================================
--- websites/staging/felix/trunk/content/documentation/faqs/apache-felix-bundle-plugin-faq.html (original)
+++ websites/staging/felix/trunk/content/documentation/faqs/apache-felix-bundle-plugin-faq.html Mon Sep 26 09:55:46 2016
@@ -96,6 +96,7 @@ h2:hover > .headerlink, h3:hover > .head
<li><a href="#when-i-build-a-bundle-some-classes-are-built-in-targetclasses-but-theyre-not-included-in-the-final-jar">When I build a bundle, some classes are built in "target/classes" but they're not included in the final jar.</a></li>
<li><a href="#how-do-i-remove-the-generated-maven-information-from-the-resulting-bundle-jar-file">How do I remove the generated Maven information from the resulting bundle JAR file?</a></li>
<li><a href="#why-do-some-generated-resources-such-as-declarative-services-xml-files-appear-in-the-final-jar-but-others-dont">Why do some generated resources (such as Declarative Services XML files) appear in the final jar, but others don't?</a></li>
+<li><a href="#use-scr-metadata-generated-by-bnd-in-unit-tests">Use SCR metadata generated by BND in Unit Tests</a></li>
</ul>
</div>
<h2 id="when-i-embed-a-dependency-why-do-i-see-duplicated-content">When I embed a dependency why do I see duplicated content?<a class="headerlink" href="#when-i-embed-a-dependency-why-do-i-see-duplicated-content" title="Permanent link">¶</a></h2>
@@ -174,8 +175,61 @@ h2:hover > .headerlink, h3:hover > .head
<p>Put this in either the JAR or bundle plugin configuration.</p>
<h2 id="why-do-some-generated-resources-such-as-declarative-services-xml-files-appear-in-the-final-jar-but-others-dont">Why do some generated resources (such as Declarative Services XML files) appear in the final jar, but others don't?<a class="headerlink" href="#why-do-some-generated-resources-such-as-declarative-services-xml-files-appear-in-the-final-jar-but-others-dont" title="Permanent link">¶</a></h2>
<p>When you use the Service-Component instruction to specify Declarative Services the BND tool scans the project classpath for components and automatically adds its generated XML to the final bundle, therefore Include-Resource is not necessary. But if you generate files under OSGI-INF using another mechanism then they won't end up in the bundle unless you add that directory using Include-Resource (this goes back to the core design decision that BND pulls classes and resources into the bundle, rather than just taking everything under target/classes). We try to provide reasonable defaults on the Maven side in the bundleplugin so local classes and resources will end up in the bundle without additional configuration, but we do this by looking at the effective pom and src/ folder rather than the generated target/classes content.</p>
+<h2 id="use-scr-metadata-generated-by-bnd-in-unit-tests">Use SCR metadata generated by BND in Unit Tests<a class="headerlink" href="#use-scr-metadata-generated-by-bnd-in-unit-tests" title="Permanent link">¶</a></h2>
+<p>BND and the maven-bundle-plugin support the generation of SCR metadata for OSGi Declarative Service components annotated with the OSGi annotations from the Java package <code>org.osgi.service.component.annotations</code>.</p>
+<p>To enable this you have to set two special instructions in your maven-bundle-plugin configuration:</p>
+<div class="codehilite"><pre><span class="nt"><configuration></span>
+ <span class="nt"><instructions></span>
+ <span class="c"><!-- Enable processing of OSGI DS component annotations --></span>
+ <span class="nt"><_dsannotations></span>*<span class="nt"></_dsannotations></span>
+ <span class="c"><!-- Enable processing of OSGI metatype annotations --></span>
+ <span class="nt"><_metatypeannotations></span>*<span class="nt"></_metatypeannotations></span>
+ <span class="nt"></instructions></span>
+<span class="nt"></configuration></span>
+</pre></div>
+
+
+<p>This generates the SCR metadata files at <code>/OSGI-INF</code> and <code>/OSGI-INF/metatype</code> when building the JAR file.</p>
+<p>If you want to run unit test in the same maven projects that need these SCR metadata files when running the tests (e.g. when using <a href="http://sling.apache.org/documentation/development/osgi-mock.html">OSGi Mocks</a>) you need some special configurations to ensure the SCR metadata is also generated in the filesystem in the maven target folder, and is already available when the unit tests are executed and not only in the package phase:</p>
+<div class="codehilite"><pre><span class="nt"><plugin></span>
+ <span class="nt"><groupId></span>org.apache.felix<span class="nt"></groupId></span>
+ <span class="nt"><artifactId></span>maven-bundle-plugin<span class="nt"></artifactId></span>
+ <span class="nt"><extensions></span>true<span class="nt"></extensions></span>
+ <span class="nt"><executions></span>
+ <span class="c"><!-- Configure extra execution of 'manifest' in process-classes phase to make sure SCR metadata is generated before unit test runs --></span>
+ <span class="nt"><execution></span>
+ <span class="nt"><id></span>scr-metadata<span class="nt"></id></span>
+ <span class="nt"><goals></span>
+ <span class="nt"><goal></span>manifest<span class="nt"></goal></span>
+ <span class="nt"></goals></span>
+ <span class="nt"><configuration></span>
+ <span class="nt"><supportIncrementalBuild></span>true<span class="nt"></supportIncrementalBuild></span>
+ <span class="nt"></configuration></span>
+ <span class="nt"></execution></span>
+ <span class="nt"></executions></span>
+ <span class="nt"><configuration></span>
+ <span class="nt"><exportScr></span>true<span class="nt"></exportScr></span>
+ <span class="nt"><instructions></span>
+ <span class="c"><!-- Enable processing of OSGI DS component annotations --></span>
+ <span class="nt"><_dsannotations></span>*<span class="nt"></_dsannotations></span>
+ <span class="c"><!-- Enable processing of OSGI metatype annotations --></span>
+ <span class="nt"><_metatypeannotations></span>*<span class="nt"></_metatypeannotations></span>
+ <span class="nt"></instructions></span>
+ <span class="nt"></configuration></span>
+<span class="nt"></plugin></span>
+</pre></div>
+
+
+<p>The flag <code>supportIncrementalBuild</code> is only necessary when you are using Eclipse and m2e, it supports generating the appropriate metadata during incremental builds. When you also want to support the old-style Felix SCR annotations from Java package <code>org.apache.felix.scr.annotations</code> you can add this BND plugin:</p>
+<div class="codehilite"><pre><span class="nt"><configuration></span>
+ <span class="nt"><instructions></span>
+ <span class="c"><!-- Support parsing of maven-scr-plugin annotations through the felix.scr.bnd plugin --></span>
+ <span class="nt"><_plugin></span>org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin;destdir=<span class="cp">${</span><span class="n">project</span><span class="o">.</span><span class="n">build</span><span class="o">.</span><span class="n">outputDirectory</span><span class="cp">}</span>;<span class="nt"></_plugin></span>
+ <span class="nt"></instructions></span>
+<span class="nt"></configuration></span>
+</pre></div>
<div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
- Rev. 1762306 by cziegeler on Mon, 26 Sep 2016 09:54:12 +0000
+ Rev. 1762308 by cziegeler on Mon, 26 Sep 2016 09:55:32 +0000
</div>
<div class="trademarkFooter">
Apache Felix, Felix, Apache, the Apache feather logo, and the Apache Felix project