So here's the problem.
You have a webapp that packs two jars A.jar, and B.jar. A depends on C.v1.jar, but B depends on C.v2.jar. Both C jars include the same class with different signatures, because they are different, incompatible, versions.
I can hear you sighing from here.
There are actually a few solutions:
1. OSGI. If you can figure it out, it can actually do the classloader magic for you.
2. If you're like me you can use the WEB-INF/classes, since these classes are loaded in a classloader that has priority over WEB-INF/lib classes, and attempt to do via sources, or a decompiler (JD-GUI) a conflicting class that is compatible with both A and B. But that's error prone, and is a LOT of work, for more complex changes in API.
3. JarJar. With JarJar you can rename a package to another package, and it will also rename all the references in the classes. So you can just pick for example B and C.v2.jar, and rename the conflicting packages or classes (directly inside the jar themselves).
4. Project JigSaw, seems to be adressing just that, but this appears to be available only with Java 8 unfortunately.
Personally I used JarJar. Seemed by far the easiest to use, and worked flawlessly.
Turns out to be BZIP2.
Considering that most of it is actually already compressed ZIP data (the JRE), it's an outstanding performance.
Whenever I hear about Firefox, I cringe a bit.
Its news lately seem to be only scandal after scandal. If you don't follow the tech news, basically:
They lost the desktop battle to Chrome, and the enterprise world is still into IE.
On mobile it's even bleaker, and they are virtually non existent, since they lost the mobile market to Webkit as well, but this time really-really bad: Safari on the IPod, Chrome and the default WebKit browser on the Android, and even platforms like Cordova that allow publishing web apps as native apps, are rendering with the phone's webview, that is ... WebKit, or IE on Windows Mobile. Opera as well switched to WebKit and V8.
On the server side, node is all the buzz, and Mozilla or IE are not existing.
So, slowly but surely, Mozilla and their Firefox slide into obscurity and instead of fixing their products or strategies they go with random stuff like Firefox OS, dreaming that the future world is a world of web things, and people will switch to their no-real-apps-available platform, ignoring the elephant in the room (the fierce battle between Apple, Samsung and Microsoft into the mobile arena), and somehow in their parallel world aren't able to see that native apps are here to stay.
Yes, Web is becoming more prevalent, but people are not using their browser, and yes many mobile apps are now HTML5+JS powered, but they're not running on the Mozilla's stack, and yes the JS is permeating now even the server side world, but not using the JS engine from Firefox, but rather V8. So this is why all the talk from Mozilla regarding open web, remains just that, talk, talk that fails to materialize into a good product and strategy.
I surely hope, for your sake Mozilla, that you'll prove me wrong with time.
Updating Joomla between major versions is painful, since plugins are not guaranteed to be compatible anymore. CentOS 6.5 adds to the difficulty since it's stuck to version 5.3.3 of PHP, and since Joomla 3.3, only versions from 5.3.10 and higher are actually supported.
This article is a general overview on how to upgrade.
1. Do a backup, and run the actual update process on a virtual machine
Two times I managed to screw up my update on the virtual machine, and had to start all over, and believe me it's easy to do so. If you don't backup you are pretty much bound to do the same at some point. Regular backups should be anyway done on a regular basis.
To do a backup you just need a copy of all the files, and of the database:
2. Remove all the custom extensions and templates (Extensions > Extension Manager > Manage)
I've seen people recommending trying to find if the plugins you have installed are available as well for Joomla 3.3. Personally I ran into trouble since some of them don't support newer versions of PHP and just spectaculously crash. This is why I decided to remove all of them, and add new plugins with the same functionality directly for Joomla 3.3.
The easiest way to do it was to sort them by ID descending, since the extensions I installed after the Joomla default setup had obviously bigger IDs.
3. Change the Template to one of the Joomla defaults
Custom templates I've seen they generally don't play nice between different versions of Joomla or PHP.
4. Update PHP to 5.5
If you are like me on a CentOS machine, you need to add a repository that actually contains PHP 5.5 (unless you feel brave enough to compile it yourself).
Remove the old PHP:
Afterwards you need to install the packages you need:
This package list might be different. For example I needed mbstring just for Piwik, that also runs on the same instance, not for the actual Joomla install.
5. Change the update policy to short term support
Joomla 3.3 should appear in the update list. If it doesn't you need to fix the database (Extensions > Extension Manager > Database), and purge your cache (System > Purged Expired Cache).
6. Update Joomla
I just update by overwriting files. For this I make sure that all the files can be written by the apache user, thus in the folder where Joomla is installed I generally run:
7. Download a new template, install plugins, and configure their modules and positions
While this last step seems the shortest, since you at this stage are on Joomla 3.3, it turned out to be the half of the time in case of my installation, to get about the same positions, and features, and even some extra functionality that I suddenly decided it would be nice to have (like FB likes).
That should be about it.
In practice you'll run into trouble, and I know I'm repeating myself: do a backup.
The one to rule them all. The browsers that is.
SharpKnight is an Android chess game.
MagicGroup is an eclipse plugin.