Liferay Portlets Deployment - java

Good afternoon.
I'm working on a migration from WebSphere to Liferay 6.2 CE.
So far I am able to Export the main project to a WAR file, and Import it in Liferay.
The real problem comes on a development environment...
When changes are made to the project, the deployment process is time consuming.
It is necessary to exclude the previous portlet, and install the new one with the changes compiled.
Is there an easier way to deploy the project, directly has a Liferay Portlet?
Something like, click a button or run a command, and have it deployed immediately to Liferay's Server.
Best regards.

Build and Deployment Automation
Liferay 6.2 portlet development supports Ant, Ivy, and Maven build automation. Our developers typically use the Ant build scripts that come standard with Liferay 6.2, and we use Jenkins to automate our deployments to our various test and production servers.
However, even with the aforementioned tools, builds in 6.2 can be tedious and very time consuming. This issue is mostly eliminated in DXP with the introduction of OSGi modules but these OSGi modules are not supported in 6.2.
While Liferay does not provide a solution for this out-of-the-box there is one tool above all else that has drastically decreased our build and deployment times in 6.2
JRebel
JRebel is a fabulous product for Java EE development and has been especially helpful and supported on the Liferay platform. Essentially JRebel is a tool that allows you to save changes to your code and see those changes instantly without running any Ant targets or moving any war files around.
JRebel is not a free product (it costs $500 a year per license) but you can get a free copy (with 100% of the functionality) if you are using for non-commercial projects. To get a license simply search for "My JRebel" and register an account.
JRebel for Liferay
JRebel integrates very easily with Liferay, and there is some documentation on the Liferay Blogs regarding configuration. However the last time I checked the blog posts outline an older way of configuration that is no longer supported (or at least no preferred). Therefore I will briefly go over the steps needed to configure JRebel with Liferay.
Configuration
Follow these steps after you have obtained either a free license through My JRebel or purchased a license key if this is a commercial project. If you are onboarding this tool at your company you will definitely want to use their license server.
Open your Liferay Development Studio (or Eclipse IDE with the Liferay plugin installed) and go to Help > Eclipse marketplace.
Once the Eclipse Marketplace window loads search for JRebel and go through the download and installation process.
Once the installation process is complete (and your IDE has restarted), go to Help > JRebel > Activation.
You will have a window with three options (activation code, license key, license server). If you are using My JRebel you will likely have a .lic file. You will want to select that option and locate the file on your system. If you are using this in an enterprise setting I highly suggest using a license server. If have not included directions for that as it is outlined elsewhere and is not at all specific to Liferay.
Once JRebel is activated you should now see a JRebel configuration perspective in the top right hand corner
Click on the perspective, navigate to the start up tab, and select the following configurations
Then navigate to the projects tabs and select all the portlets you want to apply JRebel to. Only select the first box unless you are running some type of container environment (which you did not specify).
Then in your Eclipse menu select Project > Build Automatically
Testing your configuration
There are a few indications that your configuration is working. Firstly, in your projects source folder you should see a rebel.xml configuration file.
If you see the file there it's time to start the server. Immediately after starting the server you will some new lines written at the top of the catalina log file.
Additionally in your Tomcat's temp folder you should see a new JRebel directory.
Once the portal loads make a change to one of your Java files. In the Catalina console you should see a newly printed line with the fully qualified name of the class you just modified. Check to see if your change has taken effect!
Issues
If you have issues at any part in this process there are a few things you might want to look out for. If you are receiving any permgen errors you might want to modify the JVM flags related to memory in your server configuration panel. Additionally in the same location you may need to toggle the publish automatically settings. Additionally I have always had issues with JRebel not working for made to method signatures in the ORM files generated by service builder. If I am adding a new method to those classes JRebel doesn't pick it up. If I am adding or modifying the type of a parameter in one of the methods in those classes JRebel doesn't pick it up. Changes to the code in the localserviceimpl and serviceimpls seems fine in all other regards, and every other class works fine with JRebel. The engineers at ZeroTurnAround swear it works perfectly with Service Builder, but I haven't had success in those aforementioned cases.

Related

How can I import an project in nwds web dynpro from netweaver

I have to complete the work of a colleague who is ill. My problem is I cannot talk to him and cannot work with hies files or his computer.
I can see the Project in the component browser of the PO. I have imported some files in my workspace but I cannot work with them in the WebDynpro explorer.
Does somebody know what to do to?
Have I imported the files wrong or is there any additional step I have missed?
Navigate to Development Infrastructure, find your project, right click on it and choose 'Create Project', later on ask your collegue to check-in all of his changes and sync the project in Development Infrastructure on 'Open Activites' tab.
Make sure you are not working on the same component simultaneously as version controll will give you a very hard time and it is most likely that one of you will loose the changes.

