Recently I worked on a project that introduced me to IBM® Worklight® mobile application platform. Among other things, I was pleasantly surprised at the price tag of the Developer Edition of this product: it is free. The Developer Edition comes with an Eclipse-based IDE called the Worklight Studio which offers support for authoring the client-side of your mobile web, hybrid and native apps as well as developing server-side components called adapters.
The Worklight Studio comes with a web application called the Mobile Browser Simulator that can help you with developing and testing your hybrid applications created using Apache Cordova framework. The Mobile Browser Simulator offers you a suite of visual controls for simulating a variety of native bridge APIs to such native device capabilities as accelerometer, camera, compass, file system, device info, contacts database, etc., without the need to run your apps directly on mobile devices or their emulators (which would require setting up specific run-time environments, such as ADT Eclipse plug-in for Android, Xcode for iPhone, etc.)
Here is a screen-shot of the Mobile Browser Simulator that shows Cordova APIs’ visual controls/widgets on the left with the expanded Battery widget that helps simulate different battery levels and the battery plugged-in event (fired when the battery is plugged in for charging and stays in this state until un-plugged).
So, if you are interested in this approach to testing Cordova hybrid apps, below are a few simple steps to follow that will help you get up and running in no time.
Lately I’ve been working quite a bit on expanding the classes available in our Spring 3.0 category. One of the things that has always set our Spring training apart is that we offer options to develop Spring applications for WebSphere (in addition to other classes that use JBoss or Tomcat). Spring has been a very popular framework and WebSphere a very popular server so it has always been a popular choice for our clients.
In the past, the downside has always been that WebSphere development required Rational Application Developer (RAD). Doing Spring development in RAD was never a great fit since you couldn’t use the Spring Eclipse plug-ins that were available from SpringSource. You also had some choices from MyEclipse for WebSphere and Spring tools but those weren’t free. Now recently, IBM released FREE Eclipse tools so you can control and deploy to a WebSphere server directly from Eclipse, something that used to require RAD. I’ve blogged about that before but that was without Spring tools.
So while developing our Spring 3.0 classes for WebSphere I wanted to take a fresh look at what would be the best environment for this. The contenders would be:
Read the rest to see the “Winner” and how to set it up!
What does the end of June and Java development have in common? Looking forward to the yearly coordinated release of all the latest Eclipse updates. This year the release is code named “Juno”. The release in June 2011 was “Indigo”.
This year marks the 7th time that the “Simultaneous Release” approach has been used that lets a new version of the underlying platform and all of the projects that build on top of it release. This has helped to greatly improve the compatibility between projects and the stability of the Eclipse platform as a whole. It also helps the numerous commercial products that are based on Eclipse count on a consistent schedule and release updates quickly based on the new updates. This year there were about 70 Eclipse projects part of the Juno release which expands on the 62 that were part of Indigo last year.
If you want to get started the first place to go is probably the usual Eclipse downloads page. This has been updated for links to the Juno versions of several different “pre-configured” combinations of Eclipse tools besides just the “basics” of the core platform. One of the most popular downloads is the “Eclipse for Java EE Developers”.
Now I will be the first to admit that like most of you, I can’t spend too much time looking at the new features that are coming out before they are released. So this post is more of a “news” post and future posts will dive into some of the details about what is new. Probably one of the best places to start for this kind of info are some of the “New and Noteworthy” pages like the one for the Java EE tools and the one for the core platform itself and the Java tools.
Probably one of the biggest changes is that the “default” version for the Eclipse SDK, which is the core of the platform is Eclipse 4.2. The Eclipse 4.x platform has been in the works for over a year but this is the first release where it is the “default”. All of the previous simultaneous releases were using the Eclipse 3.x platform so this has definitely been a measured process that Eclipse has gone through. It appears the “regular” Eclipse user won’t notice this much though compared to Indigo except for an updated UI style. For anyone developing Eclipse plug-ins or perhaps RCP (Rich Client Platform) applications using Eclipse there are more changes, although it is said that Eclipse plug-ins developed for previous Eclipse versions will have “binary compatibility” with the new version so hopefully this would be a smooth process. Certainly anyone in these categories will want to check out the Eclipse 4.x SDK page for more details.
BTW, if you want to set your calendars now, the next major release will be June 26th, 2013. This will be codenamed “Kepler” in keeping with the astronomical theme which has also recently started picking names that are alphabetical.
UPDATE: We’ve posted some Java EE 6 development courses that use WebSphere and Eclipse to highlight this capability. The best place to find these classes is in the WebSphere 8.0 Programming category.
UPDATE: If you are also interested in Spring tools for WebSphere development you might check out a related blog post – How about a FREE set of WebSphere and Spring Eclipse Development Tools?
UPDATE: Currently the versions of the Eclipse and WebSphere downloads are different than those detailed here. The same process still works though and the important part is that if you want to run a WebSphere server from Eclipse (one of the main reasons to perform this setup) the Eclipse instance has to point to the IBM JVM. This is easiest to do by pointing it to the IBM JVM installed with the ‘WebSphere for Developers’ as outlined in this post. Post questions if you have any as I try to keep up with the comments on this post.
For the longest time the biggest complaint we’ve heard from developers who use WebSphere is “We can’t just use Eclipse!”. In fact, the fact that the only “official” development support IBM would provide for WebSphere was Rational Application Developer created an entire market for MyEclipse Blue of people that didn’t want to pay for RAD but developed for WebSphere. Even MyEclipse Blue is not free though, it is just cheaper than RAD.
So to solve this problem you do not know how many WebSphere shops I’ve seen that:
Well now it is MUCH EASIER! IBM has just released FREE Eclipse plugins to deploy/start/stop WebSphere v7.0 and v8.0 servers from the Eclipse ‘Servers’ view. I bet you aren’t used to hearing IBM and “free” in the same sentence! These are only available for WebSphere Application Server v7.0 & v8.0 (no WebSphere 6.1, WebSphere Portal or Process Server) but these are some of the most common WebSphere environments right now and in the near future.
All of this is done with the “WebSphere Application Server Developer Tools for Eclipse” in the “WASdev” community on IBM Developerworks. Although you might see a lot of discussion about the WAS 8.5 “Liberty” profile which is an early program of some other exciting things they are doing, the WAS Developer Tools for Eclipse is something you can use NOW.
Although you can certainly get some more info on how to use these new tools from the official announcement and the WASdev downloads page, I figure I would take it one step further and give you a complete set of instructions along with some screenshots for doing this on Windows. It is really easy to do.
First of all I am going to assume for now that you are only using this for WebSphere v7.0 or v8.0 and not the “early program” (or Alpha) WAS 8.5 Liberty edition. The reason this is important is the version of Eclipse to use. For WAS 7 & 8 you will use Eclipse Helios.
UPDATE: It has been pointed out that there are 32-bit and 64-bit versions of both Eclipse and WebSphere. The type you use for both has to be the same. I would suggest the 32-bit since for development you don’t really need the expanded memory addresses of the 64-bit. If for some reason you are using different architectures for the two products and getting an error probably the easiest way to fix it is to get the Eclipse version that matches the WebSphere you have installed.
So that’s all you need right? Not quite. Besides the Eclipse tools you will also need a local WebSphere 7 or 8 test server. I know some of you are saying “darn, I knew this couldn’t be completely free!” Fear not! I promised the development environment would be completely free and it is because IBM has offered for a while now the WebSphere Application Server for Developers product, a COMPLETELY FREE version of WAS for development that is NOT a trial or expiring edition and is built from the same codebase as the production versions. The best link I’ve found to go straight to the WAS for Developers downloads is here. For those of you with IBM Passport Advantage download abilities there is also a ‘WebSphere Application Server for Developers – Eclipse Tools Edition’ which has all of this but there is also a lot of stuff you probably don’t need.
We will also need to link the Eclipse environment to the Java JVM installed with the WebSphere server. If you don’t do this you won’t be able to define a WebSphere server in Eclipse as the WebSphere Developer Tools will check that you are using an IBM JVM.
So just a few more steps and we will be set!
<WAS Install Root>\java\jre\bin\javaw.exe
UPDATE: As suggested in the comments, another way to alter the JVM used to start Eclipse is to add the ‘-vm <Path to JVM>’ syntax to the ‘Target’ property of a desktop shortcut that is used to launch Eclipse. Setting the value in the ‘eclipse.ini’ file is to set the default and the command line option overrides this. Your approach will probably depend on if you develop WebSphere and non-WebSphere projects with the same Eclipse install.
So now you have a way to do WebSphere development with completely free tools without having to deploy remotely, hack the project classpath, come up with Ant scripts just to export and deploy, etc. Obviously this opens up a whole new realm of possibilities for WebSphere development. You will have much more freedom to construct the development environment that suits your project best but still make sure you are testing against WebSphere.
Since this is obviously a thing we know our own clients have been looking to do for quite a long time we plan on using this in several areas. We will likely release a few Java EE training classes that use Eclipse and WebSphere 7.0 just to prove this is a completely capable development environment and let people get familiar with it. We will also start using this quite heavily in the Java EE 6 on WebSphere 8.0 courses that will be posted soon. We will also use this in our Spring 3 classes since one of our unique offerings has always been offering Spring development training on WebSphere. Look for another blog post soon about the best development environment to use for Spring development for WebSphere.
So start dancing in the streets, we can finally develop and test WebSphere applications on “regular” Eclipse!