On publishing test JARs

[Volkan Yazıcı]

I don't know what was our earlier policy on test JARs (if we have any at
all), but I suggest we stop deploying to Nexus anything that is not meant
for public consumption: api, core, adapters, filters, etc. Now are we
supposed to spend hours fixing the tests of an individual because he
happened to depend on Log4j tests?

-- Forwarded message -
From: Jon Wilmoth (Jira) 
Date: Tue, Feb 21, 2023 at 10:31 PM
Subject: [jira] [Created] (LOG4J2-3650) Release 2.20.0 missing artifacts
To: 


Jon Wilmoth created LOG4J2-3650:
---

 Summary: Release 2.20.0 missing artifacts
 Key: LOG4J2-3650
 URL: https://issues.apache.org/jira/browse/LOG4J2-3650
 Project: Log4j 2
  Issue Type: Bug
  Components: Core
Affects Versions: 2.20.0
Reporter: Jon Wilmoth


It looks like the new 2.20.0 release didn't publish the
log4j-core--tests.jar files that were in the previous release.
Can these files be published?

# https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.19.0/
# https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.20.0/




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Log4j team vs Logging Services team

[Volkan Yazıcı]

I propose redirecting all "Team" links in Log4j, log4cxx, etc. to the
Logging Services Team page .

I know Ralph disagrees with me[, hence this email]. He wants the Log4j
project to have its own "Team" page where its content is populated from
`pom.xml`. I strongly disagree with this. `pom.xml` only contains people
who happen to care about having their names there: some PMC members,
committers, random contributors. It didn't even contain the entire Log4j
PMC – this I fixed myself while doing the recent site work. I don't know
what it represents, but that thing is certainly not _the team_. Having one
central place, the Logging Services Team page, is not only convenient, but
accurate; those people are the official maintainers.

maven-site-plugin is dead

for a reason.

Long story short, I would appreciate your input for a tie breaker.

Broken Javadoc URL

[Volkan Yazıcı]

While fixing the javadoc for the 2.20.0 release, I renamed the path from
`//apidocs` to `/javadoc/`. As the user issue below
explains, this got some people angry. I have already temporarily fixed the
issue by creating directory symlinks. For a permanent solution, I see two
options:

   1. Configure the `javadoc-maven-plugin` to output to `//apidocs`
   instead of `/javadoc/`. The reason I am not happy with this
   approach is that it actually was like that since that is how
   `maven-site-plugin` works and it is not aligned with the website directory
   structure. Nonetheless, it is doable.
   2. Create an `.htaccess` entry *permanently* redirecting
   `2.x//apidocs` to `2.x/javadoc/`. I am sort of inclined
   with this fix, since we can stick to our directory structure.

Thoughts?