Eclipse plugin development: Is plugin update or uninstall/install really clean?

While developing Nodeclipse, I found that some bugs don't arise immediately but after some time, when combination of updates, restarts happens.
Is plugin update or uninstall/install really clean?
I develop and use installing for update, then use newer version until I got time/idea to improve. However as said above I ran into situation when Eclipse behaves differently after the new feature have been used for several days.
Is there some information that must be read about plugin install life-cycle, that mentions some not so evident behavior.
UPDATE: Some problem were in Autumn 2013 when we were switching to tycho build. Also around that time Eclipse Kepler 4.3.1 was released.
No, they are not "clean". Moreover when you do uninstall, no files are deleted, Eclipse would just prevent plugin from loading on the startup.
If you really want to remove the plugin you need to
Uninstall it via UI
Delete the plugin files in the file system
Remove plugin settings from workspace or create a new one.
Here is some interesting info for you:
There is no mechanism within Eclipse to permanently and physically
uninstall a feature and its plug-ins. The process to physically and
permanently remove an undesirable feature and its plug-ins is a manual
process that should be done when Eclipse is not running. In order to
do, you will have to manually remove the files there associated with
the feature from the eclipse/features directory and its plug-ins from
the eclipse/plugins directory. Be very cautious as to which files you
delete, and always have a backup of your Eclipse directory. If you
remove the wrong files from these directories, you may have quite some
trouble restoring your Eclipse to a stable state. Therefore, unless
your hard disk storage capacity is extraordinarily limited, it is
recommended that you simply leave the physical files in place.
Note that when manually removing plugins as described above, it is
likely that some metadata will still cached by Eclipse. This can lead
to problems later on. Running Eclipse with the -clean option may help
with that, as it causes Eclipse to clean the cached metadata. See the
Running Eclipse help page for details about this option.
Source: http://wiki.eclipse.org/FAQ_How_do_I_remove_a_plug-in%3F
You cannot do this ideally, because the plugins designed for eclipse leave their temp access files even if they are uninstalled, to do so, you will have to follow the steps:
Uninstall the Plugin: You can use the Eclipse UI directly. Go to Help > About Eclipse > Installation Details, select the software you no longer want and click Uninstall.
Delete the Present temp Files in the System, make sure to re-check the dependencies(Note: Removing Dependent Plugins might cause Eclipse to stop Working).
Remove the plugins from the workspace, or in short you can re-configure a new workspace.
This would be removing the plugins, but removing its traces manually.
ref#Link

How can we automatically disable an Eclipse plug-in on target platforms?

We have developed an Eclipse plug-in called CodingSpectator that collects some data about the usage of various Java development tools in Eclipse. This data helps us better understand how developers use Eclipse and how we can improve Eclipse to better suit the needs of programmers. CodingSpectator captures data from every workspace that is opened in Eclipse. Some of our users develop RCP applications or Eclipse plug-ins. Therefore, they run new instances of Eclipse from their main instance of Eclipse. However, we don't want CodingSpectator to collect data from the target platforms (new instances of Eclipse opened from within the main Eclipse). So, we instruct our users to configure their target platform to exclude CodingSpectator (See http://codingspectator.cs.illinois.edu/resources/documentation/user-guide.html#htoc6). But, configuring the target platform manually is not convenient. And, we are looking for better ways to stop capturing data from target platforms.
How can we automatically disable CodingSpectator on the target platforms of our users?
One way could be to look for the -dev application argument. This argument is always added by PDE when launching an application from within Eclipse.
I used Platform.inDevelopmentMode() to determine if the instance Eclipse is run from within another instance of Eclipse.
For at least RCP applications, it's likely that a target has already been defined, for stability across a team and a release.
But for those cases where someone wants to test a plug-in using the developer's version of Eclipse, perhaps you could provide a utility to make the target.
A target can be defined by a file in a project. You could provide a utility that generates the file. All the user would have to do would be:
Run your utility
Refresh the project (if necessary).
Open the generated target file in the Target Editor.
[OPTIONAL] Modify the generated target further.
Click on the "Set as Target Platform" link in the upper-left of the Target Editor.

Eclipse and JBoss not refreshing or rebuilding

