@Romain Manni-Bucau I must have misunderstood your question. Let me try again to clarify this:
1. what's the plan about the spec saying jakarta.* should be excluded from
the applications (which means it cant be used by TCK)?
I disagree with what you said jakarta.* can't be used by TCK because TCKs are part of specs and do not fall into the application category. Besides, can you point out which spec has this sentence? We need to discuss this further to see whether it is correct to say so if it does have this sentence.
Ok so the consequence of you statement is that there is no application code in TCK, no CDI bean, no EJB, no servlet, no JSP etc... (which is not true right?) so TCK are mainly a) application code and b) test code (sometimes c) runner code but let's integrate it in b)).
If you want one example, servlet 10.7.2 (for v4.0 to take one example) explicit it and for good technical reasons so it is a "must stay" but it implies TCK shouldn't reuse the same package by design and as it always had been so it let you org.eclipse for projects without an historical package (guess it is more than fine to keep the existing one when it is there).
2. What about user
confusion? "not care" :(?
Not sure what user confusion do you mean? TCKs are pretty much for implementers. Besides, I am not sure what confusions you are referring to. I think the namespace with jakarta.tck is clearer as it means the tck classes from Jakarta.
As soon as you get the dependency in a dependency - you are an user by definition - then you can get issues if you use jakarta.
It is also the case for end user - who never use tck package - on maven if they are released under jakarta groupId so as recommended in java ecosystem the groupId should be aligned on the package base name so likely use org.eclipse.jakarta.spec or alike. The risk is users start importing tck instead of the spec and application will work cause the spec comes transitively but it is not what jakarta wants, right? Making it clean is trivial and consistent with everything so I think it is worth not trying to be more clever than we need to.
@Emily: i know TCK are part of the spec as well as the API, javadoc and textual doc (pdf/word) but you didn't solve the 2 issues I mentionned (not even speaking of the inconsistency between the status and naming which is something very few will care except eclipse itself maybe) so not sure how the fact it is delivered as a whole solves the fact it is forbidden by spec to use this package.
Romain,
TCKs are part of spec, as spec includes api/spec doc /tck.
Thanks
Emily
@Emily: what's the plan about the spec saying jakarta.* should be excluded from the applications (which means it cant be used by TCK)? What about user confusion? "not care" :(?
We discussed the various package names including org.eclipse.*. The feedback is that TCKs should align with the corresponding spec. It is much nicer to start with jakarta.tck to denote the TCK classes and also easily to filter out with pattern matching when searching for api classes. Besides it is much shorter than org.eclipse.jakarta.
In Jakarta Batch Tcks, you will use jakarta.tck.batch instead of org.eclipse.jakarta.tck.batch.
Thanks
Emily
As written on jbatch list I think it is normal and safe to use org.eclipse.<something like jakarta.spec or just spec> since jakarta specs are eclipse projects. It also has the advantage to not use jakarta.* package which is treated specifically by all implementations (by spec actually ;)) and would need some specific rules in the impl is used for tcks too which is not the target of the spec at all. Lastly it makes it obvious it is not part of the API for users so it is very good too. For me, it looks like a consistent and good compromise for everyone (foundation, users, vendors and spec contributors/legal).
Sounds like a good improvement to me as well
> On Jan 4, 2022, at 12:23 PM, Emily Jiang via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
>
> I had this matter discussed in today's platform call. Below is the suggestion for the naming convention:
> • [Emily] Package naming convention for TCKs?
> • Packages for TCK starts with various names, e.g. org.ibm, org.jboss, org.eclipse, jakarta.[spec].tck etc,
> • Should they be standardized?
>
> • Two things need naming standard:
> • Packages
> • Suggested Naming Standard: jakarta.tck.[spec]
> • New classes in existing TCKs should use the new name standard
> • Artifacts
> • Same group id as the spec
> • Artifact ids [foo]-tck
> • Existing TCKs may change if they like
> New TCKs must use the new name standard
>
> The above is the general consensus from the meeting. I will start a new thread conversation for others to comment on the naming convention.
Others can chime in, but I like the above recommendation. Using jakarta.tck.[spec] is just as good as org.eclipse.jakarta.tck.[spec], perhaps better.
Also agree that it should be standard across the various TCKs.
-David
_______________________________________________
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
--
--
