Namespace - Capabilities and Requirements are defined in appropriate namespaces ; every Requirement belongs to a namespace and can only require Capabilities in the same namespace. Capability - Describes a feature or function of the Resource when installed in the Environment. Properties are key value pairs, where the keys are strings and values can be scalars or collections of String , Integer , Double , and Long.
Requirement - Specifies a Capability needed in an Environment. A Requirement can be mandatory or optional. Once this list of resources is known the associated artifacts can be installed.
The osgi. An OSGi Framework must provide a capability in the osgi. This namespace is part of the OSGi compendium and is usually added automatically by tools. A good example is when a bundle implements a whiteboard pattern. In this case there is no direct package or service link from the consumer to the implementation, and so a requirement for the osgi. The default JAR path is the the root for a directory or the filename for a file. The path can be overridden.
Once the JAR is created, the bnd program analyzes the classes and creates an import list with all the packages that are not contained in the jar but which are referred to. This import list is matched against the Import-Package instructions. However, sometimes it is necessary to ignore an import or provide attributes on the import statement, or specify an additional import. The arguments to bnd are normal given as a set of properties.
Properties that begin with an upper case are copied to the manifest possibly after processing. What's particularly interesting about Bnd is that although it comes as a single JAR file, it is actually three different tools in one. If you run it with java -jar bnd. If you add it to the Eclipse plugins directory, it is an Eclipse plugin. And, it has an Ant task built into it, so you can use it in an Ant build.
I haven't had a chance to try Bundlor out yet, but from what I read, it looks very powerful. When I get around to trying it out, I'll be sure to blog about it here. I've already reviewed these tools on this blog , so I won't go into it again here. Suffice it to say that many of the Pax tools have become indispensable in my OSGi development toolbox. You can count on me blogging more about the Pax tools soon.
Apache Felix is known as one of the leading OSGi frameworks. The vast majority of the Felix subprojects are runtime tools, such as File Install which automatically installs and uninstalls bundles from a watched directory and Web Console which provides a web-based administration console for an OSGi framework.
Apache Felix subprojects also include the Maven OSGi Plugin, which is a very handy Maven plugin for automatically generating bundles with proper manifests in Maven builds. If you take a visit to DynamicJava. I've not tried any of these out yet, but several of them look very interesting and I hope to give them a spin sometime soon. If I do, I'll be certain to blog about it here.
These are only a few examples. If you look around, you'll find a lot of useful OSGi tools And that brings me to the next item That, coupled with the fact that one of the major OSGi implementations is produced by the Eclipse Foundation, may lead some to believe that you must use Eclipse to develop OSGi-based applications.
The truth, however, is that there's nothing about OSGi that makes it proprietary to any development environment. That's because most of the OSGi-related work doesn't require anything more advanced than a simple text editor apologies to TextMate I almost didn't include this one.
I've been in the software development game for a long time and I know that anytime someone wants to discount a technology or framework, the killer phrase that is almost always thrown about is "XXX is a solution looking for a problem" or its variant: "XXX is a hammer looking for nails". But just because someone says it doesn't mean that it's true. But I heard someone say this again recently, so I tossed it in.
I've also been doing this thing long enough to know that modularity is a good thing. Developing software in modules increases maintainability, testability, flexibility, and comprehensibility.
It also offers benefits in terms of parallel development and to some degree reusability. Many languages such as Modula-2 and MIL have been around for a long time and were created with modularity as a primary concern.
Ask around Unfortunately, as awesome as Java is, it doesn't offer a lot of help with regard to modularity. JAR files and packages give only the illusion of modularity. And although there's a certain amount of modularity at the object level, that flavor of modularity is at too low of a level to be truly useful for creating modular applications.
For what it's worth, I'm not sure that modularity should be a language-level concern. My opinion in this matter is shaped by the fact that there are several wonderful languages for the Java platform and I wouldn't want modularity added to the Java language, leaving other JVM languages such as Groovy and Scala to solve the modularity problem for themselves.
So, if modularity is a good thing and Java doesn't offer support for it, then A problem begging for a solution, some might say. And modularity is one of the key things that OSGi offers.
So, in my opinion, OSGi is a timely solution to the problem of Java's missing modularity. It's certainly true, to some extent, that you don't need OSGi to achieve modularity. With the right mindset and a lot of discipline, you can develop Java applications that are modular to some degree. The OSGi Alliance has published a Semantic Versioning white paper which provides some recommendations and guidance on versioning policies.
Each bundle has a version. Each exported package has a version. For example. If the version attribute is omitted, the version is assumed to be 0. Each package import has a version range. The package import version range may be specified on the Import-Package manifest header. If interval notation is used, the version range must be enclosed in double quotes, for example:. If a version range is not specified on an import, the range 0 is assumed, meaning that any version of this package would satisfy the import.
Bundle manifests have a version which is 1 by default, indicating OSGi Release 3 semantics. Manifests themselves also have a version which must be specified as 1. Concepts Next. Life Cycle. Figure 2. Bundle life cycle. Version Numbers. Version Ranges. Versioning Policies. Bundle Version. Bundle-Version: 1. Package Version.
0コメント