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.
Although helpful, IMO templates are rather limited by the bndtools templates mechanisms. Wizards or some other more mechanism could do much more to help guide the creation of OSGi services.
What is the thinking among the current bndtools developers about such ideas for simplifying creation, development, and testing of OSGi services?
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 remember a discussion I had with @juergen-albert some time ago that something like https://start.spring.io/ would be cool to make it more attractive and get started.
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.
Iām still interested in possibly helping with the tooling challenges of creating/defining/implementing/testing/debugging osgi services (along with remote services as subset).
I havenāt been paying much attention to bndtools as of lateā¦have there been any additions of mechanism to supplement project templates?
I want to clarify on this thread that as of bndtools 7.1 (not yet in release is my understanding) there is an OSGi service wizard in bndtools.
Once bndtools 7.1 is installed and a new workspace created (using bndtools.workspace.min template/R8), the wizard is accessed by menu: File->New->Otherā¦->OSGi Services->Java OSGi Service (api, impl, consumer).
Once the project name and service name fields are completed, the wizard will create three bundle projects: .api, impl and consumer. The service interface class is in API, the service impl class is in impl and service consumer class is in consumer project. The impl and consumer both use DS for service registration and injection and as bndtools projects are compiled and built automatically.
For the Java service wizard, in the api project has a bndrun file .bndrun that can be opened, resolved, and run/debugā¦which will start a framework, register (impl), inject service (consumer) and then call the service interface method one time.
Since this is new to 7.1 I would like to ask that it have some visibility in the bndtools 7.1 release docs, and some promotion upon 7.1 release. Note that as of right now the bndtools.workspace.min workspace template is at R8 (which works with the wizard) and bndtools.workspace template is at R7 (which does not work with the wizard). I cannot fix this myself but I believe that having the two builtin workspace templates be on different version of OSGi could cause much confusion and make the OSGi service wizard very hard to use .
Finally, the new wizard classes in bndtools.core have been generalized to support the creation of other service wizards. As an example of this, Iāve created Remote Service wizards for several ECF Remote Services distribution providers including the gRPC distribution provider.
My desire is to fully document (with examples) how to create custom OSGi Service wizards so that other bndtools developers can easily create and distribute them for bndtools users if they wish. I wonāt be able to complete this documentation until after bndtools 7.1 is released, however.
Could you maybe elaborate a bit more about