Configuring the generated Manifest.mf within build.gradle does not work

[tschulte]

Currently I am trying to get a JavaFX-based RCP application to run. See https://github.com/tschulte/contacts-griffon.

After having the project running, I tried to change the project layout from the default PDE layout to the default gradle/maven layout (https://github.com/tschulte/contacts-griffon/tree/default_gradle_project_layout). In this effort I tried to remove the Manifest.mf and configure all specialitiies in build.gradle to let gradle generate the manifest:

project(':org.eclipse.fx.demo.contacts.app') {
    apply plugin: 'org.akhikhl.wuff.eclipse-equinox-app'
    tasks.jar {
        manifest {
            instruction 'Bundle-Activator', 'org.eclipse.fx.demo.contacts.BundleActivatorImpl'
            instruction 'Service-Component', 'OSGI-INF/component.xml'
        }
    }
}
project(':org.eclipse.fx.demo.contacts.edit') {
    apply plugin: 'org.akhikhl.wuff.osgi-bundle'
    jar {
        manifest {
            instruction 'Bundle-Activator', 'org.eclipse.fx.demo.contacts.provider.ContactsEditPlugin$Implementation'
        }
    }
}

Both Bundle-Activators and and the Service-Component entries are not added to the

[nedtwigg]

I had the same problem. If you have an existing MANIFEST.MF, Wuff attempts to merge them, and seems to have a hard time. My workaround to prevent merging is this little trick:

def convertManifest = ['plugin1', 'plugin2'] // the names of projects for which I want auto-generated MANIFEST.MF
configure(subprojects.findAll {convertManifest.contains(it.name)} ) {
  // delete the manifest before we start
  task deleteManifest(type: Delete) {
    delete 'META-INF/MANIFEST.MF'
  }

  // copy the manifest back into the project directory at the end
  task overrideManifest << {
    File src = file('build/tmp/jar/MANIFEST.MF')
    File dst = file('META-INF/MANIFEST.MF')
    org.apache.commons.io.FileUtils.copyFile(src, dst)
  }

  // assemble -> delete -> build -> overrideManifest
  build.dependsOn(deleteManifest)
  overrideManifest.dependsOn(build)

  // only delete if we're going to override
  gradle.taskGraph.whenReady {taskGraph ->
    deleteManifest.enabled = taskGraph.hasTask(overrideManifest)
  }
}

Whenever I make a change which will affect MANIFEST.MF, I run "gradle overrideManifest" and wuff generates clean manifests which respect the Bundle-Activators that I put in.

In the example above, I think you're going to want to also add

instruction 'Bundle-ActivationPolicy', 'lazy'

[aalmiray]

Merging manifest entries can be cumbersome. Perhaps Wuff can rely on https://github.com/johnrengelman/shadow to get this matter solved. There may be a need for a custom transformer that merges OSGi entry values if this is not already done by bnd or wuff itself.

[akhikhl]

Good point. I'll think on improving in this area. Maybe we'll do manifest merge only after specific instruction.

[akhikhl]

@tschulte, @nedtwigg, @aalmiray: I created tiny draft on the improvement in this area (MANIFEST.MF and plugin.xml handling in Wuff): https://github.com/akhikhl/wuff-drafts/blob/master/Wuff-bundle-files-draft.md The coding effort related to this improvement will be probably small and easy, but we should accurately consider all use-cases. Could you, please, contribute or give feedback?

[akhikhl]

@tschulte, @nedtwigg, @aalmiray: Just one more addition to the draft, regarding build lifecycle. Please criticize: https://github.com/akhikhl/wuff-drafts/blob/master/Wuff-bundle-files-draft.md#build-cycle Correct build cycle might be critical from the perspective of how Wuff is used in IDEs.

[nedtwigg]

I dig it.

On Oct 17, 2014, at 11:53 PM, Andrey Hihlovskiy [email protected] wrote:

@tschulte, @nedtwigg, @aalmiray: Just one more addition to the draft, regarding build lifecycle. Please criticize: https://github.com/akhikhl/wuff-drafts/blob/master/Wuff-bundle-files-draft.md#build-cycle Correct build cycle might be critical from the perspective of how Wuff is used in IDEs.

— Reply to this email directly or view it on GitHub.

[akhikhl]

I just realized the idea of processBundleFiles task is probably defect. Imagine, src/main/bundle/META-INF/MANIFEST.MF contains imports from other bundles. It will be natural to expect that these "other bundles" are also seen by Java compiler! That means: merge/generation should happen before compileJava/compileGroovy and should even change gradle dependencies. Maybe, we should do it in evaluation phase, i.e. when Plugin.apply of the Wuff plugin is being called?

[nedtwigg]

Putting things into "Plugin.apply" can be expensive for the user. It slows down large multi-project builds, and brings fragility.

I've got a hacked-up implementation of the "generation" mode. It wipes all the manifests before a build starts to prevent merging, runs the build, then copies the generated manifests to the root where Eclipse can see them. Not a good long-term plan, but it works.

If anything breaks during the build, then all my manifests are wiped, which will then cause wuff to NPE during plugin.apply(). This effectively "bricked" all of gradle for me - I couldn't make a gradle task to fix it! I had to make a BATCH script which I would run to fix the problem.

TL;DR: I don't understand the issues involved in changing gradle dependencies, and it might need to be in Plugin.apply. But it would be nice to avoid if possible, and if it does need to be in Plugin.apply, we should pay extra attention to performance and robustness.

Ned Twigg Lead Software Architect, DiffPlug LLC 949-264-3433 340 S Lemon Ave #3433, Walnut, CA 91789

On Fri, Oct 17, 2014 at 6:07 AM, Andrey Hihlovskiy <[email protected]

wrote:

I just realized the idea with processBundleFiles task is probably defect. Imagine, src/main/bundle/META-INF/MANIFEST.MF contains imports from other bundles. It will be natural to expect that these "other bundles" are also seen by Java compiler! That means: merge/generation should happen before compileJava/compileGroovy and should even change gradle dependencies. Maybe, we should do it in evaluation phase, i.e. when Plugin.apply of the Wuff plugin is being called?

— Reply to this email directly or view it on GitHub https://github.com/akhikhl/wuff/issues/30#issuecomment-59509617.

[akhikhl]

Ned, you are right, performance should be of top priority to us.

[aalmiray]

I'd recommend not to overwrite files that may exist under SCM. Perhaps wuff can create the manifest under a working area based on a template?

[akhikhl]

Overwrite or not overwrite, that is the question :smile: We will follow "least surprise" principle. By default the feature will be turned off. No generation/merge, no overwrite. When somebody enables generation/merge of META-INF/MANIFEST.MF or plugin.xml, they know what they do. Even if they are unsure, what they do, we might help with clear messages in gradle plugin output. "working area" - do you mean buildDir? But Eclipse will not see manifest and plugin.xml there?

[aalmiray]

Correct if I'm wrong but couldn't META-INF/MANIFEST be located anywhere besides the project's root? Don't know for sure about plugin.xml. And yes, by working area I meant buildDir.

[akhikhl]

I just reread what @radimk suggested regarding BUNDLE_ROOT_PATH and generated files in buildDir. I think it will work that way. Need to try.