Re: [commons] Added 2nd round of wrapper POM contributions

[Richard S. Hall]

On Mar 6, 2007, at 7:45 PM, Tim Moloney wrote:
Richard S. Hall wrote:
On Mar 6, 2007, at 6:37 PM, Tim Moloney wrote:


Here's an updated template pom file.

Tim

<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>

    <parent>
        <groupId>org.apache.felix.commons</groupId>
        <artifactId>build</artifactId>
        <version>0.9.0-incubator-SNAPSHOT</version>
    </parent>

    <properties>
      <shortName>FOO</shortName>
    </properties>

    <groupId>org.apache.felix.commons</groupId>
    <artifactId>${pom.groupId}.${shortName}</artifactId>
    <version>x.y.z</version>
    <packaging>bundle</packaging>

    <name>${shortName} bundle</name>
    <description>This bundle simply wraps ${shortName}-$ 
{pom.version}.jar.</description>

    <organization>
        <name>Apache Felix Project</name>
        <url>http://incubator.apache.org/felix/</url>
    </organization>

    <dependencies>
        <dependency>
            <groupId>FOO-groupId</groupId>
            <artifactId>${shortName}</artifactId>
            <version>${pom.version}</version>
        </dependency>
    </dependencies>

I guess I am confused about this dependency template; this seems  
to imply that the bundle will have dependencies on itself.  
Shouldn't the dependencies template look something like this:

    <dependencies>
        <dependency>
            <groupId>BAR-groupId</groupId>
            <artifactId>BAR-artifactId</artifactId>
            <version>BAR-version</version>
        </dependency>
    </dependencies>

?

Or am I missing the point?

I'm still a bit fuzzy on all the details of dependency handling but  
here's what I think happens.

There needs to be some sort of dependency for maven to find the jar  
to wrap at compile time.  The maven-bundle-plugin (bnd) then  
creates the manifest entries that define any runtime dependencies.   
I think that since maven-bundle-plugin (bnd) is creating the  
manifest (rather than maven-jar-plugin), the maven dependency  
elements don't apply at runtime.  Having said all that, we could  
set the scope to compile in the dependency.  I think.

Oh, yeah, yeah. I wasn't thinking. Yes, this is the dependency on the  
JAR you are going to wrap! Duh! :-)


    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.felix</groupId>
                <artifactId>maven-bundle-plugin</artifactId>
                <extensions>true</extensions>
                <configuration>
                    <instructions>
                        <Bundle-SymbolicName>${pom.artifactId}</ 
Bundle-SymbolicName>
                        <Export-Package>FOO</Export-Package>
                        <Private-Package>FOO.impl</Private-Package>
<!--
Uncomment this section after bnd-find-include-resource-in- 
classpath.patch from FELIX-204 has
been applied to bnd.
                        <Include-Resource>@${shortName}-$ 
{pom.version}.jar!/META-INF/LICENSE.txt</Include-Resource>
-->

Also, what is the point of this?

This tells maven-bundle-plugin (bnd) to include the specified  
resource in the bundle.  There is no runtime impact for resources  
like license files, etc.  However, there are other bundles that  
need specific resources included (e.g., mail  http:// 
issues.apache.org/jira/secure/attachment/12352679/pom.xml).   
Currently bnd will only find resources in a jar file if that jar  
file is in the root of the project directory.  The patch that I  
mentioned changes bnd to find jar files in the class path so that  
the maven-build-plugin can use the jar file that is in the local  
maven repository.

Ok, got it!

Thanks.

-> richard


-> richard

                    </instructions>
                </configuration>
            </plugin>
        </plugins>
    </build>

</project>