We Keep Coding

Java-based CMS with RESTful service / API to access content [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
For those who might vote to close this question due to "not constructive - As it currently stands, this question is not a good fit for our Q&A format." - Would be great if you would suggest where should I post this question (https://softwareengineering.stackexchange.com/ ? or any CMS-focused forum?)
Similar questions have been asked before:
https://stackoverflow.com/questions/918722/java-or-php-for-homegrown-cms
https://stackoverflow.com/questions/4005811/is-there-a-good-cms-for-java
https://stackoverflow.com/questions/8298790/java-web-cms-recommendations
https://stackoverflow.com/questions/4837502/recommendations-for-a-lightweight-java-web-cms
https://stackoverflow.com/questions/1939238/can-you-recommend-an-easy-to-use-easy-to-develop-cms
All of them are a few years old, so I am wondering if there are new recommendations / discussions around this.
Some background: We are a Java shop, we create / maintain websites for our clients, our tech stack are Java, Spring, SQL, JSP, HTML5, JQuery, Tomcat, JBoss, Maven, etc ... the usual stuff. So far in terms of "content" we either put it in some properties file read in by the JSP for copies (eg. description of product X) or back-end service that provide dynamic content (eg. what's the current value of product X).
Now we are rethinking our approach to managing content because we are managing more and more properties for the client with the same content (eg. a website, mobile website, mobile app, etc), so we definitely want to avoid having multiple copies of the same content spread around.
A few things I am particularly looking for:
Java-based (because we are Java shop: 1) more expertise in handling Java-based stuff and 2) avoid introducing another tech to the stack)
Extensibility / customization. Need to be able to customize the CMS (which is why we want to stick within our Java expertise) so that it can be extended to connect with other web services to consume content, etc.
Focus on content - we need clear separation between content vs UI-render, going back to what we are looking for where we will need to deliver the content into separate properties.
RESTful service / API to access the content - same as above. We need the content to be accessible directly as a JSON / JSON-P /. XML feed.
Need to have a decent UI to work with and the more intuitive the better for business user because some of our client that might be moved to the platform will likely want to be manage their own content
Multilingual support
Open source / low cost
So far, several options that I have are:
Adobe CQ - Looks to be the most ideal solution, but unfortunately it's cost prohibitive
Hippo CMS - Looks to fit what we are looking for, I am unsure of how well it's documented, tutorial / how-tos seems to be quite sparse, their market share seems to be bigger in Europe than in North America.
Liferay - More focused as "portal" as opposed to CMS providing content
Alfresco - More focused on "documents"
dotCMS - Like Hippo CMS, seems like this one might fit our needs.
Magnolia CMS - Looks around the same alley as dotCMS and Hippo as well. From the comments I've seen seems like they are more focused on a single website and not clean separation between content vs UI.
I personally don't have much direct experience working with CMS before.
Your thoughts / comments on each of the options above, or if you have other solutions in mind not mentioned here, would be greatly appreciated! One of my challenge is that we need to make a really sound decision because whichever path we decide to go down with, we would likely be stuck with it, decision is not something that can easily be discarded and start over.

Personally I have some experience with Hippo and a lot with dotCMS. I do know a little about Alfresco, Liferay and Magnolia but I have not worked with them before. I have no experience whatsoever with Adobe CQ, because I never took the time investigating. This is because of the high costs being a no go for many of our clients. Alfresco is indeed a better solution if you're looking for an online document management system, which I think you aren't. You are right about Hippo, Magnolia and dotCMS being somewhat similar, which isn't that strange because they try to solve the same problem: being an Enterprise class Java based Web Content Management System. They focus heavily on managing the content which can be used in pages that are also manageable with the CMS.
To be honest: I have a bias towards dotCMS because I have worked with the systems a lot and know much about it. I thought I'd explain why it works for us so you can take that into consideration. I work in a Java shop that does a lot of middleware development for its clients using JBoss and the whole EE stack. We connect old (Cobol) and new systems together and put a shiny new web interface on top of that middleware that targets both admins and consumers. To be able to create these interfaces we need a CMS that does a few things well:
Java based (because we're a Java shop this enables us to have the same people work on the CMS and the middleware)
Horizontal scalable to tens of servers without too much hassle. In the classic case when scaling out to multiple servers the database and the assets folder are shared between the nodes. This could be a problem when you have many nodes, but in practice it's not such a big issue because most of the load will hit the index and not the db or the disk. In 2.5 and up dotCMS offers a "share nothing" mode where each node has its own database and assets folder, but this does requires you to use an additional (read: licensed) authoring server that pushes the content to each of the nodes. I have not played with this setup myself, but it sounds promising, especially because each node can be a simple and cheap box that only uses postgresql / mysql and tomcat and because there is no single point of failure anymore. In the classic case if the shared assets folder or the db would die all nodes would be down as well, except when you cluster the db and the disk as well which is expensicv to do. With this "share nothing" setup this is no longer the case. As I said: I have no experience with this, but it sounds like it might work.
Admin interface usable by both power users and non techie people (clients). Not everybody is "good with computers", but they too need to be able to manage the content (very often these people work in the marketing department of our clients). dotCMS offers ways to create admin interfaces that show only a few of the functionalities dotCMS offers. This prevents them for having to understand the whole system which speeds up training and acceptance.
Structured content. This is biggie. We want to be able to define many types of content all with a fixed set of fields, just like a database table. All without having to rebuild or restart the system. The people that would define content based on this structure (the name dotCMS uses for these types) cannot enter invalid data because the system protects against that. This makes building websites so much more future proof and convenient. Especially for developers.
Focus on content first. The first months that we used dotCMS we actually only used dotCMS for managing the content itself and exposing that through JSON API's. We did not use CMS features like defining templates and creating pages. This works fine and sounds like the stuff you're looking for. dotCMS has a JSON/XML Webservice that returns content based on queries. We use this a lot in almost all our projects, see here for more info: http://dotcms.com/docs/latest/ContentAPI. Using dotCMS itself for the whole frontend is also a possibility. Especially with the Spring controllers that it supports and the CSS-framework agnostic new template designer it is a nice way to build systems that require more than just some content.
Multilingual. dotCMS offers a few ways to do this. You can create content in all languages that you need, even non textual content such as images. Because of the "content first" approach many things are content in dotCMS , and can be treated as such, including creating a version for each language that you need.
Open source. dotCMS offers a community version that we use most of the time. Only for the pro features like load balancing, using oracle for the database, etc, a paid version is necessary. And even then the costs are manageable. See http://dotcms.com/products/editions/ for more details about this.
Internal caching mechanism. Because of the high load some of the sites we have build need caching. DotCMS uses the Google Guava for their caching which works pretty well.
Extendability, also a biggie. We needed to be able to extend the functionality of dotCMS for obvious reasons. DotCMS used to only offer an old school way of doing plugins that is kinda ugly and is based on an ant script that overwrites the dotCMS classes with your own. It works fine, but I always feel dirty after writing such a plugin. However since version 2 they offer an OSGi based plugin framework that is pretty sweet and much more developer friendly. It went out of beta in the 2.5 version. We're planning to port all of our plugins to the new framework.
Multi host. We need to be able to host multiple sites within the same CMS. DotCMS provides this natively. It's also a nice way to share common stuff between multiple hosts which we use a lot.
Of course there are also down sides. Here are a few:
Web CMSes like dotCMS store its content in a database and the assets as files on the disk. This makes versioning and synchronizing between different servers a pain in the butt. Starting from the 2.5 version dotCMS offers synchronizing tools that enable you to push content from one environment (for instance UAT) to another (for instance PROD), which helps. But not being able to checkout a single version of the content from something like GIT or SVN is very annoying. Especially since we as Java developers are accustomed to things like automated testing in a continues integration environment. Of course you can store the database as a SQL statement and the assets directory but that's slow and not so "nice". But then again all systems that store state in a database have this flaw.
DotCMS takes some time to learn. It's not a small CMS like Wordpress that you'll understand in one afternoon. It has many features and is very powerful, but you'll most likely need a day or so to understand the dotCMS way and then another couple of days to understand all the API's. I do encourage you to first read some docs and tinker with it before building a real production site: many ways lead to Rome, but some of them consist out of quicksand. :)
DotCMS is RAM hungry. To keep things fast it cached everything, so if you have a lot of content it will eat away at the RAM you have available. You can tweak this but it's easier to just give it enough RAM we have found.
Not all configurations of WebDAV + editing client are compatible with dotCMS. For instance on a mac I have found that you best use Cyberduck as a WebDAV client and Aptana as a text editor. Other setups do freaky things that dotCMS does not like much. You got to play a little to find out what the best setup is for you. I did find that if you file a bug on their github they get it fixed in the next release. They told me that WebDAV is hard to get right because it's not a fixed standard which I understand but it can still be a pain in the butt.
If you want to learn dotCMS read their -not so bad- documentation: http://dotcms.com/docs/latest/TableOfContents and also take a look at their demo site (http://dotcms.com/products/demo/). In the demo site you'll find examples of all the concepts that dotCMS offers. Oh and check out our own free dotCMS plugins as well. Especially the JavaScript and CSS minifier is very handy: http://geekyplugins.com/.
Hope this helps a little. Let me know if you want to know more.

Disclaimer: I work for Hippo, so I'll try to only answer with facts and not opinion :-)
Hippo is fully Java based, front end is language independent, but geared towards JSP or Freemarker, optionally you can use a REST-interface and use whatever.
Many plugins are created and collected at the Hippo forge.
Content-centric design has been a staple of Hippo development, should pose no issue.
Yes, by default all JCR calls are available. Apart from that you are able to define your own REST interface to suit your needs, example in the demo, documented here.
I dare say yes, in my experience most non-tech users find the interface easy to understand.
Multilingual is easy, part of the default multi-channel setup.
The community edition (which is complete, no bait-and-switch) is open source, there is some enterprise functionality behind a proprietary license. The license also opens up support avenues, besides the Google Group and Stack Overflow.
Now, on your comment about the documentation being incomplete, let me offer my opinion:
You are right, the documentation is an ongoing struggle. Most stuff is documented, but is hard to find. We are working on improving the overviews, introductions and tutorials, but we are obviously not done yet. If you can't find anything, usually the community is able to help and point you in the right direction.

strategy to integrate java cms-functionality into website with highly dynamic content (Lucene / Mysql / Nosql)

I realize a lot of questions like 'what cms should I use / what is the best' have been asked, but I'm looking for integrating cms-functionality in an already functioning website.
This website (travel-related price-comparison website) is built in java with Tapestry 5 as it's web-framework. It makes extensive use of Lucene / Solr.
I'm looking for a way to be able to author additional content-rich pages, which combines content to be authored in a CMS-environment while other content is highly dynamic and results from for example Solr / Lucene or Domain Object (fetched through Hibernate).
For now I used mysql and excel as a really crude way for a CMS. --> Have Excel-files following a specific format and import the content in mysql. The website than queries mysql for the content.
Obviously, this can be approved.
I guess I'm looking for guidance at what level the integration with an existing CMS should be done.
options:
1- Loosely coupled - PREFERRED FOR NOW - Use a CMS based on a content-repository which follows the JSR-170 specs. Magnolia, as well as some others come to mind here.
- Simply author pages / page-snippets in Magnolia which are stored in the content repository.
- Have a periodic program query the content-repository, extract the data and populate MYSQL like before.
pros:
- website works like before, without changes
cons:
- no way to edit pages in-place.
2- Have a CMS that is customizable in such a way, that I can bring the solr / lucene functionality into the CMS.
pro:
- in place editing
- better editing workflow
- editing is kept in one place, etc.
cons:
- needs customization to existing CMS, and probably lot's of it. But may be worth the time for us on the long run.
3- Something in between? (like begin able to incorporate the inplace-editor part of a cms into our website, and saving to our existing backend)
suggestions welcome.
I bet I'm not the only one having such a use-case (on a high level), and am wondering what others have done / would suggest.
In particular: what Java CMS do you know of that are customizable to the extent as described above. For some reason I'm liking Magnolia far better than the others I've tested briefly (Alfresco, Hippo)
Any help appreciated.
Thanks,
Geert-Jan

We use Atlassian Confluence for this. It's not a CMS — it's a high-quality wiki — but for us it was more suitable than a 'real' CMS like Magnolia. The strong points for us were:
Price: for a small installation like ours the licence is just $10
Flexibility: full Java source code is provided with a Maven build and a very powerful plugin system. If Confluence doesn't do something, you can implement it without hassle. There's a big ecosystem of useful plugins too.
Ease of use: I find Confluence easy to use, the UI is great for normal users who just need to write — whereas some CMSes are complex and hard for non-technical people to use.
I think it would work in your scenario, but I can't tell you if it is the best option. You could make use of the Remote API to retrieve content via your Tapestry application. I don't think it supports JSR-170 though.

Looking for a feedback on JIDE [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm about to start development of fairly large java based desktop application. After looking at JIDE components and frameworks, it seems to be a good solution at a glance. I'd like to hear from those who used those products. How reliable are they? What's the learning curve? Pros and cons?

I have lived and breathed JIDE for close to 2 years. As the main developer of my company's Swing GUI app, JIDE has made my life both easier and harder.
First, the good part.
The breadth and depth of its components are incredible. Their lastest demo has 171 items, and most are for different components. It's what Swing should've been. The company is indeed small, but you can't possibly say they have only "one product" (re #Stephen C). You're not gonna find any other component suite that has everything from date chooser and popup alert, to searchable and filterable list and table, to pivot table and docking.
Their support is surreal. It's true (per #Carlos) that the only medium is the forum, but the turn-around time and quality of their responses are truly amazing (I'm the 3rd top poster there, so I do know). Many of my posts are new feature and API change (e.g. private -> protected) requests, and they fulfill the vast majority of them within one release or two (which means a few weeks to a month at most).
You can buy source code license for full source code and unobfuscated debug jars. I'd strongly suggest that you do (I wish I could get sales commission from them) if you plan to use their more complicated products like pivot and docking.
Once you have their source code, you can do a lot of customization if you need to, as the code is very open and nicely structured for extension. Sometimes it's risky to extend undocumented classes/methods, but they've kept their code very steady.
And I have to say that their code quality is top notch. It's not squeaky clean (it's as big as Swing itself), but I've never been forced to scratch my head and wonder WTF.
They have very solid developer guide(scroll down the page) for each product group. javadoc is excellent. The full demo itself is a great way to explore the components and features. Documentation was the main reason why I picked JIDE docking over FlexDock (and later I found JIDE docking also has a lot more features).
Now the difficult part.
As #Carlos mentioned, they do introduce regressions with each release. It doesn't seem like they have totally comprehensive and fully automated regression tests, but that's probably next to impossible given the complexity and interactive nature of their products, especially for things like pivot and docking. Even though they fix things very fast, it's always a pain having to wait and then upgrade to a new version, only to find other regressions. That being said, my company's GUI app has shipped several versions without major issues.
I've mainly used many of their somewhat standalone components like date chooser, balloon tip, status bar, multi-page dialog, etc., and two of their most complicated products: pivot table and docking. (Sorry, no JDAF.)
They are complicated for good reasons. OLAP is an industry of its own, and docking is the underpinning of all modern IDEs. That's why I didn't call this section "the bad part". Pivot and docking are difficult to use not because of their quality but due to their complexity.
For example, JIDE docking manager has over 70 primitive bean properties (as of 2.9.5). Some are interdependent, and it takes a while to figure out how to set them for your particular needs.
All in all, I would recommend JIDE without any reservation. It'd be a huge pity if you can't use it due to its propriety, in which case don't even look at its demo, otherwise you will find everything else out there lacking.

