MicroProfile 1.1 Proposal

[John Clingan]

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?

[alasdair....@gmail.com]

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

[Mark Little]

+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.

--
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.

[Otávio Gonçalves de Santana]

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

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/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+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/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

[Antonio Goncalves]

+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.

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

[Emily Jiang]

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

Emily

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.

[Ondrej Mihályi]

My opinions:

Ad. 1.1

 - we discussed to have releases each 3-4 months, 6 months at most. In this context, releasing 1.1 in 2Q 2017 seems too late to me. I suggest setting a release date to be in Feb/March to fit in 6 months since 1.0 (if we have something to release, but config seems promising and for me persnally it would be enough, plus finalizing the move to Eclipse)

- I suggest that health-check, JWT and fault tolerance rather target 1.2 (Q2/Q3 2017), to show that we can develop new version 1.2 in parallel with 1.1 in agile way

Ad. 1.0 

- We still need to formalize 1.0 more properly. As Mark pointed out, we don't have enough information about 1.0 release on the web page, no downloadables. We should formalize what is being delivered in each release, and improve the list later. 

    - E.g. for 1.0, we may deliver:

        - a formal document (PDF), which specifies what is MicroProfile 1.0, which specs it includes, and not much more (1 page)

        - a maven API artifact with MP dependencies

        - sample apps that should work on any MP implementation

        - the conference app as a reference app

    - For 1.1 or later releases, we could add a compatibility kit, but I don't think we have the time to do it for 1.0. We can backport the kit for 1.0 when ready, but that shouldn't stop us from releasing next MP versions 

Most importantly, we should have monthly conference talks about the direction of MP, at least for the Eclipse project contributors, but maybe open to anybody. We need a clear roadmap (timeline) and a momentum of periodic events to maintain agile velocity and get things done.

--Ondrej

Dňa utorok, 17. januára 2017 12:07:10 UTC+1 Antonio Goncalves napísal(-a):

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.

[Ondrej Mihályi]

I've already created a terminology thread here: https://groups.google.com/d/msg/microprofile/j9urpwSd6es/JKoDdnLNEAAJ

Here is my current proposal for the terminology: https://github.com/microprofile/microprofile/pull/2/files

Let's discuss the proper name for the compatibility kit there.

--Ondrej

Dňa utorok, 17. januára 2017 12:21:00 UTC+1 Emily Jiang napísal(-a):

[Mark Struberg]

TCKs stands for Technical Compatibility Kit and this term did exist long before Oracle used it.

We can freely use that term. Of course we must not claim "Java EE TCK" but only "Microprofile TCK".

LieGrue,

strub

[James Carman]

Yes, the term "Technology Compatibility Kit" (and the TCK abbreviation) seems to be fairly widespread in its use and is not particular to the JRE/JDK itself.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/4ec8d6ed-a5b7-447d-aab3-02daf31f2541%40googlegroups.com.

[Werner Keil]

+1 for the download page. Eclipse projects also have that by default, not sure, how a "hybrid" project does, that uses a lot of GitHub infrastructure or GitHub pages.

Also hard to say what the download would be for 1.0? ;-)
At the moment is is practically a Maven BOM pointing to 3 JSRs. Not much do download, you can and should use that BOM similar to e.g. Arquillian and others
https://search.maven.org/#artifactdetails|org.jboss.arquillian|arquillian-bom|1.1.12.Final|pom

There is a horrible mess I'm afraid if you search Microprofile:
https://search.maven.org/#search|ga|1|microprofile

Hammock already refers to a not even released dist-microprofile 1.1 from January 2 :-O
Except for the ws.ament namespace nothing suggests this was not a "branded" variant of Microprofile 1.1 already.

And all the others are equally bad or worse
org.wildfly.swarm.microprofile 2017.1.1
What's that supposed to be, Microprofile 1.1 from 2017 or Microprofile release January 1st 2017. And if so, what does it consist of, an exact 1.0 equivalent, a SNAPSHOT of 1.1 or something else???

Good (or to some Bad) old Java EE has been far more consistent. The latest API can be found under
https://search.maven.org/#artifactdetails|javax|javaee-api|7.0|jar

There are variations but that is the official API consisting of all Java EE 7 (Full) Ingredients.

There must be a solid versioning (also to some extent mandated by Eclipse release process) and in between of course a 1.1-SNAPSHOT version or 1.1-RC1 could be out (see the annual Eclipse Release trains) but not forks and customized variants of Microprofile all across the field.
Especially if a commercial, closed source product was shipped with
a bundle like org.eclipse.aether.api_1.0.1.v20141111 (the last part is the qualifier, so taking above Wildfly Swarm example, it only consists of a qualifier like version number) they know exactly what's in there and how it'll behave.

