Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [config-dev] Introduction – Diego Silva
Hi Diego,

Nice to see that you want to join us and contribute to the Jakarta Config specification.

Currently, the specification project has been dormant for several years. We'll need to submit a progress review to keep it formally active and enable us to release a new version when we are ready. We plan to submit the progress review some time after summer holidays. 

The project is in a state where it attempted to recreate and improve the MicroProfile Config specification but then stalled due to endless discussions about adding or refining features. The current API is in a pretty good shape but it needs a review to see whether all is reasonable and can be released as version 1.0 of the specification.

I recommend reading the latest discussion about the current status and future of the specification on this mailing list: https://www.eclipse.org/lists/config-dev/msg00257.html

The specification has many committers, but only a few have expressed a desire to continue working on it. The hard question now is whether we can continue and finish what is already in the repository, or rather just take the latest Microprofile Config specification and possibly change the package name to jakarta.* and release it as Jakarta Config 1.0.

There are a few points which often lead into lengthy discussions and disputes and I believe are still open, without any formal or even informal conclusion:
  • Should we have the goal that Jakarta Config 1.0 is a successor to the MicroProfile Config spec and MicroProfile adopts it instead of MicroProfile Config?
  • If we base the spec on MicroProfile Config, should we keep org.eclipse.microprofile namespace or switch to jakarta.* namespace? I guess this makes sense only if we have the goal above (replace MicroProfile Config)
  • Should we focus on API for application developers, hence CDI-first approach, or primarily support Java SE API so that other Jakarta EE implementations can use it for configuration, even without a CDI dependency?
  • Should we support some additional features not yet covered in MicroProfile Config in Jakarta Config 1.0, or avoid it and postpone adding new features to later versions?
  • Should we drop some MicroProfile features that are obsolete or undesirable?
From your point of view, I also recommend exploring how the current Jakarta Config repository or MicroProfile Config aligns with your experience using Kubernetes ConfigMaps. Does the mapping from plain string properties match well enough or is a tree structure more suitable? Is it useful to distinguish between configuration properties and secrets or is it OK to treat secrets as regular configuration?

All the best,
Ondro Mihalyi

Director, Jakarta EE expert
OmniFish - Modern Jakarta EE Runtimes | www.omnifish.ee


On Tue, Aug 11, 2026 at 5:46 PM Diego Silva via config-dev <config-dev@xxxxxxxxxxx> wrote:

Hi everyone,

My name is Diego Silva, and I recently joined the Jakarta Config mailing list after speaking with Otavio Santana about getting involved with Jakarta EE specification projects.

I am a Java developer with experience working with Jakarta EE and related technologies, and I am currently particularly interested in configuration management. In my current work, I deal with Kubernetes ConfigMaps and applications running on AKS, which is one of the reasons Jakarta Config caught my attention.

I am here mainly to learn how the specification project works, follow the discussions, and contribute wherever I can. I have started reviewing the Jakarta Config documentation and GitHub repository, and I would be happy to help with documentation, examples, issues, testing, or other areas where the project needs support.

If there are any good first issues or areas that would be useful for a newcomer to explore, I would really appreciate any suggestions.

Looking forward to learning from all of you and contributing to Jakarta Config.

Best regards,

Diego Silva

 
_______________________________________________
config-dev mailing list
config-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org

Back to the top