The OSGi Alliance has been using bnd for a long time in the OSGi build. bnd is used by the ant build to create the bundles and execute the compliance tests as part of our continuous builds. It is also installed in Eclipse as an IDE plugin to provide IDE support for compilation classpath and test execution by OSGi members working in the Expert Groups.
Recently Bndtools development has been underway to create a better integration of bnd with the Eclipse IDE for bundle development. Bndtools 1.0 was just released and is available for installation into the Eclipse IDE as a replacement for bnd's Eclipse IDE support.
Since the OSGi Alliance has long used bnd, we already had the bnd infrastructure in place for our build. All that we needed to do to start using Bndtools was to update each project's .project file (using the Add Bndtools Project Nature menu item). This simple change then enabled Bndtools to manage the project within the Eclipse IDE. The OSGi Alliance will continue to use bnd in the ant build, but for our Eclipse IDE use we have moved to Bndtools.
Thanks to Neil Bartlett, Peter Kriens and the other bnd and Bndtools contributors for their hard work in making bnd and Bndtools the premier tooling for OSGi development.
Friday, December 09, 2011
Tuesday, October 04, 2011
Java 8 and the 1990s
I attended the first Jigsaw session at JavaOne today where Mark Reinhold presented the latest on Jigsaw. After what appeared to be the end of the presentation, Mark continued on and began discussing why OSGi is wrong for using packages as the primary unit import and export between modules and why Jigsaw is right for requiring (aka. importing) modules (but apparently, and non-symmetrically, exporting packages and types). Mark made several strange arguments.
He found the idea of a resolver matching package importers up to package exports (essentially a broker pattern where the resolver acts as the broker) to be bad/complicated/etc. He prefers the developer to effectively be the "resolver" and declare the specific modules to be imported. This removes an important level of indirection between the thing being provided and the artifact providing it. This is like saying, "Don't use interfaces, use concrete implementation types," because we don't want to have to figure out how to map the use of the interface onto a concrete implementation type.
Mark also stated that requiring modules mapped well onto native package managers (e.g. rpm, apt) while importing package provided for no simple mapping. So therefore requiring modules is the way to go. It seems rather sad to me that the design of modules for Java 8 is being driven by the capabilities of native package managers designed in the 1990s for native code. Shouldn't the design of a module system for Java be driven by the capabilities and attributes of Java?
He found the idea of a resolver matching package importers up to package exports (essentially a broker pattern where the resolver acts as the broker) to be bad/complicated/etc. He prefers the developer to effectively be the "resolver" and declare the specific modules to be imported. This removes an important level of indirection between the thing being provided and the artifact providing it. This is like saying, "Don't use interfaces, use concrete implementation types," because we don't want to have to figure out how to map the use of the interface onto a concrete implementation type.
Mark also stated that requiring modules mapped well onto native package managers (e.g. rpm, apt) while importing package provided for no simple mapping. So therefore requiring modules is the way to go. It seems rather sad to me that the design of modules for Java 8 is being driven by the capabilities of native package managers designed in the 1990s for native code. Shouldn't the design of a module system for Java be driven by the capabilities and attributes of Java?
Friday, September 30, 2011
The Needs of the Many Outweigh the Needs of the Few
There is a discussion on the Aries dev mail list about a tool for checking semantic versioning. One of the issues misunderstood in the discussion is about the asymmetry in the treatment of versions for the roles of API consumer and API provider discussed in the whitepaper.
An API package p can contains several types. Some types must be implemented by the API provider and some are intended to be implemented by the API consumer. p.S may be a service provided by the API provider and used by the API consumer. p.L may be a listener implemented by the API consumer and user by the API provider. A syntactic analysis tool for versioning needs to understand the orientation of a type to decide whether a change to the type constitutes a major version change for the package or a minor version change.
The whitepaper does not discuss how the orientation of the type should be marked. It is beyond the scope of the whitepaper. OSGi now uses the @noimplement javadoc tag (from Eclipse) to indicate the type is not to be implemented by the API consumer (e.g. p.S). Types not marked @noimplement may be implemented by the API consumers (e.g. p.L). Adding a new method to p.S represents a minor version increment to package p as API consumers are not broken (while API providers are broken; but they have tighter version constraints, e.g. [1.0,1.1)). Adding a new method to p.L represents a major version increment to package p as API consumers are broken. Furthermore adding a new type to package p will not break API consumers. They are free to ignore it. But API providers must change to support the new type.
These are examples of the asymmetry between API providers and API consumers: an API provider must provide all of the API while an API consumer is free to use any subset of the API.
So in order for any syntactic analysis tool to properly work, the orientation of the types in the package must be properly marked so the tool can decide whether a change warrants incrementing the major or minor version. What is missing is an agreement on how to mark the types. I think this is something bnd and bndtools should provide. Perhaps a set of standard annotations.
For any API, we see there is an asymmetry in the relationships is has with API providers and API consumers. In general, there will (hopefully) be many more consumers than providers. So the semantic versioning scheme is oriented towards the many: the API consumers.
"... the needs of the many outweigh the needs of the few." - Spock.
PS. It has also been suggested that segregating consumer oriented types from provider oriented types by placing them in different packages is useful. But this does not remove the need for syntactic analysis tools to understand the orientation of each type (or each package) to provide proper advice about necessary versioning changes. And now you have 2 packages which each provider and consumer must import...
An API package p can contains several types. Some types must be implemented by the API provider and some are intended to be implemented by the API consumer. p.S may be a service provided by the API provider and used by the API consumer. p.L may be a listener implemented by the API consumer and user by the API provider. A syntactic analysis tool for versioning needs to understand the orientation of a type to decide whether a change to the type constitutes a major version change for the package or a minor version change.
The whitepaper does not discuss how the orientation of the type should be marked. It is beyond the scope of the whitepaper. OSGi now uses the @noimplement javadoc tag (from Eclipse) to indicate the type is not to be implemented by the API consumer (e.g. p.S). Types not marked @noimplement may be implemented by the API consumers (e.g. p.L). Adding a new method to p.S represents a minor version increment to package p as API consumers are not broken (while API providers are broken; but they have tighter version constraints, e.g. [1.0,1.1)). Adding a new method to p.L represents a major version increment to package p as API consumers are broken. Furthermore adding a new type to package p will not break API consumers. They are free to ignore it. But API providers must change to support the new type.
These are examples of the asymmetry between API providers and API consumers: an API provider must provide all of the API while an API consumer is free to use any subset of the API.
So in order for any syntactic analysis tool to properly work, the orientation of the types in the package must be properly marked so the tool can decide whether a change warrants incrementing the major or minor version. What is missing is an agreement on how to mark the types. I think this is something bnd and bndtools should provide. Perhaps a set of standard annotations.
For any API, we see there is an asymmetry in the relationships is has with API providers and API consumers. In general, there will (hopefully) be many more consumers than providers. So the semantic versioning scheme is oriented towards the many: the API consumers.
"... the needs of the many outweigh the needs of the few." - Spock.
PS. It has also been suggested that segregating consumer oriented types from provider oriented types by placing them in different packages is useful. But this does not remove the need for syntactic analysis tools to understand the orientation of each type (or each package) to provide proper advice about necessary versioning changes. And now you have 2 packages which each provider and consumer must import...
Thursday, May 19, 2011
OSGi issue of Java Tech Journal
Java Tech Journal has just published an OSGi issue. It contains a number of great articles about OSGi including one I co-wrote with Peter Kriens on the new Core 4.3 spec. Check it out!
Tuesday, January 11, 2011
OSGi 4.3 Early Draft 3 now available
The latest draft spec from OSGi is now available for download. It contains the final RFCs for the changes to the Core 4.3 specifications. Also included are draft RFCs for some new specs for the next releases of the Compendium, Enterprise and Residential specifications.
Since this draft is just a draft, understand that things can change, even substantially, before the final specifications are completed.
Since this draft is just a draft, understand that things can change, even substantially, before the final specifications are completed.
Subscribe to:
Posts (Atom)
