-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use the eclipse naming convention #34
Comments
Please do not yet change it. Topic is still under discussion right now. |
@struberg How far is |
@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. |
Unlike @struberg Red Hat, IBM and others have been contributing to Eclipse projects for some time now ;-) There are underlying core components like |
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. HTH |
@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 |
@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. |
@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:
|
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.
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. [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. |
Sorry @struberg but you keep beating a dead horse on that. this is Looking at Apache, apache/manifoldcf@4169c54 is a similar ticket as this one where Apache ManifoldCF changed package naming to the "Apache 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 |
@keilw ok, i wasn't ware of that. so
Let's move on. |
Yes, he said that at least a day before @struberg blocked this ticket by claiming "discussion was still ongoing" ;-/ |
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. |
Let actual facts speak: The question is: What makes the most sense from a technical, user and community pov? |
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. |
@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. |
Btw. http://vertx.io/ is not comparable to Microprofile at all because it clearly states
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 |
@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. |
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. |
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. Mark Little among others nailed it with
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.
Statement, so looks like OHT has been inactive for 2 years now. 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. |
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. |
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. |
@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. |
@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. |
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. |
@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. |
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. |
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. |
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. |
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 :-) |
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. |
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. |
@keilw I'm sure you have a lot of kudos on stackoverflow but doesn't help to make this moving.
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. |
@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? |
@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?). |
@OndrejM just said in the mailing list:
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. |
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?
|
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) 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. |
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. |
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. |
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. |
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. |
Sounds fine to target JSR330 compatibility. It should be easy to do on the API consumer side, with plain |
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. |
I created #39 as an issue on the Config API to help define a CDI api to config. |
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. |
Close this issue as all package names were updated to org.eclipse.microprofile by Mark. |
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. |
All packages need to start with org.eclipse.microprofile
The text was updated successfully, but these errors were encountered: