Since I’ve joined Oracle via the BEA acquisition I have had the opportunity to start learning JDevleoper and I like it a lot, but I’ve had some bumps in the road since I’m so used to Eclipse. Much of the IDE tooling for the Oracle’s SOA, BPM, and Application Server products is migrating to JDeveloper, which is Oracle’s comprehensive IDE. This gives developers using Oracle products a very easy-to-use and highly integrated development environment. Oracle is still strongly committed to the Eclipse community as evidenced by the contributions to many Eclipse detailed on the Oracle Enterprise Pack for Eclipse page and just announced 11g. There are some differences for accomplishing certain tasks in JDeveloper and Eclipse and I thought I’d write about my transition from the perspective of a long-time Eclipse user. Some members of the JDeveloper team have agreed to vet these entries and I hope others will contribute some knowledge as well. I’ll use Workshop 10gR3 and JDeveloper 11g as my points of comparison.
This use case was part of the inspiration for this series, simply to have an Enterprise Application with a Web Module that has a dependency on a Java project that is also included in the exported EAR. In Eclipse WTP, this is accomplished by creating 3 separate projects and linking them together:
As you can see in the J2EE Module Dependencies section of the LibraryTestApp project, I have placed dependencies on the other 2 projects, which results in the LibraryUtility.jar being placed in the EAR’s APP-INF/lib and the WAR being included in the EAR as well.
JDeveloper has the concept of an Application, which is a container for Projects. So first create a new Generic Application named LibraryTestApp. The wizard guides you through the creation of a project for this application, and selected JSP and Servlet technologies and name the project LibraryWeb. Then add a new Java Project to this Application and call it LibraryUtility. Both of these projects are initially empty, so create a new JSP file in the Web project. Looking at the structure for the web module, you can see that it has a WEB-INF directory, but no lib directory underneath it.
I’m going to side-track this a bit and talk about a variation to this use case. The first time I tried this I already had a pre-built jar file on the file system and my very first intuition was to create a lib directory underneath of WEB-INF and copy the file over. JDeveloper does not allow you to create folders with a right-click on WEB-INF. In fact, creating a folder is not directly supported in JDeveloper. You can indirectly accomplish it by launching the “New…” wizard and generic file, and put the folder name in the Wizard.
This was not exactly intuitive to me as I was used to the Resource Perspective in Eclipse that gives you a pretty good idea of what all the files look like on the file system and lets you manipulate them. I heard from the product team that this is an often requested feature and is being considered for future JDeveloper releases. It turns out that you can also just add something to the file system and JDeveloper will pick it up, but there is a better way. More on that later, but first a little more background on the Application and Project settings.
The concept of Applications and Projects will be new to Eclipse users where everything is a Project, but this helps group projects together instead of having a cluttered workspace full of potentially unrelated projects. It turns out that you can right-click on the Application name in the Application Navigator and select Application Properties. Similarly, you can right click on the Project name and select Project Properties. Alt-Enter also works as a short-cut exactly as in Eclipse. Inside of Project Properties there is a menu option for Deployments. From an Eclipse perspective, if you want to create a jar file from a java project you can right-click on the project and select “Export->Export…->Java->Jar”. JDeveloper does not have an “Export” option, but this is covered by a Deployment Profile. By default there is no Deployment Profile for the project, so create a new one and name it what you want the jar to be named. You can see that this will jar up this project and place it in the project’s deploy directory.
You can explore this even further by looking at the File Groups->Project Output->Contributors and see that the Build Output and Project Dependencies both make up the contents of this jar. Now that we have a jar, let’s turn to the LibraryWeb project that we want to use the LibraryUtility.jar. Remember earlier when I tried to manually add the jar to the WEB-INF/lib directory? I should have just used the “Project Properties->Libraries and Classpath” for the ViewController web module project and added the jar file to the classpath. Notice that the “Export” checkbox is selected which means this jar will be packaged as part of the WAR under WEB-INF/lib. So similar to the LibraryUtiilty project, you can create a Deployment Profile for the LibraryWeb project. This time select WAR as the archive type. You can see that the jar will be included in the WAR under the WEB-INF/lib contributors.
Notice that the Deployment Profile also has a menu option for Profile Dependencies. There you can indicate that this Deployment Profile depends on the Deployment Profile that builds the jar for the LibraryUtility project.
You can follow similar steps to create a Deployment Profile for the Application via the Application Properties, this time selecting an EAR archive type. Now we have a similar experience to Eclipse where I can right click on the project select Deploy->LibraryTestApp-> to EAR file. In fact, I can get fancy in the Application’s Deployment Profile and specify the path to the LibraryUtility.jar file in the EAR to be in APP-INF/lib. You can set up multiple deployment profiles per project or application, so it’s actually more flexible than the Eclipse structure.
If you notice the Deploy->LibraryTestApp-> as has a “to” option as well as “to EAR file”. Using this option I can deploy this archive to a running WLS server, more detail on that in another entry.
There is alternative to the Libraries and Classpath linked to Deployment Profile approach that JDeveloper actually uses by default for Fusion Web Applications. When you create a new Fusion Web Application, a Model project and a ViewController project are created by default. In ViewController->Project Properties->Dependencies you will see a dependency on the Model project.
Now look at the auto-generated Deployment Profile for the ViewController project and you will see this causes the build output of the Model project to be added to the build output of the ViewController project because of the checkbox for “Project Dependencies” in the WEB-INF/classes contributors section. This results in only one combined module inside the EAR, instead of two separate ones. So which method is better – Project Dependencies or linking the Libraries and Classpath to another project’s Deployment Profile? It is really a matter of taste, but since I had a preconceived notion for the structure of the EAR in the original use case, the Libraries and Classpath linked to the LibraryUtility project’s Deployment Profile worked best for me.
So the key take-aways are:
Hopefully this gives a good introduction to some of the distinctions for developing and packaging Enterprise Applications and Modules in Eclipse and JDeveloper.
Here is a list of potential topics that I think are interesting for comparison’s sake, let me know if there are others you’d like to hear about.