This is an interesting idea. I'm personally much more familiar with gradle than I am with maven, and have worked on similar gradle plugins to avoid incompatible logging dependencies (I have a few horror stories in this department). Having a standard in place to prevent classpath issues would absolutely be helpful.
Changing build systems shouldn't be taken lightly, and given that maven is still used more broadly by java open source projects, especially within the ASF, would likely increase the barrier to entry. That said, we have had some problems with IDE configuration using maven that I imagine I could solve using gradle, potentially making it easier to contribute. In isolation I would be happy to use gradle over maven, however I do not want to make the rest of our PMC and contributors uncomfortable. Perhaps contributing a feature to maven to support capability metadata is the best place to start? -ck On Fri, Jan 31, 2020, at 10:32, Ralph Goers wrote: > I wouldn’t say the chance is zero but it is close. I’m not sure if any of the > committers on the logging projects are as comfortable with Gradle as we are > with Maven. Although I haven’t contributed to Maven in a few years I am still > on the PMC and am quite familiar with how its internals work. > > Ralph > > > On Jan 31, 2020, at 3:54 AM, Louis Jacomet <ljaco...@gmail.com> wrote: > > > > 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 > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > >
