MicroProfile terminology

[Ondrej Mihályi]

Since I've seen some confusion in how we use some terms, here is a thread to discuss and agree on a unified glossary of terms we use to identify certain processes, resources, etc. This is to avoid future confusion.

First idea:

What about calling our internal MP incubating proposals "candidates" instead? E.g. a repository for config could be microprofile/config-candidate, or microprofile/microprofile-config-candidate

Other terms that come to mind are

 - candidate

 - prototype

 - concept

This term should refer to the work in process after a new proposal within the evolution process was accepted, and before the proposal comes to a final version so that it can be considered to become part of MicroProfile. E.g. a repository to develop an accepted proposal "new-idea" would be named e.g. "new-idea-candidate" 

Other terms that we already use:

 - evolution process - a formal process to evolve what is included the MicroProfile

 - proposal - a proposal for a new addition to the MicroProfile (a formal document describing what should be added and why).

 - specification - the final delivery of a "candidate" (see above), is a result of an accepted proposal, usually specifies an API or standard functionality,  may be included in MicroProfile. (this term is maybe not established so firmly, therefore feel free to discuss)

Other terms to agree on:

 - (reference) implementation - in a similar sense as a JSR (reference) implementation

 - compatibility suite/kit - which would test that an implementation is compatible with all or a subset of MicroProfile specifications. I liked the term MicroProfile Compatibility Kit (MCK)

 - reference application(s) - applications maitained by the MicroProfile project to demonstrate usage of MicroProfile 

--Ondrej

[Ondrej Mihályi]

I create a PR with a proposal for the initial glossary into the microprofile-docs repository:

https://github.com/microprofile/microprofile-docs/pull/2

Feel free to discuss also there.

--Ondrej

Dňa streda, 11. januára 2017 22:05:25 UTC+1 Ondrej Mihályi napísal(-a):

[Ken Finnigan]

On Wed, Jan 11, 2017 at 4:05 PM, Ondrej Mihályi <ondrej....@gmail.com> wrote:

Since I've seen some confusion in how we use some terms, here is a thread to discuss and agree on a unified glossary of terms we use to identify certain processes, resources, etc. This is to avoid future confusion.

First idea:

What about calling our internal MP incubating proposals "candidates" instead? E.g. a repository for config could be microprofile/config-candidate, or microprofile/microprofile-config-candidate

Other terms that come to mind are

 - candidate

 - prototype

 - concept

This term should refer to the work in process after a new proposal within the evolution process was accepted, and before the proposal comes to a final version so that it can be considered to become part of MicroProfile. E.g. a repository to develop an accepted proposal "new-idea" would be named e.g. "new-idea-candidate" 

I would lean towards "concept", as "candidate" can often have meanings associated with a near release. ie. release candidate.

 

Other terms that we already use:

 - evolution process - a formal process to evolve what is included the MicroProfile

 - proposal - a proposal for a new addition to the MicroProfile (a formal document describing what should be added and why).

 - specification - the final delivery of a "candidate" (see above), is a result of an accepted proposal, usually specifies an API or standard functionality,  may be included in MicroProfile. (this term is maybe not established so firmly, therefore feel free to discuss)

Other terms to agree on:

 - (reference) implementation - in a similar sense as a JSR (reference) implementation

 - compatibility suite/kit - which would test that an implementation is compatible with all or a subset of MicroProfile specifications. I liked the term MicroProfile Compatibility Kit (MCK)

 - reference application(s) - applications maitained by the MicroProfile project to demonstrate usage of MicroProfile 

--Ondrej

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b0035bbd-d862-42e6-8732-8e31ce36ad89%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Werner Keil]

As it sounded from Wayne's reply to threads like the one about renaming repositories, all Microprofile repositories should go under

https://github.com/eclipse.

5 projects that are on Github like that use the term "incubator". 

https://github.com/eclipse?utf8=%E2%9C%93&q=incubator&type=&language=

