You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Marshall Schor <ms...@schor.com> on 2011/08/19 20:29:28 UTC
how is used in maven-bundle-plugin
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:
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
Re: how is used in maven-bundle-plugin
Posted by Stuart McCulloch <mc...@gmail.com>.
On 26 Aug 2011, at 15:48, Marshall Schor wrote:
> Stuart, if you give me pointers to which source files in the apache repo have
> the docs for the maven bundle plugin, I'll take a crack at doing a patch for the
> documentation.
>
> I assume the maven-style docs are generated from "annotations" of some kind,
> somewhere? I'd like to add to the maven-style docs, a description of how the
> archive config parameter works, and also do a more general description
> somewhere... But I'm not sure which docs are "sources" and which are "generated"...
the maven docs at:
http://svn.apache.org/repos/asf/felix/releases/maven-bundle-plugin-2.3.5/doc/site/index.html
are generated by running "mvn clean install site" and moving the contents "target/site" under the "doc/site" directory
the source of this doc is under "src/site" (see http://maven.apache.org/plugins/maven-site-plugin/examples/creating-content.html for info on the formats)
the other docs at:
http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
are generated from confluence:
https://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Maven+Bundle+Plugin+%28BND%29
IIRC non-committer changes should be added as comments, then a committer can merge them in
> -Marshall
>
> On 8/25/2011 11:24 AM, Stuart McCulloch wrote:
>> On 25 Aug 2011, at 12:55, Marshall Schor <ms...@schor.com> wrote:
>>
>>> On 8/25/2011 12:36 AM, Stuart McCulloch wrote:
>>>> On 25 Aug 2011, at 05:17, Marshall Schor wrote:
>>>>
>>>>> Hi Stuart,
>>>>>
>>>>> It took me several readings of your note to figure out what was happening.
>>>>>
>>>>> Here's what I think you said:
>>>>>
>>>>> a) The maven-jar-plugin is configured to read the Manifest.MF from the spot the
>>>>> maven-bundle-plugin puts its result.
>>>>>
>>>>> b) because of the "feature" described in FELIX-442 and 806, the
>>>>> maven-bundle-plugin picks up the configuration in the maven-jar-plugin which
>>>>> says to read the Manifest.MF from that spot, and because of that, it reads in
>>>>> that manifest and merges it with what BND produces, and writes the merged one out.
>>>>>
>>>>> This design (where the maven-bundle-plugin reads another plugin's
>>>>> <configuration> and incorporates some of it) is very surprising to me. It seems
>>>>> to me more straight-forward, if you want <configuration> settings like are in
>>>>> the maven-jar-plugin, to be available to the maven-bundle-plugin, to simply
>>>>> allow those in the maven-bundle-plugin. I'm probably missing something obvious,
>>>>> but I'm curious - what was the motivation for this unusual design?
>>>> It was a feature requested by several people (Apache Commons, etc.) who were migrating existing projects to the "bundle" packaging:
>>>>
>>>> http://www.mail-archive.com/users@felix.apache.org/msg00726.html
>>>>
>>>> ie. they have existing maven-jar-plugin configurations defined in parent poms that they want picked up by both jar and bundle projects.
>>> From that note, though, it looks like a mistaken belief that the Jar and the
>>> Bundle plugin were both being run, whereas, actually, the bundle plugin was
>>> "substituting" for the Jar.
>> no, if that was the case then it would have been easy - the actual situation was that there were shared parent poms involved, which both jar and bundle projects extended - without this feature the archive settings would have to be duplicated and maintained in two places
>>
>> given that people still ask for additions to this feature (see current backlog) this is definitely something people still rely on when introducing bundles to existing projects (where both jar and bundle projects share corporate poms)
>>
>>> So, it seems to me that it would have been quite straightforward to copy
>>> whatever configuration was desired into the bundle plugin directly. I guess
>>> that's what I would have expected (except for the misunderstanding that both the
>>> Jar and the Bundle plugins were running).
>>>
>>>> note that you can put the <archive> section in the bundleplugin (ie. as done in the workaround below) - it's just that if that section isn't there then we also check the maven-jar-plugin configuration
>>> I suppose these 2 features (the taking of Jar plugin configuration, and the
>>> ability to include <archive> sections) are quite important to be documented on
>>> this page:
>>> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html - (I
>>> don't think they are) - as it is a very surprising thing to the uninitiated :-).
>>>
>>> -Marshall
>>>>> -Marshall
>>>>>
>>>>> On 8/24/2011 5:36 PM, Stuart McCulloch wrote:
>>>>>> 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 <ms...@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
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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
Re: how is used in maven-bundle-plugin
Posted by Marshall Schor <ms...@schor.com>.
Stuart, if you give me pointers to which source files in the apache repo have
the docs for the maven bundle plugin, I'll take a crack at doing a patch for the
documentation.
I assume the maven-style docs are generated from "annotations" of some kind,
somewhere? I'd like to add to the maven-style docs, a description of how the
archive config parameter works, and also do a more general description
somewhere... But I'm not sure which docs are "sources" and which are "generated"...
-Marshall
On 8/25/2011 11:24 AM, Stuart McCulloch wrote:
> On 25 Aug 2011, at 12:55, Marshall Schor <ms...@schor.com> wrote:
>
>> On 8/25/2011 12:36 AM, Stuart McCulloch wrote:
>>> On 25 Aug 2011, at 05:17, Marshall Schor wrote:
>>>
>>>> Hi Stuart,
>>>>
>>>> It took me several readings of your note to figure out what was happening.
>>>>
>>>> Here's what I think you said:
>>>>
>>>> a) The maven-jar-plugin is configured to read the Manifest.MF from the spot the
>>>> maven-bundle-plugin puts its result.
>>>>
>>>> b) because of the "feature" described in FELIX-442 and 806, the
>>>> maven-bundle-plugin picks up the configuration in the maven-jar-plugin which
>>>> says to read the Manifest.MF from that spot, and because of that, it reads in
>>>> that manifest and merges it with what BND produces, and writes the merged one out.
>>>>
>>>> This design (where the maven-bundle-plugin reads another plugin's
>>>> <configuration> and incorporates some of it) is very surprising to me. It seems
>>>> to me more straight-forward, if you want <configuration> settings like are in
>>>> the maven-jar-plugin, to be available to the maven-bundle-plugin, to simply
>>>> allow those in the maven-bundle-plugin. I'm probably missing something obvious,
>>>> but I'm curious - what was the motivation for this unusual design?
>>> It was a feature requested by several people (Apache Commons, etc.) who were migrating existing projects to the "bundle" packaging:
>>>
>>> http://www.mail-archive.com/users@felix.apache.org/msg00726.html
>>>
>>> ie. they have existing maven-jar-plugin configurations defined in parent poms that they want picked up by both jar and bundle projects.
>> From that note, though, it looks like a mistaken belief that the Jar and the
>> Bundle plugin were both being run, whereas, actually, the bundle plugin was
>> "substituting" for the Jar.
> no, if that was the case then it would have been easy - the actual situation was that there were shared parent poms involved, which both jar and bundle projects extended - without this feature the archive settings would have to be duplicated and maintained in two places
>
> given that people still ask for additions to this feature (see current backlog) this is definitely something people still rely on when introducing bundles to existing projects (where both jar and bundle projects share corporate poms)
>
>> So, it seems to me that it would have been quite straightforward to copy
>> whatever configuration was desired into the bundle plugin directly. I guess
>> that's what I would have expected (except for the misunderstanding that both the
>> Jar and the Bundle plugins were running).
>>
>>> note that you can put the <archive> section in the bundleplugin (ie. as done in the workaround below) - it's just that if that section isn't there then we also check the maven-jar-plugin configuration
>> I suppose these 2 features (the taking of Jar plugin configuration, and the
>> ability to include <archive> sections) are quite important to be documented on
>> this page:
>> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html - (I
>> don't think they are) - as it is a very surprising thing to the uninitiated :-).
>>
>> -Marshall
>>>> -Marshall
>>>>
>>>> On 8/24/2011 5:36 PM, Stuart McCulloch wrote:
>>>>> 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 <ms...@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
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: how is used in maven-bundle-plugin
Posted by Stuart McCulloch <mc...@gmail.com>.
On 25 Aug 2011, at 12:55, Marshall Schor <ms...@schor.com> wrote:
> On 8/25/2011 12:36 AM, Stuart McCulloch wrote:
>> On 25 Aug 2011, at 05:17, Marshall Schor wrote:
>>
>>> Hi Stuart,
>>>
>>> It took me several readings of your note to figure out what was happening.
>>>
>>> Here's what I think you said:
>>>
>>> a) The maven-jar-plugin is configured to read the Manifest.MF from the spot the
>>> maven-bundle-plugin puts its result.
>>>
>>> b) because of the "feature" described in FELIX-442 and 806, the
>>> maven-bundle-plugin picks up the configuration in the maven-jar-plugin which
>>> says to read the Manifest.MF from that spot, and because of that, it reads in
>>> that manifest and merges it with what BND produces, and writes the merged one out.
>>>
>>> This design (where the maven-bundle-plugin reads another plugin's
>>> <configuration> and incorporates some of it) is very surprising to me. It seems
>>> to me more straight-forward, if you want <configuration> settings like are in
>>> the maven-jar-plugin, to be available to the maven-bundle-plugin, to simply
>>> allow those in the maven-bundle-plugin. I'm probably missing something obvious,
>>> but I'm curious - what was the motivation for this unusual design?
>> It was a feature requested by several people (Apache Commons, etc.) who were migrating existing projects to the "bundle" packaging:
>>
>> http://www.mail-archive.com/users@felix.apache.org/msg00726.html
>>
>> ie. they have existing maven-jar-plugin configurations defined in parent poms that they want picked up by both jar and bundle projects.
>
> From that note, though, it looks like a mistaken belief that the Jar and the
> Bundle plugin were both being run, whereas, actually, the bundle plugin was
> "substituting" for the Jar.
no, if that was the case then it would have been easy - the actual situation was that there were shared parent poms involved, which both jar and bundle projects extended - without this feature the archive settings would have to be duplicated and maintained in two places
given that people still ask for additions to this feature (see current backlog) this is definitely something people still rely on when introducing bundles to existing projects (where both jar and bundle projects share corporate poms)
> So, it seems to me that it would have been quite straightforward to copy
> whatever configuration was desired into the bundle plugin directly. I guess
> that's what I would have expected (except for the misunderstanding that both the
> Jar and the Bundle plugins were running).
>
>>
>> note that you can put the <archive> section in the bundleplugin (ie. as done in the workaround below) - it's just that if that section isn't there then we also check the maven-jar-plugin configuration
>
> I suppose these 2 features (the taking of Jar plugin configuration, and the
> ability to include <archive> sections) are quite important to be documented on
> this page:
> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html - (I
> don't think they are) - as it is a very surprising thing to the uninitiated :-).
>
> -Marshall
>>
>>> -Marshall
>>>
>>> On 8/24/2011 5:36 PM, Stuart McCulloch wrote:
>>>> 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 <ms...@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
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: how is used in maven-bundle-plugin
Posted by Marshall Schor <ms...@schor.com>.
On 8/25/2011 12:36 AM, Stuart McCulloch wrote:
> On 25 Aug 2011, at 05:17, Marshall Schor wrote:
>
>> Hi Stuart,
>>
>> It took me several readings of your note to figure out what was happening.
>>
>> Here's what I think you said:
>>
>> a) The maven-jar-plugin is configured to read the Manifest.MF from the spot the
>> maven-bundle-plugin puts its result.
>>
>> b) because of the "feature" described in FELIX-442 and 806, the
>> maven-bundle-plugin picks up the configuration in the maven-jar-plugin which
>> says to read the Manifest.MF from that spot, and because of that, it reads in
>> that manifest and merges it with what BND produces, and writes the merged one out.
>>
>> This design (where the maven-bundle-plugin reads another plugin's
>> <configuration> and incorporates some of it) is very surprising to me. It seems
>> to me more straight-forward, if you want <configuration> settings like are in
>> the maven-jar-plugin, to be available to the maven-bundle-plugin, to simply
>> allow those in the maven-bundle-plugin. I'm probably missing something obvious,
>> but I'm curious - what was the motivation for this unusual design?
> It was a feature requested by several people (Apache Commons, etc.) who were migrating existing projects to the "bundle" packaging:
>
> http://www.mail-archive.com/users@felix.apache.org/msg00726.html
>
> ie. they have existing maven-jar-plugin configurations defined in parent poms that they want picked up by both jar and bundle projects.
>From that note, though, it looks like a mistaken belief that the Jar and the
Bundle plugin were both being run, whereas, actually, the bundle plugin was
"substituting" for the Jar.
So, it seems to me that it would have been quite straightforward to copy
whatever configuration was desired into the bundle plugin directly. I guess
that's what I would have expected (except for the misunderstanding that both the
Jar and the Bundle plugins were running).
>
> note that you can put the <archive> section in the bundleplugin (ie. as done in the workaround below) - it's just that if that section isn't there then we also check the maven-jar-plugin configuration
I suppose these 2 features (the taking of Jar plugin configuration, and the
ability to include <archive> sections) are quite important to be documented on
this page:
http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html - (I
don't think they are) - as it is a very surprising thing to the uninitiated :-).
-Marshall
>
>> -Marshall
>>
>> On 8/24/2011 5:36 PM, Stuart McCulloch wrote:
>>> 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 <ms...@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
>>>>
>>>>
>> ---------------------------------------------------------------------
>> 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
Re: how is used in maven-bundle-plugin
Posted by Stuart McCulloch <mc...@gmail.com>.
On 25 Aug 2011, at 05:17, Marshall Schor wrote:
> Hi Stuart,
>
> It took me several readings of your note to figure out what was happening.
>
> Here's what I think you said:
>
> a) The maven-jar-plugin is configured to read the Manifest.MF from the spot the
> maven-bundle-plugin puts its result.
>
> b) because of the "feature" described in FELIX-442 and 806, the
> maven-bundle-plugin picks up the configuration in the maven-jar-plugin which
> says to read the Manifest.MF from that spot, and because of that, it reads in
> that manifest and merges it with what BND produces, and writes the merged one out.
>
> This design (where the maven-bundle-plugin reads another plugin's
> <configuration> and incorporates some of it) is very surprising to me. It seems
> to me more straight-forward, if you want <configuration> settings like are in
> the maven-jar-plugin, to be available to the maven-bundle-plugin, to simply
> allow those in the maven-bundle-plugin. I'm probably missing something obvious,
> but I'm curious - what was the motivation for this unusual design?
It was a feature requested by several people (Apache Commons, etc.) who were migrating existing projects to the "bundle" packaging:
http://www.mail-archive.com/users@felix.apache.org/msg00726.html
ie. they have existing maven-jar-plugin configurations defined in parent poms that they want picked up by both jar and bundle projects.
note that you can put the <archive> section in the bundleplugin (ie. as done in the workaround below) - it's just that if that section isn't there then we also check the maven-jar-plugin configuration
> -Marshall
>
> On 8/24/2011 5:36 PM, Stuart McCulloch wrote:
>> 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 <ms...@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
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> 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
Re: how is used in maven-bundle-plugin
Posted by Marshall Schor <ms...@schor.com>.
Hi Stuart,
It took me several readings of your note to figure out what was happening.
Here's what I think you said:
a) The maven-jar-plugin is configured to read the Manifest.MF from the spot the
maven-bundle-plugin puts its result.
b) because of the "feature" described in FELIX-442 and 806, the
maven-bundle-plugin picks up the configuration in the maven-jar-plugin which
says to read the Manifest.MF from that spot, and because of that, it reads in
that manifest and merges it with what BND produces, and writes the merged one out.
This design (where the maven-bundle-plugin reads another plugin's
<configuration> and incorporates some of it) is very surprising to me. It seems
to me more straight-forward, if you want <configuration> settings like are in
the maven-jar-plugin, to be available to the maven-bundle-plugin, to simply
allow those in the maven-bundle-plugin. I'm probably missing something obvious,
but I'm curious - what was the motivation for this unusual design?
-Marshall
On 8/24/2011 5:36 PM, Stuart McCulloch wrote:
> 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 <ms...@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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: how is used in maven-bundle-plugin
Posted by Stuart McCulloch <mc...@gmail.com>.
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 <ms...@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
Re: how is used in maven-bundle-plugin
Posted by Marshall Schor <ms...@schor.com>.
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
Re: how is used in maven-bundle-plugin
Posted by Marshall Schor <ms...@schor.com>.
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
Re: how is used in maven-bundle-plugin
Posted by Stuart McCulloch <mc...@gmail.com>.
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