I'm having this problem in eclipse (EE) when I change things in my code (even something as simple as the text I'm printing using println) it doesn't get applied. I'm using JBoss and when I rerun the servlet, nothing happens.
Any idea how I can force JBoss/Eclipse to do this? I can't preview anything so it's really annoying if I want to test some new code.
Thanks!
Eclipse publishes the newer versions of your application periodically (its called the automatic publish feature). Either the interval is too large, or you're not waiting sufficiently long enough for re-deployment, or automatic publishing of the application has been disabled.
Sometimes, despite ensuring the above, Eclipse might still not publish the newer classes, in which case you might want to perform a clean build, which causes the newly built classes to be loaded into JBoss.
Sorry to ask such a basic question: Do you save your changes before testing?
Eclipse uses its own compiler to check for syntax errors while you are editing, but you have to save the file before the edits take effect in the application.
I only ask because this could be confusing if you are new to Eclipse, having changed from a different IDE. File permission settings can also prevent your files from being saved or built.
Working on EJB deployed in JBoss with Eclipse IDE.
We have ANT build file, in which first old project is deleted from JBoss,
then compiling classes, & building proper directory structure & deploy as .ear - .sar again in JBoss directory.
Stop JBoss, run build file, start JBoss.
Its a good practice to have a build file to deploy project.

Getting a lightweight installation of Java Eclipse

