JDeveloper project libraries and Maven dependencies

Question

hi
Using the Apache Trinidad Maven JDev Plugin, I am wondering how JDeveloper project libraries and Maven dependencies are supposed to be related (or "matched", or "kept in sync", or "work together", or ...).
With the Maven settings.xml configured like this ...
<settings>
  <!-- ... -->
  <localRepository>C:\my-maven-repository</localRepository>
  <!-- ... -->
</settings>... I tried this ...
C:\projects>mvn -v
Maven version: 2.0.9
Java version: 1.6.0_05
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
C:\projects>mvn archetype:create -DgroupId=com.oracle.forums.mvnfirstproj -DartifactId=mvn-first-proj
[INFO] OldArchetype created in dir: C:\projects\mvn-first-proj
C:\projects>cd mvn-first-proj
C:\projects\mvn-first-proj>mvn org.apache.myfaces.trinidadbuild:maven-jdev-plugin:jdev
[INFO] Scanning for projects...
[INFO] artifact org.apache.myfaces.trinidadbuild:maven-jdev-plugin: checking for updates from central
Downloading: http://repo1.maven.org/maven2/org/apache/myfaces/trinidadbuild/maven-jdev-plugin/1.2.7/maven-jdev-plugin-1.2.7.pom
2K downloaded
[INFO] [jdev:jdev]
[INFO] Generating JDeveloper 10.1.3.0.4 Project mvn-first-proj
[INFO] Generating JDeveloper 10.1.3.0.4 Project mvn-first-proj-test
...After this, the file C:\projects\mvn-first-proj\mvn-first-proj-test.jpr contains
      <!-- ... -->
      <list n="libraryDefinitions">
        <hash>
          <list n="classPath">
            <url path="../../my-maven-repository/junit/junit/3.8.1/junit-3.8.1.jar" jar-entry=""/>
          </list>
          <value v="true" n="deployedByDefault"/>
          <value v="junit:junit:jar:3.8.1" n="description"/>
          <value v="junit:junit:jar:3.8.1" n="id"/>
        </hash>
      </list>
      <!-- ... -->Notice the path for the JAR file in my specific Maven repository, to be relative to my specific project location.
questions:
(1) This seems to severely limit the options to share such a JDeveloper project file between developers in a team (e.g. using Subversion), because they would need their Maven repository and their JDeveloper project to be in the same (relative) location. Is this intended? Are there any options to work around these limitations?
(2) If a project evolves, and additional libraries need to be configured in a JDeveloper project, what would be the preferred approach to keep these in sync with Maven dependency configurations?
many thanks
Jan Vervecken

Answer 1

Hi Jan,
Yes, some of the current approach is not ideal.
+"Maven's primary goal is to allow a developer to comprehend the complete state of a development effort in the shortest period of time."+ - By having the pom.xml define for the project, I get the ability to run site goals, junit tests and other maven reports - get a feel for the project state. Even with a very basic pom.xml file containing the groupId, ArtifactId, version, SVN repository definition and the release plugin you gain the ability to use "mvn release:clean release:prepare" to help with tagging the source in SVN. These represent progress as up to this point the team has not had access to this.
+"Making the build process easy".+ - The approach does make the build part easier for JDeveloper 10.1.2. As a maven build, it is now possible to check the project into SVN and have it built by Bamboo, without having to include an installation of JDeveloper 10.1.2 (for library access) on the CI server.
+"If I understand correctly, in your approach, you are trying to keep both pom.xml and JDeveloper project files up-to-date manually?"+ - The only reason for keeping the JPR in sync with the pom.xml file is to allow the developers to still make use of features such as selecting run from the right click menu. At present, I am still slowly getting up to speed on how JDeveloper works and interacts with OC4J. Ultimately, you would want a maven plugin that will deploy the packaged WAR or EAR to the OC4J stand-alone or remote instance. This plugin would probably wrap the commands that the IDE uses, e.g.
If you right click on the deployment profile for a project (JDeveloper 10.1.2) and select the Platform > Standalone OC4J options, you find:
Deploying Ear+
${java} ${jvm.max.heap.size} -jar ${admin.jar}
${oc4j.url} ${username} ${password}
-deploy -file ${ear.file}
-deploymentName ${j2ee.app.name}
Binding Web Apps+
${java} -jar ${admin.jar}
${oc4j.url} ${username} ${password}
-bindWebApp ${j2ee.app.name} ${j2ee.web.app.name}
${oc4j.web.site} ${j2ee.context.root}
And for Platform > OracleAS Remote DCM:
${java} -Djava.protocol.handler.pkgs=HTTPClient
-jar ${Oc4jDcmClient.jar}
${dcm.servlet.url} ${username} ${password}
redeploy ${remote.oracle.home}
${ear.file} ${j2ee.app.name} ${oc4j.instance.name}
With a maven plugin- wrapping the deployment (possible even to the embedded OC4J) you could then look at get away without maintaining the libraries in the JPR. The JPR the becomes the configuration file for the IDE interaction only without affecting the build. For debugging, you can deploy to a standalone instance and start it using:
java -server -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=4000 -jar oc4j.jar
Then connect to the port specified. The primary project I was working on was developed in Netbeans and deployed to SJSAS. I have since switch this project to working with JDeveloper 11.1.1 as the IDE and doing remote debugging from the IDE connecting to the SJSAS debug port.
Note, that the maven plugin development for the managing of these aspects should be easier with JDeveloper 11.1.1 and the integrated WLS.
Have you used this approach in a project that uses ADF Business Components? - Yes, I have used it on one of the smaller ADF projects that had already been produced by the team. This project has all the maven features and ability to deploy to the remotes AS via ant scripts. The approach worked in both the dev and test environments. However, for final deployment, I still used the deployment profile to be consistent with the rest of the team.
Regards,
Graeme.