[REVIEW] MicroProfile Config 1.0 Release Candidate

[Ondrej Mihályi]

Hi,

I've just created the Config 1.0 RC 1.

- GIT TAG: https://github.com/eclipse/microprofile-config/tree/1.0-RC1

- Maven artifacts in the Eclipse MicroProfile repository: 

  - API: https://repo.eclipse.org/content/groups/microprofile/org/eclipse/microprofile/config/microprofile-config-api/1.0-RC1/

  - TCK: https://repo.eclipse.org/content/groups/microprofile/org/eclipse/microprofile/config/microprofile-config-tck/1.0-RC1/

- Specification documents are attached in this email (in PDF and HTML)

Please review it and report any issues you discover.

If no issue is reported in 7 days, we'll release this candidate version as the final version of Config 1.0.

To use the Eclipse repository in your project, add the following into settings.xml:

<repository>
          <id>eclipse.microprofile</id>
          <name>Eclipse MicroProfile Repository</name>
          <url>https://repo.eclipse.org/content/groups/microprofile/</url>
          <releases><enabled>true</enabled></releases>
          <snapshots><enabled>true</enabled></snapshots>
</repository>

To add the API artifact as a dependency:

<dependency>
  <groupId>org.eclipse.microprofile.config</groupId>
  <artifactId>microprofile-config-api</artifactId>
  <version>1.0-RC1</version>
</dependency>

--Ondro

[Kevin Sutter]

Ondrej,
I like this idea of a RC.  But, based on your comments about any issue reporting...

>  If no issue is reported in 7 days, we'll release this candidate version as the final version of Config 1.0.

I'm wondering if this should labeled a Vote rather than a Review.  As you've probably noticed, I had created a [DISCUSS] thread for the MP 1.1 release.  The next step in my mind was to have a formal [VOTE].  But, I like this idea of an RC.  I hate to do a Discuss, Review, and a Vote.  Especially since I already received many +1 votes in the Discuss thread.  Sorry that I'm kind of hijacking this thread to discuss process.  Maybe we should spin this off into its own thread if we don't have a quick, concise answer.

Thanks,
Kevin

[Emily Jiang]

Good point, Kevin! Effectively this Review thread acts the same thing as Vote. Instead of introducing too many categories, I agree it makes sense to stick with Vote.

By the way, Ondrej, Mark and I discussed the Config release today. The semi-automatic RC step done by Ondrej is a best we can achieve within Eclipse's current infrastructure. This step is completely optional from Eclipse process is concerned, but we did so as we wanted to make the community feel involved. Let's make it less formal.

Here is my big +1 on releasing the above artifacts under Config 1.0. Great team/community effort!

Emily

[Ondrej Mihályi]

Hi Kevin,

I agree with you. What I actually planned to do is to have a vote after 7 days, a quick vote that starts and finishes in a day. However, I believe that we should separate any discussion/review from voting and introduce a voting application, e.g. using google forms or similar. Mixing of vote and discussion in one thread was always confusing, with some people voting, but some people discussing. We could always have a single [VOTE] thread, but any reply to that thread would count as discussion, while votes would be recorded separately to make it easy to count votes. I'd like if the Eclipse voting system could be used for this and any kind of vote, not only for voting about candidates for committers.

--Ondro

[Ondrej Mihályi]

One comment to the RC1:

I realized that all distributed artfacts should be signed by Eclipse sign plugin. RC1 isn't signed, but I already added the sign plugin and the nightly builds are already being signed. I will release RC2 soon with JARs properly signed.

--Ondro

[Kevin Sutter]

Let's move the process-related discussion to this thread:
https://groups.google.com/forum/#!topic/microprofile/wiFmzVshHLM

We can leave this thread for comments and voting on the RC1 for Config 1.0 -- although it sounds like there might be an RC2, so this thread might die anyway...  :-)

--  Kevin

[Ondrej Mihályi]

So far we have these issues:

 - an issue with signed JARs and CDI containers (not an issue with RC1, but already reported for nigttly builds) - it is already identified as a bug in OWB and Weld and it is already fixed in OWB

 - 2 minor issues with the feature itself - https://github.com/eclipse/microprofile-config/issues?q=is%3Aissue+is%3Aopen+label%3Ampconfig-1.0 (missing test for Date converters and scope of config_ordinal property)

