Jump to: navigation, search

Difference between revisions of "Bundle Naming"

Line 31: Line 31:
[[Jeff McAffer]] : this seems excessive.
[[Jeff McAffer]] : this seems excessive.
[[Category: Orbit]]

Revision as of 01:17, 16 November 2006

Bundling third party code libraries such as Log4j or Commons Logging is generally easy. Choosing a bundle symbolic name (BSN) for the bundle can be challenging. There are a number of questions that must be asked, options investigated and decisions made. The information here is an attempt to capture some of these issues in an effort to get some level of uniformity within the Eclipse and OSGi communities. This information is put here to generate discussion and surface and resolve issues.

Issue 1 : Namespace ownership

While it is suggested that BSN's be in the form of reverse domain names, this is not required by the OSGi spec. Assuming you want to follow that guideline, there are two choices for the BSN; use your namespace or use the namespace of the library's originator. Some thoughts from the community...

  • Using your namespace correctly stamps the bundle as your view of the library
  • Using the originator's namespace correctly attributes credit/ownership for the function
  • Using the originator's namespace inhibits the originator from free use of their namespace
  • Using your namespace leads to many names for the same thing (e.g., org.eclipse.orbit.jetty and org.apache.felix.jetty vs. just org.mortbay.jetty)

As you can see, there are reasonable yet diametrically opposed views. There is some clarity in this space however.

  • if you modify or add to the library code then using your own namespace is probably best as you are not incorrectly assigning responsibility (i.e., blame) to the originator.

Issue 2 : Evolution

On the whole the issues raised here only come up because library producers are not producing OSGi bundles. The hope is that over time library producers will change and begin to ship OSGi bundles natively. As such, they will take responsibility for choosing a BSN. Some thoughts from the community...

  • When that happens, what if they choose the same name as we choose now?
  • The choice we make now will help guide the producers when picking a BSN (we are setting the example)
  • What about version number clashes?
  • What about people who are using Require-Bundle?

Option 1 : Dominant package name

For many libraries it is easy to identify one Java package as being "the root" of the function. This is a reasonable choice for the BSN assuming you are comfortable using the originator's domain name. This option implies names such as org.mortbay.jetty.

Note that some libraries do not use full domain names in their package naming. MX4J packages for example are simply mx4j.*. Following this option would lead to a BSN of just mx4j. As noted above, this is perfectly legal. One could opt here to add in the remaining domain segments and go for net.sourceforge.mx4j.

Option 2 : Your namespace + originator simple name

If you would prefer to use your own namespace (or have modified/added code) a BSN of the form org.eclipse.orbit.jetty seems reasonable. Here the first part is the shortest sequence that is in your control and the remaining part is the "short name" of the originator's function.

Option 3 : Your namespace + originator's full name

To be 100% safe with respect to namespace clashes, you could use the originator's full name in conjunction with your namespace to create a BSN of the form org.eclipse.orbit.org.mortbay.jetty. Here the first part is the shortest sequence that is in your control and the remaining part is the "full name" of the originator's function.

Jeff McAffer : this seems excessive.