What I meant is if Groovy runs fine without that package, then that package should be marked as optional.
I'm not sure from all these packages, which are required and which are optional (to Groovy). OSGi has a way to mark a package for either case.
Import-Package: net.sf.retrotranslator.runtime, javax.servlet;resolution:=optional
means that javax.servlet is optional and net.sf.retrotranslator.runtime is not optional. A required dependency that is not satisfied will prevent the bundle to get to "RESOLVED" state.
That's the runtime issue, now about the POM.
mvn pax:provision / Pax-Runner does not automatically install the dependencies of a depended POM (i.e. transitive dependencies).
If it were the case, I'd simply depend on Groovy, and Groovy will bring in asm, antlr, etc. Having the project POM depended on Groovy will compile the project with Groovy and all its transitive dependencies. However, at OSGi runtime when launching using mvn-pax-provision/Pax-Runner, only the direct dependencies are installed, not the transitive ones. The rationale for this is understandable, but can be inconvenient and slightly confusing at first.
This is why that in the project POM, I manually specify the dependencies to asm, antlr, etc. so they will be launched by pax-provision.
To Groovy packager though, this should not be their issue, it's application developer's issue.
Traditional Java has no way of specifying which packages should be in the classpath, you'll only get a runtime ClassNotFoundException.
OSGi provides a way of bundles specifying which packages it will need (required), or may use (optional). But it does not specify where it will find these required dependencies if the application developer does not install them at runtime.
This is one way of saying that it's modular. The Groovy developer can specify the packages it require, but not mandate the exact artifact (or implementation) that the application developer will use.
A typical situation is a dependency to commons-logging, which resides in org.apache.commons.logging package. At runtime, we don't need to install commons-logging itself, but can use e.g. pax-logging-api, which satisfies this dependency just fine. Although the dependent library may not know about pax-logging-api.
Rereading thoroughly your statement, it seems that your conclusion is correct. A way to supply dependencies directly is to package the dependencies within the bundle (perhaps this is what the groovy-all-jdk14 does??) however in most cases an open external dependency is recommended, as it leaves the "wiring" to the application developer (which they should, or they can use tools like Eclipse PDE that can find matching bundles that satisfy dependencies for them).