MP-0006 List of built in properties

[John D. Ament]

All,

I've raised a PR for some proposed properties that can be expected to be included in MP 1.1.  https://github.com/eclipse/microprofile-bom/pull/7  I figure the BOM repo is the one that makes the most sense, since that's effectively where our actual release happens.

Any feedback? Properties we should include?

[Emily Jiang]

I prefer the MP 1.1 bom is as light as possible, merely an aggregation of multiple specs. Why cannot the MP006 be same as other specs as Config? It is fine without any other deliverables except the spec doc. I guess a number of similar specs will have to follow this route. In this way, we can easily decide whether to include a particular spec on MP 1.1 or not.

Emily

[Kevin Sutter]

John,
So, your proposal is to update the Architecture portion of the BOM spec?  But, the actual properties would be defined by other MP components (specs and apis)?  I tend to agree with Emily that this doesn't seem to fit with the BOM component.  Maybe what we really need is to start a documentation component?  Or, maybe even just a separate section of the BOM spec?  Not sure, let's see how this discussion thread continues.  The information just doesn't seem to fit in with the definition of the MP releases.

Thanks, Kevin

[John D. Ament]

Kevin,

Basically, yes.

The way I'm seeing it, this spec simply defines built in properties any user of Microprofile can expect to see as available.  I don't believe this is a spec in its own right, but an enhancement in the core MP.

John

[Emily Jiang]

If we lump more and more such little addons onto the release bom, very soon, we will loose control. For MP006, at least, there should be a light-weight spec to describe the use case etc. The proposal is not the deliverable though. It is completely ok to make the spec based on the proposal.

Emily

[John D. Ament]

Kevin,

Thinking out loud for a bit.  For one, I don't think every change we make to microprofile results in the creation of a new spec.  In this specific case, all I'm trying to call out is that an application developer using MP, or someone building other specs in MP/extensions to, can expect these properties to exist.  This to me is outside the bounds of the config spec (which in theory, config can be used outside of any microprofile container, by someone using it in a SE mode).  So it wouldn't make sense for this to be in the config spec.

I also don't think it warrants its own spec.  The change is the literal blurb I put out there saying these properties exist and this is what each means.  We would then expect an implementation to satisfy these requirements.  Maybe we want to include an interface that has these properties defined as constants, I'm not sure.  We could have a TCK, but today we don't have a TCK for the MP BOM, e.g. nothing checks that JAX-RS, CDI and JSON-P are available.

But this is all my opinion.  If we feel (as a community) that we want to see these common properties pulled out into their own spec, that's fine.  It's not a spec that could stand on its own mind you.

John

On Tuesday, June 20, 2017 at 8:17:09 AM UTC-4, Kevin Sutter wrote:

[Emily Jiang]

John,

My view is that MP releases e.g. MP 1.1 is merely the aggregation of individual specs. e.g. MP 1.1 includes spec a and b. If a runtime implements both a and b, it will be able to certify MP 1.1. If MP 1.1 itself has other addons, it is difficult to control. For each spec, surely it has to contain tck and spec no matter how small it it.

In this spec of MP-0006, I think a spec doc and tck need to be present. Otherwise, how you can verify a runtime implements this spec? I am against the idea of lumping any specs on top of MP releases without going through a proper process. In this way, MP releases will not be delayed unnecessarily. e.g. if we allow addons and the addons are having issues, MP releases will be stalled.

Emily

[Ondrej Mihályi]

I agree with Emily, this kind of functionality needs to be covered by a TCK and shouldn't be included in the umbrella spec to avoid confusion.

However, for small cross-concern enhancements, we should consider creating a single separate spec that would be relevant only when included in the umbrella and not be itself. I think that having many small specs which cover little functionality is confusing too. 

Another option is to turn this proposal into a more generic one, covering more aspects of e.g. web applications or some other related features. While in version 1.0 it could cover only standard config properties, in future versions it could define some other aspects on top of e.g. the Servlet JSR if it's included in MP.

--Ondro

[John D. Ament]

So then what do we want to call this spec? 

[Emily Jiang]

How about microprofile-misc? Under this repo, you can create builtin-properties-tck, builtin-properties-spec. my 2 cents.

Emily

[John D. Ament]

What about microprofile-platform?  These become the requirements of the overall platform to provide.

[Ladislav Thon]

Dne 6. 7. 2017 4:07 napsal uživatel "John D. Ament" <john.d...@gmail.com>:

What about microprofile-platform?  These become the requirements of the overall platform to provide.

I'd think "microprofile" itself is microprofile-platform, and it requires the overall platform to provide implementations of all specs from given MP release.

IMHO this doesn't need any special treatment and should be just another spec in MicroProfile, something like microprofile-common-config or microprofile-common-config-properties or whatever.

LT

--
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/775c6bc0-5dd9-426f-8aff-a11ee6b1d2a2%40googlegroups.com.

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

[Emily Jiang]

Maybe it is best to create a dedicate repo say microprofile-config-properties, which will make release much easier to be managed.

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.

[Ken Finnigan]

Unless the properties being defined can only be used with the Config API, I'd steer clear of having config in the name of the repo or spec as it implies a connection.

If they are properties that could be defined in any means, then maybe microprofile-properties or something more generic?

Ken

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/73129a41-3809-4ace-8986-a2375c56bf8b%40googlegroups.com.