I used Aether as example, because Mark Struberg said he had an Eclipse committer from Aether (yet https://projects.eclipse.org/projects/technology.aether/who never mentions him, not even as historical committer?) and it has a nice separation of
- api
-spi
and other bundles many can probably be used as optional modules. Somethhing that would be highly beneficial to e.g. the configuration modules discussed here, too.

Werner

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.

[Werner Keil]

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

[Ken Finnigan]

On Tue, Jan 17, 2017 at 9:47 AM, Werner Keil <werne...@gmail.com> wrote:

+1 for the download page. Eclipse projects also have that by default, not sure, how a "hybrid" project does, that uses a lot of GitHub infrastructure or GitHub pages.

Also hard to say what the download would be for 1.0? ;-)
At the moment is is practically a Maven BOM pointing to 3 JSRs. Not much do download, you can and should use that BOM similar to e.g. Arquillian and others
https://search.maven.org/#artifactdetails|org.jboss.arquillian|arquillian-bom|1.1.12.Final|pom

There is a horrible mess I'm afraid if you search Microprofile:
https://search.maven.org/#search|ga|1|microprofile

Hammock already refers to a not even released dist-microprofile 1.1 from January 2 :-O
Except for the ws.ament namespace nothing suggests this was not a "branded" variant of Microprofile 1.1 already.

And all the others are equally bad or worse
org.wildfly.swarm.microprofile 2017.1.1
What's that supposed to be, Microprofile 1.1 from 2017 or Microprofile release January 1st 2017. And if so, what does it consist of, an exact 1.0 equivalent, a SNAPSHOT of 1.1 or something else???

There's no need to be nasty about a projects versioning choices.

Also, your confusing an API version with a vendors implementation version. Based on your logic its nonsense for WF v10 and GF v4 to support Java EE 7!

 

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/35a71b95-a083-4238-b72d-7d456e602884%40googlegroups.com.

[Werner Keil]

On Tuesday, January 17, 2017 at 3:52:25 PM UTC+1, Ken Finnigan wrote:

On Tue, Jan 17, 2017 at 9:47 AM, Werner Keil <werne...@gmail.com> wrote:

+1 for the download page. Eclipse projects also have that by default, not sure, how a "hybrid" project does, that uses a lot of GitHub infrastructure or GitHub pages.

Also hard to say what the download would be for 1.0? ;-)
At the moment is is practically a Maven BOM pointing to 3 JSRs. Not much do download, you can and should use that BOM similar to e.g. Arquillian and others
https://search.maven.org/#artifactdetails|org.jboss.arquillian|arquillian-bom|1.1.12.Final|pom

There is a horrible mess I'm afraid if you search Microprofile:
https://search.maven.org/#search|ga|1|microprofile

Hammock already refers to a not even released dist-microprofile 1.1 from January 2 :-O
Except for the ws.ament namespace nothing suggests this was not a "branded" variant of Microprofile 1.1 already.

And all the others are equally bad or worse
org.wildfly.swarm.microprofile 2017.1.1
What's that supposed to be, Microprofile 1.1 from 2017 or Microprofile release January 1st 2017. And if so, what does it consist of, an exact 1.0 equivalent, a SNAPSHOT of 1.1 or something else???

There's no need to be nasty about a projects versioning choices.

Also, your confusing an API version with a vendors implementation version. Based on your logic its nonsense for WF v10 and GF v4 to support Java EE 7!

 

Because there IS no API currently offered.
If it was it should be either io.microprofile-1.0 or say org.eclipse.microprofile_1.0_20170101 or similar (for an OSGi bundle or rather feature, since it does not have code other than those other APIs all of which should be in Orbit)
 

[Ken Finnigan]

On Tue, Jan 17, 2017 at 10:02 AM, Werner Keil <werne...@gmail.com> wrote:

On Tuesday, January 17, 2017 at 3:52:25 PM UTC+1, Ken Finnigan wrote:

On Tue, Jan 17, 2017 at 9:47 AM, Werner Keil <werne...@gmail.com> wrote:

+1 for the download page. Eclipse projects also have that by default, not sure, how a "hybrid" project does, that uses a lot of GitHub infrastructure or GitHub pages.

Also hard to say what the download would be for 1.0? ;-)
At the moment is is practically a Maven BOM pointing to 3 JSRs. Not much do download, you can and should use that BOM similar to e.g. Arquillian and others
https://search.maven.org/#artifactdetails|org.jboss.arquillian|arquillian-bom|1.1.12.Final|pom

There is a horrible mess I'm afraid if you search Microprofile:
https://search.maven.org/#search|ga|1|microprofile

Hammock already refers to a not even released dist-microprofile 1.1 from January 2 :-O
Except for the ws.ament namespace nothing suggests this was not a "branded" variant of Microprofile 1.1 already.

And all the others are equally bad or worse
org.wildfly.swarm.microprofile 2017.1.1
What's that supposed to be, Microprofile 1.1 from 2017 or Microprofile release January 1st 2017. And if so, what does it consist of, an exact 1.0 equivalent, a SNAPSHOT of 1.1 or something else???

There's no need to be nasty about a projects versioning choices.

Also, your confusing an API version with a vendors implementation version. Based on your logic its nonsense for WF v10 and GF v4 to support Java EE 7!

 

