Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] module-info tests

Catching up on this thread and trying to wrap my head around the what exactly it is we're proposing.

On the face of it it sounds:

  - we want to add module-infos to the API jars produced out of the Jakarta spec projects
  - such module-infos will be considered vendor-specific, non-portable, and not be part of a standard
  - there will be no requirements or tests for them affecting certification even if an implementation does support JPMS
  - there is no action that needs to be taken by anyone else who produces API jars

I'm fairly certain much of the above is wrong, but this will help me contrast/understand a bit better what is being proposed.


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

On Oct 8, 2021, at 8:24 AM, Scott Stark <starksm64@xxxxxxxxx> wrote:

It would be validated automatically using whatever we end up with based on the efforts talked about in this POC:

It would just be an extra check the action would perform when it validates the staged api jar exists.

On Oct 8, 2021 at 6:05:06 AM, Emily Jiang via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
+1 on adding the module-info file without TCKs!
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.
Thanks
Emily

On Fri, Oct 8, 2021 at 1:21 AM Scott Stark <starksm64@xxxxxxxxx> 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.

On Oct 7, 2021 at 4:06:18 PM, Tibor Digana <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> 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> 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 library 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
_______________________________________________
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
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev


Back to the top