| Re: [jakarta.ee-wg] Verifying TCK compatibility claims |
I already made a note in the docment about other TCK modules to be used. If they all use the Java Module System that could help, but in either case it will be an interesting challenge to include multiple other specs or JSRs that may use something like Arquillian already. CDI does, Bean Validation and the Configuration JSR which although proposed and officially led by Eclipse Foundation as well stays under jcp.org for all I know, at least until the JSR 382 is Final. It’s intended to be used by many parts of Jakarta EE in upcoming Releases. Like CDI 2 it is meant to work both in a „Full EE Profile“ close to the entire „Platform“ extent, but also in a „Java SE“ type profile where IMO Arquillian at least with traditional Java EE containers would be an Overkill and wrongly applied. Werner From: Emmanuel Bernard I agree with Scott, we could add a phrasing mentioning that results are subjects to audit by a representative of the Eclipse Foundation and that any necessary technical artifact and help (doc?) must be provided at no cost. Back to one of James, comments, No TCK is very different than a non enforced TCK. TCKs are important because they help clarify text into testable code so even if not enforced it is a strong vehicle for portability and discussions. On Wed 18-07-18 21:17, Scott Stark wrote: >Since the TCK are now open source, why not look into a creating a common >test result logging framework that produces a tamper resistant result that >can be the basis of the compliance submission. This way there is no extra >effort in trying to rerun and verify the results. > >As Bill says, if I'm bent on cheating, I can easily provide an Arquillian >adapter that simply sets a single flag on a deployment indicating a TCK >test, and all the hacks are inside of the server framework. The TCK rules >can still say something like your results are subject to an independent >audit by a representative of the Eclipse Foundation. The rules for the Java >EE TCKs Bill mentioned have this requirement. > >On Wed, Jul 18, 2018 at 8:40 PM James Roper <james@xxxxxxxxxxxxx> wrote: > >> On Thu, 19 Jul 2018 at 12:37, Bill Shannon <bill.shannon@xxxxxxxxxx> >> wrote: >> >>> If you push this to the extreme, you'll need to see the source code for >>> the vendor's product so you can make sure they haven't implemented some >>> special "TCK mode". Obviously that's not feasible. >>> >> Well, if we're talking about extremes, why not go the other way, and have >> no TCKs, and just trust each vendor at their word that they've been careful >> and done their own testing to ensure they implement the spec? But we're not >> talking about extremes here, so there's no point in bringing it up. >> Publishing an Arquillian adapter as open source is a low cost, high value >> thing that can be done, extremes are irrelevant when we're talking about >> such a cheap win. It also provides a very simple starting point for the >> frank discussions and compromises that you're saying should be done when >> necessary, since it means everyone can start from the same meaningful >> place, "we've run the TCK against product X and found Y". Plus most, if not >> all Arquillian adapters for Java EE containers out there are already open >> source, so in most cases, adding such a requirement primarily reinforces >> what is already done, it doesn't add anything new. >> >_______________________________________________ >jakarta.ee-wg mailing list >jakarta.ee-wg@xxxxxxxxxxx >To change your delivery options, retrieve your password, or unsubscribe from this list, visit >https://dev.eclipse.org/mailman/listinfo/jakarta.ee-wg _______________________________________________ jakarta.ee-wg mailing list jakarta.ee-wg@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jakarta.ee-wg |