Because there IS no API currently offered.
If it was it should be either io.microprofile-1.0 or say org.eclipse.microprofile_1.0_20170101 or similar (for an OSGi bundle or rather feature, since it does not have code other than those other APIs all of which should be in Orbit)

I agree that MP needs an API, something like org.eclipse.microprofile.

However, org.wildfly.swarm:microprofile:2017.1.1 is NOT an API, it's an implementation.

 

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/08a01c73-b805-4fa2-8e0c-d6aea638d7c8%40googlegroups.com.

[Werner Keil]

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

[Ondrej Mihályi]

Hi, Werner,

Also hard to say what the download would be for 1.0? ;-)

Let me repeat my suggestion for 1.0 release again:

For 1.0, we may deliver:

        - a formal document (PDF), which specifies what is MicroProfile 1.0, which specs it includes and info about other deliverables, and not much more (1 page)

        - a maven API artifact with MP dependencies (as discussed already)

        - sample apps that should work on any MP implementation

        - the conference app as a reference app

What do you think?

--Ondrej

[Werner Keil]

On Tuesday, January 17, 2017 at 12:32:58 PM UTC+1, Ondrej Mihályi wrote:

My opinions:

Ad. 1.1

 - we discussed to have releases each 3-4 months, 6 months at most. In this context, releasing 1.1 in 2Q 2017 seems too late to me. I suggest setting a release date to be in Feb/March to fit in 6 months since 1.0 (if we have something to release, but config seems promising and for me persnally it would be enough, plus finalizing the move to Eclipse)

Based on the current config API/SPI there is not a single JUnit component test, so we're not even talking about compatibility or integration tests here.
What should Microprofile 1.1 contain within 3 to 6 weeks? A skeleton API with no test (code coverage) nor an implementation (if that's entirely up to vendors, then of course the API/SPI could be enough, but there must be someone's implementation before you can run a compatibility test regardless of its name)

Leaving the missing official Maven/Gradle style or other download for the 1.0 BOM aside, its API was a mix & match from established Java EE APIs that have been widely tested and although the Oracle TCK is neither Open Source nor modular, in theory one could even test their usage against them if they are Java EE licencees. So nothing too wrong with the 1.0 declaration.

Creating any own API even if it's just a single feature requires a level of maturity and quality to even pass Eclipse's own review by Architecture Council and EMO. That does not seem like a rubber-stamping to me (I did a milestone release for another incubating project) and although they seem to do this regular, project coordinators also have to request a milestone release review to be scheduled (take Aether again, with its latest releases, there is no release schedule for Microprofile yet: https://projects.eclipse.org/projects/technology.aether)

Maybe no need to wait till the official Eclipse release train in June (this year MP probably has little to add or benefit) but Jan/Feb seems overambitious. Considering it takes a very long time to even agree on merging 2 open PRs in the config module. With that pace, I doubt it's ready before April or May at the earliest.

Sorry but just being realistic based on the discussions and codebase.

Werner
 

[Werner Keil]

Sounds good to me.

Please ask Wayne how exactly this release would work but AFAIK it will also be controlled by the same Eclipse mechanisms that exist for every project, so as soon as those are delivered, reviewed and approved by the responsible groups of people, 1.0.0 shold show up in the Detail page https://projects.eclipse.org/projects/technology.microprofile

I would not dare to suggest an exact 1.1 date on my own, but with review mechanisms to pass even that 1.0 artifact won't be out before late January I assume (depending on how well IP checks and everything else progressed, that can take many months, I speak from experience both as Orbit committer and author/lead of components or JSRs Eclipse projects want to use but needs to wait)

Spreading the word, Ivar did a talk in London I believe. And propsed a similar one for DWX in late June (so as a coincidence it is practically the week of overall Eclipse Oxygen Release Train) with me as co-speaker (I am also in the PC of that conference, so unless considered biased I should have a say on Java related tracks)

I am not sure, if JavaLand has an official Microprofile talk (at least one by Andy Gumbrecht is mentioned in the program) but there are also community sessions for JUGs and other community members on Java EE some of us were invited to help. So in addition to an official track some "hacking" or "hands-on" activities at JavaLand should also be possible.
I can't say if a 1.1 release could be ready and mature enough then (late March) but for a Release Candidate to play with and test by real people and their solutions I would say JavaLand could be good.

Other events are in the first half of 2017. DevoXX FR or UK already seem to have CFPs. And since it's an Eclipse project, don't forget EclipseCon France, also normally in June ;-)

Werner

[John Clingan]

As it relates to a download / release page, I think it would help for the Tomitribe folks to perhaps do a quick training session on the site setup and editing. I think right now that only Tomitribe folks can actually push a change to production.

Can someone from Tomitribe set that up? We can record it as well.

[Kevin Sutter]

