Make avaje configuration an optional dependency

[kevin70]

803f1d8#diff-1d0bfbaa32a91bd0087f12efd057327390065a04460f7771c0fd082dd7909c68

Avaje configuration has become a mandatory dependency of the project in this modification. Can the logic be refactored to make avaje configuration an optional dependency.

Great, thank you very much. Looking forward to your reply.

[rob-bygrave]

Avaje configuration has become a mandatory dependency of the project in this modification

I don't think so. DbPrimary used to have a dependency on avaje-config and still does have a dependency on avaje-config ... so this hasn't changed.

Why do you think there was not previously a dependency on avaje-config? What am I missing here?

Background:
avaje-config is actually a library that was extracted out of ebean into a separate library (so that it can be used with projects that do not use ebean). Avaje-Config is a library that I maintain and for myself it is a priority for it to be "awesome" / the best external configuration library that I am aware of - there might be better ones out there but I am unaware of any that are better (more popular than avaje-config? Yes. Better that avaje-config? None that I know of).

Can the logic be refactored to make avaje configuration an optional dependency.

Well, historically ebean has always had the ability to "just work" using properties configuration and not programmatic configuration. In that sense there is potentially 18 years worth of applications out there that can work this way. In my opinion this is not the popular / expected way to do things in 2024 in that programmatic configuration (like Spring @Configuration @Bean is now the popular / expected way to configure and bootstrap a io.ebean.Database instance ... but we have a lot of history that works the other way.

[rob-bygrave]

make avaje configuration an optional dependency

Is there a specific motivation for doing this [apart from just being more lean / lightweight]? I wonder because there is at least one case where we desire dynamic configuration which is around L2 cache regions - these can be enabled and disabled dynamically (so we have some desire for dynamic configuration). Hmm.

[kevin70]

Why do you think there was not previously a dependency on avaje-config? What am I missing here?

Yes, DbPrimary uses the avaje-config, but you can choose to use environment variables or system properties to bypass mandatory dependencies on avaje-config.

I know that avaje-config is a very lightweight and user-friendly configuration library, and I will also use it in some specific projects. But when I use Springboot or Helidon, I choose to use the framework's own configuration management. What I expect is that in this situation, our dependency on avaje configuration is optional.

In the default constructor of ContainerConfig, avaje-config is directly used for initialization, so avaje-config must also exist at runtime.

For example, the implementation of DatabaseConfig.loadFromProperties. This approach is great.

[rbygrave]

So reverting that change to ContainerConfig via - #3357