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

[David Blevins <dblevins@xxxxxxxxxxxxx>]

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