I really don't know where to start...  Yes, I agree that we had high ambitions at last year's JavaOne.  But, sometimes reality rears its ugly head...  Getting established within the Eclipse Foundation took much more work than any of us expected, and we're still not done...  So, although the request for 1.1 release in 6-8 weeks is consistent with our goals from last fall, it's just realistic.  We wouldn't have anything ready to constitute a 1.1 release in that timeframe.

I think in the next few weeks, we need to focus on getting the Eclipse environment and microprofile.io environment better integrated.  We need that 1-pager that Ondrej mentions.  We need a download page, even if it's just for our simple pom.  We need to get our github repo properly created and vetted.  We need to get our committers properly setup.  Overall, we need to look more organized.

Beyond that, we need to start narrowing down content for a 1.1 release.  Some type of TCK would be nice, but we also need some content to show that we're serious about developing code.  We have several ideas getting traction in our Groups -- Config, Health Check, Fault Tolerance, Messaging, Caching, and JWT propagation.  Yes, it would be nice to set a date and then see what's ready.  But, if we don't start putting some timeboxes around these efforts, there will be too much nirvana dreaming.  To that end, John and I selected three areas that seemed to be making progress and would have interest to our community.  We're open to discuss alternatives, but let's use some reality in our discussions.

Also, please refrain from poking holes in other people's efforts.  Most everybody involved with MicroProfile want this to be a successful effort.  Everybody is trying to do their best, especially given that most of the people here are volunteers and have other "day jobs" to contend with.

Bottom line, let's try to make this a productive discussion about what a 1.1 release could look like and when it could viably be delivered.

Thanks, Kevin

[John Clingan]

On Tuesday, January 17, 2017 at 11:18:20 AM UTC-8, Kevin Sutter wrote:

I really don't know where to start...  Yes, I agree that we had high ambitions at last year's JavaOne.  But, sometimes reality rears its ugly head...  Getting established within the Eclipse Foundation took much more work than any of us expected, and we're still not done...  So, although the request for 1.1 release in 6-8 weeks is consistent with our goals from last fall, it's just realistic.  We wouldn't have anything ready to constitute a 1.1 release in that timeframe.

 I think you mean "It's just *not* realistic" :-) 

 

I think in the next few weeks, we need to focus on getting the Eclipse environment and microprofile.io environment better integrated.  We need that 1-pager that Ondrej mentions.  We need a download page, even if it's just for our simple pom.  We need to get our github repo properly created and vetted.  We need to get our committers properly setup.  Overall, we need to look more organized.

Yes, ugh, a lot of work to get done here. I'll sign up to work on a MicroProfile 1.0 release page that we desperately need and Mark keeps ... ahem ... "encouraging" me to create :-) This can perhaps be the "one pager" as well. I prefer a web page over a PDF document.

 

Beyond that, we need to start narrowing down content for a 1.1 release.  Some type of TCK would be nice, but we also need some content to show that we're serious about developing code.  We have several ideas getting traction in our Groups -- Config, Health Check, Fault Tolerance, Messaging, Caching, and JWT propagation.  Yes, it would be nice to set a date and then see what's ready.  But, if we don't start putting some timeboxes around these efforts, there will be too much nirvana dreaming.  To that end, John and I selected three areas that seemed to be making progress and would have interest to our community.  We're open to discuss alternatives, but let's use some reality in our discussions.

+1, but then, you already knew that ...

 

Also, please refrain from poking holes in other people's efforts.  Most everybody involved with MicroProfile want this to be a successful effort.  Everybody is trying to do their best, especially given that most of the people here are volunteers and have other "day jobs" to contend with.

Bottom line, let's try to make this a productive discussion about what a 1.1 release could look like and when it could viably be delivered.

+1.1

[Mark Little]

Count me in to help where needed.

Mark.

--
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/6d89bf6f-e282-4584-89d3-ef64caa58607%40googlegroups.com.

[John Clingan]

OK, we can't let this thread die down quite yet. We need a plan. Given Kevin's last post, are there any strong disagreements to this proposal?

On Monday, January 16, 2017 at 3:28:12 PM UTC-8, John Clingan wrote:

[Alasdair Nottingham]

Not from me other than I'd like to see us aim to have fault tolerance there as well. 

Alasdair Nottingham

--

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/4a76ac0f-83e5-44f2-af0d-6d74c187c34b%40googlegroups.com.

[Mark Little]

+1

[Mark Little]

Maybe if we drop something from 1.1 but otherwise I’m worried we risk delaying 1.1. Now of course no one said 1.2 couldn’t be released quickly after 1.1.

Mark.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/948C8B37-28D3-426C-A1CB-91154F882D8A%40gmail.com.

[Martijn Verburg]

I'm happy with this - I was concerned that we hadn't actually drawn a line in the sand with 1.0.  Some of Ondrej's suggestions would help alleviate this for the the community at large.

+1 on a Tomitribe demo to deploy the site.  It's an area I could help maintain.

Cheers,
Martijn

--

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.

[Alasdair Nottingham]

