You need to omit the EEs in your proposal, als CDI is not a EE-only technology. You can use CDI with Java SE also. -Markus From: jakarta.ee-community-bounces@xxxxxxxxxxx [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] On Behalf Of Werner Keil
Sent: Freitag, 21. Dezember 2018 01:53
To: Jakarta EE community discussions
Subject: Re: [jakarta.ee-community] "Eclipse Project for Java Batch" projectproposal Bean Validation is not part of the Jakarta stack right now. So rebranding it to Jakarta Validation sounds a little odd in this case. Even if the Spec Lead may change to IBM sooner or later and it could follow what's done with the Batch spec, the JSR is just called "Bean Validation" and has no "Java" or "J" in the name. So maybe "Bean Validation for Jakarta EE" could be a more gentle transition from the JSR if it ever got to. Similar with CDI, it only had the term "for Java" in the title, but not in the acronym. So "Contexts and Dependency Injection for Jakarta EE" might seem best if it became a genuine part of the Jakarta EE stack rather than being an external dependency right now. 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 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 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 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. 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: For some of the other specs this would be less easy, but I could for instance imagine a list like: 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? 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 -------- Date: 12/20/18 12:14 PM (GMT-05:00) 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. 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
-- 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
|
