Michael Osipov

> The javadoc tool resolves the URL [here](https://github.com/openjdk/jdk/blob/e3a5e265a7747b02b8f828fbedea0dda7246fc51/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java#L438). If `elemlisturlpath` is `https://assertj.github.io/doc/#assertj-core/apidocs/` then `link` will be `https://assertj.github.io/doc/element-list`. > > And this is what I believe should be done the same...

Here is an incomplete patch: ```diff diff --git a/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java b/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java index 0a291dd9..595f81dd 100644 --- a/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java +++ b/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java @@ -5765,6 +5765,9 @@ public abstract class AbstractJavadocMojo extends AbstractMojo { try {...

Scratch that patch, it does not work. The approch taken by the plugin and Javadoc a diametral. This needs to be aligned first.

> @michael-o A long time ago I've created an issue in the Maven Javadoc plugin project: https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-792 > > Maybe we should continue the discussion there. Agree.

If so, this has to be reflected in XMP data too.

Overview for signatures: https://www.adobe.com/devnet-docs/etk_deprecated/tools/DigSig/Acrobat_DigitalSignatures_in_PDF.pdf

I have grabbed now a copy of ISO 32000 and will try to understand in the next couple of weeks whether signatures always required forms and fields.

Now I wonder whether a TL would really be better than living without the cache. How big is the impact not using a cache?

@arkanovicz While Commons Pool is very nice I use if for heavy objects as well, how do you want to expose its configuration, lifecycle, etc. to the client? As of...

I consider this to be a workaround rather than a solution because the root cause has not been found.