Re: [jakartaee-platform-dev] module-info tests

["Kevin Sutter" <sutter@xxxxxxxxxx>]

That would be a fair
compromise, Emily.  The EE 10 Release Plan only states that a module-info
tck *should* be developed.  We could remove that soft requirement
altogether for EE 10.


---------------------------------------------------
Kevin Sutter 
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter

Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)



From:
       "Emily
Jiang via jakartaee-platform-dev" <jakartaee-platform-dev@xxxxxxxxxxx>
To:
       "jakartaee-platform
developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
Cc:
       "Emily
Jiang" <emijiang6@xxxxxxxxxxxxxx>
Date:
       10/07/2021
11:59
Subject:
       [EXTERNAL]
Re: [jakartaee-platform-dev] module-info tests
Sent
by:        "jakartaee-platform-dev"
<jakartaee-platform-dev-bounces@xxxxxxxxxxx>

---

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>
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-apitestlibrary for doing the signature test verification.

Tom
 
 
 
----- Original message
-----
From: "Scott Stark" <starksm64@xxxxxxxxx>
Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
To: "jakartaee-platform developer discussions" <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>
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>
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
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
 



_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

-- 
Thanks
Emily
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev