I am not very active on the Log4j2 project any more, but I remember how it always rubbed me that the build takes so long. I use Gradle wherever I can in my projects. It makes the build much faster. The problem I see with migrating the Log4j2 build to Gradle (even if all committers would buy in to the idea) is that I am not aware of a Gradle plugin that is equivalent to maven-site-plugin for building the site.
On Sat, Feb 1, 2020 at 1:33 AM Matt Sicker <boa...@gmail.com> wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
