some maven felix bugs/improvements

[Costin Leau <co...@gmail.com>]

Hi guys,

Using the felix-maven-plugin for Spring/OSGi released, I discovered
several 'unwanted' and missing features. I'm not sure whether they
belong to the bnd jar or the maven plugin.

1. Extra manifest entries

I've discovered that when a MANIFEST.MF is available inside the project,
it's entries are copied to generated manifest. I find this useful since
it allows me to specify Dynamic imports.
However, I've found that if Include resources is used, this doesn't work
any more.

What's the official, supported way of working with it?

2. Defaults/empty properties

Inside our project, we use a lot of properties so that submodules can
customize the plugin w/o redefining it again. However, it's impossible
to 'erase'/reset settings to their defaults.

<properties> <myImportPackage>package</myImportPackage> </properties>
...

<Import-Package>${myImportPackage}</Import-Package>

If a submodule erases myImportPackage:
<myImportPackage></myImportPackage>

then a NPE is thrown by bnd tool. It would be nice if null & empty
strings should be considered defaults.

3. Include and -

Bnd tool allow include to specify several files and allows a - to
indicate that it's okay if the file is missing. However, the maven
plugin doesn't like that, it will complain if the file is missing.

<_include>-missing/file.txt</_include>


4. Import versions

The import versions are determined automatically and can't be
overridden. For example inside Spring/OSGi, we import spring 2.0.5 and
the resulting imports have version 2.0.
We want to be more specific such as 2.0.5 or [2.0.5, 2.1) but whatever I
specify as import package is completely ignored.


5. Import-Resource

Besides allowing it to work alongside 1), it would be nice if the
resources found inside the classpath could be copied automatically. This
might be difficult, I realize, but at least some patterns might be used.

I'll add also the ability to use the filtered/processed resource and not
the 'raw' one (see the 'resource filtering and bundle packaging' email
sent 2 days ago to the list).

Thanks and looking forward to a new version of the plugin.

It took a while to get it into our project but I think it was worth it.
Too bad Maven made the task way more difficult then it had to be.

Cheers,
-- 
Costin

Re: some maven felix bugs/improvements

["Steven E. Harris" <se...@panix.com>]

Costin Leau <co...@gmail.com> writes:

> Sure, I'll do this right away after getting Spring/OSGi 1.0-m2 out
> the door.

Your #2 problem regarding empty directives is at least partially
addressed by the just-filed FELIX-281:

  http://issues.apache.org/jira/browse/FELIX-281

I happened to run into the same problem this morning.

-- 
Steven E. Harris

Re: some maven felix bugs/improvements

[Costin Leau <co...@gmail.com>]

Stuart McCulloch wrote:
> Hi Costin,
> 
> thanks - can you open issues at http://issues.apache.org/jira/browse/FELIX
> for "Maven Bundle Plugin" component, so these features can be tracked :)
> 
Sure, I'll do this right away after getting Spring/OSGi 1.0-m2 out the door.


> On 11/05/07, Costin Leau <co...@gmail.com> wrote:
>> Hi guys,
>>
>> Using the felix-maven-plugin for Spring/OSGi released, I discovered
>> several 'unwanted' and missing features. I'm not sure whether they
>> belong to the bnd jar or the maven plugin.
>>
>> 1. Extra manifest entries
>>
>> I've discovered that when a MANIFEST.MF is available inside the project,
>> it's entries are copied to generated manifest. I find this useful since
>> it allows me to specify Dynamic imports.
>> However, I've found that if Include resources is used, this doesn't work
>> any more.
>>
> 
> I think this is related to #5 - at the moment the bundle plugin adds
> an Include-Resource entry for 'src/main/resources' which may be
> picking up your manifest file - adding your own Include-Resource
> setting probably overrides this, so it doesn't see it anymore.
> 
> This can be addressed in FELIX-261 ... get the plugin to append
> maven resource entries with any bnd file specified properties?
> 
>> What's the official, supported way of working with it?
>>
>> 2. Defaults/empty properties
>>
>> Inside our project, we use a lot of properties so that submodules can
>> customize the plugin w/o redefining it again. However, it's impossible
>> to 'erase'/reset settings to their defaults.
>>
>> <properties> <myImportPackage>package</myImportPackage> </properties>
>> ...
>>
>> <Import-Package>${myImportPackage}</Import-Package>
>>
>> If a submodule erases myImportPackage:
>> <myImportPackage></myImportPackage>
>>
>> then a NPE is thrown by bnd tool. It would be nice if null & empty
>> strings should be considered defaults.
>>
> 
> This would be a maven-bundle-plugin fix - should be simple.
> 
>> 3. Include and -
>>
>> Bnd tool allow include to specify several files and allows a - to
>> indicate that it's okay if the file is missing. However, the maven
>> plugin doesn't like that, it will complain if the file is missing.
>>
>> <_include>-missing/file.txt</_include>
>>
> 
> this looks like a bug in BND - there's a line in the analyzer that says:
> 
>    if ( noFileOk ) ... throw error...
> 
> so at the moment it only throws an error for missing files when they
> *are* prefixed with a '-', ie. the other way round to the documentation
> 
> I'll raise this with Peter.
> 
>>
>> 4. Import versions
>>
>> The import versions are determined automatically and can't be
>> overridden. For example inside Spring/OSGi, we import spring 2.0.5 and
>> the resulting imports have version 2.0.
>> We want to be more specific such as 2.0.5 or [2.0.5, 2.1) but whatever I
>> specify as import package is completely ignored.
>>
> 
> I think this is a BND issue again, will raise it with Peter.
> 
>>
>> 5. Import-Resource
>>
>> Besides allowing it to work alongside 1), it would be nice if the
>> resources found inside the classpath could be copied automatically. This
>> might be difficult, I realize, but at least some patterns might be used.
>>
> 
> This one needs some thinking - the BND tool has a 'pull' approach, which
> means it only includes what you ask it to include. This is great for doing
> different builds from the same classpath, but means u need to be specific.
> 
> If this was added, would probably be a non-default option.
> 
>> I'll add also the ability to use the filtered/processed resource and not
>> the 'raw' one (see the 'resource filtering and bundle packaging' email
>> sent 2 days ago to the list).
>>
> 
> vote for FELIX-261 ;)
> 
>> Thanks and looking forward to a new version of the plugin.
>>
>> It took a while to get it into our project but I think it was worth it.
>> Too bad Maven made the task way more difficult then it had to be.
>>
>> Cheers,
>> -- 
>> Costin
>>
> 
> 


