Use the eclipse naming convention

[Emily-Jiang]

All packages need to start with org.eclipse.microprofile

[struberg]

Please do not yet change it. Topic is still under discussion right now. I am very concerned that we should move an API which is intended to be vendor neutral under the package name and groupId of one of the Vendors.

[heiko-braun]

@struberg How far is org.eclipse.microprofile vendor specific? IMO it's vendor neutral and microprofile specific. But maybe we have a different understanding of the term vendor? From my perspectives the runtimes or framework implementing a microprofile API are considered "vendors".

[struberg]

@heiko-braun does Eclipse have an own servlet container and other JavaEE components in the microprofile area? Yes or No? Of course, Eclipse is not a Comany, but it surely is a Vendor in the Java Enterprise world.

[keilw]

Unlike @struberg Red Hat, IBM and others have been contributing to Eclipse projects for some time now ;-) There are underlying core components like org.eclipse.platform or others. Extended by vendor-specific bundles like com.jboss.devstudio.core in the case of JBoss Developer Studio or similar ones by IBM for Rational Application Developer or other products. There's an Eclipse servlet container Jetty. Although no working demonstration exists, there should be no problem deploying a Microservice app like the conference one to Jetty. CDI Spec Lead @antoinesd, myself and a few others did exactly that with Agorava socializer https://github.com/agorava/agorava-socializer. Out of the box a Maven goal deploys it to an embedded Eclipse Jetty container. Beside JBoss AS 7 or Wildfly 8.

[keilw]

Speaking of Jetty. It's a perfect example of a project that started under a different package structure and Maven group Id like https://mvnrepository.com/artifact/org.mortbay.jetty/jetty. And after 7.x This artifact was moved to: New Group org.eclipse.jetty

HTH

[heiko-braun]

@struberg @keilw I don't see how any of this relates to each other. IMO the spec, API and TCK developed under the name microprofile are completely separate from any framework or runtime implementing the API's, including a possible reference implementation.

From this point of view, it's perfectly valid to have API's in org.eclipse.microprofile and a reference implementation or software vendor adaptations in a completely different namespace. The result would be no different than the EE cases, where JavaEE API's reside in javax.enterprise.* but frameworks and runtimes use their own namespace for the implementation.

[struberg]

@heiko-braun except that it would be org.eclipse.microprofile.config. for the 'official' vendor neutral parts and e.g. org.eclipse.microconfig. or org.eclipse.jetty.microprofile.config.* for the impl.

That is imo just way too confusing for users. Technically it makes no difference of course. But from a user pov it is really does.

Using the very distinct top level package io.microprofile would make it absolutely clear that users get a portable API. And Eclipse already got the io.microprofile domain and rights handed over anyway, so it makes no difference from a legal aspect.

Edit: take javax. -> API vs org.glassfish. -> impl as example. It's very clear what the portable part is and what's part of the impl. My fear is that we would loose this separation if we would use org.eclipse.* for all of it.

[heiko-braun]

@struberg I see what you mean, also I would consider the jetty example an edge case. However I appreciate your suggestion and think it makes sense: io.microprofile.* for API and TCK sounds reasonable.

• Is anything preventing us from adopting this package name?
• Who do we need to consult for this?

[struberg]

Yes Heiko, it might be an edge case YET - but can we rule out that there will be a microprofile implementation hosted at Eclipse? Imo no, and it would even make perfect sense for Eclipse Jetty to do exactly that.

Is anything preventing us from adopting this package name? Who do we need to consult for this?

That's what I want to find out as well. Mike and Wayne for the boundaries I guess. So far it looks that there are already some Eclipse projects which do not use org.eclipse as package name and Maven coordinates. So I assume there is no show-stopper. And of course it's a community decision. At the ASF we have a VOTE in such a case [1]. All I try to do for now is to think ahead to detect possible problems upfront. Because at the end I hope we will have this work for quite some time I hope. LieGrue, strub

[1] http://apache.org/foundation/voting.html

PS: of course the pom and website will say that the microprofile effort is a proud Eclipse community project, but I think it would be really beneficial for adoption if the technical coordinates (package name and Apache Maven GAV) would have their own very distinct namespace.

[keilw]

Sorry @struberg but you keep beating a dead horse on that. this is NOT a JSR, everyone agrees on that (almost;-) There are RIs like org.eclipse.eclipselink for javax.persistence or JSON-B moving to its own Eclipse technology project after it used to be part of EclipseLink. The webpage microprofile.io is merely a convenience URL like

