I've used both Maven and Gradle, switching back and forth depending on jobs and projects. I typically lean toward Maven due to better tooling support, but I know this is a constantly evolving area. I'd only really be in support of a switch to Gradle if it brought more benefits (particularly around reducing build/test time as well as for generating and aggregating documentation in our various formats).
On Fri, 31 Jan 2020 at 10:24, Carter Kozak <cko...@ckozak.net> wrote: > > 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 > > > > -- Matt Sicker <boa...@gmail.com> --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
