Ant builds in JDeveloper 11g

Here is the problem in a nutshell: Java EE architecture best practices will tell you that you need to modulize your code. That means that a given developer is working on a project specific that a given problem (use case or whatever). The rest of the project is not needed – at least not the source code.

In JDeveloper that means having a large application split into smaller applications (or workspaces). Each workspace produces a jar file which a EAR-file and deployed. This approach is best described in Sten Vesterlis book “Oracle ADF Enterprise Application Development – Made Simple”.

Problem with this approach in JDeveloper 11g is that building a conventional jar from a sub-project to use as dependency doesn’t really work. Because:

an Oracle ADF library is a jar-file. And yet it isn’t really a jar-file as we know it.

To support all the special features in Fusion Middleware – Oracle has extended the jar-format a bit in 11g (bad Oracle). So creating a jar-file by ordinay means, is now longer feasible.

If you ask JDeveloper 11 to create an Ant file for a project you have solved most of the problem. However JDev will generate a build-file which includes targets to compile to code. That results in a lot of classpath setup for a call to javac. We don’t want that, since the project dependencies might change and then we’d have to change the ant-file as well.

What we want is a build-file that includes a bare minimum for building the ADF Jar library in projects which need to create that. And a build-file that creates the WAR (on project level) and the EAR-file (on application level).

It would be nice if that file didn’t have to update the build file everytime a dependency is changed in the project.

Well … ojdeploy to the rescue. :

Note that the build target created by JDeveloper use hardcoded names for project and so on. A build.properties is also created. That too contains full paths to ojdeploy and other stuff needed.

You can clean up the build.xml and remove the build.properties file. In the build.xml you add an import of a properties-file in ${user.dir} (which will allow a developer to setup his/her paths once an for all). Once that’s done the call to ojdeploy should be fairly portable to other developers machines.

Note that ojdeploy will do a lot of dirty work for you, such as compiling the source code in your current project, include source-code, web-pages and such from other projects that your current project depends on. If your dependency to another project is through a jar/war/…-file then that file will be created and included automatically… So a lot of work being done there.

If the project-parameter is left out, then ojdeploy will look for the deploy-profile at application-level instead of project-level.

… nice.

Now all we need is for the maven-support in JDeveloper to be ready for Prime Time – meaning full support ADF, BPEL and friends. What a day that will be.

Some time later I’ll the full code for a solution I created for a client. With somewhere around 20 applications (workspaces) all producing a ADF JAR building the full application (actually they had more than one) took around 8 hours. Once the ant build was in place that was brought down to about 10 minuttes. Not bad for few days work.

edit (30-05-2012):
Changed the XML inserted to pgn file. Seems that even pre and code tags can’t handle xml.

This entry was posted in Software development and tagged , , . Bookmark the permalink.

Leave a Reply