Maven2 and JDeveloper
Maven is a great tool for project automation. It provides build in tasks (like ant) for all the standard java project lifecycles, like build, test, package, documentation etc. One of the great features is it’s dependency management. You define the required libraries (and optionally define for which lifecycle it is needed) and Maven will download them to your local repository when necessary. It will then add these these libraries to the classpath (when compiling) or add them to the WEB-INF\lib directory (when making a deliverable) etc. In our projects, Maven is an essential part for continuous integration and build management, expecially because you want to independent of an IDE.
Since the plugin is not in a central Maven repository, we have to install it in our own local (or company) repository. Get the sources from the Trinidad-plugins-JDeveloper subversion repository and put them in a suitable directory. Then, open a command prompt in that directory and issue the command mvn install. This will install the plugin in you local repository. Now you can use it with your maven project file, the pom.xml. Just issue mvn jdev:jdev and the .jpr file will be generated. Note, that no jws file is generated. However, if you issue this command at the top level of a multi-module maven project, the .jws and all of the .jpr files will be generated.
If you don’t have any previous maven experience, don’t worry, maven can generate a default project (what they call a project archetype) with the following command : mvn archetype:create -DgroupId=nl.amis.demo -DartifactId=mvnDemo. This will generate a subdirectory called mvnDemo that contains a maven project file, the pom.xml, a demo java file (App.java) and a JUnit test (AppTest.java). Go to the mvnDemo directory and issue the command mvn jdev:jdev to generate the mvnDemo.jpr file that you can now open in JDeveloper (first make an application). Notice that it generates a seperate project for the JUnit test.
As mentioned before, generating the project file(s) is only part of the story. Using Maven also means you are managing your libraries (dependencies) outside your IDE, which off course is a good idea with a continuous build process (and how can you do without that?). The plugin automatically adds all the dependencies to the .jpr file as external jars (referencing the Maven repository) in the list of project libraries. This works fine with open source libraries, that are automatically retrieved from a central Maven repository. But other libraries, like jdbc drivers, the Sun J2ee libraries and many of the JDeveloper built-in libraries have to be added to your local repository manually. Besides that this is a tedious task, we also replaced one dependency for another . The solution to this is to create your own company Maven repository and deploy all these libraries there. Although initially, this will take some time, some discussions about naming conventions and a different way of working, we are sure it will pay off and will provide much better build management. With this plugin we expect that we now can implement this way of working in our JDeveloper projects too; we’ll keep you informed about our experiences.
- JDeveloper bug – ClassNotFound
- JDeveloper BPEL plugin
- Oracle JDeveloper 10.1.3 Developer Preview is here …
- Using ADF without JDeveloper – good insight in the mechanics behind Oracle's Application Development Framework and JSR-227
- Using GlassFish Reference Implementation of EJB 3.0 Persistence with JDeveloper 10.1.3EA