I'm of the view that these are things to aim to have complete for 1.1 rather than a list of things we must have.  Any of them should be dropped if they don't complete before the end of 2Q. As I said before I'm skeptical of the security one completing due to the lack of real discussion and we should absolutely ship 1.1 without it if agreement isn't reached. 

Alasdair Nottingham

[Mark Little]

The security one should be mandatory. We discussed at JavaOne and agreed it was a priority. Nothing I've seen since would indicate it's not a priority though maybe not as sexy as some of the other things. However, we all know that security cannot be an afterthought and for that reason alone I would be fine dropping focus on anything else.

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/4a76ac0f-83e5-44f2-af0d-6d74c187c34b%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+unsubscribe@googlegroups.com.

[John Clingan]

I’m cool with adding fault tolerance as a stretch goal. If we make it, awesome. If not, It’ll add meat to MicroProfile 1.2.

[Werner Keil]

What exactly is "The security one"? Just JWT?
https://jwt.io/ created an entire organization simply around that RFC.
Either add something like the 4(!) existing Java libraries or have to ensure, a newly created one is as compatible as those are.
If jwt.io / Auth0 is the only place to purchase the certificates or not, if a newly-written Microprofile implementation of JWT is not listed on central places like jwt.io, I am not sure, if it'll gain industry acceptance.

As of now, Config seems to finally move after weeks of stallmate and endless discussions over ideologies and "Not invented here" (or "Wer hat's Erfunden") at least by one person on the list.
Which other goal or feature made similar progress?

Werner

[Ondrej Mihályi]

Unfortunately, little progress has been done on other fronts than config. It's great that with config, we have reached the point where we can continue developing an impl without much arguments about the API.

For most of MicroProfile implementations, I recommend choosing an already working project that is similar to the proposal, an only create a layer over it to bind to the MicroProfile API. It can be done with config too - if we choose Archaius or Tamaya. The only risk is that we would mix implementation details with the API. Therefore we need to strictly separate the agreed API from the implementation.

For security, we can base the impl on any JWT library, but we still need to define what we want to have in the token. But even more important is to decide on what we want to solve by the "security". 

It can be security within a service (roles, access to particular actions), or it can be security between the services (which service can be called by which services, etc.). In microservices, the most important is to solve that the services are accessed only by a limited gorup of services, so that multiple "microservices applications" deployed in the same environment don't collide. But this is for another thread...

--Ondrej

[Werner Keil]

I think you'll find several goals to overlap with what's alread been started in some cases or what is still being disussed there as well in others in the JSR 375 EG: https://java.net/projects/javaee-security-spec/pages/Home

Except Payara (no JCP member) many who are involved in this list or related projects (IBM, Red Hat, Tomitribe or individuals like Ivar and myself) also are members of the JSR 375 EG. So while areas like config can use a "sandbox" because nobody seems to have enough resources at this point to standardize it or maybe it just needs refinement of API in different places (Microprofile, Archaius, Tamaya or Spring) before standardization makes sense. The security standardization started. It may not have the same pace as JSON or CDI at this point, but some of the goals and user stories are well progressed. So maybe for security it is a good idea to look at what exists on its agenda before reinventing the wheel or trying to create yet another "Shadow JSR".

Werner

[Werner Keil]

Ondrey/all,

Coming back to your suggestion for 1.0 (see below)
I think it makes great sense, but especially for the Java/Maven based artifacts, one has to finally decide and put one's foot down on the namespace question.

1.0 was never officially deployed, so there's a chance to do this right from the first release on (which some other projects may not have had, thus a few had different package or other names for a while but except one all Eclipse.org projects use org.eclisep now AFAIK)

Werner

Hi, Werner,

Also hard to say what the download would be for 1.0? ;-)

Let me repeat my suggestion for 1.0 release again:

For 1.0, we may deliver:

        - a formal document (PDF), which specifies what is MicroProfile 1.0, which specs it includes and info about other deliverables, and not much more (1 page)

        - a maven API artifact with MP dependencies (as discussed already)

        - sample apps that should work on any MP implementation

        - the conference app as a reference app

What do you think?

[Alasdair Nottingham]

If any of those items are mandatory then we have broken one of the original tenants because we will hold up the release to get the content to fit, which is why other efforts are too slow. In any case my point is that while everyone has said it is important, we haven’t made any progress on agreeing what should be done for this security item. The goal was to agree what claims goes in the JWT so we can assert the identity, but we haven’t had sufficient discussion to come close to an agreement and I don’t see a meaningful dialog moving it forward.

Alasdair

[Mark Little]

Then we need to focus on getting it done. I've asked my teams to re-engage and hope others will do likewise. Whilst microservices that can cope with increases in load or failures of machines are great, I think making them secure first is a far higher priority.

Sent from my iPad

[Werner Keil]

While none of the other areas (config, health check or failover) seem close to a JSR or similar standard that's likely to be approved right now, Security has a standard effort: https://jcp.org/en/jsr/detail?id=375
Every corporate founder of MP plus a number of individuals who are involved in discussions or contribute to some of the projects are also in the JSR 375 EG, so what's the plan for security? Create "shadow specs" and APIs under org.eclipse.microprofile that might later move into JSR 375 and successors or try to engage and support the EG of that JSR to work on areas that seem important?

