[
https://issues.apache.org/jira/browse/OAK-9989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17705219#comment-17705219
]
Marcel Reutegger commented on OAK-9989:
---------------------------------------
bq. The alternative would be to move the whole subproject outside the Oak
reactor pom (opinions?).
I'm in favour of moving the wrapped Guava library outside the reactor pom, or
even a dedicated git repo? It will and should have an independent release
cycle. There is also other candidate we could move: oak-doc-railroad-macro.
bq. Can we generate Javadoc for the shaded lib? If so, should we?
I would not do this, but I'm probably biased because I'm using IntelliJ and it
reads documentation from source files. So I'm happy as long as a sources jar
file is published to maven central.
bq. Should we try to minimize the library?
Why could you do this? I see two effects if we minimize the library
- It will be smaller. I doubt size is really an issue.
- Limit further usage of Guava in Oak. I'm not sure if this is a goal.
Anyway, the question to me is not _whether_ we should minimize it, but rather
why.
> introduce oak-wrapped-guava project
> -----------------------------------
>
> Key: OAK-9989
> URL: https://issues.apache.org/jira/browse/OAK-9989
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Major
> Fix For: 1.52.0
>
> Attachments: convert-guava.sh
>
>
> Plan:
> 1. add wrapped Guava project
> 2. change all internal uses of Guava to use o.a.j.oak.guava.* (or replace by
> JDK methods)
> 3. remove all Guava uses in public APIs (separate ticket)
> Note: IDEs do not work well with the shade plugin. In Intellij, you'll have
> to disable the wrapped-guava project. In Eclipse, you even need to remove it.
> The alternative would be to move the whole subproject outside the Oak reactor
> pom (opinions?).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