I've been using JIDE for 2,5 years now. As far as I'm concerned, it's the best Swing component library there is (as there aren't many). Some of the functionality can be replaced by other alternatives if you want to take a component from here and another from there but some seem to be unique. And of course it is easier to adopt one complete solution instead of separate components and frameworks. Though I should point out, that I've mainly used separate components from the library as well as the Docking framework, but not JDAF so I can't comment on that.
Quality has been good for the most parts although at some point it felt as every release introduced a new bug. But so does every Swing release, so can't really blame them. Response times and customer service in general has been good so you're not alone with your problems. They also seem willing to adapt their products for customers needs.
However, on some parts their operation seems a bit amateurish. For example, the last time I checked, their forum was still used as a bug database. They also have released a large number of new products, some of which seem to be stuck in the beta stage forever.
I'd recommend that you contact them about the deployment fee to get an idea of the total costs, evaluate the product and then consider the risks and costs of adopting JIDE compared to the risks and costs of other alternatives. Open source is not risk free either. Being stuck on a dead commercial product may be worse than being stuck on a dead open source product, but I wouldn't enjoy either.

I'd be wary of this product:
It appears that you will be charged a "negotiable" deployment fee if you want to distribute to customers or do a mass in-house deployment.
JIDE Software seems to be a small one product company. With any company like this, there is a significant risk that it will go out of business or be bought out, leaving customers in the lurch with a dead product.
Using JIDE would be an impediment to making your application open source ... if that step is in your future plans.
UPDATE (2022)
Another thing to be wary of is that JIDE Software don't seem to have plans for supporting newer releases of Java properly. For example, there appear to be dependencies on JDK internal APIs which are being progressively closed off ... starting in Java 9.

