Thursday, 1 September 2011

Using Maven in JDev 11.1.2 for external dependencies

In the first article on this blog, I tested the Maven capabilities of the JDeveloper 11.1.2 release. And for those dependencies defined within JDeveloper itself as libraries, it creates nicely the required files in the local maven repository and updates the POM.
So the next idea that I had, was to see if I could add dependencies which are only defined in maven, and which are not defined as library in JDeveloper.

External maven dependencies
Since CDI, context and dependency injection, is a natural companion of JSF 2.0 in EE6, I wanted to try that out. The current version of WLS is not an EE6 container but most CDI implementation like OpenWebBeans can be also used in non EE6 container like WLS.
So I started by creating a Maven application and project and the application navigator shows me a project where I can see the pom.xml file. 
I opened the file and added one of the maven dependencies of OpenWebBeans.  At this point nothing happens; there is no polling or any other mechanism that adds the newly added dependency in the pom.xml file to the project dependencies of the JDeveloper project.
If I open the Maven project properties (right click on the pom.xml file and select the corresponding menu), I can see the information message on the dependencies tab that there are things changed in the pom file that aren't propagated. After clicking on the "add from POM' button, I can see the dependency but to my surprise, the classes aren't available in the code editor.
After checking the Libraries and classpath project properties, I see the reason.  The dependency that I added has a dot (.) in the artifactId value.  And JDeveloper treats this as a directory separator as in the groupId value.

So I tried another one. This time without a dot in the artifactId value and it works as expected.  However, if you tick the ‘show libraries’, you get the list of dependencies added to your project and sees the content of the jar files.  This is not the case.  But a far larger problem is the fact that JDeveloper don't add the transitive dependencies of the added maven dependencies.  If you add a dependency, it should not only add the jar (artifact file in general) but should also look in the pom file of the dependency and add the artifacts that are defined there (if in the correct scope of course).

Without this functionality, it makes the use of JDeveloper as tool in open source coding, a lot less interesting.

Maybe when you import an existing Maven project, the support is better?  Well, I bumped into the same problem, the transitive dependencies aren't included.  And I saw another thing.  The pom file had some properties defined where I specified the version number of the artifacts I would like to use.  After importing it in JDeveloper, it has replaced all occurrences of those properties with the defined value.  This behavior could also be improved in a future version of JDeveloper.

The Maven support is a first good step.  You can now use a Maven build file for ADF based application. This frees you from JDeveloper itself if you want to use a continious integration server like Hudson.  But for opensource projects, a few bugs must be tackled and some improvements are required. Maybe the next version?

Thursday, 14 July 2011

Is JDeveloper a good IDE, Part 2

