Old jar files left hanging around after upgrading?

Help / Discuss
,
#1

Since I was playing closer attention to my log files after I upgraded to v16, I noticed the following error (all urlencoded decoded so it is readable from here on in):

[2024-02-07 10:23:57] [info] 2024-02-07 10:23:57,786 [main] WARN .e.r.i.l.LocalExtensionStorage - Failed to load extension from file [/var/lib/xwiki/data/extension/repository/org.xwiki.platform:xwiki-platform-logging-ui/12.1/org.xwiki.platform:xwiki-platform-logging-ui-12.1.xed] in local repository

So I decided to have a look in the directory and I found the following subdirectories:

./org.xwiki.platform:xwiki-platform-logging-ui:
10.0/
10.1/
10.11.1/
10.2/
10.3/
10.4/
10.5/
10.8/
10.8.1/
11.10.1/
11.2/
11.3/
11.6.1/
11.7/
11.8.1/
12.1/
12.10/
12.5.1/
12.8/
12.9/
13.0/
13.10/
13.10.2/
13.3/
13.6/
14.1/
14.10.2/
14.10.3/
14.5/
14.7/
14.8/
14.9/
15.10.3/
15.3/
15.4/
15.7/
15.8/
16.0.0/

Ignoring the actual error for the moment, I noticed that these jar files are for previous versions of xwiki.

Does that mean that every upgrade has left the previous versions of the libraries on the server? If so, why are old versions of the libraries left lying around? Is it necessary? Is there a reason why upgrading xwiki doesn’t remove these old versions?

Can I delete the older libraries? I mean, I’m pretty sure that the v10 logging-ui support jars are probably not being used on my currently installation, nor are they likely to be used again in the near future.

I am seeing this in the other library folders as well in that older versions of the library files are left hanging around.

The server is currently running ubuntu 20 and the upgrades happened via the apt upgrade command

Any insight would be helpful. I don’t want to be deleting things that are kept for reasons that I am unaware of.

Thanks.

#2

Interesting!

No idea about your question, but I’m gonna have a look at our situation.
Same here, the only difference is that folder names are url-encoded, i.e.:


# /var/lib/xwiki/data/extension/repository/
com%2Egithub%2Edocker-java%3Adocker-java-transport
com%2Egithub%2Edocker-java%3Adocker-java-transport-httpclient5
org%2Eapache%2Ehttpcomponents%2Ecore5%3Ahttpcore5-h2
org%2Ecodehaus%2Eplexus%3Aplexus-archiver
#3

Yes.

It’s more that Extension Manager does not try to figure out during upgrade if the local extension representing the previous version is still used and, for example, ask confirmation to the user to get rid of it (which would probably be the ideal).

There is a helper in https://extensions.xwiki.org/xwiki/bin/view/Extension/Extension+Tweak to remove local extensions which are not installed anymore (using this helper also mean you won’t have to restart for the change to be taken into account).

2 Likes
#4

@tmortagne it could be good to document this somewhere in the upgrade instructions, as something that admins may want to clean after upgrading.

#5

TBH (but with a hint of irony of course) as an admin I’d like to have less steps when upgrading :grin:

1 Like
#6

Yes ofc and we need to work on that. My point was to document it before we can find an automated way of dealing with it.

1 Like
#7

Sure, that’s why I added a smile at the end. Actually, I upgrade every three or four months, so an indication in the docs will be more than enough.

#8

Right. Sounds useful.

Forgive me for being so obtuse, but how do I access it once I have enabled the extension?

Edit: I found it under /Home/XWiki Advanced Administration Tools/ExtensionTweak/

#9

For those interested, my repository directory went from 813 MB in size to 79 MB after removing 3,026 unnecessary extensions.

My other xwiki installation has 1.1GB in the repository with 3,934 unnecessary extensions. I’ll tackle that one next.

This definitely needs to be noted in the upgrade instructions.

2 Likes
#10

2nd installation, after the v16 update:

4,026 extensions cleaned out
repository size from 1.2GB to 87MB.

sweet!

oh, and my xwiki startup time went from 60-90 seconds to 15. Bonus!

1 Like
#11

minor update: I just noticed that while the old local extensions are removed, the subdirectories are left behind.

I’ve submitted a bug report for this: Loading...