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

I prefer:

> in Jakarta EE applications
over
> for Jakartee EE application servers

I think it predicates itself less on the full application server idea.

- Ray

On Wed, Apr 3, 2019 at 2:07 PM Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote:
While I hadn't intended for this thread to be used in this manner, it seems like a useful thing to go through the process. Coming up with a good scope statement can be a bit of a struggle.

Before going too far, we need to bear in mind that the Jakarta EE Specification Committee must approve the scope statements. At this point, we don't know what criteria the members will apply.

I'm going to focus for now on the first paragraph/sentence.

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

I'd like to be careful to explicitly state that we mean "specification document" per the EFSP. 

The a big part of the purpose of building specifications is to "promote portability across multiple compatible implementations", so this sort of statement doesn't add value in a scope statement (though it is a good thing to remind the team and community of every once-in-a-while).

I'm thinking that you mean that Jakarta Batch is intended to describe a means for "Jakartee EE application servers to schedule, orchestrate, and manage batch processes". Or something like that. 

So, we end up with something like:

Jakarta Batch provides the specification document along with the API and TCK for describing a means for Jakartee EE application servers to schedule, orchestrate, and manage batch processes.

or maybe something like:

Jakarta Batch provides the specification document along with the API and TCK for describing a means for scheduling, orchestrating, and managing batch processes in Jakarta EE applications.

This is just my first attempt. Input welcome.

Note that it is reasonable to assume that the reader understands basic concepts like batch processing.

Details like defining job statuses are probably a little too detailed for a scope statement (the whole second paragraph feels like a good fit for the description).

Thoughts?

Wayne

On Wed, Apr 3, 2019 at 1:19 PM Scott Kurz <skurz@xxxxxxxxxx> wrote:

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






--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.

_______________________________________________
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


--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

Back to the top