JBossDeveloper

We said that OSGiMetaData is the unified view of standard *and* custom (i.e. jboss specific) meta data related to OSGi deployments. Fragmenting the the metadata across multiple objects is not a good idea because if forces clients (i.e. who want to know the SL of a bundle) to be aware of that fragmentation.

What has OSGiMetaData to do here?

DeploymentMetaData is an existing generic solution to the SL / required stage problem.

And as such should be used to solve OSGi problems as well.

If it's not, then it's not generic enough, and as such must be fixed or enhanced.

With this "two files" approach - how is the atomicity problem addressed? AFAICS there is no guaranty that the MainDeployer will present both files to the deployers in one cycle. A user might drop both files in the deploy directory, The deployment scanner however kicks in in between.

If the copy / move op is atomic, which is how you should always deploy things, then there is no problem.

Ales Justin wrote:

With this "two files" approach - how is the atomicity problem addressed? AFAICS there is no guaranty that the MainDeployer will present both files to the deployers in one cycle. A user might drop both files in the deploy directory, The deployment scanner however kicks in in between.

If the copy / move op is atomic, which is how you should always deploy things, then there is no problem.

I think we need to tell users that they have to put the .md file in the deploy directory before the bundle is there. Otherwise we can't guarantee that it's used when the bundle is deployed. However looking at your code, Ales it doesn't seem to support that as the .md deployer looks for the .jar file which could not be there yet.

I don't know how you can copy/move 2 files into a directory atomically. One some platforms copying a single file isn't even atomic (although a move might be). I think the best we can do is ensure we can lock the file when we want to deploy it (so that we know nobody else is writing to it any more) and prescribing how the user should order them... Ales, how would you handle this in the deployers?

Adding .md before would also work.

You would simply cache / keep the .md informaition in some registry.

And then for every deployed bundle, you would check if its companion .md file is part of that registry.

Could be in the same deployment lifecycle, or .md would be deployed before.

Only if bundle was deployed before .md it wouldn't work.