Looking at Apache, https://github.com/apache/manifoldcf/pull/6/commits/4169c5432199ec666127d52c593d8bf073a1fa43 is a similar ticket as this one where Apache ManifoldCF changed package naming to the "Apache Naming Conventions". I could not find a central place at ASF with naming conventions, but Eclipse has https://wiki.eclipse.org/Naming_Conventions

@waynebeaton was clear in https://groups.google.com/forum/?hl=en#!topic/microprofile/L1ygRRmb0q4 when he stated "We do require that projects use the org.eclipse namespace."

So there is no vote about it here as I interpret his statement (or response by official committers like Mark Little

If Apache Commons had a different groupId decades ago and some kept it for backward-compatibility, that is one thing, but there has not been a single Microprofile 1.0 deployment to MavenC entral or elsewhere yet, there isn't even a CI server that would push to JFrog or other Snapshot repos, so it's a clean slate and greenfield development here.

Which all new Apache projects that incubate now also obey. And again, ASF may leave this to a particular project as https://maven.apache.org/guides/mini/guide-naming-conventions.html or https://harmony.apache.org/subcomponents/classlibrary/pkgnaming.html (while Harmony is now in the attic, note This section is inspired by, and derived from, the Eclipse™ package naming convention documentation. with a link to above ;-D ) suggest, Eclipse doesn't and its naming convention even was used as template or carbon copy by Apache projects like Harmony, so please let's stick to it instead of endless discussions around things that have already long been decided.

[heiko-braun]

@keilw ok, i wasn't ware of that. so org.eclipse.microprofile it is. To quote Wayne:

We do require that projects use the org.eclipse namespace.

Let's move on.

[keilw]

Yes, he said that at least a day before @struberg blocked this ticket by claiming "discussion was still ongoing" ;-/

[keilw]

I also contribute to other Open Source ecosystems like Apache or the JCP but helped fix bugs of http://projects.eclipse.org/projects/webtools (with then BEA, now Oracle as key contributor, but Red Hat also is a major committer now) around 2005 in its incubating version 0.7 used by Java EE clients of mine. Bugzilla should have pretty much all those tickets available if they did not archive some for storage reasons.

[heiko-braun]

@keilw I would appreciate if you could leave out the hidden pointers towards @struberg and focus on the subject matter.

[struberg]

To quote Wayne: We do require that projects use the org.eclipse namespace. Let's move on.

Let actual facts speak: https://github.com/eclipse/vert.x/tree/master/src/main/java/io/vertx/core Of course Eclipse prefers to use org.eclipse.*, but it does not strictly require it it.

The question is: What makes the most sense from a technical, user and community pov?

[keilw]

Again it is one project of Hundreds, Martijn said was a special case and had been contributed based on a very large use case. Groovy being a language related project may have been excused at Apache, but the majority of new projects are not. This is not a JSR and org.eclipse is the vendor neutral package and ecosystem.

[keilw]

@heiko-braun Well it's @struberg blocking this and other issues for reasons that have nothing to do with the subject nor benefit the community.

[keilw]

Btw. http://vertx.io/ is not comparable to Microprofile at all because it clearly states

You can use Vert.x with multiple languages including Java, JavaScript, Groovy, Ruby, and Ceylon.

Of the 5 language examples only 2 (Java and Ceylon) even have the notion of a package or namespace like "org.eclipse.vertx" or "io.vertx". The others don't have it, therefore Groovy also doesn't really count as ASF example either because a lot of it deals with anonymous packages. That's the technical POV why one project in each ecosystem may have got a special exception from package and other naming conventions. Vert.x is also not under https://projects.eclipse.org/projects/technology like Microprofile, it is under the RT umbrella (https://projects.eclipse.org/projects/rt) similar to e.g. Jetty where package names and artifacts are all "org.eclipse.jetty" now (though it had a long history before, something Microprofile doesn't, there is no release that would require a backward-compatible .io package or namespace) 1.0 is merely a BOM that never got published to any Maven repository. Nor is there a release tag on any of the artifacts including https://github.com/microprofile/microprofile-config/releases

[keilw]

@heiko-braun Pretty much everyone involved in Microprofile has no prior experience with the process or conventions at Eclipse, that's not @struberg alone.