I won't prepare an RC2 until these issues are resolved.

Meanwhile, I'll work on releasing artifacts in Maven Central. We already have a project there, now I need to automate this and document in the release procedure.

--Ondro

[John D. Ament]

One item came up early today.  Are we expecting each impl to ship their own version of the JARs, or is it wise to rely on the centrally managed version? 

[Emily Jiang]

It should be decided by the runtime. We should not enforce this. Neither does any other jsr jar enforce this either, IIUC?

Emily

[Emily Jiang]

I have added the tck gap and closed one of the minor issues. Ondrej, I'm ok with John's new wording with the spec clarification for the other issue. Can you double check to see whether you are happy as you were against the previous changes like me? Hope to close all the issues so that we can do a CR2!

Emily

[Alasdair Nottingham]

In that case should we have some kind of API verification check to make sure that implementations don’t extend the API? I think that the Java EE specs do this, and I know OSGi does.

Alasdair

--
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/82ddfb7d-d2f6-489e-a927-bcb7baf5eb8b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ondrej Mihályi]

What would be the reasons to do an API verification?

I guess that JavaEE and OSGi do it because of their license, which I think doesn't allow to extend the API.

But Microprofile is an open source project and it's free to extend it under the Apache license. So I think that as long as an impl passes the TCK it's OK. Extending the API shouldn't be forbidden, though it's not wise because it could clash with the future versions of MP and require breaking changes to implement future versions of MP.

Though, we could create a verification step to warn implementers that their API differs.

--Ondro

[alasdair....@gmail.com]

To ensure that each impl is shipping the right API. Yes the license allows them to make code changes, or to expand it, but I don't know if it would allow them to then call it Eclipse MicroProfile Config. In any case we could choose to validate that the API is compatible, not that it is strictly identical (although that would also be easy). I'm not saying we should, I'm just asking the question given other groups doing similar activities clearly though it was worth it. Some of the JCP API's are apache licensed because the RI is, but I still thought they implemented these kinds of tests.

[Jeff Mesnil]

