mike_at_openbrace.com wrote on 08/22/2013 04:57 AM:
> 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.
Yes.
> - 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.
It depends.
Some of these API jars are designed to be combined with an implementation
jar and used in that way. Others are not.
> - 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.
Ideally, the API jars would include only the API class files. They definitely
should not contain any other class files, but honestly we haven't worried that
much about resource files. If it was my choice, they wouldn't include them,
but I haven't looked into all the cases to know if that would be a problem.
We've considered putting related schema files in the API jar files, but since
the specs don't define that the schema files are available as resource files
in your classpath, we haven't done that.
> 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.
At this point it seems more like a bug to me than "by design".
> 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.
>