-- 
Costin

Re: some maven felix bugs/improvements

[Stuart McCulloch <st...@jayway.net>]

Hi Costin,

thanks - can you open issues at http://issues.apache.org/jira/browse/FELIX
for "Maven Bundle Plugin" component, so these features can be tracked :)

On 11/05/07, Costin Leau <co...@gmail.com> wrote:
> Hi guys,
>
> Using the felix-maven-plugin for Spring/OSGi released, I discovered
> several 'unwanted' and missing features. I'm not sure whether they
> belong to the bnd jar or the maven plugin.
>
> 1. Extra manifest entries
>
> I've discovered that when a MANIFEST.MF is available inside the project,
> it's entries are copied to generated manifest. I find this useful since
> it allows me to specify Dynamic imports.
> However, I've found that if Include resources is used, this doesn't work
> any more.
>

I think this is related to #5 - at the moment the bundle plugin adds
an Include-Resource entry for 'src/main/resources' which may be
picking up your manifest file - adding your own Include-Resource
setting probably overrides this, so it doesn't see it anymore.

This can be addressed in FELIX-261 ... get the plugin to append
maven resource entries with any bnd file specified properties?

> What's the official, supported way of working with it?
>
> 2. Defaults/empty properties
>
> Inside our project, we use a lot of properties so that submodules can
> customize the plugin w/o redefining it again. However, it's impossible
> to 'erase'/reset settings to their defaults.
>
> <properties> <myImportPackage>package</myImportPackage> </properties>
> ...
>
> <Import-Package>${myImportPackage}</Import-Package>
>
> If a submodule erases myImportPackage:
> <myImportPackage></myImportPackage>
>
> then a NPE is thrown by bnd tool. It would be nice if null & empty
> strings should be considered defaults.
>

This would be a maven-bundle-plugin fix - should be simple.

> 3. Include and -
>
> Bnd tool allow include to specify several files and allows a - to
> indicate that it's okay if the file is missing. However, the maven
> plugin doesn't like that, it will complain if the file is missing.
>
> <_include>-missing/file.txt</_include>
>

this looks like a bug in BND - there's a line in the analyzer that says:

    if ( noFileOk ) ... throw error...

so at the moment it only throws an error for missing files when they
*are* prefixed with a '-', ie. the other way round to the documentation

I'll raise this with Peter.

>
> 4. Import versions
>
> The import versions are determined automatically and can't be
> overridden. For example inside Spring/OSGi, we import spring 2.0.5 and
> the resulting imports have version 2.0.
> We want to be more specific such as 2.0.5 or [2.0.5, 2.1) but whatever I
> specify as import package is completely ignored.
>

I think this is a BND issue again, will raise it with Peter.

>
> 5. Import-Resource
>
> Besides allowing it to work alongside 1), it would be nice if the
> resources found inside the classpath could be copied automatically. This
> might be difficult, I realize, but at least some patterns might be used.
>

This one needs some thinking - the BND tool has a 'pull' approach, which
means it only includes what you ask it to include. This is great for doing
different builds from the same classpath, but means u need to be specific.

If this was added, would probably be a non-default option.

> I'll add also the ability to use the filtered/processed resource and not
> the 'raw' one (see the 'resource filtering and bundle packaging' email
> sent 2 days ago to the list).
>

vote for FELIX-261 ;)

> Thanks and looking forward to a new version of the plugin.
>
> It took a while to get it into our project but I think it was worth it.
> Too bad Maven made the task way more difficult then it had to be.
>
> Cheers,
> --
> Costin
>


-- 
Cheers, Stuart