Maven-Bundle-Plugin ignores servicefactory-directive

[Mustafa Caylak]

Hi guys,

We have a problem with the Maven-Bundle-Plugin. When we define a
Declarative Service Component in the '.bnd'-file, we use a directive
named 'servicefactory'. But the directive doesn't have an effect on the
generated XML-Document for the DSC.
I know that the plugin is based uppon the BND-Tool by Peter Kriens. So I
used it to check if it generates the document I want. It does ( <service
servicefactory='true'> ).

Do you know why the plugin ignores the directive?


In the following you see the definition of the DSC and the relevant part
of the pom.xml.

#-----------------------------------------------------------------
# BND FILE
#-----------------------------------------------------------------
Export-Package: de.offis.utils.configSC;version=1.0.0.SNAPSHOT
Private-Package: de.offis.utils.configSC.internal;version=1.0.0.SNAPSHOT
Service-Component: de.offis.utils.configSC.internal.ConfigReaderImpl; \
    provide:=de.offis.utils.configSC.ConfigReader; \
    immediate:=false; \
    servicefactory:=true




#-----------------------------------------------------------------
# RELEVANT PART OF OUR POM.XML
#-----------------------------------------------------------------
  <build>
    <plugins>
      <!-- This is use for OSGi extention of the build script. -->
      <plugin>
        <groupId>org.ops4j</groupId>
        <artifactId>maven-pax-plugin</artifactId>
        <configuration>
          <provision>
            <param>--platform=equinox</param>
            <param>--profiles=minimal</param>
          </provision>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.apache.felix</groupId>
        <artifactId>maven-bundle-plugin</artifactId>
    <extensions>true</extensions>
        <!--
         | the following instructions build a simple set of
public/private classes into an OSGi bundle
        -->
        <configuration>
          <manifestLocation>META-INF</manifestLocation>
          <instructions>
           
<Bundle-SymbolicName>${bundle.symbolicName}</Bundle-SymbolicName>
            <Bundle-Version>${pom.version}</Bundle-Version>
            <!--
             | assume public classes are in the top package, and private
classes are under ".internal"
            -->
           
