A bndtools feature that has occurred to me is to have one or more Eclipse wizards to create OSGi services. Such wizards could include the creation of the service interface(s) declaration (e.g. interface classes, methods/signatures, even annotations) but could also include simple skeleton impls and consumers, and/or test code. It could also include support for DS annotations, remote services, standard and custom service property usage, possibly other things.
Arguably such wizards may not be the biggest advantage to existing OSGi programmers, but I think it could open up OSGi services to a wider developer audience. Having something to guide those new to OSGi services about (e.g.) interface-impl separation, service properties, ds, dynamics, and extensions like remote services could be very helpful.
The service idea is imho one of the great software ideas of our time. It is based on interface based programming but with OSGi’s lifecycle and dynamics it is truly novel.
I’ve been searching for a tool for a long time to be able to capture the essence of a service in an even more abstract way than Java interfaces inside a package, i.e. the OSGi model, allow. I’ve been involved in Alloy for a long time because I think it has the roots of such a tool but it is not there yet. Although I finally found some funding to work on this!
Wizards would not be my choice. Designing a service package is the most creative and complex aspect of a system; it designs the hinges. Much what happens with wizards tends to be curtailed by the imagination, experience, and time of the wizard designer. Wizards are great when you have no clue entering a new area. However, if you lack the skills to learn the basics, wizards tend to only postpone the barriers that people will run into.
I share your quest but my money is currently on a language that allows me to specify the essence of a service package and then derive the Java files.
I think then having a catalog of templates would be faster to get started than Wizards.
IMHO there is room for both something longer-range and flexible (e.g. a service creation language), AND there is room for something to constrain and simplify OSGi service creation.
Think of that assertion this way: languages come and go all the time…precisely because (IMHO) they are ‘high risk and high return’…there is a very good chance that the language will not be adopted (for lots of potential reasons)…like no/bad tooling, no corp to push/sell it, natural forces against new languages, etc. OTOH, something like wizards are lower risk (lots of Eclipse users use wizards and so adoption among OSGi services novices is more likely), but they don’t have as high a likely return on investment.
I agree that wizard design has an important effect, but if more than a single person were involved in that design and impl…and target users (OSGi novices) were involved early as well, those problems could be minimized.
WRT templates…I have produced a number of templates for bndtools and the creation of remote services. But as I said initially, the support for templates is (no offense intended) really limited. It would be a lot better, IMHO, if the Wizards and Wizard Page classes were API and designed as such…so that they could be reused and extended (e.g. JDT wizards). At least then the number of potential wizard designers could be increased.
With templates as they are now I would say that a catalog of templates is only minimally helpful (although for remote services I still think worth doing).
BTW…FWIW the grpc proto language is an example that works quite well with the ECF grpc remote services provider, the protoc bndtools plugin, and the bnd -generate support. One can go from a fairly compact specification in proto format to a remote service (api, impl, consumer, etc) very quickly and easily as per the videos linked to here: GitHub - ECF/bndtools.workspace: Bndtools Remote Service Workspace Template
In any event…I think it would be generally helpful for OSGi services adoption to provide something(s) more than bndtools does now (which is…IMHO…frustratingly passive for new OSGi services disigners/implementers). Wizard infrastructure is at least there and established in Eclipse.
I support the idea (in principle) of providing some kind of API for the project creation process so that you can do more complicated things with new workspace/project/component setups than what the templates alone can provide. I too have experimented with templates, and they get you 90% of the way there quickly but then you may need to jump through a few hoops for the last 10% due to the inherent limitations of templating languages.
However, I do not think I personally would not have the resources to contribute much to its development or maintenance.
I was not talking about the templates in bndtools, they are very limited. I also think a project template is not the right tool for this since you are mixing many different needs and this then suffers from lack of cohesion and creating a high required update rate.
I agree grpc is interesting for the low levels details but I personally am focusing on the high level where the relations among components, and dare I say it, the expected behavior can be encoded in such a way that its constraints can be enforced over a workspace. I.e. I want a small file so I can understand it but with the essence.
Anyway, about the laments of the templating. All true and I won’t go into this history. However, we now also have the -library instruction that I think can go a long way to address the needs. A library is a resource in the repositories that is expanded in the cnf/cache directory and that then automatically include a bnd file. Where templating is frustratingly limited, the macro language in contrast is quite powerful.
A very quick fix to make it more user friendly might be to add the libraries to the Bndtools context menu in the bnd editor? This definitely made it easier to insert a plugin.
Although I would also like a way to express (e.g.) relations/service dependencies among dynamic components, I think that for OSGi services and bndtools to be more well-established it is/will be important to appeal to ‘the general programmer’ with the ease of creating OSGi services…rather than to make the job of the OSGi expert simpler/easier. Both are valid of course, but I think of this as another opportunity for OSGi (and bndtools) to ‘break out’ of it’s current niche…with the now mature support of scr, rsa for remoting, bndtools, dynamics, versioning, etc.
Sadly I don’t have the resources nor bndtools internals knowledge to take this on myself as I’m already taxed with enhancing and supporting our impl of remote services/RSA and using bndtools to aid in remote services creation specifically.
I like quick fixes Could you maybe elaborate a bit more about library? The documentation is pretty abstract and I struggle a bit imagening “foo” examples. Do you have a more real-world example of a library?
Edit: Is a library kind of a container for multiple other bundles? So that e.g. instead of
No, that is also supported in another way but that a library is more. It allows you to expand a bundle from the repository in a cache and then include a bnd file. For example, you need to run a binary in your build, e.g. a go compiler. You can then include the binaries, or a down loader, in a bundle and refer to it as a library in your workspace or project.
It addresses the problem where you need bits on disk, when the bits in the zipped bundle are not sufficient.