Peter, I always enjoy reading your posts or blogs...
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.
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 < [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
Thanx,
Alin Dreghiciu