Having dealt with yet another stupid eclipse problem, I want to try to get the lightest, most minimal Eclipse installation as possible.
To be clear, I use eclipse for two things:
Editing Java
Debugging Java
Everything else I do through Emacs/Zsh (editing JSP/XML/JS, file management, SVN check-in, etc). I have not found any aspect of working in Eclipse to do these tasks to be efficient or even reliable, so I do not want plug-ins that relate to it.
From the eclipse.org site, this is the lightest install of eclipse that they have, and I don't want any of those things (Bugzilla, Mylyn, CVS xml_ui), and have actually had problems with each of them even though I do not use them.
So what is the minimal build I can get that will:
Ignore SVN metadata
Includes the full-featured editor (intellisense and type-finding)
Includes the full-featured debugger (standard Eclipse/JDK)
Does not have any extra plug-ins, platforms, or "integrations" with other platforms, specifically, I don't want to deal with plug-ins relating to:
Maven, JSP Validation, Javascript editing or validation, CVS or SVN, Mylyn, Spring or Hibernate "natures", app servers like a bundled Tomcat/GlassFish/etc, J2EE tools, or anything of the like.
I do primarily Spring/Hibernate/web-mvc apps, and have never dealt with an Eclipse plug-in that handles any of it gracefully, I can work effectively with my own toolset, but Eclipse extensions do nothing but get in the way.
I have worked with plain eclipse up to Ganymede, MyEclipse (up to 7.5), and the latest version of Spring-SourceTools, and find that they are all saddled with buggy useless plug-ins (though the combination is always different).
Switching to NetBeans/Intellij is not an option, and my teammates work with SVN-controlled .class/.project files, so it pretty much has to be Eclipse.
Does anyone have any good advice on how I can save a few grey hairs?
You can download the empty Eclipse platform and then manually install the JDT tools.
Go to the The Eclipse Project Downloads page.
Choose the bundle you want, probably Latest Release.
On the download page of the chosen bundle:
Download Platform Runtime Binary
Download JDT Runtime Binary
Extract the Platform Runtime Binary archive file and run it (for example, by double clicking on eclipse.exe).
Install the JDT binary:
Click Help → Install New Software → Add... → Archive.
Choose the JDT zip file you downloaded.
Uncheck Group Items by category.
Select the Eclipse Java Development Tools.
Click next to install and restart Eclipse when prompted.
JDT from the Eclipse update site
You can also install JDT from the Eclipse update site, instead of downloading the binary.
To do this, do this following:
Skip downloading the JDT Runtime Binary, only download, extract and run the Platform Runtime Binary.
Go to the Install New Software, but instead of Archive chose the Eclipse download site.
Search and install Eclipse Java Development Tools.
The "Eclipse IDE for Java Developers" version isn't the smallest one! Look for "Eclipse Classic" - it doesn't contain most of the things you mentioned. It's larger in download size only, because it comes with source code.
See this comparison: http://www.eclipse.org/downloads/compare.php
You can use a thirdparty distribution builder like Yoxos and download just what you want.
A bit late to this party, but I asked myself the same question for a while, and while now I'm back to a more fully-fledged Eclipse installation, I used to to the following to streamline it a bit. Hope it helps.
What I Needed
Functionalities:
Java Support
Java + Java EE (XML) + Debug Perspectives
Pretty much it. There's a lot of other things I like to use in Eclipse, but I needed to keep it down to the skinniest possible because I was in a 3GB environment where I also needed to run other servers in parallel, so I couldn't afford much.
Resulting Perspectives:
Lightweight Java
Lightweight Browser (fairly tweaked for code reviews and code inspection - that one was actually heavier than the others)
Lightweight Debug
What I Did
Install Eclipse Java EE (install classic if not caring about the Java EE/XML bits)
disable hungry views
disable outline (when you need one, just do CTRL+O)
disable call and type hierarchies
disable decorators
disable menu entries (right-
disable toolbar items
even better: hide the toolbar
disable hovers and actions associated with that
disable spell-checking
disable XML validation
disable Mylyn
disable non-needed search forms in CTRL+H dialog (I usually actually only use the "File Search" mode, sometimes the "Java" one)
disable usage reporting
disable unnecessary plugins or features
disables perspectives and plugins loaded automatically on startup
restrict internal limits:
some views have a scope (enclosing class, project, working set, workspace...)
some views and UI elements have boundaries (console/loggers, highlighters, markers...)
tweak the eclipse.ini to:
-clean the workspace (slower, but I tend to prefer to do that)
use G1GC
reduce memory usage (I noticed that I can perfectly live with -xss128k and -xmx384 with G1, for instance. YMMV, of course, as always with JVM tuning.)
use a server VM (and point directly to the VM's DLL)
Also disable views you don't need in the "Debug" and "Code Browsing" perspectives.
Sorry, I had actually saved all of these as a set of 3 lightweight perspectives to re-import everytime on my new project, but I cannot get my hands on them at the moment. If I ever find then, I'll add a link to them here.
Instead of going for a ready package from Eclipse Downloads, from the same page go for the Eclipse Installer. Currently available for Mac, Windows & the beloved Linux. Launch the Installer which should update (or not if you are lucky enough :) ). Select "Eclipse Platform" which is the absolute minimum from this IDE, set your other installation preferences and install.
After the download/installation process, I'd suggest your head to Help->Install New Software and search for the Eclipse Marketplace (Yes, even that is not included in this package) just to make your life a bit easier.
Get as minimal an installation as you can, and then remove whatever is left that you don't want.
Longer answer:
I played around a bit. Here's how I experimented:
Extract a clean eclipse*.zip to two different directories; call it eclipse and eclipse-bak. We'll only modify eclipse.
Before starting it the first time, remove some of the features from the features folder. I got rid of org.eclipse.cvs, org.eclipse.epp.\*, ...mylyn\*, ...wst\*.
Start up Eclipse to a workspace. Create in that workspace a Java project, debugging configuration, etc. Stuff that you would want to do and that will complain if we remove the wrong thing. Open up the Error Log view.
Close Eclipse. Remove something (or a group of things) from the plugins folder.
Open Eclipse. Check the error log to see if something you care about couldn't load. If it did, add those things back from eclipse-bak/plugins. If not, close Eclipse and return to step 4 for a new set of plugins.
Using this I got my configuration to still be able to edit and debug Java files, but including only these plugins:
com.ibm.icu*
org.apache.*
org.eclipse.compare*
org.eclipse.core*
org.eclipse.debug*
org.eclipse.draw2d*
org.eclipse.ecf*
org.eclipse.epp.package.java*
org.eclipse.equinox*
org.eclipse.help*
org.eclipse.jdt*
org.eclipse.jface*
org.eclipse.ltk*
org.eclipse.osgi*
org.eclipse.platform*
org.eclipse.rcp*
org.eclipse.search*
org.eclipse.team.core
org.eclipse.team.ui
org.eclipse.text
org.eclipse.ui*
org.eclipse.update*
org.hamcrest*
org.sat4j*
Most of that is core stuff, but you might be able to trim it down further. Notably gone are Mylyn, the usage collector, EMF, CVS, WST, even JUnit (though I think you should keep JUnit).
I feel you man, when working with Eclipse, the application is constantly trying to help.
Ignoring workspace corruptions, I spend my development time fighting all the "helpful" things Eclipse does.
XML is not that hard to read, but it still confuses the shit out of me when I get the XML designer.
All it does for me is add an extra manual step to click on the source tab.
Every time a new version of eclipse comes out they redesign the front page and the distributions.
At which time a new quest starts for finding a way to debloat Eclipse again.
I have the same experience with extensions to Eclipse by third parties and avoid them if at all possible.
WTP has somewhat usefull stuff, but overall I prefer a basic java eclipse.
It is a good idea start with the Platform Runtime Binary and add JDT.
Manually extracting the JDT runtime doesn't seem to work for me these days, so it it better to use the update client.
You can use the marketplace client, but personally I have always found it rather annoying.
An alternative is to use the director. The director can install JDT without starting the GUI.
Here is a script that downloads eclipse Oxygen 4.7.3a and installs JDT unnattended:
#!/bin/sh
die() {
echo >&2 "$#"
exit 1
}
[ "$#" -eq 1 ] || die "exactly 1 argument required [INSTALL_DIR]"
[ -e "$1" ] && die "*warning* Aborting! location exists, eclipse already installed?"
INSTALL_DIR="$1"
TARBALL=eclipse-platform-4.7.3a-linux-gtk-x86_64.tar.gz
mkdir -p $INSTALL_DIR
if [ ! -f $TARBALL ]
then
wget http://mirror.csclub.uwaterloo.ca/eclipse/eclipse/downloads/drops4/R-4.7.3a-201803300640/$TARBALL
fi
tar -v -xf "$TARBALL" -C "$INSTALL_DIR" --strip 1
echo "\nUsing director to install java development tools, this may take a while..."
$INSTALL_DIR/eclipse -noSplash -application org.eclipse.equinox.p2.director -repository http://download.eclipse.org/eclipse/updates/4.7 -installIUs org.eclipse.jdt.feature.group
Simply call the script with one argument, the directory you want Eclipse installed.
Running the script gives me an unpacked install of roughly 129MB, which is more than 100MB smaller than the default download (zipped).
That is not to say you would not be able to shrink it further, but it should rid you of most of the crap.
The executable will be cached for future executions of the script, but it will still be slow, since it needs to go online to download JDT.
Unfortunately, I do not know of a way to cache the plugin download in a local folder.
You could of course zip the created installation, but the script is easier to commit to git.
This script will only work for new users as long as the mirror stays up and will need some updates when a new version is released.
But I am sure most developers are savvy enough to update the script if need be.
If you only want to use Eclipse for editing / Debugging Java I would suggest using a plain Text editor. It seems an overkill to install Eclipse and not use most of its features.
A very popular choice is VIM. Also check out this SO link for tips in using VIM as a Java editor. You can also debug Java code with a command line debugger as mentioned in this SO link.
I have figured out how to get the lightest possible eclipse with minimal efforts(imo). For the reference this is what I want in my eclipse:
Java project with Maven support
JavaEE support(Servers)
Debugging of Java application
(Irrespective of these you can install any feature that comes with Eclipse IDE with minimal effort, just follow the guide below)
Here's how I get it:
Go to eclipse download packages (Here's the link)
Find MORE DOWNLOADS (right hand side) and go to Other builds (Here's the link)
Now go to any build you like (Usually Latest Downloads -> whatever the first Build Name. Also There is links for older versions and archive site)
Under Platform Runtime Binary you can download Eclipse Platform as per your OS and/or requirement.
Now extract the archive and run the eclipse
Go to Help -> Install New Software...
Using Work with you can install your desired plugins and tools which usually ships with bulky eclipse
In Work with drop down select the site(mostly first) similar like this 2022-03 - https://download.eclipse.org/releases/2022-03 here 2022-03 is my eclipse version you may see different depending your version.
Now you can select the group(s) or expand the group(s) and select the specific plugins which you need and also you can filter by name like maven, debug, server, marketplace client etc in filter text input just below the Work with drop-down menu.
Install plugins and enjoy your very own lightweight eclipse.
Visual Studio Code
Fast forward to 2019 and we now can use Visual Studio Code with Java plugins. They provide a plugin pack to get you started with lightweight debugger and auto complete. Other plugins include maven integration, dependency viewer and more.
Visual Studio Code is a new(ish) editor/mini-ide from Microsoft which runs on Win/Max/Linux and has plugins for many languages.
Tutorial for setup: https://blog.usejournal.com/visual-studio-code-for-java-the-ultimate-guide-2019-8de7d2b59902
Edit 2019-06-21: MS now has a dedicated installer for Java integration with VS Code, including Spring Boot support as well. While the Intelisense is not 100%, it's vastly improved and now my go-to Java editor for testing and trying new things. Announcing the Visual Studio Code Installer for Java

Categories

Resources