It is tempting to jump a couple of numbers and call this hashtag issue number 25 to match the 25 year anniversary or Java. But I decided that I will stay true to the numbering scheme to avoid confusion and leave the craziness to when we are celebrating 25 years of Jakarta EE…
The Jakarta EE Working Group elections have completed. The newly elected committee members are as follows:
Marketing Committee Participant Member: Wei Yong Sen Committer Member: VACANT
Jakarta MVC was approved by the Specification Committee and is now listed among the other Jakarta EE specifications. As soon as the final paperwork has been processed and the project fully provisioned, we will make the initial contribution and immediately start planning for the first release under Jakarta EE which will be Jakarta MVC 1.1.
The web page for the Starter for Jakarta EE is launched! So far, it is pretty limited, but we hope that the community can join us in making start.jakarta.ee the absolutely best place to get started with Jakarta EE.
Please check out our project pages for resources about how to get involved.
This week, we got a new project proposal for a Jakarta EE Specification!
We finally got around to it and created the project proposal for Jakarta MVC. The proposal is to transfer MVC 1.0 (JSR 371) to Jakarta EE. Eclipse Krazo is already transferred, so this will complete the exercise and bring MVC over where it belongs with the other Jakarta EE specifications.
As soon as the project has been approved, we will release Jakarta MVC 1.1 under the JESP pretty quickly. This release will not include any code changes, and therefore still be in the javax.* namespace. Java EE references will be removed from the specification document and be replaced by Jakarta EE counterparts. The release will be published with the Jakarta EE maven coordinates.
The next step after this is to move everything from javax.* to jakarta.*. This will result in Jakarta MVC 2.0 that will be released simultaneously with, or directly after, Jakarta EE 9.
By doing it this way, and not jumping directly into the namespace change directly with the first release, we ensure that the specification is aligned with all the recent platform releases:
MVC 1.0 -> Java EE 8 Jakarta MVC 1.1 -> Jakarta EE 8 Jakarta MVC 2.0 -> Jakarta EE 9
For Jakarta EE 10, it would be natural to aim for getting Jakarta MVC included in the Web Profile.
In the end, I will remind you about the ongoing elections to the Jakarta EE working group. If you are eligible to vote, you have received information about how to proceed in your mail. The bios of all the candidates are available in the Jakarta EE Community Drive.
In the following video, you can watch an interview I did with Martijn Verburg regarding his nomination to the Jakarta EE Steering Group representing London Java Community.
When talking about YouTube, I have been busy recording a couple of tech tips for how to sign off your Git commits when contributing to Eclipse Foundation projects. All these tips are collected in a Playlist in the Studio Jakarta EE YouTube channel.
For convenience, I have listed a summary of the commands I used in the video here.
git rebase -i [hash of the commit before the one you want to fix]
# replace the word 'pick' with 'edit', save
# add signed-off comment to the commit
git commit --amend -s
# continue the rebase
git rebase --continue
# finally force push the updated commits
git push origin [your branch] --force
The answer to that is that I don’t know yet. It may make sense to merge them sometime in the future. Or keep them apart since the type of content may be a little different. My idea with the Studio Jakarta EE channel is to have a lightweight platform for Jakarta EE related content of varying types, such as interviews, tech tips, live streams, panels, trip reports from conferences, etc. So please, go ahead and subscribe to both. That way you are sure not to miss out on anything.
The nomination period for the Jakarta EE Working group elections has closed. Now, it is up to the candidates to convince you why they should get YOUR vote. To help with this, I have offered each candidate a short Studio Jakarta EE interview.
Next week, I will be conducting interviews with more of the candidates. So, tune in to Studio Jakarta EE to learn more about the candidates before casting your vote!
I know, it’s Monday and I am one day late…I usually publish these Hashtags on Sundays. My excuse this time is that it was such beautiful weather and I was busy preparing my boat for the season. Totally slipped my mind, but here we go!
Have you nominated yourself to the Jakarta EE Elections yet? If you haven’t, there is still time. The nomination period ends on April 24, 2020.
Serving on one of the Jakarta EE committees is an excellent opportunity to increase your knowledge about governance in general and Jakarta EE specifically. It is the best way to influence the direction forward and be a part of shaping the future of Jakarta EE. Who knows, it may even boost your career!
This is the third Jakarta EE Developer Survey. The survey last year had more than 1,700 responses from individuals around the World. Let’s beat that number this year! It provides valuable insight into the state of the community to better understand the top priorities for future Jakarta EE releases.
It has been an interesting week in the Jakarta EE community. The work with Jakarta EE 9 makes progress, but we still need any help we can get from the community. Make sure you tune in to the Jakarta EE Update Call on Wednesday for more information about how you can help!
The ongoing thread on the Jakarta EE Community mailing list regarding creating a fork of MicroProfile Config as a basis for a Jakarta Config specification goes on. Please make sure to chime in with your opinion there.
I think this discussion shows that it is important that Jakarta EE states how the technical alignment with MicroProfile (as well as other potential candidates for standardization) should be from a Jakarta EE standpoint. The MicroProfile community selected a Pull approach, which in plain words means that they will not initiate any standardization efforts with Jakarta EE, or anywhere else. The Jakarta EE working group should come up with a similar strategy, or statement, for how the technical alignment should be from the Jakarta EE side in order to end this confusion.
There is a very interesting discussion ongoing on the Jakarta EE Community mailing list about forking Eclipse MicroProfile as Jakarta Configuration. While the discussion on the mailing list initially is about the MicroProfile Config specification specifically, it also raises the question of how the strategy of Jakarta EE should be for technical alignment with Eclipse MicroProfile.
A couple of weeks ago, there was a vote in the Eclipse MicroProfile community about how the technical alignment with downstream consumers. Two approaches, the Pull Model and the Push Model were voted on. The Pull Model got the most votes, and thus was selected as the strategy for technical alignment.
In parallel, the discussions regarding the creation of a MicroProfile working group have been going on since October last year. Several suggestions have been explored, including separate working groups, a combined working group with Jakarta EE, or a combination of the two with two working groups linked together with an umbrella working group.
Whether there is a single working group, a group of working groups under an umbrella working group, or just independent working groups is actually not relevant to this discussion. The technical alignment will still be the same. The MicroProfile community has chosen the Pull Model, and this is something Jakarta EE needs to figure out how to relate to.
In my mind, it is pretty simple. Jakarta EE should create a fork of the specifications that makes sense to make a part of the Jakarta EE Platform. There are several reasons for this. I have touched upon a couple of them here.
MicroProfile wants to move fast and break things, while Jakarta EE wants to maintain a certain level of backward compatibility. By creating a fork, Jakarta EE won’t have to address this concern since it will then control the life cycle of its specifications.
Java EE, and by succession Jakarta EE, has always been a very cohesive platform. A central piece like configuration will be used throughout the entire platform and it only makes sense that it is in the same namespace as the rest of the platform.
By maintaining a fork of the specification, Jakarta EE is free to make modifications that are relevant for Jakarta EE, but maybe wouldn’t be relevant for MicroProfile.
As I pointed out in Hashtag Jakarta EE #11, the headache of diverging tines of the fork lands on the vendors that support both Jakarta EE and MicroProfile in the same product. Therefore, it is kind of interesting to see that the vendors that were most in favor of the Pull approach that are all shipping products that are both Jakarta EE and MicroProfile compliant. So, clearly, they must have thought about this and have a solution in place.