Those who browse through Eclipse on GitHub would find a familiar pattern if those common to Eclipse projects were used.

Not all have mirrors for Incubator projects on GitHub or some projects historically used SVN and have not migrated every project to Git yet, but e.g. Equinox also has an Incubator: https://www.eclipse.org/equinox/incubator/

So there is an incubation stage for all new Eclipse projects, but not sure, if that justifies using another term.

Sure we can, but that would make it harder for those familiar with other Eclipse projects or simply going through the list of all projects.

Werner

[Werner Keil]

Would it be an option to use the "evolution" repository not just for concept documents but for the actual code where a proposal is found worth coding?

The description "For the evolution of new ideas" says exactly that, so what speaks against certain modules started there e.g. the ideas around config mechanisms?

Werner

[Ondrej Mihályi]

I continune the discussion about TCK here (the original discussion), TCK should stand for "Technology Compatibility Kit", which is a general term. We can introduce our specific "Microprofile Compatibility Kit" (MCP), but I don't see any reason why we just couldn't use "TCK", or more specifically the "MicroProfile TCK" :) Except for a possible confusion with Java EE TCKs, but that's not enough to justify a different name.

--Ondrej

Dňa utorok, 17. januára 2017 15:48:45 UTC+1 Werner Keil napísal(-a):

I would say "compatibility testing". As there is no desire to standardize things, I doubt something like "100% Certified Microprofile" was in our interest either. So better call it "compatible" not "certified".

Werner

On Tuesday, January 17, 2017 at 12:21:00 PM UTC+1, Emily Jiang wrote:

+1. We are probably not allowed to use the term TCK. How about CT (certified testing :o)?

Emily

On Tuesday, January 17, 2017 at 11:07:10 AM UTC, Antonio Goncalves wrote:

+1

And what about working on a "TCK"(*) for MicroProfile 1.0 ? This would show that work is being done on 1.1, but also that 1.0 is "officially" supported by X, Y, Z implementors because "they all pass the MicroProfile 1.0 TCK". This would emphasis that it's portable.

WDYT ?

Antonio

(*) This is a terrible name, we should find something else.

On Tue, Jan 17, 2017 at 11:28 AM, Otávio Gonçalves de Santana <otaviopoli...@gmail.com> wrote:

Another think that we need, we talked about it previously, is a microprofile dependency, that has the three dependencies on the first version.

Such as:

io.microprofile:api:1.0.0

On Tue, Jan 17, 2017 at 5:27 AM, Mark Little <markc...@gmail.com> wrote:

+1

And we still need a 1.0 “download page”, i.e., something we can point people at which clearly and unequivocally indicated what was in 1.0, how to download it (not just forking/copying a github repo) and whatever else we agreed was in the release.

Mark.

On 17 Jan 2017, at 02:26, alasdair....@gmail.com wrote:

I agree we need to do a 1.1 release. I'm concerned that we announced last May and this May is fast approaching and there is just a 1.0 which doesn't look like the kind of progress we intended.

In the discussions at JavaOne we discussed having date driven, rather than function driven releases, with us putting what was ready in a release. As such I'd be concerned if we said all of these had to be in a 1.1 release. In terms of an aim they are good, but I think we should be aiming for a 1.1 release in 2Q and we ship what is ready, so if one of those isn't ready it wont be in.

In terms of things to aim to have ready I would like to see the Fault Tolerance as a candidate along with those.

While we have all agreed that we should have a JWT token definition given the lack of any substantive progress on defining what would be in such a token definition I'm skeptical it would make a 1.1 release. I know that David has suggested that it should contain a principal and a set of roles, but I remain unconvinced that Java EE roles should be placed in a JWT since they should have meaning in the context of a single Java EE application/service, not have a broader meaning across services. 

Alasdair

On Monday, 16 January 2017 18:28:12 UTC-5, John Clingan wrote:

With 2016 behind us and with 2017 ahead of us, we have a ton of opportunity ahead of us. With that in mind, let's plan MicroProfile 1.1. Kevin Sutter and I chatted about it a bit last week, and here is what we'd like to propose:

MicroProfile 1.1

• Features and justification in inclusion in the 1.1 release
• MicroProfile Configuration API (thread)
• Justification: This feature is the furthest along in real code and will force us to figure out some engineering processes. It is also more of a "code first" approach.
• MicroProfile Health Check API (thread)
• Justification: This feature has taken the approach of specification first. This will let us gain some experience with an alternative approach to "code first".
• MicroProfile JWT Token Definition (thread)
• Justification: We discussed this at JavaOne and agreed that there are some really good benefits to doing this:
1. Security is important and would have good functional and marketing value
2. A first-cut at bringing in external "standards" into the MicroProfile fold
3. Interoperability with non MicroProfile projects. Phil Webb (aka Spring Boot) showed interest in interoperating with MicroProfile. We want to be friendly with other ecosystems.
• Time Frame
• 2nd Quarter Calendar Year 2017

What we would like to get out of this release is some experience under our belts with various approaches to developing features. After MicroProfile 1.1 is released, we can review the various approaches and adjust our approach. As such, MicroProfile not only a feature release, but also a "learning" release.

We know that some decisions around governance and development processes remain, but the idea is to put a release stake in the ground and use it as a forcing function for us to move forward. There are also multiple discussion threads covering other features as well.  We can begin to add additional APIs in a follow-on MicroProfile 1.2 release and target it for the second half of the year (JavaOne??), and perhaps even get to a MicroProfile 1.3 as well. However, we have a lot to figure out between now and then :-)

Thoughts? Comments?

-- 
You received this message because you are subscribed to the Google Groups "MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/adc10683-9f8e-45c1-a200-cc8f17f7956d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/0683B06F-7863-437D-96F0-17E31DEBAC74%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

-- 

Otávio Gonçalves de Santana

twitter: http://twitter.com/otaviojava

site:     http://about.me/otaviojava

-- 
You received this message because you are subscribed to the Google Groups "MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAPc8kR3NuyNXQS%3D%2BkkZqWQdLNDcBMg-WOaE9gZYHEXWL81qeUg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

-- 

Antonio Goncalves 
Java Champion, Pluralsight author and CTO of AllCraft

Blog | Twitter | LinkedIn | Pluralsight | AllCraft | Devoxx France

[Ondrej Mihályi]

Werner, 

I agree now that TCK might create an unnecessary confusion, although I think that the wikipedia page is not entirely correct (first states that TCK is related to JSRs, but later it states that "The Technology Compatibility Kit for a particular Java platform is called Java Compatibility Kit (JCK)").

I would recommend using MicroProfile Compatibility Kit (MCK), following the same pattern as "Java Compatibility Kit".

And yes, the "C" should stand for "Compatibility", not for "Certification", as we're not intentions to certify anything.

--Ondrej

On Tuesday, January 17, 2017 at 4:10:11 PM UTC+1, Werner Keil wrote:

Wikipedia exclusively refers to TCK as JCP or Java based Compatibility Kits:
https://en.wikipedia.org/wiki/Technology_Compatibility_Kit

There is a project I have never used before (nor remember concously heard of) https://libvirt.org/testtck.html that indeed uses the term TCK (Technology Compatibility Test) and even others like "Maintenance Release" (also commonly used for JSRs, but it is unlikely to be protected by Oracle there) in its site and download pages.

Not sure if the 3-character acronym "TCK" adds much value over "Compatibillity Kit"? (or MCP for Microprofile Compatibility Kit if you prefer, I'm sure that stands for 5 other things somewhere)

I would not use "Certification" unless it really should be certified against a standard.

Werner

[Mark Struberg]

Ondrej, you found a perfect example for the argument that Wikipedia articles are not allowed as resource for academic publications ;)

Ftr I'm fine with both "Microprofile TCK" and "MCK". 

There are dozen TCKs already.

