A quick question: by "validating on the spec api jars", do you mean manually eyeballing it? It sounds good. However, we need to agree on where the module-info class should end up.
Please see the other thread on the desired location of module-info.class.
But what has been argued by advocates of adding the module-info is that there are runtimes supporting JPMS and Jakarta API jars that cannot make use of tools like jlink because that does not work with automatic modules. To me a compromise is to add the module-info.class, validate it in the spec api jars, but don't test for it via signature or TCK tests.
I am with Tom on this. If we just superfluously verify such a file exists in the api jar, we don't mandate it will be used. In other words, JPMS is not forced. I don't see the point of adding a tck or even adding this class at all. We either drop it or force it. For forcing it, it will need more discussion as we have to wait and see how useful it is. If some specs wants to add it so that some impls can experiment with it, it is fine. However, don't add tcks before we force JPMS.
That is essentially my point. At runtime we
have no requirement to run in JPMS for the containers.
Containers that do not run in JPMS should not be forced to
provide module-infos in their implementation at runtime. It
would provide no value to them nor the applications and I
argue it could limit some possible innovation at the runtime
implementation level.
Here is were my inexperience with the TCK
shows. Does the TCK signature tests run outside of the
container directly against some set of JARs provided by the
implementation?
If your point is just about that we should
only test the API jars from the specification project
release for the module-info, and not in general during
compatibility testing because we don't have a requirement
for JPMS in the containers, that is valid, and one I
probably agree with.
Implementations are not required,
but if they do, then how do you certify? Right
now the TCK signature tests look to the
jars/content provided by the implementation
under test. If they have their own versions of
the API jars, they need to pass the same
requirements as the specification project
producing the API jars.
I did not intent to suggest
that apps are only allowed to be
compiled against the API JARs from
Jakarta projects. I was asking if
implementations are required to provide
to such JARs for development purposes?
Don't get me wrong, implementations
should be allowed to provide such JARs
to allow them to provide various
developer experiences as they see fit.
Open Liberty certainly does provide such
JARs for developers to compile against
also. I do think such JARs should
conform to the module-info requirements
from Jakarta. But I don't think the
specification requires an implementation
to provide such JARs for the developer
to compile against.
If implementations are not
required to provide API JARs for
compilation/development purposes then I
do not see the point of the TCK testing
for module-info classes against the
implementation. On the other hand the
Jakarta build of the API JARs should
contain a test that validates they are
providing the correct things.
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