Alasdair

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/4a76ac0f-83e5-44f2-af0d-6d74c187c34b%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.

[Mark Little]

I’m kind of surprised we haven’t made more progress on this since JavaOne. I suppose security isn’t sexy compared to something like fault tolerance (and I speak as someone who has spent the last 30 years working in the area of fault tolerant distributed systems). But a fault tolerant, insecure microservice is a scary thought :) I’d much rather have secure microservices that fail periodically if I had to make a choice.

Mark.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/7f29e91a-4167-4915-96f9-80312c40fd92%40googlegroups.com.

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

---

Mark Little

mli...@redhat.com

JBoss, by Red Hat

Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)

[Ladislav Thon]

There's another school of thought where the idea would probably go like this: security breach would cost us a lot of money, but these happen relatively infrequently and there are ways to deal with them. On the other hand, if our app isn't available, then we're losing money far more quickly, and in the world of microservices, failure is a given.

Not that I have a strong opinion either way, just offering some food for thought.

LT

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/7f29e91a-4167-4915-96f9-80312c40fd92%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

---

Mark Little

mli...@redhat.com

JBoss, by Red Hat

Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)

--
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/66F8A56C-E79A-436C-8324-1FD024815128%40redhat.com.

[Werner Keil]

Incidents like that major IoT Hack (or even everything around the Trump election or hacking of his cabinet members in recent days and weeks) show, that security does not seem the highest priority even all the way up to the new POTUS ;-/

I would have hoped JSR 375 also made a bit more progress since I last did live demos in Tel Aviv late 2015. My overall talk on Security in Java EE was extremely packed in Sofia. Rudy's presentation of JSR 375 (with a few small demos I think but most of it was slides) was also quite popular. Luckily he had the first day, not the last, that made quite a difference.

He does have another similar talk at JavaLand. For DWX I must admit, we had a similar dilema and with JSR 375 just having passed Renewal Ballot 2 (and a new Spec Lead was appointed) I did not dare to propose or select it. There other topics like Jigsaw, Fabric8 or the more visual aspects of Microprofile (or the parts that are ready and work by then;-) are more "sexy". I had offered something based on Agorava, but even among my own proposals it seemed a little more "exotic" so it is not on top of the list right now for DWX.

Soteria works though and compared to e.g. the MVC JSR I would say there is enough "meat" to have a final JSR 375 for Java EE 8, but I would not speculate about OAuth, OpenID connect or JWT because I know all the pitfalls and real life problems you face with them from trying to connect Agorava to multiple social services on multiple containers ;-|

Werner

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/7f29e91a-4167-4915-96f9-80312c40fd92%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Werner Keil]

Yes, vulnerabilities and security breaches like this one www.silicon.co.uk/security/heartbleed-bug-alive-kicking-203571

Werner

[Mark Little]

I know of companies that have been sued into obscurity due to lack of security and if they could go back and trade-off security for availability then they probably would.

Mark.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CALbocOk%2BtSLkeBkBiw9qSEzQdLmwoBKo5VrQ0UuyOZbE1Z_Z7g%40mail.gmail.com.

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

[Werner Keil]

Yep, if you work for financial clients a lot, it's usually "security first" even when some of the new "FinTechs" or upcoming API providers may help to get Microservices or SCS concepts more familiar here, too;-)

Werner

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CALbocOk%2BtSLkeBkBiw9qSEzQdLmwoBKo5VrQ0UuyOZbE1Z_Z7g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Werner Keil]

Btw. the last 2 or 3 posts almost seemed to apply more to "Security discussion", a thread that looks like it was not followed for a while now ;-O

[John Clingan]

Here is a recommendation:

* Someone sign up as the security "lead". The lead should be a committer (unless they are in Eclipse committer limbo status that we need to resolve). Let's not have a 3 day discussion threads on this topic. It's intent that matters, not current state at this point. The lead responsibilities will include:

* Form a committee of interested parties. Not everyone has to be a committer to discuss, but only committers can commit (see prior comment)

* Defining the scope to meet the MicroProfile 1.1 time frame. The baseline should be what we discussed at JavaOne - JWT token exchange unless there is a reason to re-focus.

* Within a week (two? scope it), come back with an initial proposal to the broader community. Technically the discussion will probably be in a thread here, so we're probably already watching :-)

Any takers to be a security lead?

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/7f29e91a-4167-4915-96f9-80312c40fd92%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Amelia Eiras]

Hola everyone, 