* CDI TCK, 
* https://libvirt.org/testtck.html

* http://projects.spring.io/grails-data-mapping/manual/guide/5.%20Using%20the%20Test%20Compatibility%20Kit.html

* https://github.com/raml-org/raml-tck

* http://www.ibm.com/support/knowledgecenter/SSDSNY_8.4.2/com.ibm.installingcmcmis.doc/cmscf014.htm

* http://www.appengine-tck.org/

... and about 20.000 more.

No need to shy away from the TCK term. It's just an abbreviation anyway.

LieGrue,

strub

[Werner Keil]

Of course there are many people who pay Wikipedia a lot of money, or would you imagine the article on Donald Trump being openly edited by the community?;-D

CDI is of course a JSR, so if you only mention that, there are over 300 more now (every JSR must have one, unless they got bundled with the JDK or so)

Not all, but a very large number of those run ont he JVM.

Take DevoXX, it does not seem, finding a new term has hurt it after "JavaPolis" ws prevented.

So even though it seems a lot less likely, that Oracle legal runs around and asks a license fee from every project with a TCK under that name, MCK is probably even safer.

Werner

[Mark Struberg]

Cmon Werner, JavaPolis clearly contains the trademarkt 'Java' term. Whereas TCK does not.

Even car makers use a TCK.

[Kevin Sutter]

+1, Mark.

MicroProfile TCK gets my vote.  Simple and everybody knows what's being referenced.

Kevin

[Werner Keil]

So do you prefer MTCK, MPTCK or MCK as Ondrey suggested?

Werner

[John Clingan]

Fine by me too. I do like the preceding "MicroProfile" (or preceding "M" for shortened MTCK) to show a bit of differentiation. Since we are using some Java EE technologies in MicroProfile and some of our work may end up in the JCP as a formal JSR and JSR-TCK, having a clear distinction is important to avoid confusion.

[Werner Keil]

Indeed, you scratch a valid itch. Most Java EE JSRs in question have no Open Source TCK (except CDI as you know;-) so right now for the 1.0 scope almost no JCP TCKs will be available except to registered and paying licensees. 

Let's see how JCP.next 5 goes, those who attended the London meeting or read the minutes soon will know what it hopes to archive. Although depending on its progress and finalization the effect will probably not be before Java EE 8 or 9 and the underlying JSRs (I am not sure, if e.g. like JCP 2.10 all Oracle led JSRs would be voluntarily upgraded to a JCP 2.xx including that)

Depending on who might propose or work on a hypothetical future Config (or other) JSR, if Eclipse or Microprofile was a valid collaboration environment, it is not impossible some of it could influence some JSRs

Werner 

[Mark Struberg]

Another question: what maven-coordinates do we use for?

1.) any API

2.) any TCK

3.) spec papers

4.) potentially also for default implementations.

I don't care about what we will end up, but we should be consistent and user friendly. 

Means our spec API jars should probably all end up in an own sub-group

E.g. 

<groupId>io.microprofile.api</groupId>

<artifactId>microprofile-config-api</artifactId>

Remember that the artifactId by default also will be used to determine the jar name. This will end up in e.g microprofile-config-api-1.0.jar

For non-finished APIs I would suggest to use an own groupId, like io.microprofile.proposed.api

That way we could also release these jars to maven-central - for the brave ones to pick up.

Once the community is happy with the spec it gets propagated over to the 'proper' groupId.

Wdyt?

The structure for the TCK and spec might either be analogous or we keep them together.

Probably keeping the same structure as with the APIs might work out well:

<groupId>io.microprofile.tck</groupId>

<artifactId>microprofile-config-tck</artifactId>

 

and 

<groupId>io.microprofile.spec</groupId>

<artifactId>microprofile-config-spec</artifactId>

Same trick as above but just with .proposed for not yet acked specs.

Oh btw, how to we ACK a spec? Majority VOTE with at least 3 +1?

Well, maybe a governance topic. Someone else please take over ;)

LieGrue,

strub