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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> wrote:
>> >>
>> >> On 23/03/07, Alin Dreghiciu <[EMAIL PROTECTED]> 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< [EMAIL PROTECTED]>.
>> 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 <[EMAIL PROTECTED]> 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
