Thanks,

- Raja.

Yeah, it looks like bnd works great for projects that are not structured… but I'm disappointed that it doesn't work for projects that _are_ structured.

Working with Eclipse and separating your bundles into logical projects with individual manifests is, in my opinion, cleaner and more modular. However, I have not found bnd to support this. Hiding packages (so that two classes with the same name and package could potentially exist in separate bundles and not exported) is a feature of OSGi and using one giant unstructured src/bin folder destroys that!

In my perfect world:
1) The manifest should be maintained in only _one_ spot. Generating it every time doesn't work well with version control or for just running your src straight out of the box with an IDE. Saying, "Oh, by the way… you have to run these ANT targets before you open Eclipse" isn't fun.
2) Compiling a bundle with ANT would be easy with multiple projects, source folders, and manifests.

I won't be using bnd as a build tool.

I believe the "rule" of MANIFEST.MF being the first entry is more of a best practice. If I recall correctly, it depends on how the jar is created or read. Archives created with the standard Jar tool will always have the /META-INF/MANIFEST.MF as a first entry (try jar-tvf some.jar). If memory serves me right, Equinox had no problems reading Jars with misplaced MANIFEST.MF but Knopflerfish had, since it relied on JarInputStream which, I think, doesn't read the MANIFEST unless it is the first entry.
From a stream point of view, this makes sense since the manifest is supposed to describe the archive structure and thus, should be the first available data in the stream, before the actual content.

At the end of day, it's not about the OSGi spec but rather on how the jar is actually handled at low-level. One difference between the platforms, that we discovered early on in this area for example, was the difference in which folder entries are handled. An archive can contain just the selected files but not the folder entries.
That is, only:
/a/b/c/file.txt

vs:

/a/
/a/b/
/a/b/c/
/a/b/c/file.txt

Depending on the tool that you create/use, such 'synthethic' entries can be created automatically for you or not – however, without them, searching a bundle jar can yield different results depending on whether the platform will consider the folder entries even if they don't exist or will use only what's available in the archive.

[quote comment=102133"]
One last thing: in Eclipse, it seems like bundle naming (not the things inside the MANIFEST, I mean the jar name) is important. For example, we recently had a problem with a bundle we created "asm.jar". I seem to remember we just renamed it so that the bundle was then named something like: Bundle-SymbolicName_Bunddle-Version.jar and then all went fine…
Though I didn't find any rules about bundle naming in the spec, is there any??? Could someone confirm or not that Equinox has (or may have in some situations) a special behaviour about bundle management?[/quote]
I am not aware of such a requirement in the OSGi spec or Equinox – in fact, the jars that we use in our tests have very different naming patterns and none of them resembles the one you mentioned. Maybe you are using Eclipse PDE where the jars have a certain pattern?
The actual jar name can be useful only for the bundle location (populated during install) so on bundle refresh (unless a different location in the manifest is specified), the jar is read again. But this shouldn't be affected by a ".jar" style.

Hope this helps