Java release engineering good practices [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've got a fairly simple open-source Java project I am starting. This process is new to me, I'm used to writing programs just for myself. What are some good practices to be aware of when releasing open-source projects in Java?
Here are some things I can think of, can you suggest others?
version control repository (what do you use to explain relevant tags/branches? an external README file?)
include appropriate open-source license in code
include prepackaged executable JAR file, including version number in the filename
some kind of README file that explains external dependencies needed to build/run the software (is there a common convention for what filename and where to put it?)
a webpage for the project, w/ a link to it in the source code and/or executable, in case someone obtains the source code or executable first (rather than through the webpage in question)

One thing you should definitely do (because it's Java) is to generate Javadocs for your code. This means commenting classes and methods using the Javadoc notation for easier readability to others.

You could also use Maven for releasing your code. With it it's quite easy to create a site for your project, specify the dependencies, optimize the releases...For example, the Commons projects at Apache use Maven.

Basically you want your project to work 'out of the box'. When people are choosing the right open source project for a task, they download a bunch of projects that say they support the task, and use the best one. If a project needs significant work to setup (e.g. downloading 20 JAR dependencies from 20 different sites) most people will only either try it as a last resort or just ignore it.
Repository: You might try some newer repository engine - like Mercurial or Git. They ease development and ease merging of branches. Importantly though, choose an engine that is supported natively by your IDE.
Dependencies: You should use a readme to state dependencies, but this is not sufficient, either use Maven to manage dependencies, in which case you just need to include pom.xml file, or include JARs that you are dependent on in your distribution. In second case divide dependencies into mandatory, optional, compiletime and test. An example of an optional dependency are the bytecode generation tools for Hibernate.
Site: Maven may create a site that is associated with particular version of your software (never used that though).
Documenation - JavaDoc: Document everything, and try to enforce a policy that ensures high quality javadocs:
/**
* Sets the cost
* #param decimal cost
*/
public void setCost(BigDecimal decimal){
is useless. Better is:
/**
* Sets the cost, cost is in currency setted by #setCurrency.
* #param decimal cost, precision shoule be at least three places
*/
public void setCost(BigDecimal decimal){
Documentation: Javadoc is not enough. Give some starting point - a tutorial is preferable (and I don't mean the kind of tutorial with many screenshots of eclipse dialogs ;)). Example code is OK too, or at least write somewhere - 'Reading the javadoc of the EntryPoint class is a good way to start using this library'. If you have only javadocs anyone who is considering using your library will be presented a list of all the clases and packages, and will not know where to start.
Bugtracking Software: You won't remember more that three bugs at a time (and will forget things) - also it will help you manage tasks, and new wanted features.
You may want to try:
FogBugz - its nice, but costs money. (Free for up to two developers).
Bugzilla - nice, popular and free
Project Management Software: This will help you to calculate release dates, split tasks between developers etc.
dotProject - free and OK.
FogBugz - again works great.
Try to pass Joel test
Build process: Make the build a one-click process. For example an ant script that increments the version number, launches maven builds, deploys the site and so on. Worth the effort!
Forum: A nice idea, will help support.
Wiki: In many (even quite developed) projects such wikis are rather empty which is bad (as it makes people think 'how can this be great software if no-one writes in this wiki').

Plan on developing some type of website. If your code involves web software, people really marvel if you are using it as part of your site.
Developers love good documentation and lots of samples. I have seen projects that have lots of powerful code but 0% documentation fall hard.
Having a wiki setup to let people write ideas and recipes is a definite plus. (I recommend mediawiki).
A forum to post ideas, threads of discussions, i.e. a community forum is also good.
Setup a mailing list and encourage people to join.
Post real updates to your mailing list, wiki site, and also as news on your main site to show you are really working on things. Encourage participation. Make yourself available. This all generates a sense that you are interesting in chipping in, and that you are open to input from others.

I suggest using MAVEN as tool for managing external dependencies needed to build/run
You can aslo use Vulcan or alike for continous inetgration, so it is known whetaher current version is realy working or not.

I know Maven is already mentioned, but I think that even more important than using Maven is to publish artifacts to Maven repositories, so that projects that do use Maven can use them.
Your project page can then provide direct links to a repo as well so it server as storage space for downloadables as well.
Also: in similar vein, making jars OSGi bundles -- which just means adding a few Manifest entries, nothing very complicated -- is another good thing.
Both of these help others to more easily add dependencies to your package (if applicable) and can help adoption.
Some more things to consider:
Sensible version number scheme (major version bump for incompatible changes; minor version for additions with backwards compatibility; or something like that)
Keeping good release notes
Use a bug-tracking system, if you can use one easily (Codehaus, dev.java.net, SourceForce etc all offer this)
Simple project Wiki for documentation
Mailing lists for discussion

Generate a ChangeLog from checkin comments. Separately create a release note explaining what you fixed/added in each release.

Best solution for migration from Oracle Forms 6i to the web? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I work in an Oracle shop. There's a toolset that consists of roughly 1000 Oracle Forms (using the Forms builder from 6i, early 90's software) with Oracle 10g on the back end. It's serving roughly 500 unique people a month, with 200 concurrent connections at any given time during the work day.
Obviously this is something that needs to be addressed to get rid of the Forms runtime and move to a web based solution. The tools need to be accessed from Windows, Linux, various UNIX's, VMS and Solaris.
What options out there exist that would be feasible to migrate to? Not only does it need to be feasible for migration but the development will need to be done by 8 or so engineers who support the tool set (and many of which who would prefer to stay put and not modernize this tool set).
Oracle offers a few solutions that convert Oracle Forms into a crappy Java Applet (it's a very terrible temporary solution).
My solution of choice has been migrating to Ruby on Rails (which I'm a big proponent of Rails) but this will involve a learning curve (which we'll hit with any solution) for other developers. Also, the other difficulty in this is converting some very complex forms to HTML forms.
Has anyone tackled such a solution? Are there any packages offered by anyone outside of Oracle?
Any specific Java Web frameworks?
Would GWT, jQuery UI, ExtJS or any other JavaScript UI frameworks offer the rich user experience needed?
.NET is a consideration but a last resort (mostly because of license costs, there's no room in the budget in addition to what we're paying for Oracle licenses).

That's exactly what I am currently doing using...
Oracle Application Express
The learning curve is much smaller than most web-based alternatives for Forms developers, as all the code is in PL/SQL (unless you start getting fancy with Javascript, which you can). Also, in the latest release of Application Express (3.2), there is a tool to convert Forms applications to Apex.
It comes free with Oracle versions since 9.2.

I'll +1 for Oracle Application Express -- I think that there are some significant advantages in your situation.
Free licensing
It may bean attractive option to the current staff, if they are Oracle bigots like me.
It's 100% web, and in 11g doesn't even require a web tier.

A really late answer, but relevant. The upcoming V3.2 release of Oracle Application Express adds an Oracle Forms migration tool, which you might find improves your productivity even further.

You should check out this site http://www.forms2net.com/ it's Migration Tool of Oracle Forms to .Net. It's pretty good stuff!

In The Netherlands QAFE ( http://www.qafe.com ) is becoming a populair alternative. They have been around for a couple of years now, serving companies outside Europe as well.
Their claim to fame
Automatically convert and reuse 60-70% of the code
Apply filterrules to make the output cleaner (remove all no longer applicable / needed code). A new feature to improve the quality of the output code.
Use the output and edit/run directly in QAML Builder
Provide your styling (by means of CSS)
Bulk process Forms after a ruleset is defined
Forms Analysis for a better impact analysis
Render to any web technology you want (also to yet to be developed technologies) without the hassle - because the presentation layer is separated from the 'logic'
I work for the company that developed this platform so do not take my word for it, try it yourself and let me know what you think; I think these guys made the best package outside of Oracle.

Oracle maintains a list of vendors who all specialize in doing exactly what you need to do.
This is a very common and popular topic due to the large installed base of Oracle Forms. If you do a simple Google search there are lots of accounts of making this transition.
In my personal experience, we had luckily structured our Oracle Forms applications to have nice PL/SQL APIs. It was simple to re-use all the existing PL/SQL in our transition to J2EE, which we did manually. It sounds like you have too many Forms to do that efficiently, though.

Oracle Migration Assistant is free. It pretty much does exactly what PITSS does for the Migration. PITSS offers some neat things that can be used going forward, which will justify the cost. But if it's a Forms Migration you need, Migration Assistant does the same job.
But if you do purchase PITSS, you could easily write a script to rename a set of forms to something repeatable and write a log of what the names where. Load under names like 1.fmb, 2.fmb, etc. Perform the changes. Then rename them back using another log file that references the log file. Then repeat for another set of forms. Could save you thousands per 100 forms.
And the reports migration is a waste of time. You will have to open each form anyway and reposition fields, especially on the parameter form. That's all you would have to do without the PITSS tool.

Try contacting the folks at ATX about this: http://www.atxtechnologies.co.uk/java/forms2java/. J2EE Java plus Adobe Flex means that the licensing is probably free (unless you want Flash Builder as well). If it's like Forms2Net, the conversion rate will be fairly high and you'll get good quality Java code afterwards.

Hi i have done a similar work using GWT/springs/ORMS combination, the results are fantastic ,how ever it also depends on the complexity of business process mine was a very very complex business process, what i did was segragate all the layers and treat each layer as a service , in the process i made an application which every one goes wow and at the same time is eligible for many certifications , but if you want to do it more faster and not change the front end u can use exodus
cheers
vasem
vasem_want#yahoo.co.uk

I have found that PITSS.CON, developed by PITSS ( http://www.pitssamerica.com ) is the best out there Oracle Forms Migration. Instead of doing this manually, where you can spend up a few months with a couple hundred forms or a couple years with over a thousand, PITSS.CON, enables one to migrate from any 2.3 to 10g in a matter of days. Its unbelievable what this tool can do.

Hi I work for PITSS (pitssamerica.com), and I want to elaborate on what gwoods1412 stated. You can migrate from any version of Oracle Forms 2.3, 3.0, 4.0, 4.5, 5.0, 6i, or 9i to 10g. The tool also migrates your Oracle Reports, and we have a solution to cure the issue with using the Reports parameter form. Oracel Forms and Reports 10g is a Web Based Solution, so you don't have to bite off the expense of a migration to another platform.
APEX is free to use, but it isn't free to migrate to. And the migration tool only extracts the fields (items), it does not take the Business Logic. So you are not getting your real investment out of your forms, you are getting a query and field description.
If you use a tool like PITSS.con, you will be testing you application on the web in a few days. Your developers will be working on other projects, and all will be right in the world. Oh yeah, you can interoperate with APEX, ADF, Java, .NET, etc once you are in 10g too. That means new development can be done in a new toolset. You start a gradual methodical migration to a new technology. Pretty nice to not have a huge launch party in two years when you can have one this month.
And APEX isn't really an enterprise solution. Here's a quote from David Peake who is Oracle APEX Product Manager:
"One of my key goals is to not over sell APEX conversion capabilities and ensure that attendees understand that converting Forms requires significant investment and is not going to be easy, no matter what tool you are converting to."
I stole that quote from Grant Ronald's (Oracle Fusion Middleware Product Manager ) blog which can viewed at Grant's Blog

You really need to check out the Forms Conversion utility from TurboEnterprise. I do not use Oracle Forms but a friend of mine has used their software to covert Oracle Forms and he loves it. They also have a free version on their website too i think. www.turbo-enterprise.com