> On Oct 18, 2021, at 1:21 PM, BJ Hargrave <hargrave@xxxxxxxxxx> wrote:
>
> The contents of a Jakarta EE specification project's API jar's module-info file must be specified and is thus standard.
>
> Whether or not we mandate that all Jakarta EE specification projects must specify a module-info for Jakarta EE 10 is somewhat orthogonal. But if they do, then all who provide an API jar for the Jakarta EE specification, whether it is us or it is Apache, etc., must conform to the Jakarta EE specification's definition of the module-info which includes module name, exports, opens, etc. Then all API jars are "plug" compatible with each other in module mode.
>
> This is just like a type in an API. We specify the package name of the type, the name of the type, the members of the type, etc. Any one can provide the type as long as the type conforms to the specification of the type (i.e. signature). A module-info is a type, albeit a special type and it has public signature too.
This is a perspective I can understand. In this case we would need TCK tests to verify the module-info contents to ensue everyone is compliant. We'd also probably would not be able to add that via a service release as there will be new testing requirements.
We discussed this in the last few Jakarta EE calls. The consensus is not to add TCK because Jakarta EE 10 does not reinforce JPMS. What tests will be for? There is little value in having a test to mandate module-info present. The suggestion for Jakarta EE 10 is to eyeball the module-info.java and ensure it needs to be under root, which will be on the checklists. More info can be found in the
Jakarta EE platform call minutes.
How does this affect people who use uber-jars? I.e. for example a "jakartaee-api" uber jar.
Uber-jar will just remove the module-info.java.
-David
> ----- Original message -----
> From: "David Blevins" <dblevins@xxxxxxxxxxxxx>
> 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: Mon, Oct 18, 2021 15:07
>
> > On Oct 18, 2021, at 10:44 AM, Scott Stark <starksm64@xxxxxxxxx> wrote:
> >
> > The goal was to have the Jakarta specification project API jars include a module-info.
> >
> > The discussion around what that required in terms of the ratification/testing then seemed to make it clear there really were no requirements on vendors who provided their own API jar implementations. So as of now, a,b,c,... are fine as long as 'Anyone' != Jakarta specification projects.
>
> In the Java EE days the spec was considered to be the Specification PDF, Javadoc and TCK. The API jars were considered part of the implementation and there was no standard build-time environment or jars. For a brief period of time the API jars produced out of Apache Geronimo were the only open source jars on Maven Central and many people used them even though they didn't use Geronimo. The signature tests kept everyone in line and made this possible.
>
> I'm trying to understand the vision for module-info. The two paths I can understand:
>
> a. The existence and contents of the module-info is specific to the producer of the API jar. It is not part of the standard and your build is not portable to equivalent API jars produced by others.
>
> b. The existence and contents of the module-info is standard. It is part of the standard and your build is portable to equivalent API jars produced by others.
>
>
> Path A is more or less the status quo. We wouldn't be adding TCK tests and vendors don't have to do anything, but we also need to be clear to users that any module-info they find in jars is not part of any spec and is definitely not a Jakarta EE feature. People who say it's a new feature of Jakarta EE would need to be corrected.
>
> Path B is new for us. If it is going to be considered officially part of the spec, we likely would want TCK tests, spec text to support it and we probably should not be using service releases to add the feature.
>
>
> A path I wouldn't really understand is one where we call the module-info official and standard, but there are no means/requirements for others who are currently producing equivalent API jars. The added complexity there is some of the API jars are also implementations and what is and is not standard becomes more confusing than before.
>
>
> -David
>
> > On Oct 18, 2021 at 12:34:39 PM, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
> > Sorry for the gaps in responses. Still trying to get my head around it fully before I make any comments.
> >
> > What is our goal:
> >
> > a. Anyone who produces a Jakarta EE API jar can have a module-info or no module-info at all. If they have a module-info, the contents of that module-info are up to them and how they build their API jars. Users who rely on that module-info are relying on behavior that's specific to that producer's API jar.
> >
> > b. Anyone who produces a Jakarta EE API jar can have a module-info or no module-info at all. If they have a module-info, the contents of that module-info should be identical to the module-info of any API jars produced by others. Users who rely on the module-info are relying on behavior that's guaranteed to be the same regardless of who produces the API jar, provided that producer opts to have a module-info in their API jar.
> >
> > c. Anyone who produces a Jakarta EE API jar must have a module-info. The contents of that module-info should be identical to the module-info of any API jars produced by others. Users who rely on the module-info are relying on behavior that's guaranteed to be the same regardless of who produces the API jar.
> >
> > It sounds like from BJ's comments it could be either B or C, likely not A.
> >
> >
> > -David
> >
> >
> >> On Oct 8, 2021, at 10:59 AM, Scott Stark <starksm64@xxxxxxxxx> wrote:
> >>
> >> Adding 1-4 to your points, my understanding is:
> >> (1) yes
> >> (2) not that I understand, they are what the project spec jars have, not sure what the vendor specific connection is?
> >> (3) correct
> >> (4) correct
> >>
> >> On Oct 8, 2021 at 12:38:55 PM, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
> >> 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:
> >>
> >> - (1) we want to add module-infos to the API jars produced out of the Jakarta spec projects
> >> - (2) such module-infos will be considered vendor-specific, non-portable, and not be part of a standard
> >> - (3) there will be no requirements or tests for them affecting certification even if an implementation does support JPMS
> >> - (4) 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
> >>
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> 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
