[
https://issues.apache.org/jira/browse/MNG-7659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653675#comment-17653675
]
Michael Osipov commented on MNG-7659:
-------------------------------------
I don't have a real opinion. Adding cache must be done with great cation. We
have caches in Maven which also cause regressions, Can find an example, if
necessary.
> ComparableVersion cache
> -----------------------
>
> Key: MNG-7659
> URL: https://issues.apache.org/jira/browse/MNG-7659
> Project: Maven
> Issue Type: Improvement
> Affects Versions: 3.8.7
> Reporter: Andrzej Jarmoniuk
> Priority: Minor
>
> Tobias Gruetzmacher has raised an issue with Versions Maven Plugin -
> [Performance issue with many versions/artifacts
> #869|https://github.com/mojohaus/versions/issues/869], where he points out
> that we're creating lots of ComparableVersion objects (which happens
> especially during ArtifactVersion comparison), which affects performance. He
> proposed creating a simple cache for these objects.
> This proved to increase performance in some Versions Maven Plugin jobs almost
> twofold.
> What do you guys think of introducing this to Maven?
> The cache should probably be restricted in size (e.g. use LRUMap from commons
> collections), so that it won't leak memory when used with mvnd.
> Simple implementation is here: https://github.com/mojohaus/versions/pull/870
> Using LRUMap: https://github.com/mojohaus/versions/pull/893
> The cache could alternatively be owned by DefaultArtifactVersion, where the
> construction of ComparableVersion is taking place.
> I'm querying for opinions on this; if this gains approval, I could implement
> it. Ultimately I'd like to get rid of the ComparableVersion duplicate in
> Versions Maven Plugin.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
