Hi all! I pray that you are all well!
I have developed a little tool that I have found useful a few times. I’ve dubbed it “evloser” (which is “resolve” backward). The idea is to take a set of resolved runbundles and work backward to find the minimal set of -runrequires needed to produce that set of -runbundles. I envisage that this could be part of a larger project to provide tools to automate conversion of PDE/Tycho projects to Bndtools projects.
I would like to contribute this to the project for others to use/build upon. I envisage two parts:
- the code itself (to go somewhere in bnd) as an API for drivers to call
- drivers to provide the UI (Bndtools, Gradle/Maven plugins)
Just wanted to canvass a few opinions on the above:
- exactly where in bnd should I put it? I was thinking a standalone project
biz.aQute.bnd.evloser.
- where to put the UI hooks? I personally would probably only contribute to a Bndtools GUI, as I would be unlikely to use a Gradle or Maven driver (at this stage). Within Bndtools, does it make sense to use a similar style to the resolver (ie, open a window, perform the operation, give the user the opportunity to automatically update
-runrequires based on the calculated result)? Or something similar? Should it be triggered by a button (where? on the bndrun file editor?), context menu, Bndtools menu, or some combination of these?
Or is this just a terrible idea and I should abandon it altogether?
Interested in thoughts.
biz.aQute.bnd.evloser
Actually, I think it might be better to call this project biz.aQute.bnd.pde. That way, if/when we build on it in the future to add other components needed for a full migration, they have a spot to go rather than needing to create individual projects for each one.
This seems to be a single use tool to make the “conversion” to a bndrun file. So then it is not clear that one needs maven or gradle plugins to integrate into a build.
There is already a bndtools.pde feature and a bndtools.pde project. Might this work not belong there?
Agreed.
I think the GUI part definitely belongs there. But if there is a case for separating out a standalone library that can do this under programmatic control i think it belongs in the bnd namespace rather than bndtools.
OK, but why another project? Can’t it be part of bndlib or resolver? Then it will be available in bnd if you add a command there.
I was wary of adding bloat to bndlib. I know it is part of the embedded repo and you like it to be “svelte”. 
But resolver is a reasonable candidate.
By way of full disclosure, i also have a utility that takes a PDE launch file and converts it to a bndrun. Conceptually this one doesn’t fit so well in resolver.
I’m following this with interest. We stayed on PDE when we fully moved to OSGi DS a couple of years ago due to time constraints and finding that moving to bnd was more than we could chew at the time, and we also use some Eclipse extension schemas and all. Still very short on cycles to move to bnd but maybe that is what is needed to get us there.
Alain