Hi,
As I stated yesterday on the CN4J call, any adoption by either technology must retain its original namespace. I believe that any concerns regarding stability, vendor neutrality, API reviews, and technical details, can be worked on and fixed in a way that allows this to happen. If both communities work together, it should be possible.
If this is not the case, it seems we are just buying unnecessary pain for no good gain (implementors and consumers alike) and we need to question ourselves if this is the right model to follow.
Cheers, Roberto
I thought it might be useful for each of us to write our perspective on how we see the two projects align technically in principle.
The high-level Tomitribe perspective is basically:
- We see Jakarta EE as the brand behind which we can offer more stability to customers. We see MicroProfile as the brand behind which we can address parts of the market that are volatile.
I'd say "faster moving". Volatile has a number of negative connotations ...
<Screenshot 2021-08-11 at 09.31.53.png>
In addition, fast moving shouldn't be equated with unstable. Things, like software platforms, can be fast moving and innovative as well as offering stable aspects/components/modules, whilst new things are added or deprecated.
- We've deliberately not created anything in MicroProfile that would compete with Java EE (now Jakarta EE). All specs are complimentary. We'd like to see this "no duplication" and "no competing" principle last and be bi-directional.
+1 on the collaboration and no competing efforts. At the very least, lets not split the communities. I can't see Red Hat committing efforts to a spec in one area, say Jakarta, only to have some other vendors want to spin up a similar or competing effort in MicroProfile. Doesn't make sense. Wastes time and energy. Also causes users to walk away.
- We are happy to see specifications move from MicroProfile to Jakarta as needed. The Jakarta version of the spec would be under `jakarta`. The MicroProfile version would cease to be developed, but could still be shipped as frozen for a period of time.
Gotta disagree with you here. If specs move across, in either direction, they should retain their original package namespaces unless there are compelling reasons to convince users (community and customers) that they should change their code in a non-backwardly compatible manner. We've all been there recently with the javax namespace issues and it's not something I want to see repeated.
None of the above should be confused with innovation. We don't see that innovation stops on a spec, regardless of where it is in its lifecycle.
It's really more about volatility of emerging sections of our industry where things are created and obsoleted quickly. By definition you can't create a stable spec on something that is itself unstable. In the past we did all of this under one brand and that has its own set of disadvantages and risks.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
_______________________________________________
cn4j-alliance mailing list
cn4j-alliance@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cn4j-alliance
|
