Small changes to that:
* Should move the XML configuration format to its own module, too, for the
java.xml dependency
* Should remove the Jackson JSON configuration format as we have a
dependency-free JSON format in core (the YAML format support is based on the
Jackson JSON support, so this
I can tell you that some people I work with would use property files for
everything under the sun if they could...
Gary
On Wed, Nov 29, 2023, 9:29 AM Ralph Goers
wrote:
> I agree with this. IMO the only configuration syntaxes we should support
> are those we can implement with no dependencies.
FWIw, the situation you describe isn’t really any different than it is with
Maven. If I declare an optional dependency in a component it will not be
automatically included. A user has to add it to their pom.xml as a required
dependency for it to be included. That is really no different than a
I agree with this. IMO the only configuration syntaxes we should support are
those we can implement with no dependencies. At the moment that is JSON and
Properties (Ugh!). I would love to deprecate properties but I know that is a
non-starter since we didn’t support them for years and were
I think the overall goal should be to have no optional dependencies, no
surprises. I personally hope to never force YAML on anyone.
Gary
On Wed, Nov 29, 2023, 6:51 AM Piotr P. Karwasz
wrote:
> Hi all,
>
> I have been using a modularized sandbox project to test Log4j and
> optional dependencies
Hi all,
I have been using a modularized sandbox project to test Log4j and
optional dependencies are a nightmare.
Small example: if I use Log4j API in my project and I add:
requires org.apache.logging.log4j;
then when I run the app, the JVM will automatically add `log4j-api` to
the boot layer.
