Provide option to keep original plugin.xml and MANIFEST.MF

[bodensee]

I don't want wuff to enhance my plugin.xml because it already contains the view configurations correctly. Enhancing will duplicate some of the views.

I also don't want wuff to change my MANIFEST.MF because then eclipse would not load my plug-in.

Can you please provide a simple switch, like "keepPluginXml" and "keepManifest" or something similar?

I tried to replace the original file with gradle, but at the end, the JAR file always contains the modified versions. This is my gradle code:

task replacePluginXml(type: Copy) { from project.file("plugin.xml") into 'build/extra' inputs.files 'build/extra/plugin.xml' outputs.files 'build/extra/plugin.xml' }

task replaceManifestMf(type: Copy) { from project.file("META-INF/MANIFEST.MF") into 'build/tmp-osgi' inputs.files 'build/tmp-osgi/MANIFEST.MF' outputs.files 'build/tmp-osgi/MANIFEST.MF' }

jar.dependsOn(replacePluginXml) jar.dependsOn(replaceManifestMf)

[akhikhl]

I am working on exactly these things, please stay in touch :smile:

[Fab1n]

ten million :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: !!! For hours I investigated problemes like @bodensee. A simple click on "issues" would have solved it ;-)

Do you know, how hard that is and how much time it will consume?

[akhikhl]

I plan to implement "inobtrusive" manifest and plugin.xml interpretation over this week/weekend. Generation will be optional and it will be transparent to Eclipse IDE.

[akhikhl]

Please don't hesitate reporting any "time-burners" in Wuff issue tracker. I am here to help.

[Fab1n]

very good support. Thank you. please report here, when it is ready for takeoff. In the meantime you might want to check out, what I like to build with wuff:

https://github.com/rPraml/org.openntf.domino/tree/maven

Please go into the toplevel folder /domino. This is where you will find the mavenized and gradled projects, manifests and plugin xmls. There is a private maven repo for the group 'ibm.domino' for dependencies i.e. in xsp/build.gradle or the maven equivalent pom.xml.

Unless you are notes developer, I cannot give you the jars, because these are ibm stuff, so you're not able to build, but have a look at a real world project from me

[akhikhl]

Hi @Fab1n , nice work! I'd be happy to improve Wuff, so that it solves all OSGi-related problems for you.

[akhikhl]

@bodensee, @Fab1n : 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?

[bodensee]

Thank you for the fast reply and good discussion. I've read your draft. I think it will be working for my issue (static mode). For the other two modes, this should also be working, due to the separation into the two different folders (some-bundle and some-bundle/src/main/bundle). I like your simple solution with only one property. Good work.

[akhikhl]

@bodensee, @Fab1n : 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.

[Fab1n]

sorry, business as usual so I had no time looking into. Now I will. Thanks for your great support @akhikhl

[Fab1n]

The md document contents look good. Seems pretty understandable. For our project the main problem was, that after packing the osgi plugins we had required bundles in the Manifest.mf files, that were not existent on our servers (i.e. jface, views) and we don't need. Our plugins are server-only plugins, that only use the osgi management capabilities (for installing plugins).

And then we have a private maven repo with the jars needed to be able to build our plugins. The plugins have dependencies on other plugins, which are specific to the IBM Domino server.

So I'd like to build and package the plugins with gradle (using the dependencies in build.gradle files - which already works without wuff) and then organize them together in the plugin-way with the manifest files untouched.

The problem is, if wuff looks at the dependencies in the manifest-files, how can it resolve them, if it doesn't know, where to look (that's the problem with tycho here)?

I hope this makes sense... Don't know, if it is possible

[akhikhl]

Regarding bundle resolution: There's function OsgiBundleConfigurer.configureDependencies. It iterates "Require-Bundle" elements and tries to resolve each. Since bundle names don't include maven group and version, Wuff uses the following heuristic:

project.dependencies.add 'compile', "${project.ext.eclipseMavenGroup}:$bundleName:+"

where eclipseMavenGroup is a superposition of all eclipseMavenGroup definitions in wuff-config-chain. eclipseMavenGroup is populated by "mavenized" bundles on first start of Wuff plugin (when you see those download and installation messages). Plus symbol means "take the latest version".

[Fab1n]

Some updates here? Sorry I was ill for 2 weeks and didn't catch up what happened here...

[bodensee]

Should this be working in 0.0.13-SNAPSHOT?