Hi Ralph, Currently Gradle does not have any tooling to help a Maven build produce Gradle Module Metadata. So a PR might be a challenge, mostly because it will have to do a lot to limit duplication. Any chance that Log4J 2 would consider adopting Gradle as the build tool? A migration + adoption of the feature might be an easier thing to achieve, though I would understand this feature alone could be too little motivation.
As for discussing this feature, and others provided by Gradle Module Metadata, Cédric Champeau and I met with some of the Maven developers at Devoxx Belgium back in November 2019 [1] to present the reasons and features of this new metadata format. Regards, Louis [1] https://twitter.com/aheritier/status/1192086444027846656 On Mon, Jan 20, 2020 at 3:41 PM Ralph Goers <ralph.go...@dslextreme.com> wrote: > We would certainly accept PRs to support the feature, assuming they > include tests that we can run to verify them. I have no idea how easy that > would be to do since Log4j 2 uses Maven as its build system. > > Out of curiosity, have you mentioned the metadata to the Maven team? I > know one of the problems they have had for years was figuring out how to > add more information to the pom since they made the mistake of adding > schema validation to it which pretty much makes it impossible to extend > without breaking builds that use older releases of Maven. > > Ralph > > > On Jan 20, 2020, at 7:04 AM, Louis Jacomet <ljaco...@gmail.com> wrote: > > > > Hello, > > > > The Gradle dependency management team developed a plugin [1] in parallel > to > > writing a blog post on the Gradle blog [2] that shows how Gradle can help > > detect invalid logging setup at build time using Gradle’s new > capabilities > > concept [3]. > > Feature wise, the plugin can detect invalid setups involving Slf4J and > > Log4J 2. In addition, it offers configuration options to enforce a > selected > > logging solution if conflicts are detected. > > > > If you use Gradle, take a look at the plugin as it will protect against > > invalid setups out of the box. Please report issues or feature ideas on > > GitHub [4]. > > > > The capabilities-based conflict detection in Gradle could also work > without > > plugins, if logging libraries such as Log4J 2 would publish enough > > information in their metadata, which is now possible using the new Gradle > > Module Metadata format (in addition to POM) [5]. We, at Gradle, would be > > very happy to discuss, and help with, publishing this information for > > upcoming Log4J 2 releases. Would there be an interest there (asking Log4J > > 2 maintainers)? > > > > Regards, > > Louis for the Gradle Dependency Management team > > > > [1] https://plugins.gradle.org/plugin/dev.jacomet.logging-capabilities > > [2] https://blog.gradle.org/addressing-logging-complexity-capabilities > > [3] https://docs.gradle.org/6.0.1/userguide/component_capabilities.html > > [4] https://github.com/ljacomet/logging-capabilities > > [5] > > > https://docs.gradle.org/current/userguide/publishing_gradle_module_metadata.html > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > >
