Bill, thanks, that makes sense.
So if I've understood this:
- The java-ee-api jar is the pure and minimum API for programs to be
compiled against, but its classes currently include some internal code
that depends on resource bundles that aren't part of the API.
- It's neither appropriate nor possible to build a implementation of
the API based on the javaee-api jar, nor use it for anything except
compiling against. In particular, any implementation would have to
provide the resource bundles but they're in javax packages, and in any
case the implementation would be dependent on the javaee-api jar's
internal code.
- Instead, all implementations and any run-time use should actually use
the individual API jars (or, for example, the "javaee.jar" within
Glassfish, which just points to the individual API jars). The
individual API jars do include any resources that their code internally
relies on, despite the
https://wikis.oracle.com/display/GlassFish/Maven+Versioning+Rules
rules.
- If I write e.g. servlet code, then whether or not it's protected from
risk of dependency on the non-API resource files (as recommended by the
rules) depends on whether I compile it against the Java EE API jar or
the Servlet API jar.
This still seems a bit inconsistent, with Java EE as a whole providing
an API jar file that follows the rules but its constituent APIs
providing API jar files that don't.
But I can see both the sense in the rules and the need for the
individual APIs to not adhere to them!
Anyway, thanks for the prompt reply and the link to the rules.