You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Adrien Ragot <ad...@gmail.com> on 2011/11/03 05:37:56 UTC
Bundle-ClassPath is not read
Hi,
I'm trying to upgrade from maven-bundle-plugin 2.2.0 to 2.3.4 (they
both use Bnd-1.15.0), and I'm checking there is no regression in the
generated MANIFEST.MF.
As far as I can see, Import-Package is not calculated as I expected. I
suspect Bundle-ClassPath is not read anymore. Was there any change in
this revision?
I've written a small example:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.3.4</version>
<extensions>true</extensions>
<executions>
<execution>
<goals>
<goal>manifest</goal>
</goals>
</execution>
</executions>
<configuration>
<instructions>
<Export-Package>org.adrien.exprt;version="1.4.0-SNAPSHOT"</Export-Package>
<Bundle-ClassPath>.,lib/minimal-dependancy-1.4.0-SNAPSHOT.jar</Bundle-ClassPath>
</instructions>
</configuration>
</plugin>
- "minimal-dependancy.jar" contains a reference to "org.antlr.tool" so
I expect to see it in Import-Package.
- my artifact uses "org.adrien.imprted" from "minimal-dependancy.jar",
so I don't expect to see it in Import-Package.
Unfortunately:
Old Import-Package: org.adrien.exprt,org.antlr.analysis,org.antlr.tool
New Import-Package:
org.adrien.exprt;version="[1.4,2)",org.adrien.imprted,org.antlr.analysis
See the diff: https://bitbucket.org/aragot/discrepancywithbndlib/changeset/670d96221620
And the full example:
https://bitbucket.org/aragot/discrepancywithbndlib/src/670d96221620
-Does this mean Bundle-ClassPath is not read anymore and was something
changed in maven-bundle-plugin 2.3.4?
-Also, I wouldn't expect to see "org.adrien.exprt", because I
explicitly export it. Does anyone know why this class is imported?
Thank you very much,
Adrien
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle-ClassPath is not read
Posted by Stuart McCulloch <mc...@gmail.com>.
On 8 Nov 2011, at 00:25, Adrien Ragot wrote:
> Hi Stuart,
>
> Thank you very much for your dedication.
> Here is the bug I've submitted:
> https://issues.apache.org/jira/browse/FELIX-3206 .
> I've preemptively set the fix version to 2.3.6 so that it appears in
> your radar, feel free to change it if it's not your normal process.
No that's fine, the sooner I know about issues (and which release they're needed in) the sooner I can fix them - thanks for submitting that issue
> Feel free to change the contents too if you want to describe it
> further.
>
> Best regards,
> Adrien
>
>>> Is there a way to prevent BND from modifying the Bundle-ClassPath header we write?
>>> Can you foresee any drawback of using this method? Do you still want
>>> me to raise an issue?
>>
>> Tweaking the BND instructions so it builds (in memory) the same archive that you already have in order to get the right manifest will always be more fragile than simply taking the existing archive and generating a manifest.
>>
>> So please do open an issue describing this use-case, then I can bring back the old behaviour and introduce a switch to toggle between the two behaviours.
>>
>>> Thank you,
>>> Adrien
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
>
>
> --
> Adrien Ragot
> +61 (0)4 49 206 878
>
> ---------------------------------------------------------------------
> 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: Bundle-ClassPath is not read
Posted by Adrien Ragot <ad...@gmail.com>.
Hi Stuart,
Thank you very much for your dedication.
Here is the bug I've submitted:
https://issues.apache.org/jira/browse/FELIX-3206 .
I've preemptively set the fix version to 2.3.6 so that it appears in
your radar, feel free to change it if it's not your normal process.
Feel free to change the contents too if you want to describe it
further.
Best regards,
Adrien
>> Is there a way to prevent BND from modifying the Bundle-ClassPath header we write?
>> Can you foresee any drawback of using this method? Do you still want
>> me to raise an issue?
>
> Tweaking the BND instructions so it builds (in memory) the same archive that you already have in order to get the right manifest will always be more fragile than simply taking the existing archive and generating a manifest.
>
> So please do open an issue describing this use-case, then I can bring back the old behaviour and introduce a switch to toggle between the two behaviours.
>
>> Thank you,
>> Adrien
>>
>> ---------------------------------------------------------------------
>> 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
>
>
--
Adrien Ragot
+61 (0)4 49 206 878
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle-ClassPath is not read
Posted by Stuart McCulloch <mc...@gmail.com>.
On 7 Nov 2011, at 01:04, Adrien Ragot wrote:
> On Thu, Nov 3, 2011 at 11:56 PM, Stuart McCulloch <mc...@gmail.com> wrote:
>> On 3 Nov 2011, at 04:37, Adrien Ragot wrote:
>>
>>> Hi,
>>>
>>> I'm trying to upgrade from maven-bundle-plugin 2.2.0 to 2.3.4 (they
>>> both use Bnd-1.15.0), and I'm checking there is no regression in the
>>> generated MANIFEST.MF.
>>> As far as I can see, Import-Package is not calculated as I expected. I
>>> suspect Bundle-ClassPath is not read anymore. Was there any change in
>>> this revision?
>>
>> The main change affecting the manifest goal between 2.2.0 and 2.3.4 was to use the "supportedProjectTypes" parameter to decide whether to use the BND builder approach (which uses the given instructions to assemble the content and in doing so generates the manifest) versus using the BND analyzer approach (which looks for an existing archive attached to the project and extrapolates the manifest from its contents). The difference in the final manifest is all to do with how these two approaches analyze the project classpath. For example, since there's no instruction to include the dependency jar mentioned in the Bundle-ClassPath in the bundle and that jar is not located relative to the project,
>
> Is there a way to do it?
> My only goal is to write the manifest. We don't use BND's builder, we
> just use it to create the archive.
>
> As I understand, this would make BND consider all Maven dependencies
> are part of the classpath to analyze. If I want to strictly keep the
> former manifest, I can get rid of the Embed-Dependency header using
> _removeheaders:
>
> <Embed-Dependency>*;scope=compile|runtime</Embed-Dependency>
> <_removeheaders>Include-Resource,Private-Package,Embed-Dependency</_removeheaders>
> (and no Bundle-ClassPath anymore)
>
> The drawback is it writes the Bundle-ClassPath differently (it writes
> myjar.jar, instead of our WEB-INF/lib/myjar.jar).
Note you can use Embed-Directory to put the dependency under a specific directory, and Embed-StripVersion to remove the version.
There is also the -wab instruction (or <_wab> in XML) which adds WEB-INF/classes to the bundle classpath instead of the default "."
> Is there a way to prevent BND from modifying the Bundle-ClassPath header we write?
> Can you foresee any drawback of using this method? Do you still want
> me to raise an issue?
Tweaking the BND instructions so it builds (in memory) the same archive that you already have in order to get the right manifest will always be more fragile than simply taking the existing archive and generating a manifest.
So please do open an issue describing this use-case, then I can bring back the old behaviour and introduce a switch to toggle between the two behaviours.
> Thank you,
> Adrien
>
> ---------------------------------------------------------------------
> 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: Bundle-ClassPath is not read
Posted by Adrien Ragot <ad...@gmail.com>.
On Thu, Nov 3, 2011 at 11:56 PM, Stuart McCulloch <mc...@gmail.com> wrote:
> On 3 Nov 2011, at 04:37, Adrien Ragot wrote:
>
>> Hi,
>>
>> I'm trying to upgrade from maven-bundle-plugin 2.2.0 to 2.3.4 (they
>> both use Bnd-1.15.0), and I'm checking there is no regression in the
>> generated MANIFEST.MF.
>> As far as I can see, Import-Package is not calculated as I expected. I
>> suspect Bundle-ClassPath is not read anymore. Was there any change in
>> this revision?
>
> The main change affecting the manifest goal between 2.2.0 and 2.3.4 was to use the "supportedProjectTypes" parameter to decide whether to use the BND builder approach (which uses the given instructions to assemble the content and in doing so generates the manifest) versus using the BND analyzer approach (which looks for an existing archive attached to the project and extrapolates the manifest from its contents). The difference in the final manifest is all to do with how these two approaches analyze the project classpath. For example, since there's no instruction to include the dependency jar mentioned in the Bundle-ClassPath in the bundle and that jar is not located relative to the project,
Is there a way to do it?
My only goal is to write the manifest. We don't use BND's builder, we
just use it to create the archive.
As I understand, this would make BND consider all Maven dependencies
are part of the classpath to analyze. If I want to strictly keep the
former manifest, I can get rid of the Embed-Dependency header using
_removeheaders:
<Embed-Dependency>*;scope=compile|runtime</Embed-Dependency>
<_removeheaders>Include-Resource,Private-Package,Embed-Dependency</_removeheaders>
(and no Bundle-ClassPath anymore)
The drawback is it writes the Bundle-ClassPath differently (it writes
myjar.jar, instead of our WEB-INF/lib/myjar.jar). Is there a way to
prevent BND from modifying the Bundle-ClassPath header we write?
Can you foresee any drawback of using this method? Do you still want
me to raise an issue?
Thank you,
Adrien
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle-ClassPath is not read
Posted by Stuart McCulloch <mc...@gmail.com>.
On 3 Nov 2011, at 04:37, Adrien Ragot wrote:
> Hi,
>
> I'm trying to upgrade from maven-bundle-plugin 2.2.0 to 2.3.4 (they
> both use Bnd-1.15.0), and I'm checking there is no regression in the
> generated MANIFEST.MF.
> As far as I can see, Import-Package is not calculated as I expected. I
> suspect Bundle-ClassPath is not read anymore. Was there any change in
> this revision?
The main change affecting the manifest goal between 2.2.0 and 2.3.4 was to use the "supportedProjectTypes" parameter to decide whether to use the BND builder approach (which uses the given instructions to assemble the content and in doing so generates the manifest) versus using the BND analyzer approach (which looks for an existing archive attached to the project and extrapolates the manifest from its contents). The difference in the final manifest is all to do with how these two approaches analyze the project classpath. For example, since there's no instruction to include the dependency jar mentioned in the Bundle-ClassPath in the bundle and that jar is not located relative to the project, the builder approach decides to ignore that entry (note it does actually produce a warning, but this is only reported in the latest snapshot of the bundleplugin). On the other hand, the analyzer approach can find it in the attached archive, because it only looks at the end result and doesn't attempt to apply the instructions to the original project.
The JIRA issue for this change was https://issues.apache.org/jira/browse/FELIX-2817 ... unfortunately the background leading up to this change is missing, but perhaps Hiram Chirino can fill in the details since he made the commit. IIRC it was something to do with making the manifest goal behave similar to the bundle goal, so you'd get the same results as if you'd used the bundle goal on the same project.
Unfortunately you can't use "supportedProjectTypes" to get the old behaviour back, since removing the project type from that list will just end up skipping the manifest goal (this is because "supportedProjectTypes" was originally meant as a way to let you decide which projects to run bundleplugin goals on).
We could easily change this back to the old behaviour, and instead provide a new explicit parameter to use the BND builder approach rather than attempt to guess what the developer wants. In some respect there are two use cases - one to create the manifest for a project before the artifact has been created, and one to create a manifest for an existing artifact.
Could you open an issue at https://issues.apache.org/jira/browse/FELIX/component/12311143 ? The next release is not far away, so the sooner the better :)
> I've written a small example:
>
> <plugin>
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-bundle-plugin</artifactId>
> <version>2.3.4</version>
> <extensions>true</extensions>
> <executions>
> <execution>
> <goals>
> <goal>manifest</goal>
> </goals>
> </execution>
> </executions>
> <configuration>
> <instructions>
>
> <Export-Package>org.adrien.exprt;version="1.4.0-SNAPSHOT"</Export-Package>
>
> <Bundle-ClassPath>.,lib/minimal-dependancy-1.4.0-SNAPSHOT.jar</Bundle-ClassPath>
> </instructions>
> </configuration>
> </plugin>
>
> - "minimal-dependancy.jar" contains a reference to "org.antlr.tool" so
> I expect to see it in Import-Package.
> - my artifact uses "org.adrien.imprted" from "minimal-dependancy.jar",
> so I don't expect to see it in Import-Package.
>
> Unfortunately:
> Old Import-Package: org.adrien.exprt,org.antlr.analysis,org.antlr.tool
> New Import-Package:
> org.adrien.exprt;version="[1.4,2)",org.adrien.imprted,org.antlr.analysis
>
> See the diff: https://bitbucket.org/aragot/discrepancywithbndlib/changeset/670d96221620
> And the full example:
> https://bitbucket.org/aragot/discrepancywithbndlib/src/670d96221620
>
> -Does this mean Bundle-ClassPath is not read anymore and was something
> changed in maven-bundle-plugin 2.3.4?
> -Also, I wouldn't expect to see "org.adrien.exprt", because I
> explicitly export it. Does anyone know why this class is imported?
>
> Thank you very much,
> Adrien
>
> ---------------------------------------------------------------------
> 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