I have check the code from 1.0-RC2 tag (https://github.com/eclipse/microprofile-config/tree/1.0-RC2) and it does not build 1.0-RC2 but 1.0-SNAPSHOT.

In that 1.0-RC2 tag, the POMs all uses a 1.0-SNAPSHOT (https://github.com/eclipse/microprofile-config/blob/1.0-RC2/pom.xml#L22)

It seems the release process screwed up somewhere.

jeff

[Emily Jiang]

I was in the middle of building 1.0-CR2. Looks like I screwed it up. I will do a 1.0-CR3 soon. 

By the way, re. signing jars, I checked with Wayne. Wayne said the jar signing is recommended but not required. If there are some issues, it is ok not to sign the jars. In this Config release, we will not sign the jar until Weld has fixed the issue https://issues.jboss.org/browse/WELD-2402. 

Emily

[Ondrej Mihályi]

I deleted the RC2 tag and recreated from scratch. The artifacts are deployed to Eclipse maven repo now.

But the release is not complete yet, there are still some manual steps required (the usual drill of saving PDFs, announcing the candidate, etc.)

--Ondro

[Emily Jiang]

From the RC1, John brought up some issues with the artifacts. We have now addressed the following issues:

- an issue with signed JARs and CDI containers (not an issue with RC1, but already reported for nigttly builds) - it is already identified as a bug in OWB and Weld and it is already fixed in OWB

Since signing the jar is not mandatory, we will not sign the jar until Weld has fixed the issue under this jira.

 - 2 minor issues with the feature itself - https://github.com/eclipse/microprofile-config/issues?q=is%3Aissue+is%3Aopen+label%3Ampconfig-1.0 (missing test for Date converters and scope of config_ordinal property)

With Ondrej's help with the release (Thanks Ondrej!), the Config 1.0 RC 2 is available.

- GIT TAG: https://github.com/eclipse/microprofile-config/tree/1.0-RC2

- Maven artifacts in the Eclipse MicroProfile repository: 

  - API: https://repo.eclipse.org/content/groups/microprofile/org/eclipse/microprofile/config/microprofile-config-api/1.0-RC2/

  - TCK: https://repo.eclipse.org/content/groups/microprofile/org/eclipse/microprofile/config/microprofile-config-tck/1.0-RC2/

- Specification document microprofile-config-spec.pdf here.

Please review it and report any issues you discover.

If no issue is reported in 5 days, we'll release this candidate version as the final version of Config 1.0.

To use the Eclipse repository in your project, add the following into settings.xml:

<repository>
          <id>eclipse.microprofile</id>
          <name>Eclipse MicroProfile Repository</name>
          <url>https://repo.eclipse.org/content/groups/microprofile/</url>
          <releases><enabled>true</enabled></releases>
          <snapshots><enabled>true</enabled></snapshots>
</repository>

To add the API artifact as a dependency:

<dependency>
  <groupId>org.eclipse.microprofile.config</groupId>
  <artifactId>microprofile-config-api</artifactId>

  <version>1.0-RC2</version>
</dependency>

Emily

[John D. Ament]

Hi Emily,

So just to confirm, that means the final JARs generated for Config won't be signed?  

If so that's great news, then there's just one issue I know of from a bug standpoint - https://github.com/arquillian/arquillian-container-weld/pull/40 - which hopefully gets merged soon.

John

[John D. Ament]

Emily,

One other question.  Were you able to get Optional<> support working in Websphere using both Weld and OWB?

John

[Emily Jiang]

Hi John,

Yes, the release artifacts are not signed. I'll take a look at the PR tomorrow. Thanks for your contribution! By the way, WebSphere only uses Weld for the config integration.

Emily

[Emily Jiang]

With Kevin's help (Thanks Kevin! The release script does not work on Windows:o), we have created the CR3 and this fixes a couple spec rewording, a javadoc clarification and an tck issue. Hope this is the final version of RC and then turn to the final release next week.

- GIT TAG: https://github.com/eclipse/microprofile-config/tree/1.0-RC3

- Maven artifacts in the Eclipse MicroProfile repository: 

  - API: https://repo.eclipse.org/content/groups/microprofile/org/eclipse/microprofile/config/microprofile-config-api/1.0-RC3/

  - TCK: https://repo.eclipse.org/content/groups/microprofile/org/eclipse/microprofile/config/microprofile-config-tck/1.0-RC3/

- Specification document microprofile-config-spec.pdf here.

Please review it and report any issues you discover.

If no issue is reported in 5 days , we'll release this candidate version as the final version of Config 1.0.

To use the Eclipse repository in your project, add the following into settings.xml:

<repository>
          <id>eclipse.microprofile</id>
          <name>Eclipse MicroProfile Repository</name>
          <url>https://repo.eclipse.org/content/groups/microprofile/</url>
          <releases><enabled>true</enabled></releases>
          <snapshots><enabled>true</enabled></snapshots>
</repository>

To add the API artifact as a dependency:

<dependency>
  <groupId>org.eclipse.microprofile.config</groupId>
  <artifactId>microprofile-config-api</artifactId>

  <version>1.0-RC3</version>
</dependency>

Emily

[Matjaz B. Juric]

In KumuluzEE we have a working implementation of the config framework for different config sources (env, properties, files) and for config servers – currently we support etcd and Consul.

It seems that our solution is not fully compliant with Config 1.0, however it might still be worth having a look. Particularly with config servers, you usually need to specify the root path for the config.

More on KumuluzEE config:
-    Basic config framework: https://github.com/kumuluz/kumuluzee/wiki/Configuration
-    Config server (etcd, Consul): https://github.com/kumuluz/kumuluzee-config

We also have a few samples:
-    https://github.com/kumuluz/kumuluzee-samples/tree/master/kumuluzee-config
-    https://github.com/kumuluz/kumuluzee-samples/tree/master/kumuluzee-config-etcd
-    https://github.com/kumuluz/kumuluzee-samples/tree/master/kumuluzee-config-consul

If something of this could be useful for MicroProfile, we’ll be glad to contribute.

Thanks, Matjaz

[Emily Jiang]

Thank you Matjaz for the useful info! It will be great if you can implement Config 1.0. The Config 1.0 supports different config sources as well.

After the first release, we will work on the v1.1, hopefully in a couple of weeks. We can take a further look at how best providing supports for different config sources, improve the dynamic update capability, many more. With your involvement, we might be able to borrow some useful KumuluzEE features. Will start a different thread on config 1.1 once Config 1.0 is out.

Thanks
Emily