You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by "Piotr P. Karwasz" <pi...@gmail.com> on 2022/09/06 20:40:35 UTC
Sync `master` and `release-2.x` test structure
Hi,
Due to the difference in the project structure between `master` and
`release-2.x`, most cherry-picks between the two lines fail.
What do you think about adding the `log4j-api-test` and
`log4j-core-test` modules also in `release-2.x`? This should limit the
number of conflicts to the differences that matter.
Piotr
Re: Sync `master` and `release-2.x` test structure
Posted by Matt Sicker <bo...@gmail.com>.
The structure was a limitation due to testing modules. I suppose this would depend on how relevant the tests form master will be in 2.x over time.
—
Matt Sicker
> On Sep 6, 2022, at 13:40, Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> Hi,
>
> Due to the difference in the project structure between `master` and
> `release-2.x`, most cherry-picks between the two lines fail.
>
> What do you think about adding the `log4j-api-test` and
> `log4j-core-test` modules also in `release-2.x`? This should limit the
> number of conflicts to the differences that matter.
>
> Piotr
Re: Sync `master` and `release-2.x` test structure
Posted by Ralph Goers <ra...@dslextreme.com>.
I am fine with this but please create a Jira issue for removing support for 1.8. It needs to show up in the changelog.
Ralph
> On Sep 6, 2022, at 1:57 PM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> On Tue, 6 Sept 2022 at 22:53, Ralph Goers <ra...@dslextreme.com> wrote:
>> I don’t have an issue with that but Spring has requested a release from us that supports
>> SLF4J 2.0 this week. So I am going through Jira issues looking for those that warrant
>> my attention before the release.
>
> What about: https://github.com/apache/logging-log4j2/pull/1033 ?
>
> I remove `log4j-slf4j18-impl` and rename `log4j-slf4j20-impl` to
> `log4j-slf4j2-impl`.
>
> As far as I am concerned we just need to update the docs and SLF4J2 is done.
>
> Piotr
Re: Sync `master` and `release-2.x` test structure
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
On Tue, 6 Sept 2022 at 22:53, Ralph Goers <ra...@dslextreme.com> wrote:
> I don’t have an issue with that but Spring has requested a release from us that supports
> SLF4J 2.0 this week. So I am going through Jira issues looking for those that warrant
> my attention before the release.
What about: https://github.com/apache/logging-log4j2/pull/1033 ?
I remove `log4j-slf4j18-impl` and rename `log4j-slf4j20-impl` to
`log4j-slf4j2-impl`.
As far as I am concerned we just need to update the docs and SLF4J2 is done.
Piotr
Re: Sync `master` and `release-2.x` test structure
Posted by Ralph Goers <ra...@dslextreme.com>.
I don’t have an issue with that but Spring has requested a release from us that supports
SLF4J 2.0 this week. So I am going through Jira issues looking for those that warrant
my attention before the release.
So I would ask we save this until after the release.
Ralph
> On Sep 6, 2022, at 1:40 PM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> Hi,
>
> Due to the difference in the project structure between `master` and
> `release-2.x`, most cherry-picks between the two lines fail.
>
> What do you think about adding the `log4j-api-test` and
> `log4j-core-test` modules also in `release-2.x`? This should limit the
> number of conflicts to the differences that matter.
>
> Piotr
Re: Sync `master` and `release-2.x` test structure
Posted by Volkan Yazıcı <vo...@yazi.ci>.
+1
I liked the idea.
I have been bitten by this a lot while working on JsonTemplateLayout.
On Tue, Sep 6, 2022 at 10:40 PM Piotr P. Karwasz <pi...@gmail.com>
wrote:
> Hi,
>
> Due to the difference in the project structure between `master` and
> `release-2.x`, most cherry-picks between the two lines fail.
>
> What do you think about adding the `log4j-api-test` and
> `log4j-core-test` modules also in `release-2.x`? This should limit the
> number of conflicts to the differences that matter.
>
> Piotr
>
Re: Sync `master` and `release-2.x` test structure
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi,
On Mon, 12 Sept 2022 at 18:05, Ralph Goers <ra...@dslextreme.com> wrote:
> See below. While I OK with reorganizing the parent pom.xml in release-2.x I am not
> OK with making radical changes to it since it is “stable”. I also think trying to synchronize
> the two is kind of pointless. Given that one is based on Java 8 and one is Java 11
> and the organization of the projects is different there are going to be significant differences.
I don't plan any radical changes, I would just like a similar
structure to easily compare the dependencies of the two branches. Of
course `master` can have newer dependency versions, but it can not
have older dependencies than `release-2.x`.
> > * removing the scope from `<dependencyManagement>`: this way there
> > will be no difference between BOMs and explicit dependencies. It's
> > more verbose, but we won't risk having JUnit in the compile scope.
>
> I don’t understand. A BOM MUST be <scope>import</scope> to be included properly.
> Why wouldn’t you specify Junit as test scope since it always is, except for test modules
> that deliver a test jar. Those can be overriden.
The problem with BOMs is that they import dependencies in the default
scope. If we use `junit-bom`, we need to specify the `test` scope of
JUnit libraries in all children POMs, while we don't need to do it
with `hamcrest-core` that does not have a BOM. What I propose is to
*always* specify the scope in children POMs, even if it is inherited
from <dependencyManagement>.
> > * removing exclusions from `<dependencyManagement>`: AFAIK they are
> > ignored by Maven. Or we can keep the exclusions as a template for the
> > projects.
>
> Are you sure this is true? I’m not sure it isn’t.
I stand corrected. Regardless of what StackOverflow says, exclusions
in the <dependencyManagement> seem to work (since version 2.0 :-) )
Piotr
Re: Sync `master` and `release-2.x` test structure
Posted by Ralph Goers <ra...@dslextreme.com>.
See below. While I OK with reorganizing the parent pom.xml in release-2.x I am not
OK with making radical changes to it since it is “stable”. I also think trying to synchronize
the two is kind of pointless. Given that one is based on Java 8 and one is Java 11
and the organization of the projects is different there are going to be significant differences.
> On Sep 12, 2022, at 12:11 AM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> Hi,
>
> On Tue, 6 Sept 2022 at 22:40, Piotr P. Karwasz <pi...@gmail.com> wrote:
>> What do you think about adding the `log4j-api-test` and
>> `log4j-core-test` modules also in `release-2.x`? This should limit the
>> number of conflicts to the differences that matter.
>
> It would be also nice to synchronise the `pom.xml` of `release-2.x`
> and `master`. Since the main `pom.xml` has about a hundred
> dependencies, what do you think about normalizing them by:
>
> * using BOMs if available (e.g. Jackson),
I’m fine with this.
> * removing the scope from `<dependencyManagement>`: this way there
> will be no difference between BOMs and explicit dependencies. It's
> more verbose, but we won't risk having JUnit in the compile scope.
I don’t understand. A BOM MUST be <scope>import</scope> to be included properly.
Why wouldn’t you specify Junit as test scope since it always is, except for test modules
that deliver a test jar. Those can be overriden.
> * removing exclusions from `<dependencyManagement>`: AFAIK they are
> ignored by Maven. Or we can keep the exclusions as a template for the
> projects.
Are you sure this is true? I’m not sure it isn’t.
> * adding a property in the main pom.xml for *each* dependency used
> (e.g. even `slf4j-api:2.0.0` used in a single module). A convention on
> how to name these properties would be nice too...
I don’t understand this. A property to do what?
> * sorting dependencies by scope (provided > compile > runtime >
> test), artifactId and groupId.
I’m fine with this.
>
> Since POM style is as personal as code style, I would agree to all
> possible conventions as long as they are coherent.
>
> Piotr
Ralph
Re: Sync `master` and `release-2.x` test structure
Posted by Matt Sicker <bo...@gmail.com>.
Thanks for handling this!
—
Matt Sicker
> On Oct 6, 2022, at 09:44, Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> On Mon, 12 Sept 2022 at 09:11, Piotr P. Karwasz <pi...@gmail.com> wrote:
>> It would be also nice to synchronise the `pom.xml` of `release-2.x`
>> and `master`. Since the main `pom.xml` has about a hundred
>> dependencies, what do you think about normalizing them by:
>>
>> * using BOMs if available (e.g. Jackson),
>> * removing the scope from `<dependencyManagement>`: this way there
>> will be no difference between BOMs and explicit dependencies. It's
>> more verbose, but we won't risk having JUnit in the compile scope.
>> * removing exclusions from `<dependencyManagement>`: AFAIK they are
>> ignored by Maven. Or we can keep the exclusions as a template for the
>> projects.
>> * adding a property in the main pom.xml for *each* dependency used
>> (e.g. even `slf4j-api:2.0.0` used in a single module). A convention on
>> how to name these properties would be nice too...
>> * sorting dependencies by scope (provided > compile > runtime >
>> test), artifactId and groupId.
>
> I finished moving things around. All the dependencies of the published
> artifacts are in the `log4j` POM and versions are specified through
> properties, so that they can be overridden in single modules. Of
> course `log4j-bom` and `log4j-distribution` need to deal with their
> dependencies independently (unless we add artifacts with `sources` and
> `javadoc` classifiers to `log4j-bom`).
>
> Two XSLT's in `src/tools` allow to sort the POMs and list all the
> plugin and dependency versions that are explicitly provided. Excluding
> the aforementioned `log4j`, `log4j-bom` and `log4j-distribution`,
> these are the results of running `src/tools/explicit-version.xslt` on
> all POMs (the comments are mine):
>
> Artifact:log4j-cassandra
> Version related properties:
> guava.version = 25.1-jre // still vulnerable to CVE-2020-8908, but
> Cassandra does not work with newer versions
>
> Artifact:log4j-jpl
> Version related properties:
> surefire.version = 2.13 // to use 3.x we need to run Maven on JDK 9+
>
> Artifact:log4j-jul
> Dependencies for plugin maven-surefire-plugin:
> org.apache.maven.surefire:surefire-junit47:${surefire.version} //
> `surefire-platform` initializes JUL before our tests can do it
>
> Artifact:log4j-mongodb3
> Version related properties:
> mongodb.version = 3.12.11 // override of the default 4.5
>
> Artifact:log4j-osgi
> Project dependencies:
> org.apache.logging.log4j.samples:log4j-samples-configuration:${project.version}
>
> Artifact:log4j-perf
> Dependencies for plugin maven-shade-plugin:
> com.github.edwgiz:maven-shade-plugin.log4j2-cachefile-transformer:${log4j2-cachefile-transformer.version}
>
> Artifact:log4j-samples
> Version related properties:
> maven-jetty-plugin.version = 6.1.26
> spring-ws.version = 3.1.3
> Dependency management:
> org.apache.logging.log4j.samples:log4j-samples-flume-common:${project.version}
> org.springframework.ws:spring-ws-core:${spring-ws.version}
> Plugin management:
> org.mortbay.jetty:maven-jetty-plugin:${maven-jetty-plugin.version}
>
> Artifact:log4j-slf4j-impl
> Version related properties:
> slf4j.version = 1.7.25 // 1.7.26 has breaking changes
>
> Artifact:log4j-spring-cloud-config-samples
> Version related properties:
> spring-ws.version = 3.1.3
> Dependency management:
> org.springframework.ws:spring-ws-core:${spring-ws.version}
> Plugin management:
> org.springframework.boot:spring-boot-maven-plugin:${spring-boot.version}
>
> Artifact:log4j-spring-cloud-config
> Version related properties:
> spring-cloud.version = 2021.0.4
> Dependency management:
> org.apache.logging.log4j:log4j-bom:${project.version}:pom
> org.springframework.boot:spring-boot-dependencies:${spring-boot.version}:pom
> org.springframework.cloud:spring-cloud-dependencies:${spring-cloud.version}:pom
>
> Artifact:log4j-slf4j2-impl
> Version related properties:
> slf4j.version = 2.0.0
>
> Piotr
Re: Sync `master` and `release-2.x` test structure
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
On Mon, 12 Sept 2022 at 09:11, Piotr P. Karwasz <pi...@gmail.com> wrote:
> It would be also nice to synchronise the `pom.xml` of `release-2.x`
> and `master`. Since the main `pom.xml` has about a hundred
> dependencies, what do you think about normalizing them by:
>
> * using BOMs if available (e.g. Jackson),
> * removing the scope from `<dependencyManagement>`: this way there
> will be no difference between BOMs and explicit dependencies. It's
> more verbose, but we won't risk having JUnit in the compile scope.
> * removing exclusions from `<dependencyManagement>`: AFAIK they are
> ignored by Maven. Or we can keep the exclusions as a template for the
> projects.
> * adding a property in the main pom.xml for *each* dependency used
> (e.g. even `slf4j-api:2.0.0` used in a single module). A convention on
> how to name these properties would be nice too...
> * sorting dependencies by scope (provided > compile > runtime >
> test), artifactId and groupId.
I finished moving things around. All the dependencies of the published
artifacts are in the `log4j` POM and versions are specified through
properties, so that they can be overridden in single modules. Of
course `log4j-bom` and `log4j-distribution` need to deal with their
dependencies independently (unless we add artifacts with `sources` and
`javadoc` classifiers to `log4j-bom`).
Two XSLT's in `src/tools` allow to sort the POMs and list all the
plugin and dependency versions that are explicitly provided. Excluding
the aforementioned `log4j`, `log4j-bom` and `log4j-distribution`,
these are the results of running `src/tools/explicit-version.xslt` on
all POMs (the comments are mine):
Artifact:log4j-cassandra
Version related properties:
guava.version = 25.1-jre // still vulnerable to CVE-2020-8908, but
Cassandra does not work with newer versions
Artifact:log4j-jpl
Version related properties:
surefire.version = 2.13 // to use 3.x we need to run Maven on JDK 9+
Artifact:log4j-jul
Dependencies for plugin maven-surefire-plugin:
org.apache.maven.surefire:surefire-junit47:${surefire.version} //
`surefire-platform` initializes JUL before our tests can do it
Artifact:log4j-mongodb3
Version related properties:
mongodb.version = 3.12.11 // override of the default 4.5
Artifact:log4j-osgi
Project dependencies:
org.apache.logging.log4j.samples:log4j-samples-configuration:${project.version}
Artifact:log4j-perf
Dependencies for plugin maven-shade-plugin:
com.github.edwgiz:maven-shade-plugin.log4j2-cachefile-transformer:${log4j2-cachefile-transformer.version}
Artifact:log4j-samples
Version related properties:
maven-jetty-plugin.version = 6.1.26
spring-ws.version = 3.1.3
Dependency management:
org.apache.logging.log4j.samples:log4j-samples-flume-common:${project.version}
org.springframework.ws:spring-ws-core:${spring-ws.version}
Plugin management:
org.mortbay.jetty:maven-jetty-plugin:${maven-jetty-plugin.version}
Artifact:log4j-slf4j-impl
Version related properties:
slf4j.version = 1.7.25 // 1.7.26 has breaking changes
Artifact:log4j-spring-cloud-config-samples
Version related properties:
spring-ws.version = 3.1.3
Dependency management:
org.springframework.ws:spring-ws-core:${spring-ws.version}
Plugin management:
org.springframework.boot:spring-boot-maven-plugin:${spring-boot.version}
Artifact:log4j-spring-cloud-config
Version related properties:
spring-cloud.version = 2021.0.4
Dependency management:
org.apache.logging.log4j:log4j-bom:${project.version}:pom
org.springframework.boot:spring-boot-dependencies:${spring-boot.version}:pom
org.springframework.cloud:spring-cloud-dependencies:${spring-cloud.version}:pom
Artifact:log4j-slf4j2-impl
Version related properties:
slf4j.version = 2.0.0
Piotr
Re: Dependency management style
Posted by Matt Sicker <ma...@musigma.org>.
I like this idea.
> On Jan 8, 2024, at 4:09 AM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> Hi all,
>
> Following the discussion in PR#2166, I would like to change the dep
> management convention I mentioned in 2022.
>
> On Mon, 12 Sept 2022 at 09:11, Piotr P. Karwasz <pi...@gmail.com> wrote:
>> It would be also nice to synchronise the `pom.xml` of `release-2.x`
>> and `master`. Since the main `pom.xml` has about a hundred
>> dependencies, what do you think about normalizing them by:
>>
>> * using BOMs if available (e.g. Jackson),
>> * removing the scope from `<dependencyManagement>`: this way there
>> will be no difference between BOMs and explicit dependencies. It's
>> more verbose, but we won't risk having JUnit in the compile scope.
>> * removing exclusions from `<dependencyManagement>`: AFAIK they are
>> ignored by Maven. Or we can keep the exclusions as a template for the
>> projects.
>> * adding a property in the main pom.xml for *each* dependency used
>> (e.g. even `slf4j-api:2.0.0` used in a single module). A convention on
>> how to name these properties would be nice too...
>> * sorting dependencies by scope (provided > compile > runtime >
>> test), artifactId and groupId.
>>
>> Since POM style is as personal as code style, I would agree to all
>> possible conventions as long as they are coherent.
>
> This convention seems unnatural to many of our contributors,
> especially regarding dependencies that are used by a single module.
>
> Alternative Maven resolvers have also problems with a centralized dep
> management (cf. Issue#1983 for example).
>
> Therefore I would like to amend the proposition above to state:
>
> * if a dependency is used by a single module, it is only declared in
> that module,
> * if a dependency is used by more than one module, it should be
> managed in the parent.
>
> What do you think?
>
> Piotr
>
> [1] https://github.com/apache/logging-log4j2/pull/2166
> [2] https://github.com/apache/logging-log4j2/issues/1983
Re: Dependency management style
Posted by Volkan Yazıcı <vo...@yazi.ci>.
+1
On Mon, Jan 8, 2024 at 11:11 AM Piotr P. Karwasz <pi...@gmail.com>
wrote:
> Hi all,
>
> Following the discussion in PR#2166, I would like to change the dep
> management convention I mentioned in 2022.
>
> On Mon, 12 Sept 2022 at 09:11, Piotr P. Karwasz <pi...@gmail.com>
> wrote:
> > It would be also nice to synchronise the `pom.xml` of `release-2.x`
> > and `master`. Since the main `pom.xml` has about a hundred
> > dependencies, what do you think about normalizing them by:
> >
> > * using BOMs if available (e.g. Jackson),
> > * removing the scope from `<dependencyManagement>`: this way there
> > will be no difference between BOMs and explicit dependencies. It's
> > more verbose, but we won't risk having JUnit in the compile scope.
> > * removing exclusions from `<dependencyManagement>`: AFAIK they are
> > ignored by Maven. Or we can keep the exclusions as a template for the
> > projects.
> > * adding a property in the main pom.xml for *each* dependency used
> > (e.g. even `slf4j-api:2.0.0` used in a single module). A convention on
> > how to name these properties would be nice too...
> > * sorting dependencies by scope (provided > compile > runtime >
> > test), artifactId and groupId.
> >
> > Since POM style is as personal as code style, I would agree to all
> > possible conventions as long as they are coherent.
>
> This convention seems unnatural to many of our contributors,
> especially regarding dependencies that are used by a single module.
>
> Alternative Maven resolvers have also problems with a centralized dep
> management (cf. Issue#1983 for example).
>
> Therefore I would like to amend the proposition above to state:
>
> * if a dependency is used by a single module, it is only declared in
> that module,
> * if a dependency is used by more than one module, it should be
> managed in the parent.
>
> What do you think?
>
> Piotr
>
> [1] https://github.com/apache/logging-log4j2/pull/2166
> [2] https://github.com/apache/logging-log4j2/issues/1983
>
Dependency management style
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi all,
Following the discussion in PR#2166, I would like to change the dep
management convention I mentioned in 2022.
On Mon, 12 Sept 2022 at 09:11, Piotr P. Karwasz <pi...@gmail.com> wrote:
> It would be also nice to synchronise the `pom.xml` of `release-2.x`
> and `master`. Since the main `pom.xml` has about a hundred
> dependencies, what do you think about normalizing them by:
>
> * using BOMs if available (e.g. Jackson),
> * removing the scope from `<dependencyManagement>`: this way there
> will be no difference between BOMs and explicit dependencies. It's
> more verbose, but we won't risk having JUnit in the compile scope.
> * removing exclusions from `<dependencyManagement>`: AFAIK they are
> ignored by Maven. Or we can keep the exclusions as a template for the
> projects.
> * adding a property in the main pom.xml for *each* dependency used
> (e.g. even `slf4j-api:2.0.0` used in a single module). A convention on
> how to name these properties would be nice too...
> * sorting dependencies by scope (provided > compile > runtime >
> test), artifactId and groupId.
>
> Since POM style is as personal as code style, I would agree to all
> possible conventions as long as they are coherent.
This convention seems unnatural to many of our contributors,
especially regarding dependencies that are used by a single module.
Alternative Maven resolvers have also problems with a centralized dep
management (cf. Issue#1983 for example).
Therefore I would like to amend the proposition above to state:
* if a dependency is used by a single module, it is only declared in
that module,
* if a dependency is used by more than one module, it should be
managed in the parent.
What do you think?
Piotr
[1] https://github.com/apache/logging-log4j2/pull/2166
[2] https://github.com/apache/logging-log4j2/issues/1983
Re: Sync `master` and `release-2.x` test structure
Posted by Matt Sicker <bo...@gmail.com>.
On Mon, Sep 12, 2022 at 11:10 AM Ralph Goers <ra...@dslextreme.com> wrote:
> While that might be true, we don’t use Jenkins for our builds anymore.
> Instead, they all fail with GitHub actions instead of failing with Jenkins.
It's a Maven plugin.
Re: Sync `master` and `release-2.x` test structure
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Sep 12, 2022, at 8:49 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> There's a neat plugin from the Jenkins project for making stable
> identifiers for CI builds that might be interesting:
> https://github.com/jenkinsci/incrementals-tools
While that might be true, we don’t use Jenkins for our builds anymore.
Instead, they all fail with GitHub actions instead of failing with Jenkins.
Ralph
Re: Sync `master` and `release-2.x` test structure
Posted by Matt Sicker <bo...@gmail.com>.
There's a neat plugin from the Jenkins project for making stable
identifiers for CI builds that might be interesting:
https://github.com/jenkinsci/incrementals-tools
On Mon, Sep 12, 2022 at 7:49 AM Piotr P. Karwasz
<pi...@gmail.com> wrote:
>
> Hi Volkan,
>
> On Mon, 12 Sept 2022 at 11:53, Volkan Yazıcı <vo...@yazi.ci> wrote:
> > I would like to extend this a bit more:
> >
> > * switch to CI-friendly versions via ${revision}
>
> I am not sure, what do you mean by that: do we put ${revision} instead
> of the current Log4j2 version?
>
> Piotr
Re: Sync `master` and `release-2.x` test structure
Posted by Volkan Yazıcı <vo...@yazi.ci>.
You can find more about CI-friendly versioning and ${revision} here:
https://maven.apache.org/maven-ci-friendly.html
In a nutshell, you only define the `revision` property in the parent POM's
`<properties>` block and refer to it everywhere you need to literally type
the version.
On Mon, Sep 12, 2022 at 2:49 PM Piotr P. Karwasz <pi...@gmail.com>
wrote:
> Hi Volkan,
>
> On Mon, 12 Sept 2022 at 11:53, Volkan Yazıcı <vo...@yazi.ci> wrote:
> > I would like to extend this a bit more:
> >
> > * switch to CI-friendly versions via ${revision}
>
> I am not sure, what do you mean by that: do we put ${revision} instead
> of the current Log4j2 version?
>
> Piotr
>
Re: Sync `master` and `release-2.x` test structure
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Volkan,
On Mon, 12 Sept 2022 at 11:53, Volkan Yazıcı <vo...@yazi.ci> wrote:
> I would like to extend this a bit more:
>
> * switch to CI-friendly versions via ${revision}
I am not sure, what do you mean by that: do we put ${revision} instead
of the current Log4j2 version?
Piotr
Re: Sync `master` and `release-2.x` test structure
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Sep 12, 2022, at 2:52 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
>
> Totally agreed with all the points!
>
> I would like to extend this a bit more:
>
> * switch to CI-friendly versions via ${revision}
I don’t understand this. What is a “CI-friendly version”. What do you mean by ${revision}.
Surely all dependencies can’t use the same version number.
> * group properties by domain (e.g., common, lib versions, plugin versions)
> and lexicographically sort each group
I am all for making properties easy to find. However, just sorting them is probably enough.
But I have no objection to grouping them.
Ralph
Re: Sync `master` and `release-2.x` test structure
Posted by Volkan Yazıcı <vo...@yazi.ci>.
Totally agreed with all the points!
I would like to extend this a bit more:
* switch to CI-friendly versions via ${revision}
* group properties by domain (e.g., common, lib versions, plugin versions)
and lexicographically sort each group
On Mon, Sep 12, 2022 at 9:11 AM Piotr P. Karwasz <pi...@gmail.com>
wrote:
> Hi,
>
> On Tue, 6 Sept 2022 at 22:40, Piotr P. Karwasz <pi...@gmail.com>
> wrote:
> > What do you think about adding the `log4j-api-test` and
> > `log4j-core-test` modules also in `release-2.x`? This should limit the
> > number of conflicts to the differences that matter.
>
> It would be also nice to synchronise the `pom.xml` of `release-2.x`
> and `master`. Since the main `pom.xml` has about a hundred
> dependencies, what do you think about normalizing them by:
>
> * using BOMs if available (e.g. Jackson),
> * removing the scope from `<dependencyManagement>`: this way there
> will be no difference between BOMs and explicit dependencies. It's
> more verbose, but we won't risk having JUnit in the compile scope.
> * removing exclusions from `<dependencyManagement>`: AFAIK they are
> ignored by Maven. Or we can keep the exclusions as a template for the
> projects.
> * adding a property in the main pom.xml for *each* dependency used
> (e.g. even `slf4j-api:2.0.0` used in a single module). A convention on
> how to name these properties would be nice too...
> * sorting dependencies by scope (provided > compile > runtime >
> test), artifactId and groupId.
>
> Since POM style is as personal as code style, I would agree to all
> possible conventions as long as they are coherent.
>
> Piotr
>
Re: Sync `master` and `release-2.x` test structure
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi,
On Tue, 6 Sept 2022 at 22:40, Piotr P. Karwasz <pi...@gmail.com> wrote:
> What do you think about adding the `log4j-api-test` and
> `log4j-core-test` modules also in `release-2.x`? This should limit the
> number of conflicts to the differences that matter.
It would be also nice to synchronise the `pom.xml` of `release-2.x`
and `master`. Since the main `pom.xml` has about a hundred
dependencies, what do you think about normalizing them by:
* using BOMs if available (e.g. Jackson),
* removing the scope from `<dependencyManagement>`: this way there
will be no difference between BOMs and explicit dependencies. It's
more verbose, but we won't risk having JUnit in the compile scope.
* removing exclusions from `<dependencyManagement>`: AFAIK they are
ignored by Maven. Or we can keep the exclusions as a template for the
projects.
* adding a property in the main pom.xml for *each* dependency used
(e.g. even `slf4j-api:2.0.0` used in a single module). A convention on
how to name these properties would be nice too...
* sorting dependencies by scope (provided > compile > runtime >
test), artifactId and groupId.
Since POM style is as personal as code style, I would agree to all
possible conventions as long as they are coherent.
Piotr