This week, we started the process of transferring  MP.io to Eclipse.

 Once completed, we will dedicate enough time to train #usualsuspects, who are interested in learning how to deploy site & maintain it. :)

 [ FYI: let's make knowledge transfer on subject scalable by writing documentation from day 1- in advance GRACIAS!:) ] 

Cheers,  

[Werner Keil]

Sounds like a plan.

I have done a lot in security (e.g. back-port of a SAML Identity Provicer to an older version of a Java EE container to work in a "cloud" with newer versions that already support SAML) and a working committer account (even lead of another project) so happy to help. However if someone from one of the contributing companies (e.g. RH colleagues who are involved in PicketLink, KeyCloak, etc.) wants to take the lead on security, happy to help them, too.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/7f29e91a-4167-4915-96f9-80312c40fd92%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Clingan]

Thanks Amelia & Tomitribe!

--
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/5e3f9b0a-5def-4dea-b3e4-2856b127c2e4%40googlegroups.com.

[John Clingan]

Thanks Werner. Let’s give it a day or so to give all interested parties a chance and we’ll take it from there.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/cd7d72fc-0a13-4224-9781-27463c19766d%40googlegroups.com.

[John Clingan]

FYI to all, I've updated the MicroProfile presentation with a MicroProfile 1.1 slide.

[Werner Keil]

Thanks, we shall see how it progresses, but information like that will be handy when we talk about Microprofile on other occasions like DWX, EclipseCon (France,...), DevoXX or other events.

[Wayne Beaton]

The Eclipse Foundation does have a security policy and a security team [1].

Projects can do their own thing as well, but we do have a common entry point for all projects.

One of the challenges that we discovered relatively recently is that in GitHub Issues there is no way for the project team (i.e. committers) to have a private discussion around vulnerabilities before disclosing them publicly.

For our project teams that use Bugzilla, we do have a means of marking an issue report as "committers only" that can be used for a short time while the initial mitigation work is in progress.

Our current thinking is that we'll set up a Bugzilla category for projects that don't otherwise use Bugzilla to report issues and funnel vulnerability reports in that direction [2]. We anticipate that project teams will transfer (manually) issue summaries to their GitHub issue tracker after they've decided to disclose.

We're considering a modification to the security policy that requires that project teams provide a link to their security channel on the pages most likely frequented by their community (for most projects, this would be their downloads page).

The security team is relatively small by design. We are, however, in the process of growing it a bit to ensure that each of our top-level projects has at least one representative.

FWIW, in our experience, most issues regarding security tend to be delivered via our secu...@eclipse.org alias.

HTH,

Wayne

[1] https://www.eclipse.org/security/

