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 <[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
