felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart McCulloch <mccu...@gmail.com>
Subject Re: how <manifestLocation> is used in maven-bundle-plugin
Date Wed, 24 Aug 2011 21:36:01 GMT
Hi Marshall,

Turns out this is not specific to <manifestLocation> but is instead to do
with:

  a)  generating a manifest with the bundle:manifest goal

coupled with:

  b)  pulling that manifest into a jar with the maven-jar-plugin

The issue is caused by a feature in the maven-bundle-plugin where it picks
up custom manifest settings from the maven-jar-plugin configuration and
merges those with the manifest created by BND (see
https://issues.apache.org/jira/browse/FELIX-442 and
https://issues.apache.org/jira/browse/FELIX-806). While this works as
expected for the bundle goal, it has an unexpected side-effect with the
manifest goal.

Basically because the jar plugin is configured to read the generated
manifest, if the target directory is not cleaned between builds then the
manifest goal will read the old manifest back in and merge it with the new
BND manifest. If you open an issue under
https://issues.apache.org/jira/browse/FELIX/component/12311143 I'll try to
fix this in the next release (probably by detecting the circularity during
the manifest goal and skipping the merge step).

Until then a workaround is to put a dummy <archive> element inside the
maven-bundle-plugin configuration (note: must be _outside_ the instructions
section)

        <plugin>
          <groupId>org.apache.felix</groupId>
          <artifactId>maven-bundle-plugin</artifactId>
          <configuration>
            <archive>
              <forced>true</forced><!-- dummy entry to stop bundleplugin
from picking up jar config -->
            </archive>
            <instructions>
              <!-- etc... -->
            </instructions>
          </configuration>
        </plugin>

This will trick the maven-bundle-plugin into using the above archive setting
instead of the one with the <manifestFile> from the maven-jar-plugin
configuration.

HTH

On 19 August 2011 22:25, Marshall Schor <msa@schor.com> wrote:

> Oops, cut/paste error.
>
> The 2nd svn checkout should be of course:
>
> svn checkout http://svn.apache.org/repos/asf/uima/uimaj/trunk/uimaj-parent testSmall/uimaj-parent
>
> Sorry about that...
>
> -Marshall
>
>
> On 8/19/2011 4:46 PM, Marshall Schor wrote:
> > reproducing:
> >
> > 1) you'll need svn and maven 3
> >
> > 2)
> > svn checkout
> http://svn.apache.org/repos/asf/uima/uimaj/trunk/uimaj-ep-debug
> > testSmall/uimaj-ep-debug
> > svn checkout
> http://svn.apache.org/repos/asf/uima/uimaj/trunk/uimaj-ep-debug
> > testSmall/uimaj-parent
> >
> > 3) cd testSmall/uimaj-ep-debug
> >
> > 4) mvn install                  (this builds using maven-bundle-plugin)
> >
> > 5) mvn install                  (this rebuilds, but BND now finds the
> previously
> > built MANIFEST.MF and produces the warnings.
> >
> > -Marshall
> >
> > On 8/19/2011 2:56 PM, Stuart McCulloch wrote:
> >> On 19 Aug 2011, at 19:29, Marshall Schor wrote:
> >>
> >>> The docs appear to say that <manifestLocation> is used to specify
the
> directory
> >>> where BND will write the manifest.
> >>>
> >>> However, the maven-bundle-plugin (or BND also appears to *read* an
> existing
> >>> Manifest (at least, when the "manifest" goal is used in the Maven
> plugin).  For
> >>> instance, if an existing one is there I see output in the console from
> running
> >>> maven-bundle-plugin of lots of instances of these:
> >> the "manifestLocation" parameter only affects where the manifest is
> written out to, it isn't passed into bnd or used to read an existing
> manifest
> >>
> >> however, bnd could read an existing manifest when asked to update an
> artifact - can you provide the pom (and bnd instructions) to recreate this?
> >>
> >> I think something else is going on rather than being specific to the
> "manifestLocation" parameter
> >>
> >>> WARNING: Duplicate name in Manifest: Manifest-Version.
> >>> Ensure that the manifest does not have duplicate entries, and
> >>> that blank lines separate individual sections in both your
> >>> manifest and in the META-INF/MANIFEST.MF entry in the jar file.
> >>>
> >>> If I first erase the existing MANIFEST.MF before running the
> maven-bundle-plugin
> >>> "manifest" goal, all these messages go away.
> >>>
> >>> What is the right approach to avoid these superfluous messages?
> >>>
> >>> 1) put in a step into the maven build to erase this file before calling
> the
> >>> bundle plugin?
> >>> 2) is there some special configuration or instruction to tell BND to
> not read
> >>> the Manifest.MF (I looked, but didn't see anything)
> >>> 3) something else?
> >>>
> >>> Thanks. -Marshall
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>


-- 
Cheers, Stuart

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message