In the first blog of this miniseries about the IDE qualities of JDeveloper, for the mentioned functionalities, JDeveloper scores very well for them. We will continue and make a final verdict about JDeveloper this time.
An important feature of the IDE is the refactoring capabilities that can be found in the program.  As we are all human, we should be able to correct our mistakes and with scrum development techniques, refactoring became even more important.
The classics like renaming a class or private variable is nothing special anymore.  A more important feature is the renaming of a property of a managed bean which is used in an EL expression.  This is possible with JDeveloper.  You don't have to do anything special for this.  Just do a rename of the property as you can find it in many IDE's, and JDeveloper find the usages of it in EL and does the required changes also there. I didn't found this capability in many other IDE's but it is available in IntelliJ.  A feature that IntelliJ is capable of, extracting a part of the screen and make a composite component out of it, is not available in JDeveloper. However, this could be very handy if you see that you are at the point of creating something similar as you have already in another page.
On the contrary, JDeveloper has a wizard screen to add a property to an existing managed bean, which isn't available in IntelliJ.
Due to the presence of the refactoring capabilities of bean properties, we can say that JDeveloper scores good in this category.
XML validations
All though the amount of information that needs to be put into XML files with JSF 2 is reduced, it is important to have an indication that the information which is present, is valid before we need to deploy and run the application.
And within JDeveloper we get an indication of the correctness of the names of the classes defined as managed beans (so without using the possibility to have the managed beans defined by means of annotations).  But other information within the faces-config like the names of custom defined factories isn't verified.  There are lookup screens that allow you to search your class path for a class that implements the correct interface/class that matches the factory class you are looking for.  So you are guided, but information within the XML view of the faces-config file or even autocomplete of class names as you can find it in some IDE's, would be nice.
During the time I was playing with the latest version of JDeveloper, I also came across a problem with the XML validation.  At a certain point I had a project where there were beans defined with annotations and within the faces-config file.  However, the specified property in the faces-config file, which was correct, was indicated as erroneous.  And I didn't found a way so that JDeveloper accepted the information.
Annotations are now a very important concept within JSF 2.0.  A lot of JSF artifacts, like managed beans but also converters and many other, can be defined by using annotations.  So annotation support is becoming more important.  Within JDeveloper you can find auto completion support for annotation classes and the 'elements' that are defined on it.
XHTML validations
Now that the main focus is shifted from JSP to HTML within JSF, it is important to have an indication if the XHTML written by the developer is valid.  Also here JDeveloper scores very good, it has also autocomplete for the custom components that are defined in the project (they are even available in the component palette).  The only minor point is, as we mentioned already in the previous text, that only JSF component libraries that have a TLD are correctly validated.
Running and debugging
Here you can only run the created application within the integrated WebLogic server. This is a full J2EE 5 server that allows running your JSF 2.0 application.  The startup of the server takes quite some time (can be more than a minute, and then you have to calculate the time of the deployment of your application on top of it.  That depends on the size of your application of course.)  But with the new version of JDeveloper they have a complete hot deployment available.  After your application is deployed and started, you can adjust the JSF view files, save and see immediately the changes.  That was already available in the previous version of JDeveloper (JDeveloper 11G release 1).  But now they have also added the hot deployment capabilities for java classes. Just save your change java code and do a project compile (CTRL-F9).  Is it always working?  No.  And maybe this is not a surprise.  Suppose that you have changed the managed bean which was already on the session scope and that you changed (add or removed) properties.  What can the server then do with your changes? It is too complicated to find an always working solution.  The rule is, whenever you change only some implementations details and not the signatures of methods or add and remove properties, the server can keep your application running, with the current state on the session scope.  So that is a great advantage.
JDeveloper also for non ADF applications?
It is no secret that JDeveloper is targeted at developing ADF applications.  And even if you just select to develop JSF application, ADF shows up everywhere.  There are numerous menus that refer to ADF like 'create data control' when you right click on a managed bean. The application that I created was based on the 'custom application' but in the application directory, there was a directory called '.adf' that contains a adf-config.xml file.  That file was even copied into the war which was created by the deployment wizard.
Another place where you see that ADF is crucial is in the refactoring of managed bean properties.  Due to the OSGI nature of the IDE, not all extensions are loaded at startup.  And when you perform the rename of the property, you see a small dialog where additional extensions are loaded and many of them have ADF in their name.
So, although plain JSF should be possible, ADF is still everywhere.  However, the generated war doesn’t require the ADF libraries but still has some ADF configuration files.
Within JDeveloper you can find many features that makes the developer's life much easier.  Not many other IDE's have the impressive list of features as we mentioned in this and previous text. There are a few minor points but the thing that me annoyed the most was the amount of exceptions that was thrown by the code from the IDE itself.  You get then a window saying that something went wrong and gives you the option to close JDeveloper or continue to work.  And although most of the time you can just continue, I don't feel very safe with that kind of behavior. The window says clear that you can lose some of your changes.  Also The Weblogic server behaved very odd from time to time.  Like not finding the JNDI data source even if it was correctly defined.  And after a redeploy, everything was fine again.
If everything was a little bit more stable and a few tweaks to make it not only geared to ADF, it could be the perfect IDE.  Maybe the challenge for Oracle is to have Netbeans at the same level of functionalities as JDeveloper.

