Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[] Jakarta Batch PR for Service Release 2.1.1 for TCK challenges (plus process question)
  • From: Scott Kurz <skurz@xxxxxxxxxx>
  • Date: Wed, 8 Jun 2022 14:24:43 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4Sm67r5czk1tZfq9ytRFU11QJyjP7O1DmHxfDQz5yyI=; b=EiNPwof9pNWU4S/fXBGYCu4c2+16UvJWpNwT7SbgRCR/RwMQ+DPpV3X7fofSmh1KumNbAhKnaXG8mBOUlVnEBGyf56dcsojC+9PHw/0xaL7iUa/wBqg/ezIUdv6DXJOKpFrIbfgiE8/p2zOAqC6kpBwHc+3YKruRnD6COhmhGlPZqxMa9/LcCqRZWqORfF7LKeY64Kv7BqM4pQJjBtpceaV0TQeIAgApl5gWSZMB3kPa6J6q0GezjQNN3VkoxtJBOJim+PhQvy01z1KYe0jW8+q95RuNjFyA4SgkjaARC17fJGpmxqxSSjJfSJsP8SFd6RZA4mgBiTEVx0V4W88PdQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=T2BsNuXc9eCMrcks26uZagJ7pzJLk+Xy6dY8a6MdorayjVxB/zhAngr+7Wq8dnItjgyCwAt86wNnPt7x7FuiWxa9j5QiKslzCpFAoosF6VPfUjaqmdw+2HHq4+MPOwA+mPk87aGOHXmFKwFqc2UUhFowqZVqYc/bKec6rTxRl5HfRpeByeLB+L9ME8pp1UEvVlmsh2b3URjjCo49RZcv2i/ADvN4m61RGB379uKhl3MHOidk/3bAbOLy46dztHfiEfHahtydXLkLJ2RtVU8ebuZCncFJuEnqGObWhr2YdRSWPRRE5ckIQ4RnCyXcegM1OCOEJganXCTemyvqA6nw2g==
  • Delivered-to:
  • List-archive: <>
  • List-help: <>
  • List-subscribe: <>, <>
  • List-unsubscribe: <>, <>
  • Thread-index: Adh7Q36eBnEIkTTRSJqsar+6bAVIgQ==
  • Thread-topic: Jakarta Batch PR for Service Release 2.1.1 for TCK challenges (plus process question)

To respond to a couple Jakarta Batch TCK challenges, I staged a TCK v 2.1.1 update and prepared PR:

and service release record:


One thing I’m unclear on though, even after reading:

and browsing this list is what the requirements are for the api & spec artifacts.


I don’t think it’s helping anyone to release a 2.1.1 API artifact right now, and maybe confusing.    If someone bothers to investigate “what’s the difference?” and the answer is “nothing, it’s just to fit into a complicated spec process”, is that where we want to be?  But .. say we did find a very minor bug in the API later on.  At that point would we have to do a 2.1.2 service release record (per the Eclipse release project) and would it then be weird for the API version to jump from 2.1.0 -> 2.1.2?   Has this been considered before?


As far as the CCR itself, I’m not planning on creating a new one. Rather I’m thinking I’ll let the original issue of jbatch certified against TCK v2.1.0 remain, while adding a note to the certification issue that the implementation has been run informally against the new v2.1.1 TCK



On top of this there is an altogether separate point I need to eventually raise which is that, following Scott Marlow’s advice (, I actually modified the challenged test rather than simply excluding it.   We could oversimplify and say that before the test expected behavior A1, and now it accepts either A1 OR A2.   Ideally this would be raised as an update/clarification to the TCK process but I’m struggling some to put it into words, so for now just mentioning that this has come up.



Scott Kurz

Back to the top