The parsing of ParameterAttribute(s) and its decendent classes was already broken. The issue is in the javacc generated code. The change I made was to parse the BundleSymbolicName as a ParameterAttribute instead of a plain string because it has directives and attributes, e.g. Bundle-Symbolic-Name=foo.bar;singleton=true The reason is that the grammer is ambigous so sometimes it thinks it is parsing a PATH when it should be parsing a QNAME. The "tokenizer" part of the code is generating a wrong token and then it fails to match in the parsing. There's a commented out test with a TODO in the package import testing because of this. Fixing this parsing problem is on my list of things to fix. P.S. This is an "anti-pattern" | public String getBundleSymbolicName() | { | | <snip/> | | if (symbolicName == null) | throw new IllegalStateException("Cannot obtain " + Constants.BUNDLE_SYMBOLICNAME); | | return symbolicName; | } | You shouldn't put validation logic in the metadata model. This validation of the model should be done when we are asked to install the bundle so that others can augment/vary the model. e.g. you could imagine a custom deployer that does for example | OSGiMetaData md = ...; | if (md.getBundleSymbolicName() == null) | // generate one | Instead your validation in the getter would mean it has to catch the exception which is counter intuitive. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251737#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...