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.
Another great feature is to generate local project files for your IDE which relieves you from the burdening task of (re)configuring your development environment all the time for the proper libraries: finally we get rid of these files in subversion :-). This is great when you develop with Eclipse and IDEA, but unfortunately there is no support for JDeveloper anymore. However, the architecture of Maven makes it possible to extend its functionality with a suitable plugin. We were just on the brim of developing such a plugin on our own, when I found out that the guys of the Apache MyFaces-Trinidad project have developed such a plugin. Although the plugin still has an alpha status, due to the incubator status of the Trinidad, I’ve been assured that it is fully functional and can be considered production ready. In time it will certainly become an official Maven plugin. By the way, these guys have developed more interesting plugins, like a javascript, a i18n and JSF archetype and jsf compile plugins.
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.
We wanna use maven2 on jdeveloper11g. But it doesnt seem to suit yet.
http://adf.webloji.net
Hi Jim,
Good point. Unfortunately, JDeveloper is not very well suited for using Maven. It does not provide any integration with maven, so you have to define external tools or use ant wrappers, which is what we do. Than, the result will be displayed in the ant output dialog; but with minimal interactive options.
Another issue is, still, the library management. Since JDeveloper cannut use variables for the path, the references to the libraries in the projectfiles are still to absolute paths, which means that all developers must have the same project directory and maven repository directory. That is if you share projectfiles.
In the meantime JDeveloper continues with its stubborn library management and new libraries will continue to pop-up in the project dependencies. Another nuisance is that the plugin cannot handle tha project and maven repository on different drives.
Our main goal with mavenizing an adf project is for project automation, i.e. perform automatically all the development lifecycle goals and not have the developer performing them manually and to be able to perform then on a seperate, integration environment. The integration with JDeveloper is currently a secondary goal, although we were able to accomplish, more or less, that for a customer by defining a standard developer environment.
Concerning the projectfiles, I get the impression that it is quite possible to not share the projectfiles and to (re)generate them when relevant changes have been made in the pom file.
Ciao
Aino
If anyone is still following this… Forgive my newby question please. So this plugin generates the JDev jpr file, creating entries in the Libraries list, so that I’m not drowning in red underlines in the text editor, so I have my right-click to source/javadoc/etc. But, it appears that the build is still done w/ the JDev-specified JDK, JDev dependency mechanism, etc, which subverts the whole Maven ‘continuous build’ process? So should I setup External Tools to run mvn w/ various goals from within JDev? Should I setup Ant tasks of some sort? In either of these approaches, how do I then (or can I even) get JDev to parse the resultinig output to provide me the ‘jump to source error’ capability that I usually get in the Compiler Log tab? Also, if I make changes to my pom, do I need to re-run the mvn jdev:jdev command in order to update my JDev Library entries? Any other tricks, hints, tips, etc that anyone can share? Thanks!
Sorry, I added some xml code, which does not show in the comment. The code can be found at : http://wiki.apache.org/myfaces/Trinidad_Plugins
Or add the following to your (parent) project pom.xml :
org.apache.myfaces.trinidadbuild
maven-jdev-plugin
Extra note : the jdev plugin is going to move to the maven project itself (be it mojo.codehaus.org or apache maven subversion, so in that case jdev:jdev will start working again đŸ™‚
Hi Maarten,
First of all, maven2 doesn’t use a plugin registry anymore, so the plugin doesn’t need to register.
The problem you are facing is that if you just specify jdev:jdev, internally maven will actually execute org.apache.maven.plugins:jdev:jdev or if that is not working, org.codehaus.mojo:jdev:jdev, which is not where the plugin resides. Even though maven cannot find the plugin it will however create a directory structure with the metadata (don’t have clue why though).
So plugins not in org.apache.maven.plugins or in org.codehaus.org should be written like this :
groupId:artifactId:goal (in my case I still use the old plugin, which makes it mvn org.apache.myfaces.adfbuild:maven-jdev-plugin:jdev. You can find the groupId and the artifactId in the pom.xml of the plugin though..
Good stuff!
I’m currently working in a JDeveloper shop and we want to use Maven. This would make the two interoperate much better.
Unfortunately, it does not work on my system.
When I invoke mvn jdev:jdev, I get “The plugin ‘org.apache.maven.plugins:maven-jdev-plugin’ does not exist or no valid version could be found.”
When I look in my local repository, I see a directory /org/apache/maven/plugins/maven-jdev-plugin, and only 1 file in it: maven-metadata-central.xml.
The other plug-ins in the repository contain version directories.
So it seems to me that the jdev plug-in did not get registered correctly, although the installation reported success.
Note: I’m using the latest maven, 2.0.4.
Any thoughts or help on this would be much appreciated.