2008/10/8 Marina Vatkina <[EMAIL PROTECTED]>
> Unfortunately I don't see any difference if I add <manifestLocation> entry
> :(.
>
hmm... this pom is from GlassFish isn't it? (it looks like it)
if so then this workaround works for me with both 2.0.7 and 2.0.9
- btw, you only need to change the "javax.ejb" project pom like so:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<configuration>
<instructions>
<Embed-Dependency>
javax.xml.rpc;inline=javax/xml/rpc/handler/*.class
</Embed-Dependency>
<Export-Package>
${extension.name}.*; version=${spec.version},
javax.interceptor.*; version=${spec.version},
javax.xml.rpc.handler;
version=${javax.xml.rpc.version}
</Export-Package>
<Private-Package>!*</Private-Package>
</instructions>
<!-- workaround for the manifest merging issue on 2.0.9
-->
<manifestLocation>${pom.build.directory}</manifestLocation>
<unpackBundle>true</unpackBundle>
</configuration>
<executions>
<execution>
<id>osgi-bundle</id>
<phase>package</phase>
<goals>
<goal>bundle</goal>
</goals>
</execution>
</executions>
</plugin>
thanks,
> -marina
>
> Stuart McCulloch wrote:
>
>> 2008/10/7 Marina Vatkina <[EMAIL PROTECTED]>
>>
>> Stuart McCulloch wrote:
>>>
>>>
>>> 2008/10/4 Marina Vatkina <[EMAIL PROTECTED]>
>>>>
>>>> I'm observing a different behavior of the felix plugin between maven
>>>>
>>>> 2.0.7
>>>>> and 2.0.9 in generating manifest file entries when embedding dependency
>>>>> from
>>>>> one jar into another. The contents of the jar stays the same.
>>>>>
>>>>> With maven 2.0.7 the following configuration correctly adds
>>>>> javax.xml.rpc.handler to the Export-Package entry in the manifest file,
>>>>> while with 2.0.9 the package is missing:
>>>>>
>>>>>
>>>>>
>>>> if it works with 2.0.7 but not with 2.0.9 (and everything else is
>>>> exactly
>>>> the same)
>>>> then that suggests something has changed in the Maven dependency
>>>> algorithm.
>>>> it could be a regression in Maven - but I'd need to investigate further
>>>> to
>>>> be sure...
>>>>
>>>> FYI, the complete set of changes in Maven 2.0.9 is available here:
>>>>
>>>> http://maven.apache.org/release-notes.html
>>>>
>>>>
>>> I can't find anything that can seem realted to my problem.
>>>
>>>
>>> and there are several updates and patches to the Maven dependency
>>>> mechanism.
>>>>
>>>> have you tried enabling debug trace with "mvn -X ..." and comparing the
>>>> 2
>>>> traces?
>>>> (this might then show if the dependency graph changes between 2.0.7 and
>>>> 2.0.9)
>>>>
>>>>
>>> I do have such outputs and they do not differ in the section that relates
>>> to the felix plugin. Are there any other sections that I can look at?
>>>
>>>
>>
>> actually I ran some local tests and there does appear to be a difference
>> between 2.0.7 and 2.0.9 when it comes to picking up a customized jar
>> manifest that's generated as part of the same build.
>>
>> (there's some code inside the bundle mojo that checks the settings for
>> the maven-jar-plugin so it can merge any customized manifest with the
>> bundle generated one - this feature was required by apache commons)
>>
>> looking at the GlassFish build pom for "javax.ejb" it uses jar packaging,
>> adds both the bundle and manifest goals, and sets the maven-jar-plugin
>> to use the generated manifest under "target/classes/META-INF/..."
>>
>> in 2.0.7 the manifest goal runs first and generates a manifest without
>> the "javax.xml.rpc.handler" (because Bnd for some reason isn't taking
>> the Include-Resource instruction into account - possibly because we
>> don't actually build the bundle but just analyze the classpath...)
>>
>> anyway, this generated manifest is _not_ picked up when the bundle
>> goal runs (possibly because of a bug in Maven wrt. detecting changes
>> to the build - I think this was one of the major changes in 2.0.9...) and
>> the final bundle has the correct manifest
>>
>> in 2.0.9 the same thing happens, except this time the bundle goal can
>> see the generated manifest (without the "javax.xml.rpc.handler" entry)
>> and merges it with the generated bundle manifest - unfortunately the
>> entries from the custom jar manifest take priority, and so the bundle
>> ends up with the incorrect Export-Package entry.
>>
>> getting the manifest and bundle goals aligned has been a rocky road
>> and it's still not an exact match as you can see - but I hope to sort
>> this out in the next release, as part of a push to improve usability
>>
>> for now there is a simple workaround you can use to fix the problem:
>>
>> <manifestLocation>${pom.build.directory}</manifestLocation>
>>
>> which means the bundleplugin will write the generated manifest from
>> the manifest goal in a different place (not "target/classes/META-INF")
>> and therefore this won't be picked up when the bundle goal runs.
>>
>> I've tested this locally and the build is the same on 2.0.7 and 2.0.9
>>
>> HTH
>>
>> thanks,
>>
>> -marina
>>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Cheers, Stuart
