You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Costin Leau <co...@gmail.com> on 2007/05/09 13:56:39 UTC
resource filtering and bundle packaging
Hi,
I'm not sure if it's me but I've noticed that resource filtering doesn't
work any more if bundle packaging is used.
If I have a file inside src/main/resources with a property:
Hello ${name}, with bundle packaging, the 'unexpanded' version is
included in the jar while the expanded version (Hello this is the name)
from target/classes is ignored.
Cheers,
--
Costin
Re: resource filtering and bundle packaging
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Stuart McCulloch wrote:
> actually the patch alin submitted was my original suggestion ;)
>
> the benefit of using the target files is that what you get matches
> what you'd expect coming from maven, and so makes it easier to
> convert an existing project to OSGi - but as you say, it means the
> bundle plugin is less in control.
>
> if you copy the source of the <resources/> files then you'd get the
> unfiltered files - question is should the plugin then add {...} brackets
> automatically to those files that *would* be filtered by maven?
Yes, definitely, in my opinion.
> whichever solution gets chosen (ie. no resources, source resources
> or target resources) we should make it really clear on the plugin page
> so users know what to expect
Agreed.
>
> PS, afaik BND uses a 'pull' approach, so at the moment it would
> be pulling in the resources directly rather than overwriting files in
> the maven target/classes folder
You could be right, I don't really know.
> PPS, ironically I tend to use the <resources/> setting to filter BND
> config files so I can use them outside of maven - including them in
> the bundle means I know how it was configured ;)
I guess you could still have BND include its own file as a resource... :-)
-> richard
>
> On 13/05/07, Richard S. Hall <he...@ungoverned.org> wrote:
>> I think this situation is not so straightforward.
>>
>> The issue that we face here is that we have two different actors trying
>> to control what gets included in the resulting bundle JAR file, i.e.,
>> BND and Maven.
>>
>> It is not the case that BND copies the raw resources, the issue is that
>> BND is probably overwriting the copied resources when generating the
>> bundle content because it defaults to "src/main/resources" like Maven
>> without property substitution. You can tell BND to use property
>> substitution too (e.g., "{src/main/resources}"), then it might work the
>> way that you want.
>>
>> Ultimately, I would argue that users of maven-bundle-plugin should let
>> the plugin (i.e., BND) be in control of defining the content of the JAR
>> and to not use Maven's facilities at all for class or resource
>> inclusion. This means that the content of the JAR file would be
>> completely discernible from <Private-Package>, <Export-Package>, and
>> <Include-Resource>.
>>
>> I agree that we could perhaps come up with a better default value for
>> <Include-Resource>, which could suck in the values of <resources/>, so
>> that way if people do use it they get closer to what they are expecting.
>> This is essentially the patch that Alin submitted in the body of
>> FELIX-261. I would, however, argue against the patch submitted by
>> Stuart, since this appears to convert the resources into the target
>> directories, which then relies on Maven copying them in there, when BND
>> already has that capability.
>>
>> Obviously, this is not a clear cut situation, but from my point of view
>> we should encourage users of the plugin to rely on the plugin for all of
>> their needs as the proper way of using it. In the end, this will be
>> beneficial if they ever need to change their build to use BND stand
>> alone or use it with the Ant task, because the <instructions> will be
>> self-contained.
>>
>> -> richard
>>
>> Stuart McCulloch wrote:
>> > Yep - the current snapshot of the bundle-plugin adds
>> 'src/main/resources'
>> > to the BND directives using Include-Resource, instead of using the
>> target
>> > path which has the filtered files.
>> >
>> > There's an open bug
>> (http://issues.apache.org/jira/browse/FELIX-261) to
>> > address this issue, and also use maven configured resources instead of
>> > a hard-coded location - see patch attached to FELIX-261.
>> >
>> > I've been using this patch in the OPS4J branch of the bundle plugin
>> (used
>> > for testing patches and new features) and it seems to work ok, but
>> would
>> > appreciate if someone from Maven (Carlos?) could check it over.
>> >
>> > Until then, workaround is to provide your own Include-Resource
>> setting :(
>> >
>> > On 09/05/07, Costin Leau <co...@gmail.com> wrote:
>> >> Hi,
>> >>
>> >> I'm not sure if it's me but I've noticed that resource filtering
>> doesn't
>> >> work any more if bundle packaging is used.
>> >>
>> >> If I have a file inside src/main/resources with a property:
>> >> Hello ${name}, with bundle packaging, the 'unexpanded' version is
>> >> included in the jar while the expanded version (Hello this is the
>> name)
>> >> from target/classes is ignored.
>> >>
>> >>
>> >> Cheers,
>> >> --
>> >> Costin
>> >>
>> >
>> >
>>
>
>
Re: resource filtering and bundle packaging
Posted by Stuart McCulloch <st...@jayway.net>.
actually the patch alin submitted was my original suggestion ;)
the benefit of using the target files is that what you get matches
what you'd expect coming from maven, and so makes it easier to
convert an existing project to OSGi - but as you say, it means the
bundle plugin is less in control.
if you copy the source of the <resources/> files then you'd get the
unfiltered files - question is should the plugin then add {...} brackets
automatically to those files that *would* be filtered by maven?
( if it didn't then this could be just as confusing to new users )
whichever solution gets chosen (ie. no resources, source resources
or target resources) we should make it really clear on the plugin page
so users know what to expect
PS, afaik BND uses a 'pull' approach, so at the moment it would
be pulling in the resources directly rather than overwriting files in
the maven target/classes folder
PPS, ironically I tend to use the <resources/> setting to filter BND
config files so I can use them outside of maven - including them in
the bundle means I know how it was configured ;)
On 13/05/07, Richard S. Hall <he...@ungoverned.org> wrote:
> I think this situation is not so straightforward.
>
> The issue that we face here is that we have two different actors trying
> to control what gets included in the resulting bundle JAR file, i.e.,
> BND and Maven.
>
> It is not the case that BND copies the raw resources, the issue is that
> BND is probably overwriting the copied resources when generating the
> bundle content because it defaults to "src/main/resources" like Maven
> without property substitution. You can tell BND to use property
> substitution too (e.g., "{src/main/resources}"), then it might work the
> way that you want.
>
> Ultimately, I would argue that users of maven-bundle-plugin should let
> the plugin (i.e., BND) be in control of defining the content of the JAR
> and to not use Maven's facilities at all for class or resource
> inclusion. This means that the content of the JAR file would be
> completely discernible from <Private-Package>, <Export-Package>, and
> <Include-Resource>.
>
> I agree that we could perhaps come up with a better default value for
> <Include-Resource>, which could suck in the values of <resources/>, so
> that way if people do use it they get closer to what they are expecting.
> This is essentially the patch that Alin submitted in the body of
> FELIX-261. I would, however, argue against the patch submitted by
> Stuart, since this appears to convert the resources into the target
> directories, which then relies on Maven copying them in there, when BND
> already has that capability.
>
> Obviously, this is not a clear cut situation, but from my point of view
> we should encourage users of the plugin to rely on the plugin for all of
> their needs as the proper way of using it. In the end, this will be
> beneficial if they ever need to change their build to use BND stand
> alone or use it with the Ant task, because the <instructions> will be
> self-contained.
>
> -> richard
>
> Stuart McCulloch wrote:
> > Yep - the current snapshot of the bundle-plugin adds 'src/main/resources'
> > to the BND directives using Include-Resource, instead of using the target
> > path which has the filtered files.
> >
> > There's an open bug (http://issues.apache.org/jira/browse/FELIX-261) to
> > address this issue, and also use maven configured resources instead of
> > a hard-coded location - see patch attached to FELIX-261.
> >
> > I've been using this patch in the OPS4J branch of the bundle plugin (used
> > for testing patches and new features) and it seems to work ok, but would
> > appreciate if someone from Maven (Carlos?) could check it over.
> >
> > Until then, workaround is to provide your own Include-Resource setting :(
> >
> > On 09/05/07, Costin Leau <co...@gmail.com> wrote:
> >> Hi,
> >>
> >> I'm not sure if it's me but I've noticed that resource filtering doesn't
> >> work any more if bundle packaging is used.
> >>
> >> If I have a file inside src/main/resources with a property:
> >> Hello ${name}, with bundle packaging, the 'unexpanded' version is
> >> included in the jar while the expanded version (Hello this is the name)
> >> from target/classes is ignored.
> >>
> >>
> >> Cheers,
> >> --
> >> Costin
> >>
> >
> >
>
--
Cheers, Stuart
Re: resource filtering and bundle packaging
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I think this situation is not so straightforward.
The issue that we face here is that we have two different actors trying
to control what gets included in the resulting bundle JAR file, i.e.,
BND and Maven.
It is not the case that BND copies the raw resources, the issue is that
BND is probably overwriting the copied resources when generating the
bundle content because it defaults to "src/main/resources" like Maven
without property substitution. You can tell BND to use property
substitution too (e.g., "{src/main/resources}"), then it might work the
way that you want.
Ultimately, I would argue that users of maven-bundle-plugin should let
the plugin (i.e., BND) be in control of defining the content of the JAR
and to not use Maven's facilities at all for class or resource
inclusion. This means that the content of the JAR file would be
completely discernible from <Private-Package>, <Export-Package>, and
<Include-Resource>.
I agree that we could perhaps come up with a better default value for
<Include-Resource>, which could suck in the values of <resources/>, so
that way if people do use it they get closer to what they are expecting.
This is essentially the patch that Alin submitted in the body of
FELIX-261. I would, however, argue against the patch submitted by
Stuart, since this appears to convert the resources into the target
directories, which then relies on Maven copying them in there, when BND
already has that capability.
Obviously, this is not a clear cut situation, but from my point of view
we should encourage users of the plugin to rely on the plugin for all of
their needs as the proper way of using it. In the end, this will be
beneficial if they ever need to change their build to use BND stand
alone or use it with the Ant task, because the <instructions> will be
self-contained.
-> richard
Stuart McCulloch wrote:
> Yep - the current snapshot of the bundle-plugin adds 'src/main/resources'
> to the BND directives using Include-Resource, instead of using the target
> path which has the filtered files.
>
> There's an open bug (http://issues.apache.org/jira/browse/FELIX-261) to
> address this issue, and also use maven configured resources instead of
> a hard-coded location - see patch attached to FELIX-261.
>
> I've been using this patch in the OPS4J branch of the bundle plugin (used
> for testing patches and new features) and it seems to work ok, but would
> appreciate if someone from Maven (Carlos?) could check it over.
>
> Until then, workaround is to provide your own Include-Resource setting :(
>
> On 09/05/07, Costin Leau <co...@gmail.com> wrote:
>> Hi,
>>
>> I'm not sure if it's me but I've noticed that resource filtering doesn't
>> work any more if bundle packaging is used.
>>
>> If I have a file inside src/main/resources with a property:
>> Hello ${name}, with bundle packaging, the 'unexpanded' version is
>> included in the jar while the expanded version (Hello this is the name)
>> from target/classes is ignored.
>>
>>
>> Cheers,
>> --
>> Costin
>>
>
>
Re: resource filtering and bundle packaging
Posted by Stuart McCulloch <st...@jayway.net>.
Yep - the current snapshot of the bundle-plugin adds 'src/main/resources'
to the BND directives using Include-Resource, instead of using the target
path which has the filtered files.
There's an open bug (http://issues.apache.org/jira/browse/FELIX-261) to
address this issue, and also use maven configured resources instead of
a hard-coded location - see patch attached to FELIX-261.
I've been using this patch in the OPS4J branch of the bundle plugin (used
for testing patches and new features) and it seems to work ok, but would
appreciate if someone from Maven (Carlos?) could check it over.
Until then, workaround is to provide your own Include-Resource setting :(
On 09/05/07, Costin Leau <co...@gmail.com> wrote:
> Hi,
>
> I'm not sure if it's me but I've noticed that resource filtering doesn't
> work any more if bundle packaging is used.
>
> If I have a file inside src/main/resources with a property:
> Hello ${name}, with bundle packaging, the 'unexpanded' version is
> included in the jar while the expanded version (Hello this is the name)
> from target/classes is ignored.
>
>
> Cheers,
> --
> Costin
>
--
Cheers, Stuart