[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-platform-dev] module-info tests
|
> 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