Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [External] : Re: JPMS Module Info classes 
On 30.08.2023 0:19, David Blevins via jakartaee-platform-dev wrote:
As long as we're all on the same page about that, great.  Note on that front, we need to avoid saying in specifications that these are features of the spec:
  - https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0 <https://urldefense.com/v3/__https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0__;!!ACWV5N9M2RV99hQ!MIdja2GmyribNCOycKWc9Re9XvS-YDdWxs_9rza4qSnaAKqCoNEHqQbfx5alk61lm5vyxgg_L6fM6L-UKROcKM2j6TZL1JEi$>
Any spec that refers to the Maven coordinates, module-infos, etc as a feature of the spec should be removed.  Spec jars are the responsibility of the implementation and we should avoid referring to one set of them as the one-true version and we should avoid referring to their non-portable features as features of the spec.
We should remove that section of the CDI spec and replace it with language like we added to the EE 10 spec.
I - if anything - would rather see the language to be update to make it clear that JPMS is *opt-in* feature of the spec with defined guarantees around that if user opts-in to run on JPMS, then x,y,z packages are and must be provided by the module named x.y.z. Additional step here - for consideration by particular spec team - would be to increase level of vendor neutrality, should runtimes need reflective access to user code, by also saying sth like "user code" needs to be open to at least x.y.z module.
This is something what - in my opinion - is reasonable, does not look hard to test - be it manually through ie javadoc tool and inspecting output or within TCK through very simple test (in JUnit - ModuleDescriptor.read(in).{name(),exports()} is what I'd be looking at as a starting point) and can be applicable to *standalone* spec projects only. 

thanks,
--lukas



--
David Blevins
http://twitter.com/dblevins <https://urldefense.com/v3/__http://twitter.com/dblevins__;!!ACWV5N9M2RV99hQ!MIdja2GmyribNCOycKWc9Re9XvS-YDdWxs_9rza4qSnaAKqCoNEHqQbfx5alk61lm5vyxgg_L6fM6L-UKROcKM2j6Qe3UQQQ$> http://www.tomitribe.com <https://urldefense.com/v3/__http://www.tomitribe.com__;!!ACWV5N9M2RV99hQ!MIdja2GmyribNCOycKWc9Re9XvS-YDdWxs_9rza4qSnaAKqCoNEHqQbfx5alk61lm5vyxgg_L6fM6L-UKROcKM2j6d3oUM3o$>
On Aug 29, 2023, at 2:27 PM, Scott Stark <starksm64@xxxxxxxxx <mailto:starksm64@xxxxxxxxx>> wrote:
The requirements are the same as EE 10 in that one should be provided with the indicated naming pattern. The content is unspecified and there are no TCK tests for modules is the status quo for EE 11.
On Mon, Aug 28, 2023 at 9:58 PM David Blevins via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx <mailto:jakartaee-platform-dev@xxxxxxxxxxx>> wrote: 

    "It is desired to firm up these suggestions into requirements.
    Several discussions via Issues, Mailing Lists, and the Platform
    call have resulted in these requirements for Jakarta EE 11."

     -
    https://jakartaee.github.io/jakartaee-platform/jakartaee11/JakartaEE11ReleasePlan <https://urldefense.com/v3/__https://jakartaee.github.io/jakartaee-platform/jakartaee11/JakartaEE11ReleasePlan__;!!ACWV5N9M2RV99hQ!MIdja2GmyribNCOycKWc9Re9XvS-YDdWxs_9rza4qSnaAKqCoNEHqQbfx5alk61lm5vyxgg_L6fM6L-UKROcKM2j6ZlYDfkk$>

    The last agreement I recall is that the module-infos are there for
    convenience and are not standard or requirements of the specification:

     - https://github.com/jakartaee/jakartaee-platform/issues/425
    <https://urldefense.com/v3/__https://github.com/jakartaee/jakartaee-platform/issues/425__;!!ACWV5N9M2RV99hQ!MIdja2GmyribNCOycKWc9Re9XvS-YDdWxs_9rza4qSnaAKqCoNEHqQbfx5alk61lm5vyxgg_L6fM6L-UKROcKM2j6UnzRJoc$>
     -
    https://www.eclipse.org/lists/jakartaee-platform-dev/msg02906.html
    <https://urldefense.com/v3/__https://www.eclipse.org/lists/jakartaee-platform-dev/msg02906.html__;!!ACWV5N9M2RV99hQ!MIdja2GmyribNCOycKWc9Re9XvS-YDdWxs_9rza4qSnaAKqCoNEHqQbfx5alk61lm5vyxgg_L6fM6L-UKROcKM2j6e4jJTJf$>

    We have this in section 13.3 of the EE 10 specification:

        "The contents of module-info.class files are not standard,
        portable, may change without notice and there is no requirement
        around testing of JPMS in API jar signature tests or TCKs. Vendors
        are free to create their own API jars that pass the signature
        tests, but include no JPMS module-info.class files or JPMS
        module-info.class files with different or conflicting contents."
-- David Blevins 
    http://twitter.com/dblevins
    <https://urldefense.com/v3/__http://twitter.com/dblevins__;!!ACWV5N9M2RV99hQ!MIdja2GmyribNCOycKWc9Re9XvS-YDdWxs_9rza4qSnaAKqCoNEHqQbfx5alk61lm5vyxgg_L6fM6L-UKROcKM2j6Qe3UQQQ$>
    http://www.tomitribe.com
    <https://urldefense.com/v3/__http://www.tomitribe.com/__;!!ACWV5N9M2RV99hQ!MIdja2GmyribNCOycKWc9Re9XvS-YDdWxs_9rza4qSnaAKqCoNEHqQbfx5alk61lm5vyxgg_L6fM6L-UKROcKM2j6dgajlZw$>

    _______________________________________________
    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!MIdja2GmyribNCOycKWc9Re9XvS-YDdWxs_9rza4qSnaAKqCoNEHqQbfx5alk61lm5vyxgg_L6fM6L-UKROcKM2j6cwQCSUd$>




_______________________________________________
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!MIdja2GmyribNCOycKWc9Re9XvS-YDdWxs_9rza4qSnaAKqCoNEHqQbfx5alk61lm5vyxgg_L6fM6L-UKROcKM2j6cwQCSUd$

Back to the top