Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.

Hi all,

I just chimed in and have read up on everything. For me as an end user, I hope that MP continues to stay flexible and try out stuff, where Jakarta can consume a stable stream. Hopefully without forking in such a way that they start deviating.

To quote Thodoris: "I hope we can agree to integrate them together. I don't know how yet, but that's why we're here, to figure it out together.". That's exactly my thoughts and sincere desire and one of the reasons that I'm around in these communities.


On Sat, 4 Apr 2020 at 19:21, Thodoris Bais <thodoris.bais@xxxxxxxxx> wrote:
Being quite new to all these discussions, my 2 cents are:

- I can understand the motivation behind keeping two different implementations (stability and flexibility)
- I still believe that keeping those two apart will be too expensive for everybody

That said, I hope we can agree to integrate them together. 
I don't know how yet, but that's why we're here, to figure it out together.


Op za 4 apr. 2020 om 18:18 schreef Scott Stark <starksm64@xxxxxxxxx>:
Good point.

On Sat, Apr 4, 2020 at 4:29 AM Emily Jiang <emijiang6@xxxxxxxxxxxxxx> wrote:
I have 2 comments to make:
1. It is orthogonal to debate here how good MP Config is. For different people, you might get a different answer. However, majority feedback is very positive. Sure, there is still room for improvement and more features need to be added to make it more powerful, more effective and performant. It is not perfect but it is  very useful already.

2. Let's just look at what Otavio needs and provide an answer in this thread. Otavio and I had a brief chat and went through his use case in terms of JNoSQL. It turned out JNoSQL does not require a full Jakarta Config spec but wants some JNoSQL properties to be visible to applications. In more details, there is no Config API dependencies required from the JNoSQL API jar. All JNoSQL needs  is to state some properties must be available to the applications as config properties. With the support of MP Config, the JNoSQL spec can state "refer to MicroProfile Config for how to look up the properties, e.g."
@ConfigProperty(name = "suffix")
private ColumnFamilyManager manager;
In this case, even though MicroProfile Config has made any subsequent changes, JNoSQL is not massively affected as it has no direct dependency on its jars. Only TCKs have direct dependencies on MP Config and they can just pick a version of MicroProfile Config and stick to it. For end users, they can choose the version of MP Config they want to inject JNoSQL properties.

Therefore, I think once MicroProfile has sorted the WG (hopefully in a few weeks), it should be feasible for JNoSQL to adopt MicroProfile Config and make progress. It will be much easier for JNoSQL to move forward to declare 1.0 release instead of waiting for a spec to be created and then releaased first, which could take a long time.

My 2cents.


_______________________________________________ mailing list
To unsubscribe from this list, visit

Thodoris Bais

_______________________________________________ mailing list
To unsubscribe from this list, visit

Back to the top