Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-pmc] Specification project scope statements

Wayne,

Not sure you intended to use this thread for this purpose, but...

Since I've been struggling writing up the Jakarta Batch "Scope" statement, and examples seem lacking, maybe I'll throw out my latest attempt here:
https://projects.eclipse.org/proposals/jakarta-batch
to get feedback, comments what to include / not include, etc.


Here's the current "Scope" text:

> The Jakarta Batch project provides the specification along with the API and TCK for Jakarta Batch, and so promotes portability of batch artifacts across multiple compatible implementations.  

> The specification also facilitates artifact reuse by defining separate responsibilities for the developer of application artifacts and the designer of the job as a whole, with well-defined ways for the designer to compose a job from application artifacts and conveniently parameterize them with values for an individual job.  The specification defines a standard set of job statuses (such as COMPLETED, FAILED) but allows the flexibility for these jobs to be scheduled or orchestrated in any number of ways, and stops short of defining scheduling or orchestrating of multiple or repeated jobs.    Given Jakarta Batch's role as a component within the Jakarta EE platform, the specification intends to define integration with other components and APIs (e.g. JTA and global transactions), to allow developers to employ common patterns and best practices within the platform, and to be able to continually leverage innovation in the platform.  

Now, I don't want to waste anyone's time nitpicking over word selection and phrasing, so let me also break it down into bullet points of what I'm essentially trying to communicate:


* project consists of spec+API+TCK (NOT implementation)
* defines reusable Java artifacts composable in XML and parameterizable via XML + runtime
* does NOT get into scheduling of jobs; we stop short of that
- (the fact that it defines standard statuses is maybe unimportant here..not needed to set up the previous point as I was doing)
* intends to leverage constructs within the Jakarta platform
* intends to innovate along with the Jakarta platform

Again, if this is the wrong forum or thread, my apologies, but if this helps the discussion, then appreciate feedback.

Thank you,
------------------------------------------------------
Scott Kurz
WebSphere Batch and Compute Grid
Development and Level 3 Team Lead
http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102544
skurz@xxxxxxxxxx
--------------------------------------------------------


Inactive hide details for Bill Shannon ---04/01/2019 05:40:55 PM---Wayne Beaton wrote on 4/1/19 10:15 AM: > First, the scope stBill Shannon ---04/01/2019 05:40:55 PM---Wayne Beaton wrote on 4/1/19 10:15 AM: > First, the scope statement is for both the specification pr

From: Bill Shannon <bill.shannon@xxxxxxxxxx>
To: EE4J PMC Discussions <ee4j-pmc@xxxxxxxxxxx>, Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>
Date: 04/01/2019 05:40 PM
Subject: Re: [ee4j-pmc] Specification project scope statements
Sent by: ee4j-pmc-bounces@xxxxxxxxxxx





Wayne Beaton wrote on 4/1/19 10:15 AM:
> First, the scope statement is for both the specification project and the
> technology area. I had originally though of separating them, but figure that
> is too complicated.
>
> e.g.
>
> "Jakarta Persistence provides a specification document, API, and TCK that
> describes the management of persistence and object/relational mapping in
> Java(R) environments."
>
> So... "specification document, API, and TCK" describes the scope of the
> project (in that the production of these artifacts is in scope, and
> "management of persistence and object/relational mapping in Java(R)
> environments" is about the specification itself. My sense is that this is far
> more natural than trying to separate the two.
>
I thought we decided previously that specification projects would need to be
separate from TCK projects because specification projects need to operate under
different rules with different legal requirements.  Is that no longer the case?

_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc





Back to the top