<Export-Package>!${bundle.namespace}.internal.*,${bundle.namespace}.*;version="${pom.version}"</Export-Package>
<!--            
<Private-Package>${bundle.namespace}.internal.*</Private-Package>-->
          </instructions>
        </configuration>
      </plugin>
      <plugin>
        <artifactId>maven-clean-plugin</artifactId>
        <configuration>
          <filesets>
            <fileset>
              <directory>META-INF</directory>
            </fileset>
            <fileset>
              <directory>runner</directory>
            </fileset>
            <fileset>
              <directory>.</directory>
              <includes>
                <include>**/build.properties</include>
              </includes>
              <excludes>
                <exclude>**/*</exclude>
              </excludes>
            </fileset>
            <fileset>
              <directory>.settings</directory>
            </fileset>
          </filesets>
        </configuration>
      </plugin>
      <!-- Automation for test. -->
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>findbugs-maven-plugin</artifactId>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-javadoc-plugin</artifactId>
        <configuration>
          <destDir>${target.javadoc}</destDir>
        </configuration>
        <executions>
          <execution>
            <phase>package</phase>
            <goals>
              <goal>javadoc</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
      <!--
       | Include the compiler plugin. This will be used to setup the
java source
       | and target version. Default the source and target version is
set to 1.3
       | in this project we will use 1.6.
       -->
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.6</source>
          <target>1.6</target>
        </configuration>
      </plugin>
    </plugins>
  </build>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Mustafa Caylak]

Hi,

Is really no one there who had this problem or knows why it occurs?
Or is something unclear?
It would be very kind if someone could help me.


Best regards,
Mustafa Caylak








Mustafa Caylak wrote:

> Hi guys,
>
> We have a problem with the Maven-Bundle-Plugin. When we define a
> Declarative Service Component in the '.bnd'-file, we use a directive
> named 'servicefactory'. But the directive doesn't have an effect on
> the generated XML-Document for the DSC.
> I know that the plugin is based uppon the BND-Tool by Peter Kriens. So
> I used it to check if it generates the document I want. It does (
> <service servicefactory='true'> ).
>
> Do you know why the plugin ignores the directive?
>
>
> In the following you see the definition of the DSC and the relevant
> part of the pom.xml.
>
> #-----------------------------------------------------------------
> # BND FILE
> #-----------------------------------------------------------------
> Export-Package: de.offis.utils.configSC;version=1.0.0.SNAPSHOT
> Private-Package: de.offis.utils.configSC.internal;version=1.0.0.SNAPSHOT
> Service-Component: de.offis.utils.configSC.internal.ConfigReaderImpl; \
>    provide:=de.offis.utils.configSC.ConfigReader; \
>    immediate:=false; \
>    servicefactory:=true
>
>
>
>
> #-----------------------------------------------------------------
> # RELEVANT PART OF OUR POM.XML
> #-----------------------------------------------------------------
>  <build>
>    <plugins>
>      <!-- This is use for OSGi extention of the build script. -->
>      <plugin>
>        <groupId>org.ops4j</groupId>
>        <artifactId>maven-pax-plugin</artifactId>
>        <configuration>
>          <provision>
>            <param>--platform=equinox</param>
>            <param>--profiles=minimal</param>
>          </provision>
>        </configuration>
>      </plugin>
>      <plugin>
>        <groupId>org.apache.felix</groupId>
>        <artifactId>maven-bundle-plugin</artifactId>
>    <extensions>true</extensions>
>        <!--
>         | the following instructions build a simple set of
> public/private classes into an OSGi bundle
>        -->
>        <configuration>
>          <manifestLocation>META-INF</manifestLocation>
>          <instructions>
>            
> <Bundle-SymbolicName>${bundle.symbolicName}</Bundle-SymbolicName>
>            <Bundle-Version>${pom.version}</Bundle-Version>
>            <!--
>             | assume public classes are in the top package, and
> private classes are under ".internal"
>            -->
>            
> <Export-Package>!${bundle.namespace}.internal.*,${bundle.namespace}.*;version="${pom.version}"</Export-Package>
>
> <!--            
> <Private-Package>${bundle.namespace}.internal.*</Private-Package>-->
>          </instructions>
>        </configuration>
>      </plugin>
>      <plugin>
>        <artifactId>maven-clean-plugin</artifactId>
>        <configuration>
>          <filesets>
>            <fileset>
>              <directory>META-INF</directory>
>            </fileset>
>            <fileset>
>              <directory>runner</directory>
>            </fileset>
>            <fileset>
>              <directory>.</directory>
>              <includes>
>                <include>**/build.properties</include>
>              </includes>
>              <excludes>
>                <exclude>**/*</exclude>
>              </excludes>
>            </fileset>
>            <fileset>
>              <directory>.settings</directory>
>            </fileset>
>          </filesets>
>        </configuration>
>      </plugin>
>      <!-- Automation for test. -->
>      <plugin>
>        <groupId>org.codehaus.mojo</groupId>
>        <artifactId>findbugs-maven-plugin</artifactId>
>      </plugin>
>      <plugin>
>        <groupId>org.apache.maven.plugins</groupId>
>        <artifactId>maven-javadoc-plugin</artifactId>
>        <configuration>
>          <destDir>${target.javadoc}</destDir>
>        </configuration>
>        <executions>
>          <execution>
>            <phase>package</phase>
>            <goals>
>              <goal>javadoc</goal>
>            </goals>
>          </execution>
>        </executions>
>      </plugin>
>      <!--
>       | Include the compiler plugin. This will be used to setup the
> java source
>       | and target version. Default the source and target version is
> set to 1.3
>       | in this project we will use 1.6.
>       -->
>      <plugin>
>        <groupId>org.apache.maven.plugins</groupId>
>        <artifactId>maven-compiler-plugin</artifactId>
>        <configuration>
>          <source>1.6</source>
>          <target>1.6</target>
>        </configuration>
>      </plugin>
>    </plugins>
>  </build>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Stuart McCulloch]

2009/10/28 Mustafa Caylak <mustafa@...>

> Hi,
>
> Is really no one there who had this problem or knows why it occurs?
> Or is something unclear?
> It would be very kind if someone could help me.
>

I haven't had time this week to investigate - if you're using the latest
bundleplugin (2.0.1) you can use -X to see if the attribute is passed to Bnd

   ie.  mvn clean package -X > LOG

best redirect it to a file (because Maven 2 debug output is verbose) then
search this file for the section starting with "BND Instructions".

If the attribute is being passed to Bnd it should be generating the same
output... if it's not being passed you need to check your configuration.

> Best regards,
> Mustafa Caylak
>
> Mustafa Caylak wrote:
>
>> Hi guys,
>>
>> We have a problem with the Maven-Bundle-Plugin. When we define a
>> Declarative Service Component in the '.bnd'-file, we use a directive named
>> 'servicefactory'. But the directive doesn't have an effect on the generated
>> XML-Document for the DSC.
>> I know that the plugin is based uppon the BND-Tool by Peter Kriens. So I
>> used it to check if it generates the document I want. It does ( <service
>> servicefactory='true'> ).
>>
>> Do you know why the plugin ignores the directive?
>>
>>
>> In the following you see the definition of the DSC and the relevant part
>> of the pom.xml.
>>
>> #-----------------------------------------------------------------
>> # BND FILE
>> #-----------------------------------------------------------------
>> Export-Package: de.offis.utils.configSC;version=1.0.0.SNAPSHOT
>> Private-Package: de.offis.utils.configSC.internal;version=1.0.0.SNAPSHOT
>> Service-Component: de.offis.utils.configSC.internal.ConfigReaderImpl; \
>>   provide:=de.offis.utils.configSC.ConfigReader; \
>>   immediate:=false; \
>>   servicefactory:=true
>>
>>
>>
>>
>> #-----------------------------------------------------------------
>> # RELEVANT PART OF OUR POM.XML
>> #-----------------------------------------------------------------
>>  <build>
>>   <plugins>
>>     <!-- This is use for OSGi extention of the build script. -->
>>     <plugin>
>>       <groupId>org.ops4j</groupId>
>>       <artifactId>maven-pax-plugin</artifactId>
>>       <configuration>
>>         <provision>
>>           <param>--platform=equinox</param>
>>           <param>--profiles=minimal</param>
>>         </provision>
>>       </configuration>
>>     </plugin>
>>     <plugin>
>>       <groupId>org.apache.felix</groupId>
>>       <artifactId>maven-bundle-plugin</artifactId>
>>   <extensions>true</extensions>
>>       <!--
>>        | the following instructions build a simple set of public/private
>> classes into an OSGi bundle
>>       -->
>>       <configuration>
>>         <manifestLocation>META-INF</manifestLocation>
>>         <instructions>
>>
>> <Bundle-SymbolicName>${bundle.symbolicName}</Bundle-SymbolicName>
>>           <Bundle-Version>${pom.version}</Bundle-Version>
>>           <!--
>>            | assume public classes are in the top package, and private
>> classes are under ".internal"
>>           -->
>>
>> <Export-Package>!${bundle.namespace}.internal.*,${bundle.namespace}.*;version="${pom.version}"</Export-Package>
>>
>> <!--
>>  <Private-Package>${bundle.namespace}.internal.*</Private-Package>-->
>>         </instructions>
>>       </configuration>
>>     </plugin>
>>     <plugin>
>>       <artifactId>maven-clean-plugin</artifactId>
>>       <configuration>
>>         <filesets>
>>           <fileset>
>>             <directory>META-INF</directory>
>>           </fileset>
>>           <fileset>
>>             <directory>runner</directory>
>>           </fileset>
>>           <fileset>
>>             <directory>.</directory>
>>             <includes>
>>               <include>**/build.properties</include>
>>             </includes>
>>             <excludes>
>>               <exclude>**/*</exclude>
>>             </excludes>
>>           </fileset>
>>           <fileset>
>>             <directory>.settings</directory>
>>           </fileset>
>>         </filesets>
>>       </configuration>
>>     </plugin>
>>     <!-- Automation for test. -->
>>     <plugin>
>>       <groupId>org.codehaus.mojo</groupId>
>>       <artifactId>findbugs-maven-plugin</artifactId>
>>     </plugin>
>>     <plugin>
>>       <groupId>org.apache.maven.plugins</groupId>
>>       <artifactId>maven-javadoc-plugin</artifactId>
>>       <configuration>
>>         <destDir>${target.javadoc}</destDir>
>>       </configuration>
>>       <executions>
>>         <execution>
>>           <phase>package</phase>
>>           <goals>
>>             <goal>javadoc</goal>
>>           </goals>
>>         </execution>
>>       </executions>
>>     </plugin>
>>     <!--
>>      | Include the compiler plugin. This will be used to setup the java
>> source
>>      | and target version. Default the source and target version is set to
>> 1.3
>>      | in this project we will use 1.6.
>>      -->
>>     <plugin>
>>       <groupId>org.apache.maven.plugins</groupId>
>>       <artifactId>maven-compiler-plugin</artifactId>
>>       <configuration>
>>         <source>1.6</source>
>>         <target>1.6</target>
>>       </configuration>
>>     </plugin>
>>   </plugins>
>>  </build>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
Cheers, Stuart

[Mustafa Caylak]

Hi,

Thanks for your reply.
Ive done what you said. Apparently Maven reads the BND Instructions and
knows what I want:
[DEBUG] Service-Component:
de.offis.utils.configSC.internal.ConfigReaderImpl;
provide:=de.offis.utils.configSC.ConfigReader; servicefactory:=true;
immediate:=false

But the servicefactory-directive doesn't appear in the generated XML-file.


Shall I check something else? I think Maven doesn't like me...




Regards
Mustafa Caylak




Stuart McCulloch wrote:

> 2009/10/28 Mustafa Caylak <mustafa@...>
>
>  
>> Hi,
>>
>> Is really no one there who had this problem or knows why it occurs?
>> Or is something unclear?
>> It would be very kind if someone could help me.
>>
>>    
>
> I haven't had time this week to investigate - if you're using the latest
> bundleplugin (2.0.1) you can use -X to see if the attribute is passed to Bnd
>
>    ie.  mvn clean package -X > LOG
>
> best redirect it to a file (because Maven 2 debug output is verbose) then
> search this file for the section starting with "BND Instructions".
>
> If the attribute is being passed to Bnd it should be generating the same
> output... if it's not being passed you need to check your configuration.
>
>
>  
>> Best regards,
>> Mustafa Caylak
>>
>> Mustafa Caylak wrote:
>>
>>    
>>> Hi guys,
>>>
>>> We have a problem with the Maven-Bundle-Plugin. When we define a
>>> Declarative Service Component in the '.bnd'-file, we use a directive named
>>> 'servicefactory'. But the directive doesn't have an effect on the generated
>>> XML-Document for the DSC.
>>> I know that the plugin is based uppon the BND-Tool by Peter Kriens. So I
>>> used it to check if it generates the document I want. It does ( <service
>>> servicefactory='true'> ).
>>>
>>> Do you know why the plugin ignores the directive?
>>>
>>>
>>> In the following you see the definition of the DSC and the relevant part
>>> of the pom.xml.
>>>
>>> #-----------------------------------------------------------------
>>> # BND FILE
>>> #-----------------------------------------------------------------
>>> Export-Package: de.offis.utils.configSC;version=1.0.0.SNAPSHOT
>>> Private-Package: de.offis.utils.configSC.internal;version=1.0.0.SNAPSHOT
>>> Service-Component: de.offis.utils.configSC.internal.ConfigReaderImpl; \
>>>   provide:=de.offis.utils.configSC.ConfigReader; \
>>>   immediate:=false; \
>>>   servicefactory:=true
>>>
>>>
>>>
>>>
>>> #-----------------------------------------------------------------
>>> # RELEVANT PART OF OUR POM.XML
>>> #-----------------------------------------------------------------
>>>  <build>
>>>   <plugins>
>>>     <!-- This is use for OSGi extention of the build script. -->
>>>     <plugin>
>>>       <groupId>org.ops4j</groupId>
>>>       <artifactId>maven-pax-plugin</artifactId>
>>>       <configuration>
>>>         <provision>
>>>           <param>--platform=equinox</param>
>>>           <param>--profiles=minimal</param>
>>>         </provision>
>>>       </configuration>
>>>     </plugin>
>>>     <plugin>
>>>       <groupId>org.apache.felix</groupId>
>>>       <artifactId>maven-bundle-plugin</artifactId>
>>>   <extensions>true</extensions>
>>>       <!--
>>>        | the following instructions build a simple set of public/private
>>> classes into an OSGi bundle
>>>       -->
>>>       <configuration>
>>>         <manifestLocation>META-INF</manifestLocation>
>>>         <instructions>
>>>
>>> <Bundle-SymbolicName>${bundle.symbolicName}</Bundle-SymbolicName>
>>>           <Bundle-Version>${pom.version}</Bundle-Version>
>>>           <!--
>>>            | assume public classes are in the top package, and private
>>> classes are under ".internal"
>>>           -->
>>>
>>> <Export-Package>!${bundle.namespace}.internal.*,${bundle.namespace}.*;version="${pom.version}"</Export-Package>
>>>
>>> <!--
>>>  <Private-Package>${bundle.namespace}.internal.*</Private-Package>-->
>>>         </instructions>
>>>       </configuration>
>>>     </plugin>
>>>     <plugin>
>>>       <artifactId>maven-clean-plugin</artifactId>
>>>       <configuration>
>>>         <filesets>
>>>           <fileset>
>>>             <directory>META-INF</directory>
>>>           </fileset>
>>>           <fileset>
>>>             <directory>runner</directory>
>>>           </fileset>
>>>           <fileset>
>>>             <directory>.</directory>
>>>             <includes>
>>>               <include>**/build.properties</include>
>>>             </includes>
>>>             <excludes>
>>>               <exclude>**/*</exclude>
>>>             </excludes>
>>>           </fileset>
>>>           <fileset>
>>>             <directory>.settings</directory>
>>>           </fileset>
>>>         </filesets>
>>>       </configuration>
>>>     </plugin>
>>>     <!-- Automation for test. -->
>>>     <plugin>
>>>       <groupId>org.codehaus.mojo</groupId>
>>>       <artifactId>findbugs-maven-plugin</artifactId>
>>>     </plugin>
>>>     <plugin>
>>>       <groupId>org.apache.maven.plugins</groupId>
>>>       <artifactId>maven-javadoc-plugin</artifactId>
>>>       <configuration>
>>>         <destDir>${target.javadoc}</destDir>
>>>       </configuration>
>>>       <executions>
>>>         <execution>
>>>           <phase>package</phase>
>>>           <goals>
>>>             <goal>javadoc</goal>
>>>           </goals>
>>>         </execution>
>>>       </executions>
>>>     </plugin>
>>>     <!--
>>>      | Include the compiler plugin. This will be used to setup the java
>>> source
>>>      | and target version. Default the source and target version is set to
>>> 1.3
>>>      | in this project we will use 1.6.
>>>      -->
>>>     <plugin>
>>>       <groupId>org.apache.maven.plugins</groupId>
>>>       <artifactId>maven-compiler-plugin</artifactId>
>>>       <configuration>
>>>         <source>1.6</source>
>>>         <target>1.6</target>
>>>       </configuration>
>>>     </plugin>
>>>   </plugins>
>>>  </build>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>>
>>>
>>>      
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>>    
>
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Mustafa Caylak]

Hi,

I forgot to tell you the version I have:
org.ops4j:maven-pax-plugin:1.4
and org.apache.felix:maven-bundle-plugin:2.0.1

The maven-bundle-plugin uses BND Tool 0.0.357




Regards
Mustafa Caylak





Stuart McCulloch wrote:

> 2009/10/28 Mustafa Caylak <mustafa@...>
>
>> Hi,
>>
>> Is really no one there who had this problem or knows why it occurs?
>> Or is something unclear?
>> It would be very kind if someone could help me.
>>
>
> I haven't had time this week to investigate - if you're using the latest
> bundleplugin (2.0.1) you can use -X to see if the attribute is passed to Bnd
>
>    ie.  mvn clean package -X > LOG
>
> best redirect it to a file (because Maven 2 debug output is verbose) then
> search this file for the section starting with "BND Instructions".
>
> If the attribute is being passed to Bnd it should be generating the same
> output... if it's not being passed you need to check your configuration.
>
>
>> Best regards,
>> Mustafa Caylak
>>
>> Mustafa Caylak wrote:
>>
>>> Hi guys,
>>>
>>> We have a problem with the Maven-Bundle-Plugin. When we define a
>>> Declarative Service Component in the '.bnd'-file, we use a directive named
>>> 'servicefactory'. But the directive doesn't have an effect on the generated
>>> XML-Document for the DSC.
>>> I know that the plugin is based uppon the BND-Tool by Peter Kriens. So I
>>> used it to check if it generates the document I want. It does ( <service
>>> servicefactory='true'> ).
>>>
>>> Do you know why the plugin ignores the directive?
>>>
>>>
>>> In the following you see the definition of the DSC and the relevant part
>>> of the pom.xml.
>>>
>>> #-----------------------------------------------------------------
>>> # BND FILE
>>> #-----------------------------------------------------------------
>>> Export-Package: de.offis.utils.configSC;version=1.0.0.SNAPSHOT
>>> Private-Package: de.offis.utils.configSC.internal;version=1.0.0.SNAPSHOT
>>> Service-Component: de.offis.utils.configSC.internal.ConfigReaderImpl; \
>>>   provide:=de.offis.utils.configSC.ConfigReader; \
>>>   immediate:=false; \
>>>   servicefactory:=true
>>>
>>>
>>>
>>>
>>> #-----------------------------------------------------------------
>>> # RELEVANT PART OF OUR POM.XML
>>> #-----------------------------------------------------------------
>>>  <build>
>>>   <plugins>
>>>     <!-- This is use for OSGi extention of the build script. -->
>>>     <plugin>
>>>       <groupId>org.ops4j</groupId>
>>>       <artifactId>maven-pax-plugin</artifactId>
>>>       <configuration>
>>>         <provision>
>>>           <param>--platform=equinox</param>
>>>           <param>--profiles=minimal</param>
>>>         </provision>
>>>       </configuration>
>>>     </plugin>
>>>     <plugin>
>>>       <groupId>org.apache.felix</groupId>
>>>       <artifactId>maven-bundle-plugin</artifactId>
>>>   <extensions>true</extensions>
>>>       <!--
>>>        | the following instructions build a simple set of public/private
>>> classes into an OSGi bundle
>>>       -->
>>>       <configuration>
>>>         <manifestLocation>META-INF</manifestLocation>
>>>         <instructions>
>>>
>>> <Bundle-SymbolicName>${bundle.symbolicName}</Bundle-SymbolicName>
>>>           <Bundle-Version>${pom.version}</Bundle-Version>
>>>           <!--
>>>            | assume public classes are in the top package, and private
>>> classes are under ".internal"
>>>           -->
>>>
>>> <Export-Package>!${bundle.namespace}.internal.*,${bundle.namespace}.*;version="${pom.version}"</Export-Package>
>>>
>>> <!--
>>>  <Private-Package>${bundle.namespace}.internal.*</Private-Package>-->
>>>         </instructions>
>>>       </configuration>
>>>     </plugin>
>>>     <plugin>
>>>       <artifactId>maven-clean-plugin</artifactId>
>>>       <configuration>
>>>         <filesets>
>>>           <fileset>
>>>             <directory>META-INF</directory>
>>>           </fileset>
>>>           <fileset>
>>>             <directory>runner</directory>
>>>           </fileset>
>>>           <fileset>
>>>             <directory>.</directory>
>>>             <includes>
>>>               <include>**/build.properties</include>
>>>             </includes>
>>>             <excludes>
>>>               <exclude>**/*</exclude>
>>>             </excludes>
>>>           </fileset>
>>>           <fileset>
>>>             <directory>.settings</directory>
>>>           </fileset>
>>>         </filesets>
>>>       </configuration>
>>>     </plugin>
>>>     <!-- Automation for test. -->
>>>     <plugin>
>>>       <groupId>org.codehaus.mojo</groupId>
>>>       <artifactId>findbugs-maven-plugin</artifactId>
>>>     </plugin>
>>>     <plugin>
>>>       <groupId>org.apache.maven.plugins</groupId>
>>>       <artifactId>maven-javadoc-plugin</artifactId>
>>>       <configuration>
>>>         <destDir>${target.javadoc}</destDir>
>>>       </configuration>
>>>       <executions>
>>>         <execution>
>>>           <phase>package</phase>
>>>           <goals>
>>>             <goal>javadoc</goal>
>>>           </goals>
>>>         </execution>
>>>       </executions>
>>>     </plugin>
>>>     <!--
>>>      | Include the compiler plugin. This will be used to setup the java
>>> source
>>>      | and target version. Default the source and target version is set to
>>> 1.3
>>>      | in this project we will use 1.6.
>>>      -->
>>>     <plugin>
>>>       <groupId>org.apache.maven.plugins</groupId>
>>>       <artifactId>maven-compiler-plugin</artifactId>
>>>       <configuration>
>>>         <source>1.6</source>
>>>         <target>1.6</target>
>>>       </configuration>
>>>     </plugin>
>>>   </plugins>
>>>  </build>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Mustafa Caylak]

Hi,

It's me again. I don't know what to do anymore. Apparently there is no
one with the same problem, so can anyone tell me how I find out what the
problem  is?




Regards
Mustafa Caylak




Mustafa Caylak wrote:

> Hi,
>
> I forgot to tell you which version I have:
> org.ops4j:maven-pax-plugin:1.4
> and org.apache.felix:maven-bundle-plugin:2.0.1
>
> The maven-bundle-plugin uses BND Tool 0.0.357
>
>
>
>
> Regards
> Mustafa Caylak
>
>
>
>
>
> Stuart McCulloch wrote:
>> 2009/10/28 Mustafa Caylak <mustafa@...>
>>
>>> Hi,
>>>
>>> Is really no one there who had this problem or knows why it occurs?
>>> Or is something unclear?
>>> It would be very kind if someone could help me.
>>>
>>
>> I haven't had time this week to investigate - if you're using the latest
>> bundleplugin (2.0.1) you can use -X to see if the attribute is passed
>> to Bnd
>>
>>    ie.  mvn clean package -X > LOG
>>
>> best redirect it to a file (because Maven 2 debug output is verbose)
>> then
>> search this file for the section starting with "BND Instructions".
>>
>> If the attribute is being passed to Bnd it should be generating the same
>> output... if it's not being passed you need to check your configuration.
>>
>>
>>> Best regards,
>>> Mustafa Caylak
>>>
>>> Mustafa Caylak wrote:
>>>
>>>> Hi guys,
>>>>
>>>> We have a problem with the Maven-Bundle-Plugin. When we define a
>>>> Declarative Service Component in the '.bnd'-file, we use a
>>>> directive named
>>>> 'servicefactory'. But the directive doesn't have an effect on the
>>>> generated
>>>> XML-Document for the DSC.
>>>> I know that the plugin is based uppon the BND-Tool by Peter Kriens.
>>>> So I
>>>> used it to check if it generates the document I want. It does (
>>>> <service
>>>> servicefactory='true'> ).
>>>>
>>>> Do you know why the plugin ignores the directive?
>>>>
>>>>
>>>> In the following you see the definition of the DSC and the relevant
>>>> part
>>>> of the pom.xml.
>>>>
>>>> #-----------------------------------------------------------------
>>>> # BND FILE
>>>> #-----------------------------------------------------------------
>>>> Export-Package: de.offis.utils.configSC;version=1.0.0.SNAPSHOT
>>>> Private-Package:
>>>> de.offis.utils.configSC.internal;version=1.0.0.SNAPSHOT
>>>> Service-Component:
>>>> de.offis.utils.configSC.internal.ConfigReaderImpl; \
>>>>   provide:=de.offis.utils.configSC.ConfigReader; \
>>>>   immediate:=false; \
>>>>   servicefactory:=true
>>>>
>>>>
>>>>
>>>>
>>>> #-----------------------------------------------------------------
>>>> # RELEVANT PART OF OUR POM.XML
>>>> #-----------------------------------------------------------------
>>>>  <build>
>>>>   <plugins>
>>>>     <!-- This is use for OSGi extention of the build script. -->
>>>>     <plugin>
>>>>       <groupId>org.ops4j</groupId>
>>>>       <artifactId>maven-pax-plugin</artifactId>
>>>>       <configuration>
>>>>         <provision>
>>>>           <param>--platform=equinox</param>
>>>>           <param>--profiles=minimal</param>
>>>>         </provision>
>>>>       </configuration>
>>>>     </plugin>
>>>>     <plugin>
>>>>       <groupId>org.apache.felix</groupId>
>>>>       <artifactId>maven-bundle-plugin</artifactId>
>>>>   <extensions>true</extensions>
>>>>       <!--
>>>>        | the following instructions build a simple set of
>>>> public/private
>>>> classes into an OSGi bundle
>>>>       -->
>>>>       <configuration>
>>>>         <manifestLocation>META-INF</manifestLocation>
>>>>         <instructions>
>>>>
>>>> <Bundle-SymbolicName>${bundle.symbolicName}</Bundle-SymbolicName>
>>>>           <Bundle-Version>${pom.version}</Bundle-Version>
>>>>           <!--
>>>>            | assume public classes are in the top package, and private
>>>> classes are under ".internal"
>>>>           -->
>>>>
>>>> <Export-Package>!${bundle.namespace}.internal.*,${bundle.namespace}.*;version="${pom.version}"</Export-Package>
>>>>
>>>>
>>>> <!--
>>>>  <Private-Package>${bundle.namespace}.internal.*</Private-Package>-->
>>>>         </instructions>
>>>>       </configuration>
>>>>     </plugin>
>>>>     <plugin>
>>>>       <artifactId>maven-clean-plugin</artifactId>
>>>>       <configuration>
>>>>         <filesets>
>>>>           <fileset>
>>>>             <directory>META-INF</directory>
>>>>           </fileset>
>>>>           <fileset>
>>>>             <directory>runner</directory>
>>>>           </fileset>
>>>>           <fileset>
>>>>             <directory>.</directory>
>>>>             <includes>
>>>>               <include>**/build.properties</include>
>>>>             </includes>
>>>>             <excludes>
>>>>               <exclude>**/*</exclude>
>>>>             </excludes>
>>>>           </fileset>
>>>>           <fileset>
>>>>             <directory>.settings</directory>
>>>>           </fileset>
>>>>         </filesets>
>>>>       </configuration>
>>>>     </plugin>
>>>>     <!-- Automation for test. -->
>>>>     <plugin>
>>>>       <groupId>org.codehaus.mojo</groupId>
>>>>       <artifactId>findbugs-maven-plugin</artifactId>
>>>>     </plugin>
>>>>     <plugin>
>>>>       <groupId>org.apache.maven.plugins</groupId>
>>>>       <artifactId>maven-javadoc-plugin</artifactId>
>>>>       <configuration>
>>>>         <destDir>${target.javadoc}</destDir>
>>>>       </configuration>
>>>>       <executions>
>>>>         <execution>
>>>>           <phase>package</phase>
>>>>           <goals>
>>>>             <goal>javadoc</goal>
>>>>           </goals>
>>>>         </execution>
>>>>       </executions>
>>>>     </plugin>
>>>>     <!--
>>>>      | Include the compiler plugin. This will be used to setup the
>>>> java
>>>> source
>>>>      | and target version. Default the source and target version is
>>>> set to
>>>> 1.3
>>>>      | in this project we will use 1.6.
>>>>      -->
>>>>     <plugin>
>>>>       <groupId>org.apache.maven.plugins</groupId>
>>>>       <artifactId>maven-compiler-plugin</artifactId>
>>>>       <configuration>
>>>>         <source>1.6</source>
>>>>         <target>1.6</target>
>>>>       </configuration>
>>>>     </plugin>
>>>>   </plugins>
>>>>  </build>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Guido Spadotto]

Why don't you just use the maven-scr-plugin and its annotations?
I've found it very handy to generate the component descriptor.

This is a snippet of a pom of mine (notice there's no bnd file "tampering"):

<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <properties>
       
<component.descriptor.name>Locator.xml</component.descriptor.name>      
    </properties>

    <!-- List dependencies here -->
    <dependencies>
        ...
        <dependency>
            <groupId>org.apache.felix</groupId>
            <artifactId>org.apache.felix.scr.annotations</artifactId>
            <version>0.9.0</version>
        </dependency>
        ...
    </dependencies>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.felix</groupId>
                <artifactId>maven-bundle-plugin</artifactId>
                <extensions>true</extensions>
                <configuration>
                    <instructions>
                        <Bundle-Name>${project.name}</Bundle-Name>
                        <Export-Package>org.something.api</Export-Package>
                       
<Service-Component>OSGI-INF/${component.descriptor.name}</Service-Component>    
                 
                    </instructions>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.felix</groupId>
                <artifactId>maven-scr-plugin</artifactId>
                <version>1.0.8</version>
                <configuration>
                    <finalName>${component.descriptor.name}</finalName>
                </configuration>
                <executions>
                    <execution>
                        <id>generate-scr-scrdescriptor</id>
                        <goals>
                            <goal>scr</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

</project>


Cheers,
 Guido

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Stuart McCulloch]

2009/11/10 Mustafa Caylak <mustafa@...>

> Hi,
>
> It's me again. I don't know what to do anymore. Apparently there is no one
> with the same problem, so can anyone tell me how I find out what the problem
>  is?
>

personally I still have next-to-zero time to do any investigation, however
the code is available if anyone happens to want to step in and help out

just want to point out that according to the debug output the instruction
is reaching bnd, and at that point the bundleplugin hands off generation
of the actual bundle to bnd

so I'm confused why this appears to work outside in bnd, unless you're
using a later version of bnd than is used in the bundleplugin, because if
bnd receives the instruction then it should be processing it

if you can put together a standalone build (ie. that someone can build
locally) that recreates this, feel free to open a JIRA issue and attach a
zip of the build - that will save some time for whoever picks it up:

  http://issues.apache.org/jira/browse/FELIX

another option is to use the scrplugin, as someone else mentioned...

Regards

>
> Mustafa Caylak
>
> Mustafa Caylak wrote:
>
>> Hi,
>>
>> I forgot to tell you which version I have:
>>
>> org.ops4j:maven-pax-plugin:1.4
>> and org.apache.felix:maven-bundle-plugin:2.0.1
>>
>> The maven-bundle-plugin uses BND Tool 0.0.357
>>
>>
>>
>>
>> Regards
>> Mustafa Caylak
>>
>>
>>
>>
>>
>> Stuart McCulloch wrote:
>>
>>> 2009/10/28 Mustafa Caylak <mustafa@...>
>>>
>>>  Hi,
>>>>
>>>> Is really no one there who had this problem or knows why it occurs?
>>>> Or is something unclear?
>>>> It would be very kind if someone could help me.
>>>>
>>>>
>>> I haven't had time this week to investigate - if you're using the latest
>>> bundleplugin (2.0.1) you can use -X to see if the attribute is passed to
>>> Bnd
>>>
>>>   ie.  mvn clean package -X > LOG
>>>
>>> best redirect it to a file (because Maven 2 debug output is verbose) then
>>> search this file for the section starting with "BND Instructions".
>>>
>>> If the attribute is being passed to Bnd it should be generating the same
>>> output... if it's not being passed you need to check your configuration.
>>>
>>>
>>>  Best regards,
>>>> Mustafa Caylak
>>>>
>>>> Mustafa Caylak wrote:
>>>>
>>>>  Hi guys,
>>>>>
>>>>> We have a problem with the Maven-Bundle-Plugin. When we define a
>>>>> Declarative Service Component in the '.bnd'-file, we use a directive
>>>>> named
>>>>> 'servicefactory'. But the directive doesn't have an effect on the
>>>>> generated
>>>>> XML-Document for the DSC.
>>>>> I know that the plugin is based uppon the BND-Tool by Peter Kriens. So
>>>>> I
>>>>> used it to check if it generates the document I want. It does (
>>>>> <service
>>>>> servicefactory='true'> ).
>>>>>
>>>>> Do you know why the plugin ignores the directive?
>>>>>
>>>>>
>>>>> In the following you see the definition of the DSC and the relevant
>>>>> part
>>>>> of the pom.xml.
>>>>>
>>>>> #-----------------------------------------------------------------
>>>>> # BND FILE
>>>>> #-----------------------------------------------------------------
>>>>> Export-Package: de.offis.utils.configSC;version=1.0.0.SNAPSHOT
>>>>> Private-Package:
>>>>> de.offis.utils.configSC.internal;version=1.0.0.SNAPSHOT
>>>>> Service-Component: de.offis.utils.configSC.internal.ConfigReaderImpl; \
>>>>>  provide:=de.offis.utils.configSC.ConfigReader; \
>>>>>  immediate:=false; \
>>>>>  servicefactory:=true
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> #-----------------------------------------------------------------
>>>>> # RELEVANT PART OF OUR POM.XML
>>>>> #-----------------------------------------------------------------
>>>>>  <build>
>>>>>  <plugins>
>>>>>    <!-- This is use for OSGi extention of the build script. -->
>>>>>    <plugin>
>>>>>      <groupId>org.ops4j</groupId>
>>>>>      <artifactId>maven-pax-plugin</artifactId>
>>>>>      <configuration>
>>>>>        <provision>
>>>>>          <param>--platform=equinox</param>
>>>>>          <param>--profiles=minimal</param>
>>>>>        </provision>
>>>>>      </configuration>
>>>>>    </plugin>
>>>>>    <plugin>
>>>>>      <groupId>org.apache.felix</groupId>
>>>>>      <artifactId>maven-bundle-plugin</artifactId>
>>>>>  <extensions>true</extensions>
>>>>>      <!--
>>>>>       | the following instructions build a simple set of public/private
>>>>> classes into an OSGi bundle
>>>>>      -->
>>>>>      <configuration>
>>>>>        <manifestLocation>META-INF</manifestLocation>
>>>>>        <instructions>
>>>>>
>>>>> <Bundle-SymbolicName>${bundle.symbolicName}</Bundle-SymbolicName>
>>>>>          <Bundle-Version>${pom.version}</Bundle-Version>
>>>>>          <!--
>>>>>           | assume public classes are in the top package, and private
>>>>> classes are under ".internal"
>>>>>          -->
>>>>>
>>>>> <Export-Package>!${bundle.namespace}.internal.*,${bundle.namespace}.*;version="${pom.version}"</Export-Package>
>>>>>
>>>>>
>>>>> <!--
>>>>>  <Private-Package>${bundle.namespace}.internal.*</Private-Package>-->
>>>>>        </instructions>
>>>>>      </configuration>
>>>>>    </plugin>
>>>>>    <plugin>
>>>>>      <artifactId>maven-clean-plugin</artifactId>
>>>>>      <configuration>
>>>>>        <filesets>
>>>>>          <fileset>
>>>>>            <directory>META-INF</directory>
>>>>>          </fileset>
>>>>>          <fileset>
>>>>>            <directory>runner</directory>
>>>>>          </fileset>
>>>>>          <fileset>
>>>>>            <directory>.</directory>
>>>>>            <includes>
>>>>>              <include>**/build.properties</include>
>>>>>            </includes>
>>>>>            <excludes>
>>>>>              <exclude>**/*</exclude>
>>>>>            </excludes>
>>>>>          </fileset>
>>>>>          <fileset>
>>>>>            <directory>.settings</directory>
>>>>>          </fileset>
>>>>>        </filesets>
>>>>>      </configuration>
>>>>>    </plugin>
>>>>>    <!-- Automation for test. -->
>>>>>    <plugin>
>>>>>      <groupId>org.codehaus.mojo</groupId>
>>>>>      <artifactId>findbugs-maven-plugin</artifactId>
>>>>>    </plugin>
>>>>>    <plugin>
>>>>>      <groupId>org.apache.maven.plugins</groupId>
>>>>>      <artifactId>maven-javadoc-plugin</artifactId>
>>>>>      <configuration>
>>>>>        <destDir>${target.javadoc}</destDir>
>>>>>      </configuration>
>>>>>      <executions>
>>>>>        <execution>
>>>>>          <phase>package</phase>
>>>>>          <goals>
>>>>>            <goal>javadoc</goal>
>>>>>          </goals>
>>>>>        </execution>
>>>>>      </executions>
>>>>>    </plugin>
>>>>>    <!--
>>>>>     | Include the compiler plugin. This will be used to setup the java
>>>>> source
>>>>>     | and target version. Default the source and target version is set
>>>>> to
>>>>> 1.3
>>>>>     | in this project we will use 1.6.
>>>>>     -->
>>>>>    <plugin>
>>>>>      <groupId>org.apache.maven.plugins</groupId>
>>>>>      <artifactId>maven-compiler-plugin</artifactId>
>>>>>      <configuration>
>>>>>        <source>1.6</source>
>>>>>        <target>1.6</target>
>>>>>      </configuration>
>>>>>    </plugin>
>>>>>  </plugins>
>>>>>  </build>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>  ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>>
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
Cheers, Stuart

[Mustafa Caylak]

Thanks for your answers.

I will inform me about the src-plugin and try it out.
If nothing happens I will see if i can upload the project.


See you
Mustafa




Stuart McCulloch wrote:

> 2009/11/10 Mustafa Caylak <mustafa@...>
>
>  
>> Hi,
>>
>> It's me again. I don't know what to do anymore. Apparently there is no one
>> with the same problem, so can anyone tell me how I find out what the problem
>>  is?
>>
>>    
>
> personally I still have next-to-zero time to do any investigation, however
> the code is available if anyone happens to want to step in and help out
>
> just want to point out that according to the debug output the instruction
> is reaching bnd, and at that point the bundleplugin hands off generation
> of the actual bundle to bnd
>
> so I'm confused why this appears to work outside in bnd, unless you're
> using a later version of bnd than is used in the bundleplugin, because if
> bnd receives the instruction then it should be processing it
>
> if you can put together a standalone build (ie. that someone can build
> locally) that recreates this, feel free to open a JIRA issue and attach a
> zip of the build - that will save some time for whoever picks it up:
>
>   http://issues.apache.org/jira/browse/FELIX
>
> another option is to use the scrplugin, as someone else mentioned...
>
> Regards
>  
>> Mustafa Caylak
>>
>> Mustafa Caylak wrote:
>>
>>    
>>> Hi,
>>>
>>> I forgot to tell you which version I have:
>>>
>>> org.ops4j:maven-pax-plugin:1.4
>>> and org.apache.felix:maven-bundle-plugin:2.0.1
>>>
>>> The maven-bundle-plugin uses BND Tool 0.0.357
>>>
>>>
>>>
>>>
>>> Regards
>>> Mustafa Caylak
>>>
>>>
>>>
>>>
>>>
>>> Stuart McCulloch wrote:
>>>
>>>      
>>>> 2009/10/28 Mustafa Caylak <mustafa@...>
>>>>
>>>>  Hi,
>>>>        
>>>>> Is really no one there who had this problem or knows why it occurs?
>>>>> Or is something unclear?
>>>>> It would be very kind if someone could help me.
>>>>>
>>>>>
>>>>>          
>>>> I haven't had time this week to investigate - if you're using the latest
>>>> bundleplugin (2.0.1) you can use -X to see if the attribute is passed to
>>>> Bnd
>>>>
>>>>   ie.  mvn clean package -X > LOG
>>>>
>>>> best redirect it to a file (because Maven 2 debug output is verbose) then
>>>> search this file for the section starting with "BND Instructions".
>>>>
>>>> If the attribute is being passed to Bnd it should be generating the same
>>>> output... if it's not being passed you need to check your configuration.
>>>>
>>>>
>>>>  Best regards,
>>>>        
>>>>> Mustafa Caylak
>>>>>
>>>>> Mustafa Caylak wrote:
>>>>>
>>>>>  Hi guys,
>>>>>          
>>>>>> We have a problem with the Maven-Bundle-Plugin. When we define a
>>>>>> Declarative Service Component in the '.bnd'-file, we use a directive
>>>>>> named
>>>>>> 'servicefactory'. But the directive doesn't have an effect on the
>>>>>> generated
>>>>>> XML-Document for the DSC.
>>>>>> I know that the plugin is based uppon the BND-Tool by Peter Kriens. So
>>>>>> I
>>>>>> used it to check if it generates the document I want. It does (
>>>>>> <service
>>>>>> servicefactory='true'> ).
>>>>>>
>>>>>> Do you know why the plugin ignores the directive?
>>>>>>
>>>>>>
>>>>>> In the following you see the definition of the DSC and the relevant
>>>>>> part
>>>>>> of the pom.xml.
>>>>>>
>>>>>> #-----------------------------------------------------------------
>>>>>> # BND FILE
>>>>>> #-----------------------------------------------------------------
>>>>>> Export-Package: de.offis.utils.configSC;version=1.0.0.SNAPSHOT
>>>>>> Private-Package:
>>>>>> de.offis.utils.configSC.internal;version=1.0.0.SNAPSHOT
>>>>>> Service-Component: de.offis.utils.configSC.internal.ConfigReaderImpl; \
>>>>>>  provide:=de.offis.utils.configSC.ConfigReader; \
>>>>>>  immediate:=false; \
>>>>>>  servicefactory:=true
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> #-----------------------------------------------------------------
>>>>>> # RELEVANT PART OF OUR POM.XML
>>>>>> #-----------------------------------------------------------------
>>>>>>  <build>
>>>>>>  <plugins>
>>>>>>    <!-- This is use for OSGi extention of the build script. -->
>>>>>>    <plugin>
>>>>>>      <groupId>org.ops4j</groupId>
>>>>>>      <artifactId>maven-pax-plugin</artifactId>
>>>>>>      <configuration>
>>>>>>        <provision>
>>>>>>          <param>--platform=equinox</param>
>>>>>>          <param>--profiles=minimal</param>
>>>>>>        </provision>
>>>>>>      </configuration>
>>>>>>    </plugin>
>>>>>>    <plugin>
>>>>>>      <groupId>org.apache.felix</groupId>
>>>>>>      <artifactId>maven-bundle-plugin</artifactId>
>>>>>>  <extensions>true</extensions>
>>>>>>      <!--
>>>>>>       | the following instructions build a simple set of public/private
>>>>>> classes into an OSGi bundle
>>>>>>      -->
>>>>>>      <configuration>
>>>>>>        <manifestLocation>META-INF</manifestLocation>
>>>>>>        <instructions>
>>>>>>
>>>>>> <Bundle-SymbolicName>${bundle.symbolicName}</Bundle-SymbolicName>
>>>>>>          <Bundle-Version>${pom.version}</Bundle-Version>
>>>>>>          <!--
>>>>>>           | assume public classes are in the top package, and private
>>>>>> classes are under ".internal"
>>>>>>          -->
>>>>>>
>>>>>> <Export-Package>!${bundle.namespace}.internal.*,${bundle.namespace}.*;version="${pom.version}"</Export-Package>
>>>>>>
>>>>>>
>>>>>> <!--
>>>>>>  <Private-Package>${bundle.namespace}.internal.*</Private-Package>-->
>>>>>>        </instructions>
>>>>>>      </configuration>
>>>>>>    </plugin>
>>>>>>    <plugin>
>>>>>>      <artifactId>maven-clean-plugin</artifactId>
>>>>>>      <configuration>
>>>>>>        <filesets>
>>>>>>          <fileset>
>>>>>>            <directory>META-INF</directory>
>>>>>>          </fileset>
>>>>>>          <fileset>
>>>>>>            <directory>runner</directory>
>>>>>>          </fileset>
>>>>>>          <fileset>
>>>>>>            <directory>.</directory>
>>>>>>            <includes>
>>>>>>              <include>**/build.properties</include>
>>>>>>            </includes>
>>>>>>            <excludes>
>>>>>>              <exclude>**/*</exclude>
>>>>>>            </excludes>
>>>>>>          </fileset>
>>>>>>          <fileset>
>>>>>>            <directory>.settings</directory>
>>>>>>          </fileset>
>>>>>>        </filesets>
>>>>>>      </configuration>
>>>>>>    </plugin>
>>>>>>    <!-- Automation for test. -->
>>>>>>    <plugin>
>>>>>>      <groupId>org.codehaus.mojo</groupId>
>>>>>>      <artifactId>findbugs-maven-plugin</artifactId>
>>>>>>    </plugin>
>>>>>>    <plugin>
>>>>>>      <groupId>org.apache.maven.plugins</groupId>
>>>>>>      <artifactId>maven-javadoc-plugin</artifactId>
>>>>>>      <configuration>
>>>>>>        <destDir>${target.javadoc}</destDir>
>>>>>>      </configuration>
>>>>>>      <executions>
>>>>>>        <execution>
>>>>>>          <phase>package</phase>
>>>>>>          <goals>
>>>>>>            <goal>javadoc</goal>
>>>>>>          </goals>
>>>>>>        </execution>
>>>>>>      </executions>
>>>>>>    </plugin>
>>>>>>    <!--
>>>>>>     | Include the compiler plugin. This will be used to setup the java
>>>>>> source
>>>>>>     | and target version. Default the source and target version is set
>>>>>> to
>>>>>> 1.3
>>>>>>     | in this project we will use 1.6.
>>>>>>     -->
>>>>>>    <plugin>
>>>>>>      <groupId>org.apache.maven.plugins</groupId>
>>>>>>      <artifactId>maven-compiler-plugin</artifactId>
>>>>>>      <configuration>
>>>>>>        <source>1.6</source>
>>>>>>        <target>1.6</target>
>>>>>>      </configuration>
>>>>>>    </plugin>
>>>>>>  </plugins>
>>>>>>  </build>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>> For additional commands, e-mail: users-help@...
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>  ---------------------------------------------------------------------
>>>>>>            
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>        
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>>
>>>
>>>      
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>>    
>
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Mustafa Caylak]

Hello Guido,

I've used your suggestion, but the only output I got is:
[ERROR] Error building bundle
de.offis.utils.configSC:configSC:bundle:1.0-SNAPSHOT : Service-Component
entry can not be located in JAR: OSGI-INF/Locator.xml

Of course I renamed my xml-file to Locator.xml.
What do your Locator.xml look like?




Guido Spadotto wrote:

> Why don't you just use the maven-scr-plugin and its annotations?
> I've found it very handy to generate the component descriptor.
>
> This is a snippet of a pom of mine (notice there's no bnd file
> "tampering"):
>
> <project xmlns="http://maven.apache.org/POM/4.0.0"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/maven-v4_0_0.xsd">
>    <modelVersion>4.0.0</modelVersion>
>    <properties>
>        
> <component.descriptor.name>Locator.xml</component.descriptor.name>      
>    </properties>
>
>    <!-- List dependencies here -->
>    <dependencies>
>        ...
>        <dependency>
>            <groupId>org.apache.felix</groupId>
>            <artifactId>org.apache.felix.scr.annotations</artifactId>
>            <version>0.9.0</version>
>        </dependency>
>        ...
>    </dependencies>
>    <build>
>        <plugins>
>            <plugin>
>                <groupId>org.apache.felix</groupId>
>                <artifactId>maven-bundle-plugin</artifactId>
>                <extensions>true</extensions>
>                <configuration>
>                    <instructions>
>                        <Bundle-Name>${project.name}</Bundle-Name>
>                        <Export-Package>org.something.api</Export-Package>
>                        
> <Service-Component>OSGI-INF/${component.descriptor.name}</Service-Component>    
>                                     </instructions>
>                </configuration>
>            </plugin>
>            <plugin>
>                <groupId>org.apache.felix</groupId>
>                <artifactId>maven-scr-plugin</artifactId>
>                <version>1.0.8</version>
>                <configuration>
>                    <finalName>${component.descriptor.name}</finalName>
>                </configuration>
>                <executions>
>                    <execution>
>                        <id>generate-scr-scrdescriptor</id>
>                        <goals>
>                            <goal>scr</goal>
>                        </goals>
>                    </execution>
>                </executions>
>            </plugin>
>        </plugins>
>    </build>
>
> </project>
>
>
> Cheers,
> Guido
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Guido Spadotto]

Mustafa Caylak wrote:

> Hello Guido,
>
> I've used your suggestion, but the only output I got is:
> [ERROR] Error building bundle
> de.offis.utils.configSC:configSC:bundle:1.0-SNAPSHOT :
> Service-Component entry can not be located in JAR: OSGI-INF/Locator.xml
>
> Of course I renamed my xml-file to Locator.xml.
> What do your Locator.xml look like?
>

Hi Mustafa,
 first, you can name the *automatically* generated component descriptor
as you like.

I've named it Locator.xml because that made sense for the component I
developed,
but you can set the value of the *component.descriptor.name *property to
anything
you like.

That said, could you take a look inside the
\target\scr-plugin-generated\OSGI-INF
directory of your project? It should contain the generated component
descriptor file,
whose name will be the value of the *component.descriptor.name
*property, if specified.

If it's there, then the scr plugin worked, and that's all it's supposed
to do (according to [1]).

In order for the maven-bundle-plugin to insert that descriptor file in
the bundle,
you will have to add this directive within its configuration instructions:
<Service-Component>OSGI-INF/${component.descriptor.name}</Service-Component>


Sorry to ask this, but have you added the relevant annotations inside
the component implementation?

It might also be that you've experienced [2], but I can't say for sure
with the amount
of information you provided so far.

Cheers,
 Guido

[1]: http://felix.apache.org/site/apache-felix-maven-scr-plugin.html
[2]:
http://old.nabble.com/-jira--Created:-%28FELIX-1847%29-Error-with-duplicates-when-using-maven-bundle-plugin-2.0.1-and-maven-scr-plugin-1.4-td26216540.html

>
>
>
> Guido Spadotto wrote:
>> Why don't you just use the maven-scr-plugin and its annotations?
>> I've found it very handy to generate the component descriptor.
>>
>> This is a snippet of a pom of mine (notice there's no bnd file
>> "tampering"):
>>
>> <project xmlns="http://maven.apache.org/POM/4.0.0"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
>> http://maven.apache.org/maven-v4_0_0.xsd">
>>    <modelVersion>4.0.0</modelVersion>
>>    <properties>
>>        
>> <*component.descriptor.name*>_WhateverYouLike.xml_</component.descriptor.name>      
>> </properties>
>>
>>  
>>    </dependencies>
>>    <build>
>>        <plugins>
>>            <plugin>
>>                <groupId>org.apache.felix</groupId>
>>                <artifactId>maven-bundle-plugin</artifactId>
>>                <extensions>true</extensions>
>>                <configuration>
>>                    <instructions>
>>                        <Bundle-Name>${project.name}</Bundle-Name>
>>                        
>> <Export-Package>org.something.api</Export-Package>
>>                        
>> <Service-Component>OSGI-INF/${*component.descriptor.name*}</Service-Component>    
>>                                     </instructions>
>>                </configuration>
>>            </plugin>
>>            <plugin>
>>                <groupId>org.apache.felix</groupId>
>>                <artifactId>maven-scr-plugin</artifactId>
>>                <version>1.0.8</version>
>>                <configuration>
>>                    <finalName>${*component.descriptor.name*}</finalName>
>>                </configuration>
>>                <executions>
>>                    <execution>
>>                        <id>generate-scr-scrdescriptor</id>
>>                        <goals>
>>                            <goal>scr</goal>
>>                        </goals>
>>                    </execution>
>>                </executions>
>>            </plugin>
>>        </plugins>
>>    </build>
>>
>> </project>
>>
>>
>> Cheers,
>> Guido
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Mustafa Caylak]

Hi,

I know that I can set the name of the xml-file. I was just too lazy :)

The problem could be that there is no a directory like
/target/scr-plugin-generated/OSGI-INF.
Does it mean that no descriptor.xml is generated?

I'm a bit confuesed. Where do I use the annotations? Aren't they the
same annotations that you use when you define a Declarative Service
Component?
Where do the scr-plugin know what it has to generate?

I know I'm annoying but you have to bear it, please ^^

I think I hate maven more every day... :P


Regards
Mustafa



Guido Spadotto wrote:

> Mustafa Caylak wrote:
>> Hello Guido,
>>
>> I've used your suggestion, but the only output I got is:
>> [ERROR] Error building bundle
>> de.offis.utils.configSC:configSC:bundle:1.0-SNAPSHOT :
>> Service-Component entry can not be located in JAR: OSGI-INF/Locator.xml
>>
>> Of course I renamed my xml-file to Locator.xml.
>> What do your Locator.xml look like?
>>
> Hi Mustafa,
> first, you can name the *automatically* generated component descriptor
> as you like.
>
> I've named it Locator.xml because that made sense for the component I
> developed,
> but you can set the value of the *component.descriptor.name *property
> to anything
> you like.
>
> That said, could you take a look inside the
> \target\scr-plugin-generated\OSGI-INF
> directory of your project? It should contain the generated component
> descriptor file,
> whose name will be the value of the *component.descriptor.name
> *property, if specified.
>
> If it's there, then the scr plugin worked, and that's all it's
> supposed to do (according to [1]).
>
> In order for the maven-bundle-plugin to insert that descriptor file in
> the bundle,
> you will have to add this directive within its configuration
> instructions:
> <Service-Component>OSGI-INF/${component.descriptor.name}</Service-Component>
>
>
>
> Sorry to ask this, but have you added the relevant annotations inside
> the component implementation?
>
> It might also be that you've experienced [2], but I can't say for sure
> with the amount
> of information you provided so far.
>
> Cheers,
> Guido
>
> [1]: http://felix.apache.org/site/apache-felix-maven-scr-plugin.html
> [2]:
> http://old.nabble.com/-jira--Created:-%28FELIX-1847%29-Error-with-duplicates-when-using-maven-bundle-plugin-2.0.1-and-maven-scr-plugin-1.4-td26216540.html 
>
>>
>>
>>
>> Guido Spadotto wrote:
>>> Why don't you just use the maven-scr-plugin and its annotations?
>>> I've found it very handy to generate the component descriptor.
>>>
>>> This is a snippet of a pom of mine (notice there's no bnd file
>>> "tampering"):
>>>
>>> <project xmlns="http://maven.apache.org/POM/4.0.0"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
>>> http://maven.apache.org/maven-v4_0_0.xsd">
>>>    <modelVersion>4.0.0</modelVersion>
>>>    <properties>
>>>        
>>> <*component.descriptor.name*>_WhateverYouLike.xml_</component.descriptor.name>      
>>> </properties>
>>>
>>>      </dependencies>
>>>    <build>
>>>        <plugins>
>>>            <plugin>
>>>                <groupId>org.apache.felix</groupId>
>>>                <artifactId>maven-bundle-plugin</artifactId>
>>>                <extensions>true</extensions>
>>>                <configuration>
>>>                    <instructions>
>>>                        <Bundle-Name>${project.name}</Bundle-Name>
>>>                        
>>> <Export-Package>org.something.api</Export-Package>
>>>                        
>>> <Service-Component>OSGI-INF/${*component.descriptor.name*}</Service-Component>    
>>>                                     </instructions>
>>>                </configuration>
>>>            </plugin>
>>>            <plugin>
>>>                <groupId>org.apache.felix</groupId>
>>>                <artifactId>maven-scr-plugin</artifactId>
>>>                <version>1.0.8</version>
>>>                <configuration>
>>>                    
>>> <finalName>${*component.descriptor.name*}</finalName>
>>>                </configuration>
>>>                <executions>
>>>                    <execution>
>>>                        <id>generate-scr-scrdescriptor</id>
>>>                        <goals>
>>>                            <goal>scr</goal>
>>>                        </goals>
>>>                    </execution>
>>>                </executions>
>>>            </plugin>
>>>        </plugins>
>>>    </build>
>>>
>>> </project>
>>>
>>>
>>> Cheers,
>>> Guido
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Guido Spadotto]

Mustafa Caylak wrote:

> Hi,
>
> I know that I can set the name of the xml-file. I was just too lazy :)
>
> The problem could be that there is no a directory like
> /target/scr-plugin-generated/OSGI-INF.
> Does it mean that no descriptor.xml is generated?
>
> I'm a bit confused. Where do I use the annotations? Aren't they the
> same annotations that you use when you define a Declarative Service
> Component?
> Where do the scr-plugin know what it has to generate?

You embed JAVA annotations in your Component implementation source code.
When you execute Maven, the scr plugin will inspect the annotated
classes and generate
the corresponding XML Component Descriptor file for you.
>
> I know I'm annoying but you have to bear it, please ^^
This is no Customer Service, so you'll have to do some homework.
Read [1], slide 18 and following, read [2], slide 19 for an example of
annotated class.

[1]: http://www.slideshare.net/cziegeler/maven-scr-plugin
[2]: http://www.slideshare.net/bdelacretaz/tales-from-the-osgi-trenches


Best,
 Guido

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Mustafa Caylak]

> This is no Customer Service, so you'll have to do some homework.
> Read [1], slide 18 and following, read [2], slide 19 for an example of
> annotated class.
>
> [1]: http://www.slideshare.net/cziegeler/maven-scr-plugin
> [2]: http://www.slideshare.net/bdelacretaz/tales-from-the-osgi-trenches
Yes, you're right. And I hate that I have to ask you guys for help. Just
a minute ago I argued with someone because he didn't want to do his
homework.
I really searched for tutorials or something alike but I couldn't find
anything.

The two sites you send me - I've never seen them before.

Where I do get these sites?


I think it won't take any longer until I let you alone :)


Best regards
Mustafa

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Guido Spadotto]

Mustafa Caylak wrote:

>
>> This is no Customer Service, so you'll have to do some homework.
>> Read [1], slide 18 and following, read [2], slide 19 for an example
>> of annotated class.
>>
>> [1]: http://www.slideshare.net/cziegeler/maven-scr-plugin
>> [2]: http://www.slideshare.net/bdelacretaz/tales-from-the-osgi-trenches
> Yes, you're right. And I hate that I have to ask you guys for help.
> Just a minute ago I argued with someone because he didn't want to do
> his homework.
> I really searched for tutorials or something alike but I couldn't find
> anything.
>
> The two sites you send me - I've never seen them before.
>
> Where I do get these sites?

Here:
http://tinyurl.com/y9vjg53

:)

Guido

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Mustafa Caylak]

Yeah,

Thank God - it works! The mvn-scr-plugin doesn't ignore my directive.

Thank you guys for your engagement!



Good night
Mustafa

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[John E. Conlon]

How does the Config Admin deal with type conversion between the
properties oriented *.cfg files (storing Strings) and the updated
configurations that are sent by the service that may be a non String
(Integer, Boolean, etc)?

Have worked with another framework that use the Metatype service for
this kind of conversion, but I am not aware that Felix has a Metatype
service??

Without a Metatype service in Felix, do I have to manage the conversion
for all non Strings myself?

thanks,

John

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Stuart McCulloch]

2009/11/15 John E. Conlon <jconlon@...>

> How does the Config Admin deal with type conversion between the properties
> oriented *.cfg files (storing Strings) and the updated configurations that
> are sent by the service that may be a non String (Integer, Boolean, etc)?
>
> Have worked with another framework that use the Metatype service for this
> kind of conversion, but I am not aware that Felix has a Metatype service??
> Without a Metatype service in Felix, do I have to manage the conversion for
> all non Strings myself?
>

FYI, Felix does have a metatype service:

   http://felix.apache.org/site/apache-felix-metatype-service.html

   http://www.apache.org/dist/felix/org.apache.felix.metatype-1.0.4.jar

also you can often mix service bundles between frameworks - for example,
there is nothing Felix specific (afaik) about its metatype implementation so
you could deploy it onto any other OSGi framework (equinox, KF, etc.)

the same is true for most OSGi services, so feel free to mix'n'match

thanks,
>
> John
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>


--
Cheers, Stuart

[Felix Meschberger-2]

Hi John,

John E. Conlon schrieb:
> How does the Config Admin deal with type conversion between the
> properties oriented *.cfg files (storing Strings) and the updated
> configurations that are sent by the service that may be a non String
> (Integer, Boolean, etc)?

It depends on what you mean by "*.cfg" files. Are these the files
maintained internally by the config admin service ?

Or is this the files handled by fileinstall ?

In the first case the config admin service internally ensures with type
tags that properties are read into the correct type when loading.

In fact, the Felix config admin service implementation does not use the
metatype service: It just stores and loads the data types as they are
provided in the configuration object. There is no conversion involved.

For fileinstall, I don't know.

Regards
Felix

>
> Have worked with another framework that use the Metatype service for
> this kind of conversion, but I am not aware that Felix has a Metatype
> service??
> Without a Metatype service in Felix, do I have to manage the conversion
> for all non Strings myself?
>
> thanks,
>
> John
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[John E. Conlon]

Hi Stuart,

See inline responses...

Stuart McCulloch wrote:

> 2009/11/15 John E. Conlon <jconlon@...>
>
>  
>> How does the Config Admin deal with type conversion between the properties
>> oriented *.cfg files (storing Strings) and the updated configurations that
>> are sent by the service that may be a non String (Integer, Boolean, etc)?
>>
>> Have worked with another framework that use the Metatype service for this
>> kind of conversion, but I am not aware that Felix has a Metatype service??
>> Without a Metatype service in Felix, do I have to manage the conversion for
>> all non Strings myself?
>>
>>    
>
> FYI, Felix does have a metatype service:
>
>    http://felix.apache.org/site/apache-felix-metatype-service.html
>
>    http://www.apache.org/dist/felix/org.apache.felix.metatype-1.0.4.jar
>  

Duh, - that's what I get for working so late:-)  
> also you can often mix service bundles between frameworks - for example,
> there is nothing Felix specific (afaik) about its metatype implementation so
> you could deploy it onto any other OSGi framework (equinox, KF, etc.)
>
> the same is true for most OSGi services, so feel free to mix'n'match
>  
Yes, I have done this with the org.eclipse.equinox.io and
org.eclipse.equinox.wireadmin as I couldn't find these in Felix when
(that was during the daytime when I was awake;-).

thanks for the reminder,

John

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...