[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] [External] : Re: module-info tests
|
On 10/8/21 2:21 AM, Scott Stark wrote:
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.
with activation-tck on JDK 11 I'm able to get:
[javatest.batch]
PASSED........javasoft/sqe/tests/api/jakarta/activation/URLDataSource/getURL_Test.java#getURL_Test
[javatest.batch]
PASSED........javasoft/sqe/tests/api/jakarta/activation/URLDataSource/URLDataSource_Test.java#URLDataSource_Test
[javatest.batch] PASSED........com/sun/tdk/signaturetest/SignatureTest.java
[javatest.batch] Oct 8, 2021, 2:50:58 AM Finished executing all tests,
wait for cleanup...
[javatest.batch] Oct 8, 2021, 2:50:58 AM Harness done with cleanup from
test run.
[javatest.batch] Total time = 30s
[javatest.batch] Setup time = 0s
[javatest.batch] Cleanup time = 0s
[javatest.batch] Test results: passed: 90
and tests themselves are being executed with having
jakarta.activation-api.jar on the module path and angus-activation.jar
on the classpath (note that I have it quick and dirty just to try it
out...). In this setup simple assertEquals("jakarta.activation",
DataSource.class.getModule().getName()) in arbitrary test passes. But I
agree that activation is probably the simplest one to test this way as
it has no dependencies. Another drawback is that this does not cover
having the implementation on the module path as well - that is out of
scope for EE 10, I believe.
thanks,
--lukas
On Oct 7, 2021 at 4:06:18 PM, Tibor Digana <tibordigana@xxxxxxxxxx
<mailto:tibordigana@xxxxxxxxxx>> wrote:
Exactly!
If there is no business purpose from containers world (never seen
any such of), it becomes funny to cut a release with JPMS descriptors.
Just count the cost vs benefits with JPMS change.
I am awaiting other goals in Jakarta EE:
1. integrating/repackaging Microprofile into Jakarta
2. Quarkus on Jakarta EE API
The first was discussed with IBM and Jakarta some time ago, and the
second goal is expected from the world of developers.
T
On Thu, Oct 7, 2021 at 6:59 PM Emily Jiang via
jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>> wrote:
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.
Thanks
Emily
On Thu, Oct 7, 2021 at 4:54 PM Scott Marlow <smarlow@xxxxxxxxxx
<mailto:smarlow@xxxxxxxxxx>> wrote:
On 10/7/21 11:28 AM, Thomas Watson wrote:
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?
Yes and we use the
https://github.com/jtulach/netbeans-apitest
<https://urldefense.com/v3/__https://github.com/jtulach/netbeans-apitest__;!!ACWV5N9M2RV99hQ!dwK3zf08IyupwtnrN2x-jQY9Z6Po1d1FTD4_UU3OZHzYZSShN-tXaIK3lGJt60_ZAfU$>
library for doing the signature test verification.
Tom
----- Original message -----
From: "Scott Stark" <starksm64@xxxxxxxxx>
<mailto:starksm64@xxxxxxxxx>
Sent by: "jakartaee-platform-dev"
<jakartaee-platform-dev-bounces@xxxxxxxxxxx>
<mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx>
To: "jakartaee-platform developer discussions"
<jakartaee-platform-dev@xxxxxxxxxxx>
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
Cc:
Subject: [EXTERNAL] Re: [jakartaee-platform-dev]
module-info tests
Date: Thu, Oct 7, 2021 9:43 AM
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.
On Oct 7, 2021 at 9:34:41 AM, Scott Stark
<starksm64@xxxxxxxxx <mailto:starksm64@xxxxxxxxx>> wrote:
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.
On Oct 7, 2021 at 9:24:36 AM, Thomas Watson
<tjwatson@xxxxxxxxxx <mailto:tjwatson@xxxxxxxxxx>>
wrote:
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.
Tom
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!dwK3zf08IyupwtnrN2x-jQY9Z6Po1d1FTD4_UU3OZHzYZSShN-tXaIK3lGJtJHeZmgA$>
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx <mailto:jakartaee-platform-dev@xxxxxxxxxxx>
To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev <https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!dwK3zf08IyupwtnrN2x-jQY9Z6Po1d1FTD4_UU3OZHzYZSShN-tXaIK3lGJtJHeZmgA$>
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!dwK3zf08IyupwtnrN2x-jQY9Z6Po1d1FTD4_UU3OZHzYZSShN-tXaIK3lGJtJHeZmgA$>
--
Thanks
Emily
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!dwK3zf08IyupwtnrN2x-jQY9Z6Po1d1FTD4_UU3OZHzYZSShN-tXaIK3lGJtJHeZmgA$>
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!dwK3zf08IyupwtnrN2x-jQY9Z6Po1d1FTD4_UU3OZHzYZSShN-tXaIK3lGJtJHeZmgA$>
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!dwK3zf08IyupwtnrN2x-jQY9Z6Po1d1FTD4_UU3OZHzYZSShN-tXaIK3lGJtJHeZmgA$
