Talk:PropertyFiles

From APIDesign

(Difference between revisions)
Jump to: navigation, search
(Comment provided by Ansgar Konermann - via ArticleComments extension)
Line 39: Line 39:
--[http://apidesign.org JaroslavTulach] 14:39, 19 December 2008 (CET)
--[http://apidesign.org JaroslavTulach] 14:39, 19 December 2008 (CET)
 +
</div>
 +
== Ansgar Konermann said ... ==
 +
 +
<div class='commentBlock'>
 +
Hi Jaroslav,
 +
 +
what if a developer accidentally specifies a wrong Bundle-ManifestVersion value? The Require-Bundle tag would still be ignored!
 +
 +
To me, merely making the Bundle-ManifestVersion header mandatory from version 1 on does not help very much in practice.
 +
 +
Instead, the user of the API should be *informed* if the service providing this API detects "inconsistent use" of different versions of the API. In this case: the OSGi container or bundling tool should warn at packaging or deployment time if one tries to create/use a bundle without Bundle-ManifestVersion specified, but containing tags from "non-1.0" API versions inside the bundle manifest.
 +
 +
This is similar to a "syntax check" done by programming language compilers. If our OSGi tooling does not support this syntax check (yet?), at least the runtime container should do.
 +
 +
The point I'm trying to make is: let's not blame the API *specification* for a *missing mechanism* which can ensure that the API is used correctly.
 +
 +
Best regards
 +
 +
Ansgar
 +
 +
--[http://passion.forco.de/ Ansgar Konermann] 17:34, 25 November 2010 (CET)
</div>
</div>

Revision as of 16:34, 25 November 2010

Comments on PropertyFiles <comments />


Contents

Wayne Beaton said ...

FWIW, The Eclipse Plug-in Development Environment (PDE) has tools for configuring OSGi manifests. And it works with Felix.

--Wayne Beaton 14:54, 16 December 2008 (CET)

Richard S. Hall said ...

Actually, the real reason we had to introduce Bundle-ManifestVersion is because we changed the semantics of the existing Export-Package header (in R3 it also implied an Import-Package, but in R4 it does not). Otherwise, I agree it would have been smarter to include the manifest version from the beginning. :-)

--Richard S. Hall 15:25, 16 December 2008 (CET)

Richard S. Hall said ...

Also, Wayne makes a good point. BND will also "verify" bundles, but I am not sure if it would have pointed out the issue in this case. Of course, the moral to this story is, don't use Require-Bundle, use Import-Package instead. ;-)

--Richard S. Hall 15:27, 16 December 2008 (CET)

Chris Aniszczyk said ...

If you used any OSGi-related tools like Eclipse PDE... this would catch the problem immediately.

Your point about including version identifiers is very valid and people should learn to take it in heart. It's a common mistake people forget about.

--Chris Aniszczyk 16:03, 16 December 2008 (CET)

JaroslavTulach said ...

Somewhere in TheAPIBook, I guess it is in Chapter 9, I mentioned that one of the best APIs is wizard. Good wizard can turn any API, regardless how bad, into perfectly shining, beautiful star. I am sure that if I used PDE, I would avoid falling into the ManifestVersion trap.

--JaroslavTulach 14:39, 19 December 2008 (CET)

Ansgar Konermann said ...

Hi Jaroslav,

what if a developer accidentally specifies a wrong Bundle-ManifestVersion value? The Require-Bundle tag would still be ignored!

To me, merely making the Bundle-ManifestVersion header mandatory from version 1 on does not help very much in practice.

Instead, the user of the API should be *informed* if the service providing this API detects "inconsistent use" of different versions of the API. In this case: the OSGi container or bundling tool should warn at packaging or deployment time if one tries to create/use a bundle without Bundle-ManifestVersion specified, but containing tags from "non-1.0" API versions inside the bundle manifest.

This is similar to a "syntax check" done by programming language compilers. If our OSGi tooling does not support this syntax check (yet?), at least the runtime container should do.

The point I'm trying to make is: let's not blame the API *specification* for a *missing mechanism* which can ensure that the API is used correctly.

Best regards

Ansgar

--Ansgar Konermann 17:34, 25 November 2010 (CET)

Personal tools
buy