JDeveloper 12c and Maven: Real-life experiences, anyone?

[Sten Vesterli]

Is anybody building ADF applications with Maven? I'm not a Maven expert and I've noticed that even running Maven on a freshly built, empty ADF project fails. There was an earlier thread this summer that seemed to indicate that there are still some kinks to work out.

I'd love to hear from those of you who are successfully using Maven (especially with 12c) about your experiences.

Best regards

Sten Vesterli

[jwglista]

Sten,

At my company, we are currently working towards moving our ADF applications to a maven build.  The fundamentals of our projects are that we are using ADF Faces with task flows, but we are *not* using business components; for the services layer, we are using standard EJB 3.0.  Our latest application is structured so that we have several different shared ADF libraries that we deploy, then one main project that uses each of those deployed ADF shared libraries.  Also, we are still on JDeveloper 11g (11.1.2.3.0).  Here are some of the issues we have faced, and are still working to overcome.

In order to generate a working ADF shared library war, we had to use ojdeploy.exe.  This was done by configuring an ant task to do this, then executing the ant task from within the maven POM.  This is not an ideal solution, and I'm working right now to remove ojdeploy.exe from all of our projects.  However, there are a few issues surrounding this that are a bit frustrating.  ojdeploy.exe appears to generate certain ADF proprietary files at build time, which may be dynamic based on the individual project.  These files end up in the final ADF jar, and include: "oracle.adf.common.services.ResourceService.sva", "adflibWEBINDEX.txt", and "task-flow-registry.xml".  If the .sva file or task-flow-registry files are missing from the jar, this will cause errors at runtime.  As a solution, we've pulled these files from the ojdeploy-generated jar, and checked in these files into our project in certain locations such as src/main/resources, then used the maven-assembly plugin to define file sets for where these proprietary files should go inside the final jar.  This is obviously very far from an ideal solution, as the content of proprietary files may change as your project becomes larger and uses more features and taskflows.  The only way to get around this is to maintain two separate builds; one with ojdeploy, and the other with purely maven.  Every so often you'll have to rebuild with ojdeploy to regnerate the ADF jar, pull out those proprietary files, then check them back into your project with the update contents.  I'm sure there is a way to automate this, but really we shouldn't have to be doing this.  I think Oracle needs to create a true Maven plugin that doesn't simply use ojdeploy/ojmake.  Until that is done, I don't think the maven functionality currently provided in JDeveloper can be called "maven integration".  It's more like a "maven extension". 

Our main motivation for doing this is because we want to have an IDE-agnostic build that will not depend on any Oracle executables.  This is also important for doing the builds on our Hudson server.  We would have pointed the build to the Oracle exe's on the Hudson server, but I feel that it's best to not use any of that.  Also, ojdeploy and ojmake depend on the JDeveloper project files, which can easily be changed and accidentally checked in, causing the build to become broken.  Developers should be free to change the project files without fear of breaking a build.

I've also experienced some issues where JDeveloper isn't "in sync" with my Maven dependencies, meaning a code window shows packages as not found, when the dependency jar is clearly defined in the POM (and no errors are showing in Project Properties --> Maven --> Dependencies).

I'd be curious to hear from some Oracle folks as to what is planned for providing true maven integration in JDeveloper without the use of ojdeploy and ojmake.  I understand that integrating Maven will take time, and there will be growing pains, but it will be nice once we finally have a fully integrated solution.

Regards,

John

[Brian Fry]

Yes, definitely some growing pains, but we're working on improving the Maven integration. Feedback is very welcome.

The current situation is that ojmake/ojdeploy are required for most ADF applications, and we don't have a good way of determining when it's necessary or not for a particular project. So, the company line is that you should use ojmake/ojdeploy for ADF. As you discovered, trying to recreate what ojdeploy is doing on your own is a bit of a guessing game. For 12.1.2, we introduced Maven plugins for ojmake and ojdeploy. It still requires an Oracle executable on your build server, but 1) avoids having to hand-craft invoking the ant tasks from Maven, and 2) allows ojmake/ojdeploy to use dependencies declared in the POM rather than hard-coded references to JDeveloper libraries. Additionally, in 12.1.2, across FMW we introduced a Maven "sync" tool to populate a Maven repos from an Oracle home. This was a big effort across FMW (including ADF) to define POMs for all our developer-facing artifacts and be able to reliably push them to a repos.

I can't speak too much to future features and time frames, unfortunately. We're working on addressing gaps as best we can. Relatively soon you should see improvements for the pom<>jpr synchronization issues you mentioned. We'll be rolling out some audit support for reporting discrepancies between the pom and jpr with user control on resolving them. We're also looking at making JDeveloper projects intrinsically able to understand dependencies declared in POMs. We're also planning to provide some ADF archetypes to make it easier to get started from scratch.

Further down the line, we are looking at what we can do to improve command-line build operations such as ojmake and ojdeploy, especially for use in automated build environments. For the short term though, I would strongly recommend against trying to circumvent them.

 -- Brian

--
--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).
 
---
You received this message because you are subscribed to the Google Groups "ADF Enterprise Methodology Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adf-methodolo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[John Glista]

Brian,

Thanks for the response.  It definitely looks like you guys are hard at work trying to improve the Maven integration in JDeveloper.