At Red Hat or IBM you have plenty of colleagues like https://projects.eclipse.org/user/617 you may ask. Since he's also committer to projects like JDT with a long history and relatively large number of committers, also some individuals, maybe you could and should ask some of them for advise. Apache License is not new to Eclipse on the other hand, plenty of projects e.g. around OSGi and Equinox look like they have Apache as the only license.

[rmannibucau]

Guys, I think you should about the users first, if eclipse doesn't want of a top level package microprofile then don't stay at eclipse.

If you will to do a project org.eclipse is fine, if you want to try to propulse a spec vendors will implement I fear org.eclipse will look like a vendor already (in particular if you have the implementation there which would be the worse kind fo ad you can get for a spec). org.microprofile or io.microprofile are likely the best you can do.

If the spec part needs to stay on github and eclipse only host the RI then be it but don't start by forgetting users and goal of the work done please.

[keilw]

io.microprofile was vendor spefic (registered by Tomitribe) until it was handed over to Eclipse Foundation, so if he's not too busy, I wonder what your managers (David or Amelia) at Tomitribe feel about that. They certainly were OK with Eclipse otherwise they would not have given away the domain. And since an Apache 2 License is quite common (in that case Eclipse suggested dual-licensing, but does not mandate or enforce, see Equinox and several other projects) that was no problem either. This thread had an extensive discussion about when or where to standardise: https://groups.google.com/forum/?hl=en#!topic/microprofile/JeAI19DkEXM

Mark Little among others nailed it with

Yeah, it’s when not “if for standardisation :) Then it’s where* :)

That thread made it pretty clear, now is not the time to standardise. Nor would eclipse.org, apache.org or microprofile.io a place to standardise. So please forget the Pseudostandard you clearly came from with this rogue JSR idea of yours earlier. Neither eclipse.org nor microprofile or another sane Open Source foundation would act as playground for this. And everyone who discussed the "JSR or not" topic made the impression of a consensus.

Sure, there are projects that went away from Eclipse, e.g. some OHF contributors left to something called http://www.openhealthtools.org/. I don't think they did any standardisation there either like e.g. HL7, OASIS or similar standard organisations do. Note the

Carequality / OHT Webinar about 2 years ago

Statement, so looks like OHT has been inactive for 2 years now. The remaining projects, especially STEM has been extremely active: http://www.eclipse.org/stem/ Not only because of emergency situations with Ebola, Zika or various flu outbreaks, but the team (who has a monthly call, I try to join that as often as I can) was also consulted by WHO and others.

STEM is a perfect example where a "standard" or "spec" (in this case EMF and the various flavors) is used yet again, STEM does this in a vendor-neutral way (though led by IBM) on top of the vendor neutral Eclipse EMF and ECore definitions.

So please don't pretend there is no vendor neutral foundation under eclipse.org. Those few who are not able to cope with Eclipse are more than welcome to move into "their OHT", but I don't think a large majority of contributing companies wants to do that right now.

In fact, with Babel http://www.eclipse.org/babel/ on top of language/resource bundles Eclipse succeeded where Apache projects failed. By creating a crowd-sourced content repository and translation service for i18n across multiple projects. Not only UI and IDE plugins, but those are more dominant. And vendor specific products like Lotus Notes, RAD or Adobe tools running on Eclipse and their users benefit from a unified standard translation where you know "File > Properties" will have exactly one translation per language and all products behave the same way. If a typo is fixed in Babel, all products using these message bundles immediately benefit from it.

[keilw]

Those who don't want to understand it, probably never will, but take Eclipse Team API (http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fteam%2Fcore%2Fpackage-summary.html an older version, but it's been there for ages)