Wednesday, 29 June 2011

Is JDeveloper a good IDE, Part 1

In the latest version of JDeveloper, there is now support for JSF 2.0.  There is no doubt that it is functional because under the hood, you can find Mojarra 2.0.5.  But more important than to know that it is just functional, is how easy, or difficult, it is to develop JSF 2 application with JDeveloper.  So how good is JDeveloper?

Good IDE
Well that question is a bit subjective, because we all have our habits of working with some IDE, which can be Eclipse, IntelliJ, Netbeans or whatever other IDE.  But we can all agree that the main purpose of an IDE is that typo errors made by the developer must avoid as much as possible.
Some functionality that can help achieve that are

- Write files from basic templates
- Navigate through code
- Code completion
- Refactor code
- Run and debug code

During the Confess 2011 conference, there was a session about the JSF IDE support (day 2, see site

Based on that list, I examined JDeveloper and here are some remarks that I found.

Artifact creation
How did I start?  I created a new 'Custom application', with a project with the JavaServer Faces (JSF) project nature. I now have an empty faces-config file (with the correct root tag for JSF 2.0) and a web.xml where the JSF application is defined as a prefix URL mapping (/faces/*).  I always prefer the URL suffix mapping (as *.jsf) but the only addition I have to make is the default page suffix (parameter ...)

Then I created a new JSF page, using facelets as document type and I get a correct XML file with jsf view, head, body and form tags in it.

From the faces-config file, on the overview tab, I can create new managed beans, also using the new annotations mechanism.

So regarding the most important artifacts for JSF, I can create them based on wizards which saves me some time and type errors.  So in this category, JDeveloper scores very high.

Visual design.
A lot of people also like to design their application in a visual fashion. You can select the desired component from a palette and drag it to the visual design of your page.  You immediately see the result of your work. The standard tags in the f and h namespace can be found in the palette of JDeveloper and can be 'previewed' in the design tag.  And all the component libraries that have a TLD can be registered, so that they are shown within the palette.  Once, they are registered, the information in the TLD is also used to validate the xhtml file and the autocomplete feature within the XHTML page of the tags and attributes is based on it.
But not all component libraries have a TLD, because it is not required.  Primefaces for instance, is registering all the components through a facelets tag library.  Since there is no TLD, you can't register it, so you don't have autocomplete, validation and visualization.
If you specify the namespace on top of the page correct and know the tags and attributes, a page with primefaces is working when deployed on the Weblogic server.  As said in the first paragraph, it is not the question if it works or not, but how the IDE can guide you and here they have a loose end.

Code completion
As already mentioned, all the components libraries that have a TLD and which are registered, are picked up during code completion.  This means that, when you are typing in the jsf page, you can quickly get the correct tags, attributes and values for some attributes (like values for the layout attribute of the panelGroup tag).
Also the autocomplete of EL expressions has been greatly improved. Within the JSF page, you have the autocomplete feature for LE expressions in all attribute values where it is allowed.  Also for the resource bundles defined in the faces-config, is the completion available.
But in some areas it is missing which can lead to confusion.  For instance it isn't available in the value attribute of the ManagedProperty annotation.  So, making some typo errors here will lead probably to some NullPointerExceptions during execution.

And maybe it belongs more to running and debugging the application but in a previous version you were able to evaluate EL expressions when the application was stopped on a breakpoint.  It was some kind of advanced watch functionality. That I didn't found anymore.  It would be nice if it was still available and that the EL autocompletion also functioned there (which wasn’t the case at that time.)

In this first part, there were a lot of good features presented of JDeveloper to make it a good IDE to do some JSF application development.  In the next part I’ll discuss the other topics outlined in the confess 2011 presentations, then we can give the final verdict about JDeveloper as JSF IDE.

Wednesday, 15 June 2011

Maven and JDeveloper

Maven support is now fully integrated within JDeveloper 11.1.2, as of this writing, the latest version of the IDE.  Some people asked for such an integration for more than 5 years.  In this version, it should be integrated completely.  So I asked myself the following questions:
  • Can I import one of the open source projects that I'm working on into JDeveloper (MyFaces Extensions Validation framework aka ExtVal)
  • How are the library concepts translated to Maven.
First try
So I downloaded and installed the latest version and selected "Maven application" in the "new gallery" wizard. After the names and locations for the application and project, I received a screen where I could specify the group and artifact ID for Maven and the version.  There was also a checkbox that let me change the project structure to the Maven one.  So the typical structure src\main\java and src\main\webapp is  created and understood by JDeveloper.  That is a nice achievement.

But when I added a JSF page, I received a warning in the log that the directory <USERPROFILE>\.m2 wasn't a valid repository and when I tried to package the application, he couldn't find the dependency oracle.jdeveloper.library:JSP-Runtime:pom:

For a moment, I feared that the developer needed to maintain those POM structures for the JDeveloper library structures themselves.  But then I saw the real problem, I have a custom location for my local maven repository.  And JDeveloper by default, uses the settings file in <USERPROFILE> location, which doesn't contain the custom location.

First integration
So, I tried again.  First I changed the settings.xml file of maven in the <USERPROFILE> location to point to my local maven repository.  Then I repeated my first attempt and at the point where I created the JSF page (using facelets) I saw the following entry (one of the 3 entries) in the log:

Deploying Library [JSTL 1.2]
Deployment of {groupId=oracle.jdeveloper.library, artifactId=JSTL, version=1.2, type=pom} has finished
Deploying jar file glassfish.jstl_1.2.0.1.jar
Deployment of {groupId=glassfish, artifactId=jstl, version=, type=jar} has finished

That was a big relief, the 'translation' of the library concept of JDeveloper to Maven dependencies is done automatically.
And now, I didn't have any problems with packaging the application into a war file.

Importing existing project
After the first success, I tried to import the MyFaces ExtVal project.  I created a new application using the "custom application " item in the wizard.  Then I selected new again and picked the "Import Maven projects" from the "New gallery" screen.
I received a window where I could select a root directory and JDeveloper found all the POM files in the different subdirectories.  He organised them also in a hierarchical structure as shown here
After selecting the top level POM file, he imported all modules as projects in the application. During the package of the project, I saw that there where additional maven dependencies downloads because it uses Maven 2 and not Maven 3 as I'm used working with.

There are a few remarks that I can make already
  • When you import an existing maven structure, there are no dependencies created between the project.  During the import, see image above, he recognize the structure, but is isn't reflected in the dependencies between the projects.
  • By default JDeveloper uses the maven version bundled with the IDE which is 2.2.1.  You can change that, but it is managed by the projects and not the application or even IDE wide.
  • The combination of these 2 requires me that I need to change the Maven version for each project if I want to be able to build the complete ExtVal project and only parts of it.
At first glance, the integration with Maven is quit complete in the latest JDeveloper release.  It handles the library dependency by installing POM dependencies in your local repository and it is able to import a complex open source project with different levels of sub modules.

Thursday, 9 June 2011

Jdeveloper and JSF 2.0

Oracle has just released a new version of JDeveloper (version 11.1.2) with some new features available like JSF 2.0 and Maven.  Other IDE's like Eclipse, Netbeans and Intellij, are already a long time equipped with such support.  But I'm curious what the developer experience is for developing applications in Jdeveloper with Maven and JSF 2.0.

So in the following weeks, I'll play a bit with those features and keep you all informed about my findings. Questions that I have are
- What do I need to do to have the maven support?
- Can I use something like CDI?
- Is it possible to use Jetty as runtime server? (since I'm using maven)
- How well can you mix the JSF 2.0 new features with ADF?
- etc ...

My adventures and findings will be published here. Stay tuned.