I think that’s an understatement lol.
Yeah, I got that the first time. I think a bundle is both unnecessarily technically cumbersome, and doesn’t meet my needs wrt adding tooling that is connected to workspace (or other bndtools) templates.
Here’s my specific use case: I have a workspace template that provides a number of project templates + repositories for doing remote services development via ECF’s RSA impl…and the various distribution and discovery providers. I also have a number of Eclipse plugins that add views, RS tooling, etc.
With the new bndtools OSGi service wizard I provided (which is implemented with/uses bndtools templates) it’s possible to add a new service wizard by a) creating bndtools project templates; b) Adding an eclipse newWizard extension (that points to the 3 project templates).
Because of this templates/plugin/tooling connection…and the more general desire to have bndtools-based tooling and workspace creation (e.g. remote services) be simpler for the tooling install + bndtools workspace setup and configuration…I would like to reduce the workflow: install /plugins tools with p2 then create associated bndtools workspace… to one user action (e.g. install plugins tools and extend p2 to create/install/uninstall the associated bndtools workspace). I would also like to provide more tooling that uses/takes advantage of templates and other resources (more/other repos, workspace config, etc).
p2 native and osgi touchpoints and custom touchpoints have been used by Eclipse plugins (and commercial/non-commercial third-party tools providers) to extend p2 so that the non-bundle-based Eclipse config and/or other install/uninstall operations can be integrated with p2 (both what it does and the UI).
For reference: Help - Eclipse Platform
You appear to be saying (reflection) that you will help me implement this strategy (bundle-based custom install operations). Although appreciated, that’s not what I want…I can do that completely on my own, but I don’t want to do that because I would likely find myself re-implementing (or reusing the same bundle) multiple times in the future…as I create and distribute (for example) distribution-provider specific tooling + templates (e.g. gRPC distribution provider, or etcd discovery provider, etc). This isn’t theoretical…I already have both Eclipse tooling (e.g. proto3 editor) and service/project/bndtools templates specifically for gRPC distribution provider.
So…the way that looks easiest to me, and meets my needs for both repeated usage of this mechanism, and user install/workspace setup simplification appears to me to create a custom touchpoint(s) for bndtools, include it with bndtools (so it’s there when needed for remote services tooling+templates install/uninstall).
If there is another way in bndtools to meet these needs then I’m open to it. I’ve looked for existing bndtools touchpoints and haven’t found any. I agree that including tooling install into workspaces is probably not the way to go.
I will consider implementing a custom touchpoint (with your help) and contributing it to bndtools, but I looked over bndtools code yesterday and couldn’t immediately figure out the best bndtools bundle to include it. There will be static dependencies to ProvisioningAction (custom actions are subclasses of ProvisioningAction) so the location of this dependency will be important I expect.
Thought of that…but since we are talking about installing tooling for remote services development we’ve got to get the horses (tooling plugins and workspace template) before the carts.
But if you are suggesting distributing Remote Services tooling with bndtools I would be happy to consider it. 