dev@glassfish.java.net

Re: MANIFEST.MF problems in Maven and OSGi packaging, naming and versioning rules

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Thu, 21 Jul 2011 14:46:16 -0700

Ed Burns wrote on 07/21/2011 10:23 AM:
> SECTION: jstl-api-1.2.jar

Clearly this hasn't been updated to the new conventions:
http://wikis.sun.com/display/GlassFish/Maven+Versioning+Rules

> SECTION: javax.el-api-2.2.1.jar

Looks like some obvious bugs here as well.

> SECTION: javax.servlet-api-3.0.1.jar
>
> Export-Package: javax.servlet;uses:="javax.servlet.descriptor,javax.se
> rvlet.annotation";version="3.0",javax.servlet.descriptor;version="3.0
> ",javax.servlet.annotation;uses:="javax.servlet";version="3.0",javax.
> servlet.http;uses:="javax.servlet";version="3.0"
>
> EB> Shouldn't the exported versions be 3.0.1, to match the maven version
> EB> of the artifact, and, indeed, the OSGi Bundle-version?

Not necessarily. See the URL above.

> SECTION: javax.servlet.jsp-api-2.2.1.jar
>
> Export-Package: javax.servlet.jsp.el;uses:="javax.servlet,javax.el,jav
> ax.servlet.jsp,javax.servlet.http";version="2.2.1",javax.servlet.jsp.
> tagext;uses:="javax.servlet.jsp";version="2.2.1",javax.servlet.jsp;us
> es:="javax.servlet,javax.el,javax.servlet.jsp.el,javax.servlet.jsp.ta
> gext,javax.servlet.http";version="2.2.1"
> Tool: Bnd-0.0.255
> Import-Package: javax.el,javax.servlet,javax.servlet.http,javax.servle
> t.jsp;version="2.2.1",javax.servlet.jsp.el;version="2.2.1",javax.serv
> let.jsp.tagext;version="2.2.1"
>
> EB> Same comment as for the EL artifact

Ditto.

To expand a bit...

There's two cases to consider for the API jar files:

1. The API jar file is used only to provide the signatures that define
    the API; it's not used at runtime.

        In this case the version number of the exported APIs should only
        change when the API signatures change.

2. The API jar file is used to define the signatures of the API *and*
    is used at runtime; the runtime depends on the code in these API classes
    even though the details of the code might not be specified by the spec.

        In this case the version number of the exported APIs should be
        changed whenever the code in the API classes changes; often the
        version number will simply track the bundle version number.

Does that help?