[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-community] Naming and Package Name Concerns

Some comments in line.

On Sat, Sep 30, 2017 at 3:56 PM Martijn Verburg <martijnverburg@xxxxxxxxx> wrote:
Hi Thomas,

Responses inline.

On 30 September 2017 at 12:48, Thomas Andraschko <tandraschko@xxxxxxxxxx> wrote:
| However any new specifications (e.g. a Circuit Breaker specification) would have to use whatever new package naming scheme the community decides.

Hmpf... It must really say that it would be a shame if a new spec must use e.g. "org.eclipse.ee4j.circuitbreaker".
For me it would be no difference in using "de.someone.circuitbreaker" instead of "org.eclipse.ee4j.circuitbreaker". It feels like it will loose the "de-facto-standard"-feeling.

It may not be org.eclipse.etc.etc - that will be up to the community to decide - the specifications may be under a different (std?) package structure. That's the sort of thing we all need to decide together.

One of the things learned from MicroProfile, is that Eclipse seems to have a strong preference about java package naming. That project was expected to use org.eclipse.microprofile, based on comments at [1].

[1]:Âhttps://groups.google.com/forum/#!topic/microprofile/ZRnNjmVkQ5o
Â

Cheers,
Martijn

2017-09-30 20:41 GMT+02:00 Martijn Verburg <martijnverburg@xxxxxxxxx>:
Hi Reza,

On 30 September 2017 at 11:16, reza_rahman <reza_rahman@lycos.com> wrote:
The community at large has expressed several concerns with Java EE renaming. For some details on these concerns, please read here and on the related threads on the Java EE Guardians Google Group:Âhttps://groups.google.com/d/msg/javaee-guardians/J5Gf8ftlBc0/qxFAWcQhAwAJ. In particular, the issue that remains unresolved is whether or not this initiative will retain the possibility of using the javax packages for new and existing technologies. Can folks involved in the thus far at least somewhat closed process kindly comment on these issues?

Oracle very much intends to allow EE4J to continue to use the javax naming scheme for existing specifications / technologies and extensions of those specifications / technologies. However any new specifications (e.g. a Circuit Breaker specification) would have to use whatever new package naming scheme the community decides.

I'm personally very happy with that compromise.

I'm honestly not sure what people expected here, but this seems like the best solution possible. Oracle's made it clear since the beginning that the name wasn't going to move. They wanted to move their code, specs, etc into a foundation to allow the community to better drive it. Likewise, it's extremely common for foundations to include their name in the project's name. We do it Apache. Eclipse has made it clear that they do it. It's completely normal to do.

The continued use of javax for existing specs will create confusion. At some point, I suspect existing specs will move off of the name and into an org.eclipse name.ÂÂ
Â
Â
On a minor note, many folks in the community have not necessarily been very enthusiastic about the name of this initiative that they feel they had little opportunity to give feedback on.

Naming is hard, naming by a committee of thousands is impossible :-).
Â
I feel I also must ask you whether you can engage the community on the Java EE Guardians Google Group at least on this issue. While I and others will do our best to encourage everyone to engage with this effort, I do not think it is unreasonable for existing communities that care about these technologies to expect to be engaged on their own terms at least initially.

I'll repeat what I and many, many others have been advising at early F2F meetings with JUG leaders, Java Champions and JCP members.

The time to have a say in the future of Java EE is *now* and that place *is* the EE4J community at the Eclipse Foundation. There's no single vendor with defacto control so we have a blank sheet of paper to decide how this is all going to work. That work has to be carried out at the Foundation for Legal and Logistical reasons so simply put, the folks on the Guardians list who care about this and are willing to contribute *need* to come to Eclipse and this community, it's where all of the decision making and work will be done.
Â
Let me repeat a caveat I have tried to express privately several times now - not making real efforts to engage the community now risks this effort coming off as not sufficiently open and rather vendor driven. I believe the MicroProfile initiative currently suffers from this perception problem for very similar reasons. Please make efforts to ensure that does not happen here. It will mean all of the work so many of us have done for so long may get needlessly undermined.

See above, the Eclipse Foundation is the centralised place people should be coming to in order to have an impact for EE4J. There are lots of IP flow and other reasons why the decision making and work needs to be done at the Foundation.

I imagine the EE4J community will quickly form an outreach program to inform as well as encourage folks to contribute. But if those people don't choose to turn up then they won't have an equal say.

I'm forwarding this to the Guardians list as well.

Cheers,
Martijn


Â
Thanks in advance and I look forward to a new era in enterprise Java.

_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community



_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community



_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community

_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community