Renaming a Liferay Project is Not The End Of The Story
You and your team have been working for weeks on a project. The deadline is tightening, but you are almost done. All finalization documents are being processed, but you still have to rename an Eclipse Liferay project according to requirements.
Doing so you run Service Builder for a test and there is that unsuspected BIG crash. The only solution Google gives you in this desperate hour is “Don’t ever rename. Create a new project and manually copy and paste everything you need.” Count to 10 and take a deep breath!
There is a way out of this situation, although it requires a good amount of attention. Just use this hint: Once you have run the renamed project, the Service Builder creates a new set of libraries with automatically generated code. This code is needed to implement, find, create, update and delete operations in the database, allowing you to focus on the higher level aspects of service design. For example, your project was first called “New Project.jar” and now it is called “Ready Project.jar”, but they both load sets of identical number of libraries with the same generic names. When renaming the project, the first set of automatic libraries are kept and not deleted.
The issue is that the two collections of automatic libraries refer to the same classes, and the two sets are loaded on the server arranged alphabetically (N is before R). When you rename the project, you run again the Service Builder and the new set of libraries are loaded on the server.
Then, you test your project after renaming it, the server loads the automatic set of libraries for the old project name, because they appear first. Then it loads the libraries for the new name. It finds out that those libraries are already loaded, there is a conflict and it crashes. The solution is to locate the automatically created library files for the old project name and delete them one by one. Next time when you run the project for a test there is no conflict.
ScaleFocus Team Leaders