[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=509103

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/3138d3f7-6517-4b04-8cd2-6b72c850b447%40googlegroups.com.

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

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation

[Werner Keil]

Wayne,

Thanks for the update. Do you suggest, the representative from the security team could also take the lead on that or should be involved?

I actively participated in several Eclipse projects over the yeaers. From filing bugs or issues to committing or leading one. I'm not listed in Microprofile, but beside some that don't show up (like Babel) I have 2 projects mentioned in my committer profile
None of the active participants (https://projects.eclipse.org/projects/technology.microprofile/who) have done anything in other Eclipse projects based on their profiles. Most work on at least one Apache project. Except for the mentors of course;-)

Would it be an option to have someone from the security team also lead the security effort? To help others based on his or her experience?

Regards,
Werner

[Wayne Beaton]

The security can provide feedback. After you feel that your policy is starting to take form, you can solicit feedback. It would also be a good idea to solicit feedback from the Technology PMC.

The security team does not generally have resources to lead these sorts of efforts. Their focus is more on the EF-wide policy.

HTH,

Wayne

--
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/99c47bb1-2250-4bd1-bfc3-47d1d0da3910%40googlegroups.com.

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

[John Clingan]

Thanks Wayne, this is good to know. However, perhaps I'm missing something, but I think we are speaking to two different things. I'm speaking about features for MicroProfile, and I think you are speaking to security vulnerabilities (in code/implementation). I think both are important, but I want to draw a distinction to see if we are speaking to the same topic.

Alasdair

To view this discussion on the web visit <a moz-do-not-send="true" href="https://groups.google.com/d/msgid/microprofile/4a76ac0f-83e5-44f2-af0d-6d74c187c34b%40googlegroups.com?utm_medium=email&utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href='https://groups.google.com/d/msgid/microprofile/4a76ac0f-83e5-44f2-af0d-6d74c187c34b%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" onclick="this.href='https://groups.google.com/d/msgid/microprofile/4a76ac0f-83e5-44f2-af0d-6d74c187c34b%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter';return tr

[Wayne Beaton]

Correct. I am speaking about vulnerabilities in project code.

My apologies if I've added confusion.

On the plus side, this did give me an opportunity to ensure that you are aware that we have a security policy.

Thanks,

Wayne

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/d3b5884b-ce73-4652-b46b-ac48179809a9%40googlegroups.com.

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

[John Clingan]

LOL, +1 wayne. All goodness :-)

[Werner Keil]

Thanks for the clarification Wayne.

[Kevin Sutter]

We need to resurrect this thread...  We need to close on the content of MicroProfile 1.1.  As John's original post indicated, we would like to announce the content of MicroProfile 1.1 in 2Q.  And, the obvious choice of conference is Devoxx UK in early May.  We already have a panel scheduled to discuss MicroProfile, so this provides a great opportunity.

This thread has jumped from topic to topic, but let's focus on just the content for MicroProfile 1.1.  As I read through the various proposals, google group threads, PRs, etc, I'm seeing progress on the following two features:

Config API 1.0
Fault Tolerance 1.0

The JWT Security effort is also making progress, but I'm not sure if it will be ready for MicroProfile 1.1.

And, the Health Check proposal may need some tweaking...

By "ready", I mean that we will need...

• completed specification
• completed API
• some type of implementation (reference or vendor)
• updated architecture (conference) app demonstrating the feature
  

"ready" does not mean...

• every vendor has a "microProfile 1.1" feature ready by Devoxx UK
  

Am I off in my analysis?  Please educate me (and others) if I'm reading the progress incorrectly.  With Devoxx UK about one month away, we don't have much time left.

Thanks!
Kevin

[Ken Finnigan]

From my perspective I think Config API is likely ready to be part of MP 1.1, barring minor cleanup tasks.

Beyond that I'm not convinced that anything else will be.

Another thing I've just thought of regarding MP 1.1. I presume this release will be going through the Eclipse IP and release processes which means a question must be asked about what we're proposing to announce at Devoxx UK?

Is it that MP 1.1 is available for use or just that the release is being started? If the former, I would imagine that release process would need to start now to provide enough time for Config API to go through CQ processes and for MP 1.1 BOM to be "released" through Eclipse.

Ken

[Emily Jiang]

+1 on Kevin's proposal. As for Fault Tolerance, I have been working closely with Antoine and John A and we are committed to cleanup the APIs and SPIs and get this proposal into MP 1.1. If MP 1.1 just contains Config, it is be too light after one year's evolution. We need to stretch to achieve more. Therefore, I would like to see MP 1.1 to contain:

1. Config

2. Fault Tolerance

Emily

[Kevin Sutter]

Ken,
The timing and content for MP 1.1 is somewhere in between your two suggestions...  I would like to have MP 1.1 available for "implementation" in 2Q.  We would have to start the clean up and release process soon so that implementors of the spec/api would have something to work with in 2Q.  Personally, I doubt that we could have this all ready by Devoxx UK. But, we should be close enough to be able to announce it at Devoxx UK, with a release later in May or June.

Aggressive?  Yes.  But, we need to keep this train moving...

Kevin

[Kevin Sutter]

Thanks, Emily, for your enthusiasm.  :-)  I'm iffy on Fault Tolerance myself (like Ken), but I'm hoping we can pull this off.

Kevin

[Mark Little]

Can we set a deadline for MP 1.1 and release with FT if it’s ready or just drop it if not and yet still do a 1.1 release?

Mark.

--
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/3acbe3f5-c237-4a63-8af5-7a3befaaf4d6%40googlegroups.com.

[John Clingan]

Devoxx.uk is an opportunistic release date. Conference-driven development :-)

I'm not really a fan of "pre-announcing", although it seems to work for the smartphone vendors :-) I'm not 100% against it. I guess the MicroProfile calendar would be great there to find out what the next conference after Devoxx.us is in 2Q.

The way I look at these features, they are "1.0" releases. We can iterate on them over time and incrementally deliver features, so we don't need to have every use case addressed in 1.0. That being said, we need to define the use cases that the 1.0 release does address.

Also, each vendor with MicroProfile 1.1 interest will need to be prepared to verbalize plans around MicroProfile, because the community will come asking for plans to implement.

[John Clingan]

Sigh, yes, good point. I'll look into this later today.

[John D. Ament]

Not sure if you got a chance, to look into this.

An issue came up in another thread.  Can we expand Microprofile 1.1 to indicate that Servlet spec is available?  Is that an Evolution Process thing?

John

[Ondrej Mihályi]

I think that any addition even of an existing spec is subject to the evolution process. Feel free to create a proposal to add servlet spec, or start a separate mailing list thread to discuss, in the same way as we do with other proposals. I suggest to collect and describe reasons why to do so though, because I don't that a plain suggestion to include it just because we can would have a high chance to be accepted.

--Ondrej

[Werner Keil]

As long as Servlet was optional (some runtimes/implementations will do perfectly fine with REST only) I see no problem with that.

@John C

Given MicroProfile 1.0 started as a pure "pre-announcement" between DevoXX UK and JavaOne '16 while the first real 1.0 deliverables were published no more than 3 weeks to 6 days (a bit sooner in Bintray/JCenter, just a week ago tagged and also deployed in Sonatype https://github.com/microprofile/microprofile-bom/releases/tag/1.0.0) maybe announcing 1.1 based on some form of Release Candidate or Milestone (as long as it meets the requirements of Eclipse Foundation for Incubating projects) with a formal Release review even scheduled, it does not sound so bad especially compared to how the 1.0 train went.

Werner