Bundlor 1.0.0.RC1: MANIFEST.MF is not in the jar

[ctranxuan]

Hi all,
I am testing Bundlor 1.0.0.RC1 with maven but I don't manage to include my generated MANIFEST.MF in the jar: I just got the default one generated by maven. Nevertheless, it is generated in the target/classes/META-INF but not in the generated jar.
Furthermore, it seems that my template.mf is not taken in account since some properties of the generated manifest are not overriden (e.g. the bundleVersion).

I attach a zip of my project. If someone has an idea about what I am doing wrong...

I used:
- Bundlor 1.0.0.RC1
- maven 2.2.1 and maven 3
- Windows 7 (64bits)

Thanks in advance,

Cédric.

[dsklyut]

Add this for jar projects:

<plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <configuration>
                    <archive>
                        <manifestFile>${bundlor.manifest.output.dir}/META-INF/MANIFEST.MF</manifestFile>
                    </archive>
                </configuration>
            </plugin>

bundlor.manifest.output.dir is location where bundlor places MANIFEST.MF. By default it will in in ${project.build.outputDirectory}.

[ctranxuan]

Thanks! It works fine!
But I still got the issue about the template.mf file that is not taken in account. Have I also missed a maven configuration somewhere?

[dsklyut]

That could be a defect. I am also noticing that bundlor overrides BundleSymbolic name with maven ${project.artifactId}

[ctranxuan]

It looks like. I have run maven using bundlor 1.0.0.M6 and the template.mf is well taken in account.
Thanks again for the help!

Cédric.

[Ben Hale]

@ctranxuan and @Dimitry,

You guys are right, there's a precedence problem here. The precedence currently works such that if a BSN or BV is specified in the Maven configuration it overrides anything specified in the template. This puts it in line with all of the other user-specifible values.

However (and this is unlike the ANT task), we also aggressively specify default values for nearly every piece of configuration you can do through Maven. This leads to the defaults always overriding the template. I could reverse this, but it becomes non-standard to the rest of Bundlor, as well as to other configuration parameters potentially.

So my question is, as a user, how would you like the precedence to work? This is a change I'd like to make (if needed) for 1.0.0.

[dsklyut]

@Ben,

I would expect template.mf to be an "override" to any defaults provided by plugin. There is still an issue of "explicit" properties provided to plugin configuration vs. "implicit" determined by the plugin code (i.e. project.version, project* maven variables) and how those "explicit" properties interact with template.mf properties.

I think there is some need for documentation about this. From my experience with maven plugins it boils down to:

Use defaults IF there is no override in some form, i.e. either in plugin configuration or an external file (if plugin allows it).

There must be a way to specify a version that is different from project.version and BSN that is different from project.artifactId.

I have a usage pattern right now where I define bundlor configuration in the parent pom and just provide overrides from template.mf. This way I do not have to duplicate plugin configuration in each project. So template.mf overrides are a preferred way for me.

my 2 c

[ctranxuan]

@Ben
I would expect the template.mf overrides the maven plugin properties. Otherwise, if you need to override the default properties set by the maven plugin (for instance, the version or the bundle-name), you will be forced to rewrite these properties in the configuration of the maven plugin. Thus, the bundlor properties will be "transfered" to the pom file, which will make the template.mf less usefull.
From tooling point of view (i.e. STS + bundlor), I think that "template.mf over maven plugin" has some assets:
- first, I think the developper will be inclined to edit the template.mf to configure bundlor rather than a pom
- then, it will be easier to enhance the "template.mf" editor with new features that eases the work of the developper (completion and stuff like that)

To summarize, I liked the behavior of the 1.0.0.M6.
My 2 cents too.

[Ben Hale]

I've been kicking around this problem with some people at the SpringSource office and here are my conclusions.

First, I believe that the configuration of the build plugin, be it ANT or Maven, must always take precedence over what is in the template.mf. If you are using STS which automatically generates your manifests you must specify both a Bundle-SymbolicName and a Bundle-Version or the generated manifest will have errors in it. So this development style assumes that you've specified some Bundle-Version, but your build system will need to override that Bundle-Version for each build so that you can get something like 'Bundle-Version: 1.0.0.CI-232' as the bundle version number. Therefore I think that no matter what an explicitly configured (either in the pom.xml or passed in via a -D parameter) should take precedence.

Second, I don't think that the default value should have the lower precedence level. I propose that overriding should happen in the following way:

1. Explicitly configured value
2. template.mf
3. manifest.mf
4. default value

This means that you are not required to configure those values anywhere and defaults from the POM will be used. If you've configured it in the template.mf, that will trump the defaults, and if you explicitly configure it in your POM (either a hard-coded value or a -Dparameter) that will trump everything.

Any issues with this?

[Ben Hale]

I've just published a new snapshot that modifies this behavior. Please take a look and if this meets your requirements I'll ship out the 1.0.0.RELEASE.