Ok, lets talk about this in more detail when you have something that runs and are generally happy with.
I generally think that this
@Dependency("org.jboss.logging"), @Dependency("org.jboss.logmanager")
is evil because results in jboss proprietary manifest headers that also has an equivalent standard, which is Require-Bundle
So instead of putting
Dependencies: org.jboss.logging, org.jboss.logmanager
we could also add
Require-Bundle: org.jboss.logging, org.jboss.logmanager
On the topic on why Require-Bundle is also bad see JBoss AS7 OSGi Integration half way down the page section
3.12.3 Issues With Requiring Bundles
Our demos should show the recommended set of AS7 best practises, so perhaps we need to reach a conclusion on 'Dependencies' vs. 'Require-Bundle' vs. 'Package-Import'
For now I would say that 'Dependencies' does exist and gets processed by the DUP, but we should not promote its usage by introducing an annotation for it. How about requiring the user to explicitly put it in the @Deployment artifact manifest like I do in ModuleAccessesBundleServiceTestCase
private JavaArchive getClientModuleArchive() throws Exception
{
final JavaArchive archive = ShrinkWrap.create(JavaArchive.class, "example-xservice-client-module");
archive.addClasses(EchoInvokerService.class, ClientModuleActivator.class);
String activatorPath = "META-INF/services/" + ServiceActivator.class.getName();
archive.addResource(getResourceFile("xservice/client-module/" + activatorPath), activatorPath);
archive.setManifest(getResourceFile("xservice/client-module/" + JarFile.MANIFEST_NAME));
return archive;
}