Oh, and though I haven't used it in over a year, SBT is the build tool I'm most familiar with internals of (followed by Ant), so I don't have a real preference between Maven and Gradle (both have incomprehensible internals to me at this time).
On Fri, 31 Jan 2020 at 10:31, Matt Sicker <boa...@gmail.com> wrote: > > 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> -- 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