A spec/API implemented by myriads of different team connectors. From CVS or PVCS in the early days to SVN or Mercurial and Git nowadays. And even more corporate products for solutions like Rational Team Concert and others. Some like SVN got at least 2 competing implementations. Where the official Eclipse project (can't call it RI here, but the one under "org.eclipse") Subversive never got the same user base and acceptance as its rival by contributors to Apache Subversion itself at CollabNet like @markphip.

[starksm64]

This needs to be assigned and closed with the org.eclipse.microprofile package prefix change done. The Eclipse foundation is about as vendor centric as the Apache foundation.

[rmannibucau]

@keilw acceptance by vendor is useless until you get acceptance by users, this is the whole point. Those who don't want to understand it, probably never will.

[struberg]

@starksm64 It seems your 'vendor' term is totally different from mine. Of course the ASF is as much a vendor in this as the Eclipse Foundation is. Not a commercial vendor, but it certainly IS a vendor. Or is the Apache TomEE server is not a microprofile player in your terms? If so we could also have done this as org.apache.tomee.config package. Imagine you would be a random user: would you think that this api would be vendor neutral? Of course not. And the same will happen with org.eclipse.* packages. We will not get any adoption that way. But apparently this is exactly what Werner wants...

[keilw]

No, Eclipse Foundation wants that as ASF practically every project (especially if they join the incubator now) to obey its name space and naming convention.

[keilw]

@rmannibucau Please ask @waynebeaton or check out download stats, if users accept or use those APIs. Everyone uses something like the Preference API, it has become as common as e.g.java.util.Properties in the JDK. Similar with other standards like the Team API. Whether you check your stuff out from Git, Mercurial or elsewhere everybody uses this API. Sure there are at least 3 other major IDEs, but Eclipse has a larger user base than those.

[keilw]

Actually Eclipse has not only Preferences but a Config API already. Both based on OSGi, http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/tree/bundles/org.eclipse.equinox.cm/src/org/eclipse/equinox/internal/cm So no dependencies to UI or IDE. It (OSGi) is widely used, both by "org.eclipse" and "org.apache" projects and many others.

[rmannibucau]

Are you saying "org.osgi.service.cm.Configuration" is in eclipse package and implemented by OSGi containers? Think you just messed up with links no?

Also think about usage, eclipse API you are talking about are a concentrators for vendors implementing it, here we speak about that side of a spec/API - which doesnt care about the packages, right - but also user consumption - which cares about package. (I see it as a graph, not sure it helps everyone but personally it makes it quite obvious).

Please don't take a random link to some code and try to use it to (poorly) defend your opinion. Build pro and cons and see what's the outcome.

[keilw]

The outcome is org.eclipse.microprofile has to be used otherwise you need to contribute to something else. Full stop. Don't try to beat a dead horse and prevent a module from being used by the release process. It needs review and @waynebeaton told us numerous times e.g. the entire "tck" (simple unit tests because it comes with an implementation instead of testing other implementations) has broken headers. Etc. If this repository violates them it won't be released. It's as simple as that and you cannot make up ridiculous arguments. Or listen to guys in this thread from companies involved in Apache and Eclipse or the JCP for ages.

[jclingan]

Let's continue moving forward with org.eclipse*. We need to do this for Eclipse process reasons reasons. Plus, I'm proud to be a part of the Eclipse Foundation! :-)

Let's now slow down forward progress on this point. We have an industry to move forward :-)

[rmannibucau]

You mix things again, you speak of headers where topic is package. Read again please and see the point: user consumption/facing side. Headers are not important there.

Eclipse doesn't require strictly org.eclipse package - sure you can send a tons of links showing it - and worse case API itself can be hosted outside eclipse organization (on github to take a very random place).

Please deal with the topic and avoid arguments like "it is like that" which just show you are not able to discuss/explain anything.

[keilw]

There are multiple, please check the other issues. And the headers must be in order, otherwise this won't be released. Sorry if you may not have had the experience here about those things, but I was involved in dozens of CQs on https://dev.eclipse.org/ipzilla/. Both up-stream and down-stream. Some work fast, others even for big companies take many months. Because of things like headers or license information missing. You have to discuss the package name with @waynebeaton, but I think everyone (but you) is sick of this discussion and wants to move on to at least prepare a release. Some rare exception even its committers said had good reasons (e.g. languages other than Java) are no valid arguments. And TomEE also uses org.apache, not something else, so why keep arguing here and not at Apache? It shows, you must have been among those who voted against this community and now try to make everyone's lives hard and miserable. While everybody else me included tries too get things going. Also from a process point. E.g. to finally release what was announced months ago.

[rmannibucau]

@keilw I'm sure you have a lot of kudos on stackoverflow but doesn't help to make this moving.

why not arguing at apache?

you still don't understand, please try to take time to read it and understand it. The point is not about implementations but only about API in term of "constraints" for end users (classname/packages, method signatures, what oracle provides as .sig). Fully ignore vendors/implementations there, they will adapt.

[keilw]

@rmannibucau Please just read all other inputs here, everyone says "go with org.eclipse".

Apache, why do you talk about Apache here, this isn't an Apache project. The license, sure, most of the OSGi/Equinox parts also use Apache License, too, but that's about it. There is nothing we need to ask Apache Foundation here, just listen to advise or requirements by Eclipse Foundation. And the project leads or mentors all said the same. Why can't you listen?