I was happy to see your comments about the new "sync" tool that will allow easy population of internal repositories.  One of the ways I've attempted to do this so far has been to start with an empty local development repo, then create a new maven project in JDev, adding all available features.  This would then cause JDev to install all those dependencies into the local maven repo.  After that, I would then move that folder structure onto our internal maven repo server.  Even doing that, I did end up still having some dependencies missing.  I'm guessing that there must be other "triggers" in JDev that cause certain dependencies to get installed into your local repo.

Regarding the use of ojdeploy, it raises the question as to whether or not it's even worth using Maven at all in 11g, despite the fact that it's an included feature.  When using ojdeploy as an ant task through maven, you're essentially circumventing maven's dependency management, and instead, using the standard dependency configuration built into the libraries and classpath settings of the project.  At this point, it seems nearly useless to use maven at all, and you should just continue using ant alone.  If you had some nifty maven plug-ins that you wanted to use, that would be beneficial, but in a bare bones scenario, there might not be any benefit.  In fact, there me be a detriment in terms of efficiency, due to setup overhead.

The reason we need to continue to use maven is because our latest project is fairly modular, and there are many inter-project dependencies that are best managed using maven.

I do have 2 questions:

Question 1: These proprietary files that are only included in the final jar/war at build time -- would it not be better to have jdeveloper manage these on the fly during development rather than at build time?  I know JDev tends to do the same with things like web.xml (as I often see diffs pop up in that file, then find that JDev has inserted things), so can't it be done with these other proprietary files?  This would be a step in the right direction, and would allow for safer, ojdeploy-free builds.

Question 2: For users of the OEPE with Eclipse, how are these proprietary files generated at build time?  Is ojdeploy/ojmake also included with OEPE?

John

You received this message because you are subscribed to a topic in the Google Groups "ADF Enterprise Methodology Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/adf-methodology/IZPibfpdCic/unsubscribe.
To unsubscribe from this group and all its topics, send an email to adf-methodolo...@googlegroups.com.

[Florin Marcus]

I tend to agree with John on this one:

"Regarding the use of ojdeploy, it raises the question as to whether or not it's even worth using Maven at all in 11g, despite the fact that it's an included feature. [...] At this point, it seems nearly useless to use maven at all, and you should just continue using ant alone."

Florin

[Brian Fry]

Yes, the introduction of ojmake and ojdeploy Maven plugins in 12.1.2 (along with the Maven "sync" tool) is crucial to making Maven feasible for use with ADF applications. We have customers (many of whom participate in this ADF methodology group) who have managed to make this work for their individual cases, but through much trial and error. By the way, feedback from those customers was instrumental to the Maven support we have in 11.1.2 and further developed in 12c.

To your specific questions:

1) Perhaps. This is currently under consideration. Up to now, we've maintained that most developers don't want to have to deal with deployment artifacts that are specific to their deployment target until they are actually packaging and deploying their app. But, there are some advantages of managing these resources as part of the source code of the app, too. So, we're trying to find the right path forward.

2) ojmake/ojdeploy are currently not included with OEPE.  The scaled down ADF design time support in Eclipse does not include cases where they are necessary.

-- Brian

[12brink]

I'd stick with OJDeploy for the reasons of proprietary files as you mention. Also I think allowing developers to build both from within JDev and from command line (build systems) is important. Any reason you need maven to actually do the packaging, and not just let ojdeploy fully create the artifact?

[John Glista]

The reason we want maven to do the packaging is because we want to actually use maven dependency management.  Our most recent application is fairly modular and contains a lot of inter-module dependencies which are most easily configured by using real maven dependency management, not the dependency setup in a .jpr file.  When building using ojdeploy as an external ant task, the maven dependencies are ignored.  Ojdeploy handles its own dependency management based on the configuration of dependencies in your JDeveloper project.  I've also noticed that JDeveloper makes it hard to manually edit pom files.  If you edit the xml of a pom file then go into the maven dependencies from the project properties, JDeveloper will overwrite your manual configuration so that it matches the configuration in the jpr file.

Although cumbersome, I've been making decent progress with this.  The proprietary files do present a slight bottleneck, so I hope that Oracle chooses to eliminate the process of creating these at build-time in the future.

Brian: on point number 2 regarding OEPE, do you know specifically have a build in Eclipse is done for an ADF project?  If ojmake/ojdeploy are not included in OEPE, then how are the required ADF proprietary files generated at build time?

John

--

[Raghunathan Srinivasan]

Hi,

 

Regarding the Maven support in OEPE, currently we don’t support the building of an  ADF Library on a project.  We do have a limited support to export a ADF project as an ADF Library and  do plan to complete the support in a future release. The goal is to enable re-use of ADF projects between OEPE and JDev in a heterogeneous IDE environment.

 

In a Maven-centric world, for a non-BC based projects, we would like to explore using standard mechanism to package and re-use ADF projects so we don’t have to manage the proprietary artifacts listed below.  What this implies is that OEPE will support the re-use capabilities of an ADF Library leveraging Maven dependency management.  Please let me know if there is interest in such a capability in OEPE.

 

Hope this helps.

-Raghu

You received this message because you are subscribed to the Google Groups "ADF Enterprise Methodology Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to adf-methodolo...@googlegroups.com.