Re: Deterministic formatter

[Volkan Yazıcı]

I completely agree with Matt. With or without IDE plugins, we run `./mvnw
spotless:apply` anyway. Hence, lack of Eclipse support is not a blocker,
IMO. Gary is covered.

+1 deterministic formatter (don't have an opinion on Palantir-vs-Google)

Piotr, it has been two months or so since we are discussing this. No
objections so far. Please go ahead and implement this. It will help a lot
for sync'ing `2.x` and `3.x`.

On Tue, Nov 7, 2023 at 7:10 PM Matt Sicker  wrote:

> In the worst case scenario, we can still format from maven before
> committing (which is what I used to do before finding that there were
> IntelliJ plugins for this). In fact, I have to do that all the time lately
> anyways by running `mvn spotless:apply`.
>
> > On Nov 6, 2023, at 9:00 AM, Carter Kozak 
> wrote:
> >
> > I'd be happy to review+release changes to get the eclipse plugin in that
> repo into a good place as long as it doesn't make the build process a great
> deal more complicated. We don't have many folks internally using eclipse so
> support hasn't been a priority, but the easier it is to use across common
> toolchains, the better!
> >
> > -ck
> >
> > On Mon, Nov 6, 2023, at 06:55, Piotr P. Karwasz wrote:
> >> Hi Gary,
> >>
> >> On Mon, 6 Nov 2023 at 11:45, Gary Gregory 
> wrote:
> >>>
> >>> Well, I use Eclipse, so... I won't be using whatever this does or when
> it
> >>> does it.
> >>
> >> What version of Eclipse do you use? The Eclipse plugin is one class, I
> >> can probably fix it, compile it and release it.
> >>
> >> Piotr
> >>
>
>

Re: Deterministic formatter

[Christian Grobmeier]

On Wed, Nov 8, 2023, at 09:04, Volkan Yazıcı wrote:
> I completely agree with Matt. With or without IDE plugins, we run `./mvnw
> spotless:apply` anyway. Hence, lack of Eclipse support is not a blocker,
> IMO. Gary is covered.
>
> +1 deterministic formatter (don't have an opinion on Palantir-vs-Google)
>
> Piotr, it has been two months or so since we are discussing this. No
> objections so far. Please go ahead and implement this. It will help a lot
> for sync'ing `2.x` and `3.x`.
>

+1,

I like the palantir formatter the most for the same reasons Matt mentioned.
Since it can be done using Maven, I don't know why an IDE should block it.

Christian

> On Tue, Nov 7, 2023 at 7:10 PM Matt Sicker  wrote:
>
>> In the worst case scenario, we can still format from maven before
>> committing (which is what I used to do before finding that there were
>> IntelliJ plugins for this). In fact, I have to do that all the time lately
>> anyways by running `mvn spotless:apply`.
>>
>> > On Nov 6, 2023, at 9:00 AM, Carter Kozak 
>> wrote:
>> >
>> > I'd be happy to review+release changes to get the eclipse plugin in that
>> repo into a good place as long as it doesn't make the build process a great
>> deal more complicated. We don't have many folks internally using eclipse so
>> support hasn't been a priority, but the easier it is to use across common
>> toolchains, the better!
>> >
>> > -ck
>> >
>> > On Mon, Nov 6, 2023, at 06:55, Piotr P. Karwasz wrote:
>> >> Hi Gary,
>> >>
>> >> On Mon, 6 Nov 2023 at 11:45, Gary Gregory 
>> wrote:
>> >>>
>> >>> Well, I use Eclipse, so... I won't be using whatever this does or when
>> it
>> >>> does it.
>> >>
>> >> What version of Eclipse do you use? The Eclipse plugin is one class, I
>> >> can probably fix it, compile it and release it.
>> >>
>> >> Piotr
>> >>
>>
>>

Vulnerability Disclosure Report (VDR)

[Volkan Yazıcı]

Today I have published the CycloneDX Vulnerability Disclosure Report (VDR)
 Piotr and I have been working on.
This VDR is expected to contain all CVEs filed by Logging Services. All our
SBOMs will point to this one-and-only VDR file with the most recent
`logging-parent` release.

*Public URL:* https://logging.apache.org/cyclonedx/vdr.xml
*Canonical URL:*
https://logging.apache.org/cyclonedx/urn:uuid:dfa35519-9734-4259-bba1-3e825cf4be06
*Source:*
https://github.com/apache/logging-site/blob/cyclonedx/urn%3Acdx%3Adfa35519-9734-4259-bba1-3e825cf4be06/1.xml

I already filled in all CVEs published against Log4j. I will appreciate it
if the rest of you can help us to do the same for Chainsaw, Log4cxx, etc.

Please do create a PR for your changes (I will be more than happy to review
them!) and follow a chronological order (newer CVE comes first) in
`vulnerability` entries.

Re: [VOTE][LAZY] Release Apache Logging Parent 10.3.0 (RC2)

[Volkan Yazıcı]

We just figured a mistake in the VDR URL scheme.
It should have been `uuid` instead of `cdx`, which requires a version.
I cancel this vote.
I will issue an RC3 promptly, though I will stick to the timeline of the
RC2 vote.

On Mon, Nov 6, 2023 at 11:32 AM Volkan Yazıcı  wrote:

> This is a lazy-vote to release the Apache Logging Parent 10.3.0 RC2.
>
> Website: https://logging.staged.apache.org/logging-parent
> GitHub: https://github.com/apache/logging-parent
> Commit: ca99077f82923a97d79ea7947e05cb589873d241
> Distribution:
> https://dist.apache.org/repos/dist/dev/logging/logging-parent
> Nexus:
> https://repository.apache.org/content/repositories/orgapachelogging-1221
> Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0
>
> Please download, test, and cast your votes on this mailing list.
>
> [ ] +1, release the artifacts
> [ ] -1, don't release, because...
>
> This vote is open for 72 hours and will pass unless getting a
> net negative vote count. All votes are welcome and we encourage
> everyone to test the release, but only the Logging Services PMC
> votes are officially counted.
>
> === Release Notes
>
> This minor release contains several small improvements.
>
>  Added
>
> * Add support to extend the `bnd-maven-plugin` configuration with
> `bnd-extra-config` property (apache/logging-log4j2#1895)
> * Add support to replace `project.build.outputTimestamp` Maven
> property in CI (#50)
> * Add XSLT transformation step to add a deterministic `serialNumber`
> and VDR links to the SBOM
> * Add support for an optional `spotbugs-exclude.xml` file in each repo.
>
>  Changed
>
> * `deploy-release-reusable.yaml` is improved to automatically derive
> deployed artifacts as attachments. This renders both
> `distribution-attachment-filepath-pattern` and
> `distribution-attachment-count` input arguments redundant for almost
> all cases.
> * Disable the usage of `` and alpha releases
> in the `bnd-baseline-maven-plugin`.
> * Convert `bnd-maven-plugin` API leakage warnings to errors
> (apache/logging-log4j2#1895)
> * Update `com.google.errorprone:error_prone_core` to version `2.23.0` (#49)
> * Update `org.cyclonedx:cyclonedx-maven-plugin` to version `2.7.10` (#54)
>
>  Fixed
>
> * Fix broken changelog entry validation
> * Attach `flatten:clean` to `clean` phase
> * Add missing `Implementation-` and `Specification-` entries in
> `MANIFEST.MF` to `bnd-maven-plugin` configuration
> (apache/logging-log4j2#1923)
>

Re: Vulnerability Disclosure Report (VDR)

[Matt Sicker]

Very neat! Thanks for getting this started.

> On Nov 8, 2023, at 9:49 AM, Volkan Yazıcı  wrote:
> 
> Today I have published the CycloneDX Vulnerability Disclosure Report (VDR)
>  Piotr and I have been working on.
> This VDR is expected to contain all CVEs filed by Logging Services. All our
> SBOMs will point to this one-and-only VDR file with the most recent
> `logging-parent` release.
> 
> *Public URL:* https://logging.apache.org/cyclonedx/vdr.xml
> *Canonical URL:*
> https://logging.apache.org/cyclonedx/urn:uuid:dfa35519-9734-4259-bba1-3e825cf4be06
> *Source:*
> https://github.com/apache/logging-site/blob/cyclonedx/urn%3Acdx%3Adfa35519-9734-4259-bba1-3e825cf4be06/1.xml
> 
> I already filled in all CVEs published against Log4j. I will appreciate it
> if the rest of you can help us to do the same for Chainsaw, Log4cxx, etc.
> 
> Please do create a PR for your changes (I will be more than happy to review
> them!) and follow a chronological order (newer CVE comes first) in
> `vulnerability` entries.

Re: [log4j] What is JPMS support and its state

[Christian Grobmeier]

On Tue, Nov 7, 2023, at 15:05, Matt Sicker wrote:
> I’m not going to backport the DI system. It relies on Java 11 in all 
> sorts of random places, first of all. I had to update numerous plugins 
> and tests along the way, especially things that set up or manipulate 
> static state, much of which has been cleaned up in main. It’s hard to 
> describe all the little things that went into that.

The DI system is, for me, one of the best reasons for having a new major 
version. I would be totally confused if we would backport it and we would need 
strong reasons for such a move.

While I want to learn more about the benefits of the next iteration, my main 
concern would be more “when” rather than “if”.

For me it is clear 3.x will happen. It seems there are different ideas on the 
distinction between 2.x and 3.x, so we should make this distinction clear and 
define when the one version starts and the other stops.

We can draw that line on Sunday together.

That said, thanks Ralph for the insight. I also found the question valuable, 
because they need to be asked.

> —
> Matt Sicker
>
>> On Nov 7, 2023, at 05:31, Piotr P. Karwasz  wrote:
>> 
>> Hi Ralph,
>> 
>>> On Tue, 7 Nov 2023 at 05:05, Ralph Goers  wrote:
>>> Next, there is a good chance that users really using JPMS won’t be able to 
>>> access any plugins outside of log4j-core. See 
>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#getResource(java.lang.String).
>>>  This is precisely why 3.x uses ServiceLoader to locate all plugins.
>> 
>> The `META-INF` directory is not encapsulated, so `getResource` should
>> work fine. Nevertheless using `ServiceLoader` is a much cleaner
>> solution and would allow us to greatly simplify our OSGi-specific
>> code.
>> 
>> Piotr