[rmannibucau]

@keilw well if nobody care i'll not fight for months but nobody got the point too I think and it makes the project dead as an API (not as an implementation) by design IMHO. Also I didnt bring apache there, you did (you don't even know what you write?).

[keilw]

@OndrejM just said in the mailing list:

I can understand your point of view, but let me remind you that we are creating a MicroProfile API in the >first place. A general-purpose API is not a priority for most projects that currently implement 1.0.

He does not have to convince me or most others who commented here, but @rmannibucau and @struberg still think they or this project must create a "Shadow JSR" or general purpose API here and now.

[rmannibucau]

adding microprofile or not doesnt help. Question is this one: do you create an API for a product extension OR an API for user usage with multiple implementations OR an API with a single implementation for user usage?

1. is typically IDE case
2. is what i expected @microprofile (can be wrong)
3. is what would mean using a not neutral packaging

[keilw]

Most of the APIs that get extended/implemented are not IDE specific. Projects like http://www.eclipse.org/che/ are Cloud-focused (in fact both Red Hat and Tomitribe are listed as contributors there) If creating a vendor-neutral API for Microprofile is the initial goal, then the vendor-neutral org.eclipse package is just fine. Should somebody decide to go for standardization (in a different place) then the public API may be in a different namespace, but those driving the schedule and content plans for MP (the guys here https://projects.eclipse.org/projects/technology.microprofile/who) feel a vendor neutral API for other microprofile components is something to focus on. Standardization may come later. A bit like Hibernate and other projects that later helped shape the JPA standard. Or Spring in other areas like Batch or JSR330.

Springs @Autowired and @Inject work more or less the same way in Spring apps (I get to help clients with a few right now) So not in the case of CDI, but for new APIs, the initial goal should be to create something like @Autowired that works fine for Microprofile like it did for Spring. And consider replacing or complementing it with a standard mechanism like @Inject when the time comes.

[rmannibucau]

I see, so still a "sandbox-like" (don't take it negatively, didn't find a better word this morning). In that case org.eclipse makes sense. Goal was not that obvious for me (and was probably too used to/biased by EE spec). Thanks for the clarification.

[keilw]

Pivotal also contributes to Eclipse, the Virgo runtime (https://projects.eclipse.org/projects/rt.virgo) plans another release in Q1/17 and looks like it could also (similar to Jetty) work for Microprofile. If this API does not mandate CDI but allows injection (by JSR330 as minimum requirement) I would not be surprised, if Spring/Pivotal also used or contributed to it.

[struberg]

The current proposal already describes the "@Inject Config" use case. And having something like @ConfigProperty and even injecting owner-style config classes is also perfectly reasonable. Nobody is arguing against this.

But first we need the foundation to take the information from. Then it's easy to write CDI producers.

[keilw]

Sounds fine. I believe a much bigger factor that influences adoption and usage is, whether the API can be injected (with @Inject making it fairly compatible with everything from CDI to Spring or Guice) or has mandatory dependencies to CDI API, than whether it's called org.eclipse.microprofile or something else.

[OndroMih]

Sounds fine to target JSR330 compatibility. It should be easy to do on the API consumer side, with plain @Inject and qualifiers. However, I'm not sure if JSR330 would be enough for an SPI, if we want to provide API to provide a custom config source. We'll see, but we don't have to have the CDI-based SPI in v1. I'll propose a CDI based API inspired by the Sabot project (by Tomitribe) soon, targeting only JSR330 if possible.

[keilw]

Maybe there's a way to offer certain SPI elements/bundles for basic use cases like JSR330 and others for more sophisticated ones, similar to CDI 2 with at least 2 "profiles" one for Java SE only and the other for Full Scale EE.

[smillidge]

I created https://github.com/microprofile/microprofile-config/issues/39 as an issue on the Config API to help define a CDI api to config.

[keilw]

Thanks, I was just about to suggest something similar because the last aspects of this discussion barely touch the question of refactoring to org.eclipse.

[Emily-Jiang]

Close this issue as all package names were updated to org.eclipse.microprofile by Mark.

[keilw]

They look OK especially from a package point now and in shape for the first Eclipse release (likely 1.1) Thanks for all who helped and gathering the ECAs by those who either contributed to PRs (and were not existing committers) or got mentioned via "author" tag.