Leveraging Gradle to detect invalid logging setups

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Leveraging Gradle to detect invalid logging setups

Louis Jacomet
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
Reply | Threaded
Open this post in threaded view
|

Re: Leveraging Gradle to detect invalid logging setups

Ralph Goers
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Leveraging Gradle to detect invalid logging setups

Louis Jacomet
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 <[hidden email]>
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Leveraging Gradle to detect invalid logging setups

Ralph Goers
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Leveraging Gradle to detect invalid logging setups

Carter Kozak-2
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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]> 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: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Leveraging Gradle to detect invalid logging setups

Matt Sicker
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > > 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 <[hidden email]> 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: [hidden email]
> > >> For additional commands, e-mail: [hidden email]
> > >>
> > >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >



--
Matt Sicker <[hidden email]>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Leveraging Gradle to detect invalid logging setups

Matt Sicker
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > > > 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 <[hidden email]> 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: [hidden email]
> > > >> For additional commands, e-mail: [hidden email]
> > > >>
> > > >>
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
>
>
>
> --
> Matt Sicker <[hidden email]>



--
Matt Sicker <[hidden email]>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Leveraging Gradle to detect invalid logging setups

Remko Popma-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > > > > 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 <[hidden email]> 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: [hidden email]
> > > > >> For additional commands, e-mail: [hidden email]
> > > > >>
> > > > >>
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
> >
> >
> >
> > --
> > Matt Sicker <[hidden email]>
>
>
>
> --
> Matt Sicker <[hidden email]>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]