-- Forwarded message -
From: Alexander Brandes 
Date: Wed, Feb 22, 2023 at 9:36 AM
Subject: [apache/logging-log4j2] Broken Javadoc URL (Issue #1284)
To: apache/logging-log4j2 
Cc: Subscribed 


Hey,

It appears that a recent changed forced a change of the Javadoc URL from
https://logging.apache.org/log4j/2.x/log4j-api/apidocs/ to
https://logging.apache.org/log4j/2.x/javadoc/log4j-api/index.html.

Is there a particular reason why this was changed without a redirect
pointing to the new location? This change affects hundreds

of files in open source projects, now left behind broken.

Some builds may also fail because a build tool can no longer obtain the
file from the old location:

Error fetching URL:
https://logging.apache.org/log4j/2.x/log4j-api/apidocs/
(java.io.FileNotFoundException:
https://logging.apache.org/log4j/2.x/log4j-api/apidocs/package-list)

—
Reply to this email directly, view it on GitHub
, or unsubscribe

.
You are receiving this because you are subscribed to this thread.Message
ID: 

Re: On publishing test JARs

[Gary Gregory]

Please keep publishing test jars, at least the core and api jars. One of
these contains Junit rules and utilities that are very useful and I reply
on those for many projects.

Gary

On Wed, Feb 22, 2023, 03:04 Volkan Yazıcı  wrote:

> I don't know what was our earlier policy on test JARs (if we have any at
> all), but I suggest we stop deploying to Nexus anything that is not meant
> for public consumption: api, core, adapters, filters, etc. Now are we
> supposed to spend hours fixing the tests of an individual because he
> happened to depend on Log4j tests?
>
> -- Forwarded message -
> From: Jon Wilmoth (Jira) 
> Date: Tue, Feb 21, 2023 at 10:31 PM
> Subject: [jira] [Created] (LOG4J2-3650) Release 2.20.0 missing artifacts
> To: 
>
>
> Jon Wilmoth created LOG4J2-3650:
> ---
>
>  Summary: Release 2.20.0 missing artifacts
>  Key: LOG4J2-3650
>  URL: https://issues.apache.org/jira/browse/LOG4J2-3650
>  Project: Log4j 2
>   Issue Type: Bug
>   Components: Core
> Affects Versions: 2.20.0
> Reporter: Jon Wilmoth
>
>
> It looks like the new 2.20.0 release didn't publish the
> log4j-core--tests.jar files that were in the previous release.
> Can these files be published?
>
> #
> https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.19.0/
> #
> https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.20.0/
>
>
>
>
> --
> This message was sent by Atlassian Jira
> (v8.20.10#820010)
>

Re: On publishing test JARs

[Gary Gregory]

I should add that I don't expect any kind of BC compatibility, I take them
as they are and adapt.

Gary

On Wed, Feb 22, 2023, 07:23 Gary Gregory  wrote:

> Please keep publishing test jars, at least the core and api jars. One of
> these contains Junit rules and utilities that are very useful and I reply
> on those for many projects.
>
> Gary
>
> On Wed, Feb 22, 2023, 03:04 Volkan Yazıcı  wrote:
>
>> I don't know what was our earlier policy on test JARs (if we have any at
>> all), but I suggest we stop deploying to Nexus anything that is not meant
>> for public consumption: api, core, adapters, filters, etc. Now are we
>> supposed to spend hours fixing the tests of an individual because he
>> happened to depend on Log4j tests?
>>
>> -- Forwarded message -
>> From: Jon Wilmoth (Jira) 
>> Date: Tue, Feb 21, 2023 at 10:31 PM
>> Subject: [jira] [Created] (LOG4J2-3650) Release 2.20.0 missing artifacts
>> To: 
>>
>>
>> Jon Wilmoth created LOG4J2-3650:
>> ---
>>
>>  Summary: Release 2.20.0 missing artifacts
>>  Key: LOG4J2-3650
>>  URL: https://issues.apache.org/jira/browse/LOG4J2-3650
>>  Project: Log4j 2
>>   Issue Type: Bug
>>   Components: Core
>> Affects Versions: 2.20.0
>> Reporter: Jon Wilmoth
>>
>>
>> It looks like the new 2.20.0 release didn't publish the
>> log4j-core--tests.jar files that were in the previous release.
>> Can these files be published?
>>
>> #
>> https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.19.0/
>> #
>> https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.20.0/
>>
>>
>>
>>
>> --
>> This message was sent by Atlassian Jira
>> (v8.20.10#820010)
>>
>

Re: On publishing test JARs

[Volkan Yazıcı]

I understand the use case, but I don't agree on the solution. You are using
Log4j tests. Do I really need to explain why this is a bad idea? Imagine
you in a similar way used Kernel tests and posed this question in the
mailing lists and Linus writing you a response...

What I would find approachable is to create a separate module bundling
these utilities and only these! There we can even exercise our regular
support policy.

On Wed, Feb 22, 2023 at 1:24 PM Gary Gregory  wrote:

> Please keep publishing test jars, at least the core and api jars. One of
> these contains Junit rules and utilities that are very useful and I reply
> on those for many projects.
>
> Gary
>
> On Wed, Feb 22, 2023, 03:04 Volkan Yazıcı  wrote:
>
> > I don't know what was our earlier policy on test JARs (if we have any at
> > all), but I suggest we stop deploying to Nexus anything that is not meant
> > for public consumption: api, core, adapters, filters, etc. Now are we
> > supposed to spend hours fixing the tests of an individual because he
> > happened to depend on Log4j tests?
> >
> > -- Forwarded message -
> > From: Jon Wilmoth (Jira) 
> > Date: Tue, Feb 21, 2023 at 10:31 PM
> > Subject: [jira] [Created] (LOG4J2-3650) Release 2.20.0 missing artifacts
> > To: 
> >
> >
> > Jon Wilmoth created LOG4J2-3650:
> > ---
> >
> >  Summary: Release 2.20.0 missing artifacts
> >  Key: LOG4J2-3650
> >  URL: https://issues.apache.org/jira/browse/LOG4J2-3650
> >  Project: Log4j 2
> >   Issue Type: Bug
> >   Components: Core
> > Affects Versions: 2.20.0
> > Reporter: Jon Wilmoth
> >
> >
> > It looks like the new 2.20.0 release didn't publish the
> > log4j-core--tests.jar files that were in the previous release.
> > Can these files be published?
> >
> > #
> >
> https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.19.0/
> > #
> >
> https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.20.0/
> >
> >
> >
> >
> > --
> > This message was sent by Atlassian Jira
> > (v8.20.10#820010)
> >
>

Re: On publishing test JARs

[Ralph Goers]

Both Piotr and I have responded to that Jira issue and I marked it as resolved. 
We do publish test jars. They just no longer use a classifier. 

Volkan, the test jars we publish are expected to be used for public 
consumption. Note that I did NOT include Json Template Layout’s test jar in the 
distribution zip but if it doesn’t have the skip deploy property set then it is 
still being published to Maven Central. You would know best of users would need 
that for some reason but I kind of doubt it.

Just to clarify, the test jars we publish contain NO unit tests, only the 
testing framework classes we use.

Ralph

> On Feb 22, 2023, at 5:25 AM, Gary Gregory  wrote:
> 
> I should add that I don't expect any kind of BC compatibility, I take them
> as they are and adapt.
> 
> Gary
> 
> On Wed, Feb 22, 2023, 07:23 Gary Gregory  wrote:
> 
>> Please keep publishing test jars, at least the core and api jars. One of
>> these contains Junit rules and utilities that are very useful and I reply
>> on those for many projects.
>> 
>> Gary
>> 
>> On Wed, Feb 22, 2023, 03:04 Volkan Yazıcı  wrote:
>> 
>>> I don't know what was our earlier policy on test JARs (if we have any at
>>> all), but I suggest we stop deploying to Nexus anything that is not meant
>>> for public consumption: api, core, adapters, filters, etc. Now are we
>>> supposed to spend hours fixing the tests of an individual because he
>>> happened to depend on Log4j tests?
>>> 
>>> -- Forwarded message -
>>> From: Jon Wilmoth (Jira) 
>>> Date: Tue, Feb 21, 2023 at 10:31 PM
>>> Subject: [jira] [Created] (LOG4J2-3650) Release 2.20.0 missing artifacts
>>> To: 
>>> 
>>> 
>>> Jon Wilmoth created LOG4J2-3650:
>>> ---
>>> 
>>> Summary: Release 2.20.0 missing artifacts
>>> Key: LOG4J2-3650
>>> URL: https://issues.apache.org/jira/browse/LOG4J2-3650
>>> Project: Log4j 2
>>>  Issue Type: Bug
>>>  Components: Core
>>>Affects Versions: 2.20.0
>>>Reporter: Jon Wilmoth
>>> 
>>> 
>>> It looks like the new 2.20.0 release didn't publish the
>>> log4j-core--tests.jar files that were in the previous release.
>>> Can these files be published?
>>> 
>>> #
>>> https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.19.0/
>>> #
>>> https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.20.0/
>>> 
>>> 
>>> 
>>> 
>>> --
>>> This message was sent by Atlassian Jira
>>> (v8.20.10#820010)
>>> 
>> 

Re: Log4j team vs Logging Services team

[Ralph Goers]

Yes, I disagree for a few reasons:

1. Not all the people listed in the logging services team page contribute to 
each project. While it is probably OK for Log4j because most Logging Services 
members are contributing to Log4j the same would not be true for Log4cxx and 
Log4Net. 
2. We are not going to add contributors to the Logging Services Team page so 
individuals who have made contributions but are not a committer or PMC member 
are not going to be acknowledged. 

The main issue as I see it is that the developer list in the pom.xml is not 
being maintained. That is probably because we have never discussed it.  The 
answer to that is pretty simple - we just need an agreement on when 
contributors to the project should be added and how long they should stay, as 
well as keeping the list of PMC members and committers accurate.

Ralph

On 2023/02/22 08:26:20 Volkan Yazıcı wrote:
> I propose redirecting all "Team" links in Log4j, log4cxx, etc. to the
> Logging Services Team page .
> 
> I know Ralph disagrees with me[, hence this email]. He wants the Log4j
> project to have its own "Team" page where its content is populated from
> `pom.xml`. I strongly disagree with this. `pom.xml` only contains people
> who happen to care about having their names there: some PMC members,
> committers, random contributors. It didn't even contain the entire Log4j
> PMC – this I fixed myself while doing the recent site work. I don't know
> what it represents, but that thing is certainly not _the team_. Having one
> central place, the Logging Services Team page, is not only convenient, but
> accurate; those people are the official maintainers.
> 
> maven-site-plugin is dead
> 
> for a reason.
> 
> Long story short, I would appreciate your input for a tie breaker.
> 

Re: Broken Javadoc URL

[Ralph Goers]

Answering right now my preference is number 1 however that could change if no 
other complaints are made regarding the web site. We eliminated a number of 
project reports that users might yet complain about. So adding in the module 
directories makes it much easier to restore missing reports should that be 
needed. However, if no one complains then my answer would probably change. 

All that said, I am not sure using .htaccess the way you describe will be 
sufficient as it only solves the problem for the latest release. Anyone who 
references a specific release will still have a bad link.

Ralph

On 2023/02/22 09:28:24 Volkan Yazıcı wrote:
> While fixing the javadoc for the 2.20.0 release, I renamed the path from
> `//apidocs` to `/javadoc/`. As the user issue below
> explains, this got some people angry. I have already temporarily fixed the
> issue by creating directory symlinks. For a permanent solution, I see two
> options:
> 
>1. Configure the `javadoc-maven-plugin` to output to `//apidocs`
>instead of `/javadoc/`. The reason I am not happy with this
>approach is that it actually was like that since that is how
>`maven-site-plugin` works and it is not aligned with the website directory
>structure. Nonetheless, it is doable.
>2. Create an `.htaccess` entry *permanently* redirecting
>`2.x//apidocs` to `2.x/javadoc/`. I am sort of inclined
>with this fix, since we can stick to our directory structure.
> 
> Thoughts?
> 
> -- Forwarded message -
> From: Alexander Brandes 
> Date: Wed, Feb 22, 2023 at 9:36 AM
> Subject: [apache/logging-log4j2] Broken Javadoc URL (Issue #1284)
> To: apache/logging-log4j2 
> Cc: Subscribed 
> 
> 
> Hey,
> 
> It appears that a recent changed forced a change of the Javadoc URL from
> https://logging.apache.org/log4j/2.x/log4j-api/apidocs/ to
> https://logging.apache.org/log4j/2.x/javadoc/log4j-api/index.html.
> 
> Is there a particular reason why this was changed without a redirect
> pointing to the new location? This change affects hundreds
> 
> of files in open source projects, now left behind broken.
> 
> Some builds may also fail because a build tool can no longer obtain the
> file from the old location:
> 
> Error fetching URL:
> https://logging.apache.org/log4j/2.x/log4j-api/apidocs/
> (java.io.FileNotFoundException:
> https://logging.apache.org/log4j/2.x/log4j-api/apidocs/package-list)
> 
> —
> Reply to this email directly, view it on GitHub
> , or unsubscribe
> 
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: 
> 

Re: On publishing test JARs

[Matt Sicker]

Right, there are intentionally public test fixtures in API test and Core test 
(and eventually plugin test). While they don’t guarantee strict backward 
compatibility, they are intended for use outside of this project.

> On Feb 22, 2023, at 10:02 AM, Ralph Goers  wrote:
> 
> Both Piotr and I have responded to that Jira issue and I marked it as 
> resolved. We do publish test jars. They just no longer use a classifier. 
> 
> Volkan, the test jars we publish are expected to be used for public 
> consumption. Note that I did NOT include Json Template Layout’s test jar in 
> the distribution zip but if it doesn’t have the skip deploy property set then 
> it is still being published to Maven Central. You would know best of users 
> would need that for some reason but I kind of doubt it.
> 
> Just to clarify, the test jars we publish contain NO unit tests, only the 
> testing framework classes we use.
> 
> Ralph
> 
>> On Feb 22, 2023, at 5:25 AM, Gary Gregory  wrote:
>> 
>> I should add that I don't expect any kind of BC compatibility, I take them
>> as they are and adapt.
>> 
>> Gary
>> 
>> On Wed, Feb 22, 2023, 07:23 Gary Gregory  wrote:
>> 
>>> Please keep publishing test jars, at least the core and api jars. One of
>>> these contains Junit rules and utilities that are very useful and I reply
>>> on those for many projects.
>>> 
>>> Gary
>>> 
>>> On Wed, Feb 22, 2023, 03:04 Volkan Yazıcı  wrote:
>>> 
 I don't know what was our earlier policy on test JARs (if we have any at
 all), but I suggest we stop deploying to Nexus anything that is not meant
 for public consumption: api, core, adapters, filters, etc. Now are we
 supposed to spend hours fixing the tests of an individual because he
 happened to depend on Log4j tests?
 
 -- Forwarded message -
 From: Jon Wilmoth (Jira) 
 Date: Tue, Feb 21, 2023 at 10:31 PM
 Subject: [jira] [Created] (LOG4J2-3650) Release 2.20.0 missing artifacts
 To: 
 
 
 Jon Wilmoth created LOG4J2-3650:
 ---
 
Summary: Release 2.20.0 missing artifacts
Key: LOG4J2-3650
URL: https://issues.apache.org/jira/browse/LOG4J2-3650
Project: Log4j 2
 Issue Type: Bug
 Components: Core
   Affects Versions: 2.20.0
   Reporter: Jon Wilmoth
 
 
 It looks like the new 2.20.0 release didn't publish the
 log4j-core--tests.jar files that were in the previous release.
 Can these files be published?
 
 #
 https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.19.0/
 #
 https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.20.0/
 
 
 
 
 --
 This message was sent by Atlassian Jira
 (v8.20.10#820010)
 
>>> 
>