You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Peter Kriens <Pe...@aQute.biz> on 2007/03/23 10:04:16 UTC
Re[2]: maven-bundle-plugin, Include-Resource and src/main/resources
I think the discussion is progressing along nicely ... :-)
Resource folders
I understood Maven standardized the resource folder so that is why
the resource folder is hard coded. If you can specify additional
folders, then the plugin should automatically append these to the
Include-Resource header if this is not set. This should -not- be
optional if this is what maven specifies.
Export of non-java packages
I never envisioned anybody using * for Export-Package ... that
seems a bit random to me, I am sure it would hurt me if I used it. As
I argued before, packing a bundle is part of the design of your
system. The fact that you get META-INF/spring as an exported package
is a consequence of this export all strategy. I think bnd contains
more than enough flexibility to solve the problem, as is shown by
excluding sub-packages from META-INF with the ! operator. The fact
that it looks ugly caused by the fact that you do not want to specify
the packages that you designed to be inside the bundle but rely on the
classpath.
3. The warning that you get looks wrong, the ! should not be in the
expansion of the pattern. I'll check that out.
I am -very- reluctant to add options for these special cases
because in my experience it makes the tool over time a monster in
complexity. Even people that do not use have to understand these
options to not use them ... It is usually the easy way out to just add
options because it makes people happy and the others do not care.
However, newcomers have a tendency to be put off by the myriad of
options for special cases.
So I think bnd can do what you want and it would be wrong to add extra
options only to make the manifest look more pleasing in a case
that I think is not a good practice ...
Kind regards,
Peter Kriens
AD> On 3/23/07, Stuart McCulloch <st...@jayway.net> wrote:
>>
>> On 23/03/07, Alin Dreghiciu <ad...@gmail.com> wrote:
>> > Just checked out and if I use:
>> >
>> > <Export-Package>
>> > !META-INF.*,
>> > *
>> > </Export-Package>
>> >
>> > I will get what I want: META-INF/spring not exported but included in the
>> > bundle due to, I suppose, Include-resource.
>> > It is anyhow annoying that I will have exclude via the export-package
>> > directive the content of resources folder.
AD> With this approach, as I told works fine but bnd will warn as follows:
AD> [WARNING] Instructions for Export-Package that are never used:
AD> META-INF\..*|!META-INF
AD> But it is at least clear - the bnd tool could perhaps avoid exporting
>> folders
>> which don't contain Java classes, but you might want a resource exported
>> in some situations and wonder why it didn't appear in export-package.
AD> I have the "feeling" but I'm waiting for a reaction from Peter
AD> Kriens<Pe...@aQute.biz>.
AD> He may have some experience to share with us.
AD> I will rather have a default approach that will not export any package that
AD> do not contain java and the possibility to force the export by using the
AD> Export-Package instruction.
>> On 3/22/07, Alin Dreghiciu <ad...@gmail.com> wrote:
>> > >
>> > > I do not have any problem with the Include-Resource directive from
>> BND.
>> > > That has it's role and I can imagine is usefull.
>> > >
>>
>> It's extremely useful if you want to embed/inline jarfiles inside your
>> bundle.
AD> That was the use case I imagined.
>> > > probably correct, but I don't know what the solution is. At a minimum,
>> > > > perhaps the plugin should automatically append every resource
>> location
>> > > > specified in the POM file to the <Include-Resource> directive by
>> > > > default...if that is possible.
>>
>> I think you just need to iterate through the project resource list, for
>> example:
>>
>> /*
>> * I grant license to ASF for inclusion of the following code
>> * in ASF works, as per the Apache Software License
>> */
>> StringBuilder resourcePaths = new StringBuilder();
>> for (Iterator i = project.getResources().iterator(); i.hasNext();) {
>> org.apache.maven.model.Resource resource =
>> (org.apache.maven.model.Resource)i.next();
>> if (new File(resource.getDirectory()).exists()) {
>> String path = resource.getDirectory();
>> String base = baseDir.getAbsolutePath();
>> if (path.startsWith(base)) {
>> path = path.substring(base.length() + 1);
>> }
>> if (resourcePaths.length() > 0) {
>> resourcePaths.append(',');
>> }
>> resourcePaths.append(path);
>> }
>> }
>> header(properties, Analyzer.INCLUDE_RESOURCE, resourcePaths);
>>
>> /*** warning: it hasn't been thoroughly tested! ***/
>>
>> There should also be a plugin option to turn off this code, just in case
>> ;)
>>
>> Also should we be preserving the path layout in the bundle, which requires
>> the PATH=PATH form of Include-Resource, or should we flatten resources?
>> Perhaps add another plugin option...
AD> I would vote for the plugin options and change.
AD> Alin, do you want to open a JIRA issue for this?
>>
>> --
>> Cheers, Stuart
AD> I will.
AD> Alin Dreghiciu
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: Re[2]: maven-bundle-plugin, Include-Resource and src/main/resources
Posted by Stuart McCulloch <st...@jayway.net>.
On 23/03/07, Alin Dreghiciu <ad...@gmail.com> wrote:
> The options were meant for maven-bundle-plugin. And since is a build tool it
> should offer flexibility. But those should be advanced usage and have good
> common defaults.
Actually, looking into this more, we might not need the extra plugin options,
as maven will give us the information we require - for example, wrt. flattening
resource paths, we just need to check the target dir for each resource entry.
(ie. follow whatever flattening is specified in the pom)
--
Cheers, Stuart
Re: Fwd: Re[2]: maven-bundle-plugin, Include-Resource and src/main/resources
Posted by Peter Kriens <Pe...@aQute.biz>.
Hmm, I think you are right that it can never make sense to export
META-INF/* ... This directory is clearly intended to be used for
bundle specific setup. I will build in a rule to remove any such
packages from the export.
I actually had missed the part where * was used for the wrapping of
existing bundles, in that case it actually makes sense I think because
the classpath is only the target jar.
Kind regards,
Peter Kriens
AD> Peter, I always enjoy reading your posts or blogs...
AD> On 3/23/07, Peter Kriens <Pe...@aqute.biz> wrote:
>>
>> I think the discussion is progressing along nicely ... :-)
>>
>> Resource folders
>> I understood Maven standardized the resource folder so that is why
>> the resource folder is hard coded. If you can specify additional
>> folders, then the plugin should automatically append these to the
>> Include-Resource header if this is not set. This should -not- be
>> optional if this is what maven specifies.
AD> The so called "standard" src/main/resources is just a default and is always
AD> good to respect it to get less configuration. But is also possible that you
AD> do not have it at all and use a different folder or even more folders.
AD> Stuart posted a patch to maven-bundle-plugin and I'm sure that this will be
AD> solved.
AD> Export of non-java packages
>> I never envisioned anybody using * for Export-Package ... that
>> seems a bit random to me, I am sure it would hurt me if I used it. As
>> I argued before, packing a bundle is part of the design of your
>> system. The fact that you get META-INF/spring as an exported package
>> is a consequence of this export all strategy. I think bnd contains
>> more than enough flexibility to solve the problem, as is shown by
>> excluding sub-packages from META-INF with the ! operator. The fact
>> that it looks ugly caused by the fact that you do not want to specify
>> the packages that you designed to be inside the bundle but rely on the
>> classpath.
AD> Totally agree with you about the packaging/design part and that bnd is
AD> flexible enough and I can easily go over the "ugly" part.
AD> Just wondering about the special case of META-INF folders: how can someone
AD> else substitute this packages. Just take the spring case...
AD> About the *, I agree for the bundles I build. But for those we wrapped is a
AD> very useful option for now since is hard and time consuming to figure out
AD> the public api.
AD> 3. The warning that you get looks wrong, the ! should not be in the
>> expansion of the pattern. I'll check that out.
AD> Thanx.
AD> I am -very- reluctant to add options for these special cases
>> because in my experience it makes the tool over time a monster in
>> complexity. Even people that do not use have to understand these
>> options to not use them ... It is usually the easy way out to just add
>> options because it makes people happy and the others do not care.
>> However, newcomers have a tendency to be put off by the myriad of
>> options for special cases.
>>
>> So I think bnd can do what you want and it would be wrong to add extra
>> options only to make the manifest look more pleasing in a case
>> that I think is not a good practice ...
AD> The options were meant for maven-bundle-plugin. And since is a build tool it
AD> should offer flexibility. But those should be advanced usage and have good
AD> common defaults.
AD> Kind regards,
>>
>> Peter Kriens
>>
>> AD> On 3/23/07, Stuart McCulloch < stuart.mcculloch@jayway.net> wrote:
>> >>
>> >> On 23/03/07, Alin Dreghiciu <ad...@gmail.com> wrote:
>> >> > Just checked out and if I use:
>> >> >
>> >> > <Export-Package>
>> >> > !META-INF.*,
>> >> > *
>> >> > </Export-Package>
>> >> >
>> >> > I will get what I want: META-INF/spring not exported but included in
>> the
>> >> > bundle due to, I suppose, Include-resource.
>> >> > It is anyhow annoying that I will have exclude via the export-package
>>
>> >> > directive the content of resources folder.
>>
>>
>>
>> AD> With this approach, as I told works fine but bnd will warn as follows:
>> AD> [WARNING] Instructions for Export-Package that are never used:
>> AD> META-INF\..*|!META-INF
>>
>> AD> But it is at least clear - the bnd tool could perhaps avoid exporting
>> >> folders
>> >> which don't contain Java classes, but you might want a resource
>> exported
>> >> in some situations and wonder why it didn't appear in export-package.
>>
>>
>> AD> I have the "feeling" but I'm waiting for a reaction from Peter
>> AD> Kriens< Peter.Kriens@aQute.biz>.
>> AD> He may have some experience to share with us.
>> AD> I will rather have a default approach that will not export any package
>> that
>> AD> do not contain java and the possibility to force the export by using
>> the
>> AD> Export-Package instruction.
>>
>> >> On 3/22/07, Alin Dreghiciu <ad...@gmail.com> wrote:
>> >> > >
>> >> > > I do not have any problem with the Include-Resource directive from
>> >> BND.
>> >> > > That has it's role and I can imagine is usefull.
>> >> > >
>> >>
>> >> It's extremely useful if you want to embed/inline jarfiles inside your
>> >> bundle.
>>
>>
>> AD> That was the use case I imagined.
>>
>> >> > > probably correct, but I don't know what the solution is. At a
>> minimum,
>> >> > > > perhaps the plugin should automatically append every resource
>> >> location
>> >> > > > specified in the POM file to the <Include-Resource> directive by
>> >> > > > default...if that is possible.
>> >>
>> >> I think you just need to iterate through the project resource list, for
>>
>> >> example:
>> >>
>> >> /*
>> >> * I grant license to ASF for inclusion of the following code
>> >> * in ASF works, as per the Apache Software License
>> >> */
>> >> StringBuilder resourcePaths = new StringBuilder();
>> >> for (Iterator i = project.getResources().iterator(); i.hasNext();) {
>> >> org.apache.maven.model.Resource resource =
>> >> (org.apache.maven.model.Resource)i.next();
>> >> if (new File( resource.getDirectory()).exists()) {
>> >> String path = resource.getDirectory();
>> >> String base = baseDir.getAbsolutePath();
>> >> if (path.startsWith(base)) {
>> >> path = path.substring(base.length() + 1);
>> >> }
>> >> if (resourcePaths.length() > 0) {
>> >> resourcePaths.append(',');
>> >> }
>> >> resourcePaths.append (path);
>> >> }
>> >> }
>> >> header(properties, Analyzer.INCLUDE_RESOURCE, resourcePaths);
>> >>
>> >> /*** warning: it hasn't been thoroughly tested! ***/
>> >>
>> >> There should also be a plugin option to turn off this code, just in
>> case
>> >> ;)
>> >>
>> >> Also should we be preserving the path layout in the bundle, which
>> requires
>> >> the PATH=PATH form of Include-Resource, or should we flatten resources?
>> >> Perhaps add another plugin option...
>>
>>
>> AD> I would vote for the plugin options and change.
>>
>> AD> Alin, do you want to open a JIRA issue for this?
>> >>
>> >> --
>> >> Cheers, Stuart
>>
>>
>>
>> AD> I will.
>>
>> AD> Alin Dreghiciu
>>
>>
>> --
>> Peter Kriens Tel +33467542167
>> 9C, Avenue St. Drézéry AOL,Yahoo: pkriens
>> 34160 Beaulieu, France ICQ 255570717
>> Skype pkriens Fax +1 8153772599
>>
>>
AD> Thanx,
AD> Alin Dreghiciu
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Fwd: Re[2]: maven-bundle-plugin, Include-Resource and src/main/resources
Posted by Alin Dreghiciu <ad...@gmail.com>.
Peter, I always enjoy reading your posts or blogs...
On 3/23/07, Peter Kriens <Pe...@aqute.biz> wrote:
>
> I think the discussion is progressing along nicely ... :-)
>
> Resource folders
> I understood Maven standardized the resource folder so that is why
> the resource folder is hard coded. If you can specify additional
> folders, then the plugin should automatically append these to the
> Include-Resource header if this is not set. This should -not- be
> optional if this is what maven specifies.
The so called "standard" src/main/resources is just a default and is always
good to respect it to get less configuration. But is also possible that you
do not have it at all and use a different folder or even more folders.
Stuart posted a patch to maven-bundle-plugin and I'm sure that this will be
solved.
Export of non-java packages
> I never envisioned anybody using * for Export-Package ... that
> seems a bit random to me, I am sure it would hurt me if I used it. As
> I argued before, packing a bundle is part of the design of your
> system. The fact that you get META-INF/spring as an exported package
> is a consequence of this export all strategy. I think bnd contains
> more than enough flexibility to solve the problem, as is shown by
> excluding sub-packages from META-INF with the ! operator. The fact
> that it looks ugly caused by the fact that you do not want to specify
> the packages that you designed to be inside the bundle but rely on the
> classpath.
Totally agree with you about the packaging/design part and that bnd is
flexible enough and I can easily go over the "ugly" part.
Just wondering about the special case of META-INF folders: how can someone
else substitute this packages. Just take the spring case...
About the *, I agree for the bundles I build. But for those we wrapped is a
very useful option for now since is hard and time consuming to figure out
the public api.
3. The warning that you get looks wrong, the ! should not be in the
> expansion of the pattern. I'll check that out.
Thanx.
I am -very- reluctant to add options for these special cases
> because in my experience it makes the tool over time a monster in
> complexity. Even people that do not use have to understand these
> options to not use them ... It is usually the easy way out to just add
> options because it makes people happy and the others do not care.
> However, newcomers have a tendency to be put off by the myriad of
> options for special cases.
>
> So I think bnd can do what you want and it would be wrong to add extra
> options only to make the manifest look more pleasing in a case
> that I think is not a good practice ...
The options were meant for maven-bundle-plugin. And since is a build tool it
should offer flexibility. But those should be advanced usage and have good
common defaults.
Kind regards,
>
> Peter Kriens
>
> AD> On 3/23/07, Stuart McCulloch < stuart.mcculloch@jayway.net> wrote:
> >>
> >> On 23/03/07, Alin Dreghiciu <ad...@gmail.com> wrote:
> >> > Just checked out and if I use:
> >> >
> >> > <Export-Package>
> >> > !META-INF.*,
> >> > *
> >> > </Export-Package>
> >> >
> >> > I will get what I want: META-INF/spring not exported but included in
> the
> >> > bundle due to, I suppose, Include-resource.
> >> > It is anyhow annoying that I will have exclude via the export-package
>
> >> > directive the content of resources folder.
>
>
>
> AD> With this approach, as I told works fine but bnd will warn as follows:
> AD> [WARNING] Instructions for Export-Package that are never used:
> AD> META-INF\..*|!META-INF
>
> AD> But it is at least clear - the bnd tool could perhaps avoid exporting
> >> folders
> >> which don't contain Java classes, but you might want a resource
> exported
> >> in some situations and wonder why it didn't appear in export-package.
>
>
> AD> I have the "feeling" but I'm waiting for a reaction from Peter
> AD> Kriens< Peter.Kriens@aQute.biz>.
> AD> He may have some experience to share with us.
> AD> I will rather have a default approach that will not export any package
> that
> AD> do not contain java and the possibility to force the export by using
> the
> AD> Export-Package instruction.
>
> >> On 3/22/07, Alin Dreghiciu <ad...@gmail.com> wrote:
> >> > >
> >> > > I do not have any problem with the Include-Resource directive from
> >> BND.
> >> > > That has it's role and I can imagine is usefull.
> >> > >
> >>
> >> It's extremely useful if you want to embed/inline jarfiles inside your
> >> bundle.
>
>
> AD> That was the use case I imagined.
>
> >> > > probably correct, but I don't know what the solution is. At a
> minimum,
> >> > > > perhaps the plugin should automatically append every resource
> >> location
> >> > > > specified in the POM file to the <Include-Resource> directive by
> >> > > > default...if that is possible.
> >>
> >> I think you just need to iterate through the project resource list, for
>
> >> example:
> >>
> >> /*
> >> * I grant license to ASF for inclusion of the following code
> >> * in ASF works, as per the Apache Software License
> >> */
> >> StringBuilder resourcePaths = new StringBuilder();
> >> for (Iterator i = project.getResources().iterator(); i.hasNext();) {
> >> org.apache.maven.model.Resource resource =
> >> (org.apache.maven.model.Resource)i.next();
> >> if (new File( resource.getDirectory()).exists()) {
> >> String path = resource.getDirectory();
> >> String base = baseDir.getAbsolutePath();
> >> if (path.startsWith(base)) {
> >> path = path.substring(base.length() + 1);
> >> }
> >> if (resourcePaths.length() > 0) {
> >> resourcePaths.append(',');
> >> }
> >> resourcePaths.append (path);
> >> }
> >> }
> >> header(properties, Analyzer.INCLUDE_RESOURCE, resourcePaths);
> >>
> >> /*** warning: it hasn't been thoroughly tested! ***/
> >>
> >> There should also be a plugin option to turn off this code, just in
> case
> >> ;)
> >>
> >> Also should we be preserving the path layout in the bundle, which
> requires
> >> the PATH=PATH form of Include-Resource, or should we flatten resources?
> >> Perhaps add another plugin option...
>
>
> AD> I would vote for the plugin options and change.
>
> AD> Alin, do you want to open a JIRA issue for this?
> >>
> >> --
> >> Cheers, Stuart
>
>
>
> AD> I will.
>
> AD> Alin Dreghiciu
>
>
> --
> Peter Kriens Tel +33467542167
> 9C, Avenue St. Drézéry AOL,Yahoo: pkriens
> 34160 Beaulieu, France ICQ 255570717
> Skype pkriens Fax +1 8153772599
>
>
Thanx,
Alin Dreghiciu