| Re: [jakarta.ee-community] "Eclipse Project for Java Batch"projectproposal |
What I personally see is an evolution of the technology.There is no doubt platform implementations are still geared towards the server-side/enterprise in some shape or form. For that reason we should keep the "EE" part in the platform. It is also a nod to the roots of the technology that we should not shy away from.It is just that individual technologies are often very useful outside the server-side/platform use case (that is nothing bad and is indeed very good). We should embrace this fact and drop the "EE" part where it does not add much value and in fact risks an impression that technologies are only or primarily intended for use on the server-side/enterprise/platform._______________________________________________Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone-------- Original message --------From: Raymond Auge <raymond.auge@xxxxxxxxxxx>Date: 12/21/18 1:43 PM (GMT-05:00)To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>Subject: Re: [jakarta.ee-community] "Eclipse Project for Java Batch"projectproposalI'm a little confused!The project is called "Jakarta EE Working Group", the domain is "jakarta.ee". The "about" page [1] mentions "EE" 16 times.If EE is not so important, why is it all over the place and referred to specifically as "the Jakarta EE brand".I'm neither for or against any of the naming suggested mentioned so far. I think the suggestions have all been fair in my opinion.What I am a little afraid of is there seems to be an identity crisis taking shape, and particularly with the addition of "stand alone" implementations (for which I am 100% a proponent of BTW) choosing or wishing to avoid the EE connotations.Is there some kind of disagreement with what EE means or implies?- RayOn Fri, Dec 21, 2018 at 9:25 AM Scott Kurz <skurz@xxxxxxxxxx> wrote:_______________________________________________Some replies (sorry not individually):
1) I like "Jakarta Batch" (or "Eclipse Project for Jakarta Batch) over "Jakarta EE Batch". The API is targeted to be useful in SE environments as well. The "Jakarta" part of the name references the "platform" and the fact that we also leverage the APIs and capabilities of the full platform when available, and are part of that platform, so I think the tie-in back to the platform is clear. Plus the name is shorter and less awkward.
2) Speaking of shorter, "JBatch" is overloaded/ambiguous by now, also used to refer to IBM's RI and Liberty JSR 352 impls, and the JSR 352 spec project. If the context is clear, it might be hard to stop ! But I'd rather keep that for informal reference only, not in anything formal.
3) As far as a timeless description, we already have this in the JSR 352 spec:
<quote>
Batch processing is a pervasive workload pattern, expressed by a distinct application organization and execution model. It is found across virtually every industry, applied to such tasks as statement generation, bank postings, risk evaluation, credit score calculation, inventory management, portfolio optimization, and on and on. Nearly any bulk processing task from any business sector is a candidate for batch processing.
Batch processing is typified by bulk-oriented, non-interactive, background execution. Frequently long-running, it may be data or computationally intensive, execute sequentially or in parallel, and may be initiated through various invocation models, including ad hoc, scheduled, and on-demand.
Batch applications have common requirements, including logging, checkpointing, and parallelization. Batch workloads have common requirements, especially operational control, which allow for initiation of, and interaction with, batch instances; such interactions include stop and restart.
</quote>
Is that the length we're looking for? We could always start fresh too... maybe include "ETL" ?
Thanks,
------------------------------------------------------
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
--------------------------------------------------------arjan tijms ---12/20/2018 04:41:14 PM---Hi, As Reza mentioned, some specs can be used standalone in SE, and as Wayne
From: arjan tijms <arjan.tijms@xxxxxxxxx>
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Date: 12/20/2018 04:41 PM
Subject: Re: [jakarta.ee-community] "Eclipse Project for Java Batch" projectproposal
Sent by: jakarta.ee-community-bounces@xxxxxxxxxxx
Hi,
As Reza mentioned, some specs can be used standalone in SE, and as Wayne mentioned "Jakarta" is the brand, and finally as Werner mentioned "Jakarta" can exactly stand-in for "Java" in the existing abbreviations (whether we should let eventually go of those is another matter, of course).
So given all those insights the simple Jakarta prefix might indeed work best.
"Jakarta EE" is then the name of the various Jakarta specs (APIs), so the last list again with Jakarta EE added:
Jakarta EE - All the specs further in the list
Jakarta Security - JSR 375
Jakarta Batch - Jbatch
Jakarta Transactions - JTA, retroactively meaning Jakarta Transactions API
Jakarta Validation - BVal
Jakarta Authentication - JASPIC, retroactively meaning Jakarta Authentication SPI for Containers
Jakarta Authorization - JACC, retroactively meaning Jakarta Authorization Contract for Containers
Jakarta Concurrency - CUJ, retroactively meaning Concurrency Utilities for Jakarta EE
A few names are as mentioned a bit more difficult, but *perhaps*:
Jakarta MVC - JSF, retroactively meaning JakartaServer Faces
"Servlet" is a somewhat unique name without an abbreviation. Once used as the opposite of Applet, which has finally been forgotten. Could perhaps simply officially become:
Jakarta Servlet - Servlet
Kind regards,
Arjan
On Thu, Dec 20, 2018 at 10:22 PM Werner Keil <werner.keil@xxxxxxxxx> wrote:I assume „Enterprise Security“ could be fine, but if it was for Consistency, we could also call it „Jakarta Enterprise Security“ in that case.
Werner
Sent from Mail for Windows 10
From: Wayne Beaton
Sent: Thursday, December 20, 2018 22:18
To: Jakarta EE community discussions
Subject: Re: [jakarta.ee-community] "Eclipse Project for Java Batch" projectproposal
For completeness, "EE" won't work as a brand. The brand that we're working with is "Jakarta". Whether we go with "Jakarta" or "Jakarta EE" is a matter that we can discuss. Personally, I don't think that "EE" adds anything (but the Jakarta EE Working Group may have an opinion on the matter).
Note also, that there's nothing in the Eclipse process that would prevent a "Jakarta Mail" project being responsible for producing the "JavaMail" specification and/or API, or force the change of any technical namespace. This extends to a potential (just a suggestion) "Jakarta Enterprise Beans" project that produces the EJB specification. My strong preference is that the name start with "Jakarta", but including it in the middle of a name can also work if there's a good reason.
Whether or not the names we select will stand up to trademark scrutiny is a separate question.
Wayne
On Thu, Dec 20, 2018 at 2:06 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,
It would be a good to re-think some of the names in the EE ecosystem. For now Jakarta EE Batch seems okay, but I could also imagine a Jakarta Batch or an EE Batch instead.
For example, as for JSR 375, that is now formally called "Java™️ EE Security API", and it doesn't have a well accepted abbreviation. Informally I often find myself saying "EE Security".
Going forward we could have:
EE Security
EE Batch
...
Or
Jakarta Security
Jakarta Batch
...
For some of the other specs this would be less easy, but I could for instance imagine a list like:
Jakarta Security
Jakarta Batch
Jakarta Transactions
Jakarta Validation
Jakarta Authentication
Jakarta Authorization
One if the criticisms against Java EE was all the abbreviations that bewilder people who are new to the platform. ES, JB, JTA, BVal, JASPIC, JACC, CDI, EJB, JSF, EL... although I personally got attached to some of those for me well known abbreviations, it may be time to let them go?
Just a thought though.
Kind regards,
Arjan
On Thu, Dec 20, 2018 at 7:14 PM reza_rahman <reza_rahman@xxxxxxxxx> wrote:
I generally agree with this viewpoint. Jakarta EE Batch seems perfectly reasonable.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
From: Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>
Date: 12/20/18 12:14 PM (GMT-05:00)
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-community] "Eclipse Project for Java Batch" project proposal
"Eclipse Project for..." is not intended to be a standard. We chose that, basically, as a work around to reduce some of the friction of bringing these projects over to the Eclipse Foundation.
By way of background, we need our project names to avoid infringing on trademarks held by others. There's a little grey area regarding which spec names are trademarked and and which aren't, we didn't have the name "Jakarta" sorted out at the time, and we didn't want to spend a week coming up with a bunch of new names, so we came up with this work around. At least in part, we went with this because I got tired of arguing about it, and "Eclipse Project for..." was the least bad option.
IMHO, "Eclipse Project for..." is meaningless and there is value in keeping "Eclipse" out of the names of the specifications. "Jakarta" is a brand supported by the Eclipse Foundation and so it can be used in project names. By way of background (again), we require that formal project names include our brand (e.g. "Eclipse Kura"); as a brand of the Eclipse Foundation, "Jakarta EE Batch" is (general trademark issues notwithstanding) a completely reasonable project name.
Our most recent project is named "Jakarta EE NoSQL". This feels like a better standard pattern to me. In fact, I'd love to see us rename some of the existing projects as we turn them into proper "specification projects". We might consider, for example, renaming "Eclipse Project for JAX-WS" to something like "Jakarta EE XML Web Services" (we might want to try and tighten that one up: "Jakarta XML Web Services"?). Note that I haven't fully vetted this from a trademark management point of view. Let's maybe save that larger conversation until the new year.
HTH,
Wayne
Wayne
On Thu, Dec 20, 2018 at 11:42 AM Kevin Sutter <sutter@xxxxxxxxxx> wrote:
Hi,
We are looking to move the Java Batch project under the Jakarta EE umbrella! The project proposal just went live!
https://projects.eclipse.org/proposals/eclipse-project-java-batch
This project proposal is now under Community Review. We are looking for comments and suggestions to improve the proposal before submitting to Eclipse for a Creation Review. The Creation Review won't happen until sometime in 1Q2019.
You are welcome to provide your comments via the proposal page, or via this thread in ee-community, or via private emails to either myself or Scott Kurz (the real lead for Java Batch). Only use this last option if there is something you just can't share more openly. Eclipse really promotes the use of open dialog, so we would prefer a public discussion on the proposal. Thanks!
FYI, a couple of comments already received verbally...
- Change the name to "Eclipse Project for Jakarta Batch" or maybe "Eclipse Project for Jakarta EE Batch". The "Eclipse Project for..." prefix is our "standard" prefix for Specification and API projects in EE4J, so that part won't change. But, changing "Java Batch" to either "Jakarta Batch" or "Jakarta EE Batch" looks reasonable.
- We need to expand on the Scope statement. The circular reference back to the JSR 352 page just doesn't cut it. We need to develop a "timeless" statement about the Java Batch technical content and direction.
Thanks!
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc._______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
--Raymond Augé (@rotty3000)Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community