Richard,
The below test does not replicate the original result because it does not
imitate the original behavior.
In the original bug, the ${pom.version} was set to "0.04-SNAPSHOT". The
<Bundle-Version>, <Import-Package>, and the <Export-Package> sections of the
maven-bundle-plugin were all present, but empty.
In the resulting bundle, the following was in the MANIFEST.MF file:
>>> In the Export-Package section of the MANIFEST.MF file, the number is
>>> resolved to "0.04.0.SNAPSHOT", which is the expected behavior.
>>>
>>>
>>>
>>> In the Import-Package section of the MANIFEST.MF file, all of the bundles
>>> packages are imported with version "0.4". This creates an unresolved
>>> constraint violation upon deployment.
It should be noted that the Bundle-Version was set to "0.04.0.SNAPSHOT" in the
MANIFEST.MF file.
v/r,
Mike Van
----- Original Message -----
From: "Richard S. Hall" <[email protected]>
To: [email protected]
Sent: Tuesday, October 26, 2010 3:32:12 PM
Subject: Re: possible bug in maven-bundle-plugin
On 10/26/10 11:54, [email protected] wrote:
>
> When attempting to deploy the bundle from a features.xml file, the deploy
> directory, or from the command-line, the unresolved constraint error is
> exhibited.
Must be something else going on, because this works for me:
g! lb
START LEVEL 1
ID|State |Level|Name
0|Active | 0|System Bundle (3.1.0.SNAPSHOT)
1|Active | 1|Apache Felix Bundle Repository (1.6.2)
2|Active | 1|Apache Felix Gogo Command (0.7.0.SNAPSHOT)
3|Active | 1|Apache Felix Gogo Runtime (0.6.1)
4|Active | 1|Apache Felix Gogo Shell (0.6.1)
5|Installed | 1|exporter (0.0.0)
6|Installed | 1|importer (0.0.0)
g! headers 5 6
Bundle 5
--------
Bundle-ManifestVersion = 2
Bundle-SymbolicName = exporter
Created-By = 1.6.0_22 (Apple Inc.)
Export-Package = org.foo; version=0.04.0.SNAPSHOT
Manifest-Version = 1.0
Bundle 6
--------
Bundle-ManifestVersion = 2
Bundle-SymbolicName = importer
Created-By = 1.6.0_22 (Apple Inc.)
Import-Package = org.foo; version=0.4
Manifest-Version = 1.0
g! resolve 6
DEBUG: WIRE: [6.0] package; (&(package=org.foo)(version>=0.4.0)) -> [5.0]
g!
-> richard
>
>
> v/r,
>
>
>
> Mike Van
>
>
> ----- Original Message -----
> From: "Richard S. Hall"<[email protected]>
> To: [email protected]
> Sent: Tuesday, October 26, 2010 9:37:25 AM
> Subject: Re: possible bug in maven-bundle-plugin
>
>
>
> On 10/26/10 3:08, Peter Kriens wrote:
>> I think this is a framework error :-) The parts of the versions are integers
>> this 04 == 4. So 0.04.0.SNAPSHOT>= 0.4
> Yeah, actually, that didn't even dawn on me. How/when are you getting an
> unresolved constraint?
>
> -> richard
>
>> But I can add a feature to bnd to cleanup the import version. I am already
>> doing this for getting rid of the - sign and other mavenisms.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>> On 22 okt 2010, at 22:48, [email protected] wrote:
>>
>>> All,
>>>
>>>
>>>
>>> A project I'm working with is using a very minimalist implementation of the
>>> maven bundle plugin that relies on the maven-bundle-plugin to use the
>>> default version of the bundle for<Bundle-Version>(whatever the pom.version
>>> property is set to). In this case, the version is 0.04-SNAPSHOT.
>>>
>>>
>>>
>>> In the Export-Package section of the MANIFEST.MF file, the number is
>>> resolved to "0.04.0.SNAPSHOT", which is the expected behavior.
>>>
>>>
>>>
>>> In the Import-Package section of the MANIFEST.MF file, all of the bundles
>>> packages are imported with version "0.4". This creates an unresolved
>>> constraint violation upon deployment.
>>>
>>>
>>>
>>> I have spoken with the project, and they will be using "0.4-SNAPSHOT" as
>>> thier pom.version. However, this is a workaround, and there still appears
>>> to be a bug in the plugin or in the BND library.
>>>
>>>
>>>
>>>
>>>
>>> v/r,
>>>
>>>
>>>
>>> Mike Van
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
