Roma is the only “meta” framework. Using Roma you're definitely free from the technology you're using. How does it work? Roma provides very generic behavior interfaces called “Aspects”. Aspects enclose the most common use cases. Using the tool and framework through the Aspect allow to leave your code clean from the technology. But if I need to use the technology directly, can I do it with Roma? Sure. You can always reach the implementation under the hood. Just remember you had to migrate that pieces of code in case tomorrow you'll change the technology. In the documentation you can find some best practice to make migration the easiest possible. Roma allows you to develop enterprise level Java applications with low effort following a real Domain Driven Design approach. It's a new way to conceive the application: anything is a POJO, from the GUI forms to the persistent objects. Using the Meta-Framework approach you can integrate the latest breaking technology in your application without modifying your domain and application logic because they are really decoupled. Roma provides you automatic support for every layer and aspect for your application, from dynamic web user interface and persistence, to report functionalities, portlet development and semantic technologies. Roma is Open Source and licensed under the commercial friendly Apache 2.0. See all the tools and frameworks supported today: http://www.romaframework.org/advanced_technology.htm To know more: http://www.romaframework.org.

Congratulations in releasing this product! It is very interesting. Anyway what I don't like is the article itself, because the "question-answer" pattern does not communicate what the features are, a list would have been better. The documentation should be reviewed by a native English speaker. I have just a question: how does it compare to things like NakedObjects?

Congratulations in releasing this product! It is very interesting.
Anyway what I don't like is the article itself, because the "question-answer" pattern does not communicate what the features are, a list would have been better.
The documentation should be reviewed by a native English speaker.

The Roma's first two goals are: - decoupling business code from technology - fast development This is an example of a POJO rendered directly as a form: public class Login{ private String name; @ViewField(render="password") private String password; @FlowAction(next=HomePage.class) public void login(){ // check authentication } } This will be rendered as a classic login form with a button called "login". Once pressed the code of login method will be called. If no exceptions will be catched the Flow Aspect will redirect the request to a new HomePage POJO. This is a very simple example! The free PDF Handbook already contains all the documentation and tutorials about the Roma usage.

I have just a question: how does it compare to things like NakedObjects?

There are many points in common with Naked Objects. However I can resume the main differences: - Roma covers not just GUI and Persistence but so many aspects: scheduling, i18n, service, semantic, etc. - Roma was designed to allow swap of technologies leaving your business code unmodified. You can swap from Echo2 to the new XHTML-CSS view module at no cost. - Naked Objects's GUI is quite different from ordinary applications and most of interactions are via drag&drop: some customer may not appreciate it bye, Luca Garulli

Meta or not. Just another framework.

Meta or not. Just another framework.

You're right. But it aims to integrate each others as glue and leave to the developer a POJO view of anything. bye, Luca Garulli

I think I will start a meta-meta-framework project which will allow you to swap out meta-framework Roma implementation and put your favorite one. This way your project will not depend on meta-framework and you will be free to develop and integrate endless inter-framework abstraction layers which will totally occupy your team as change in a domain will have to propagate to all integration layers. This way your team will have less time to concentrate on meaningless business logic.

Oh, forgot to mention, I will write a best practices white paper on how to best propagate the changes through abstraction and inter-framework layers.

Actually, this isn't such a bad idea. Personally, I will check this out as the idea has potential and many advantages IMO.

... inter-framework layers ...

A meta-meta-framework...? I am actually working on a logging-abstraction-abstraction, maybe we could reuse some concepts here (there are potentially interesting design pattern patterns to draw from this).

Congratulations Luca and team on this important milestone!

There's never too many Linux distros. There's never too many JavaScript UI toolkits. There's never too many Java web frameworks. Many people complain about that. I find it just fine. What irks to the point of derision is the Java programmer's inclination to over engineer absolutely everything they touch. Everything they do must be super flexible, super extensible super adaptable, super pluggable (is it a word?), and super abstractable and super meta-able. Just super. It's sick. Have a super simple framework in your language. Build your app. Enjoy the sunshine. Take a look at Click framework. You can build a full CRM in days with it. Add javarebel (that Sun should buy) and you go home early enough to kiss the kids good night and some. You never hear of a meta PHP framework with which you can build a Java app. And the web is littered with great solutions. For some reasons for the java programmer simple is not gratifying.

...For some reasons for the java programmer simple is not gratifying.

Roma was born because coding an entire application in Java often is too difficult, poor productive and you need to know so much things! Let's think to the DOMAIN (DDD approach) since it's the real value of an application. The effort the community made was to simplify the life of the Java programmer: just write anything as POJO and don't worry too much about the presentation, persistence, i18n, service, etc. Or better... Worry only if you need! You can write a full working Ajax Web Application that interacts with a DBMS in minutes without writing a line of HTML, Javascript and SQL! @ViewClass( layout = "popup" ) public class EmployeeForm {   @ViewField( layout = "expand" )   private Employee entity;   public void save(){     ObjectContext.getInstance().getComponent(PersistenceAspect).updateObject( entity );   } }

Ciao Luca, first of all congratulations for publicly releasing the juice of your efforts. I had a (unfortunately sheer) look at your website and I am sure you won't mind if I ask a few questions. I may have missed the point, but Roma does not look so "meta" - in other words, it looks like it wants to solve the same problem Spring wants to solve but with a different approach which is aspect-based rather than layer-based. Is my understanding correct? Use of annotations in Roma Framework: how does the Roma framework handle with the annotations used by the underlying frameworks? Is switching from, e.g., IBATIS/JDO/plain Hibernate to JPA really transparent? And what about switching from, let's say, Echo2 to GWT, JSF or WebFlow? I beg your pardon if I haven't chance of better reading the documentation, simply had no time. Will surely do this weekend. One last comment: this is absolutely personal taste - I did not like the lower-case "i" on the interface names (e.g. iQuery) - wasn't IQuery better? Fluent interface: many frameworks miss a fluent-interface API - is there one planned for the Roma framework? Grazie e ciao!

I may have missed the point, but Roma does not look so "meta" - in other words, it looks like it wants to solve the same problem Spring wants to solve but with a different approach which is aspect-based rather than layer-based. Is my understanding correct?

Roma is entirely based on Spring (but you could easly change it with another IoC). How you are telling Roma addresses the abstraction of all the aspects around the applicaiton Domain: persistence, presentation, i18n, scheduling, semantic, services, sessions, etc. They are behavioural interfaces.

Use of annotations in Roma Framework: how does the Roma framework handle with the annotations used by the underlying frameworks? Is switching from, e.g., IBATIS/JDO/plain Hibernate to JPA really transparent? And what about switching from, let's say, Echo2 to GWT, JSF or WebFlow?

You can use Java5 annotation as well XML Annotation. It's a new concept in java: leave the code clean in favour of writing a XML file named as the java class (but with extension .xml). Example of Company.xml: <?xml version="1.0" encoding="UTF-8"?>                                        Or the same using Java5 annotations public class Company{   ....   @ViewField(render="table")   private List employees;   .... } This annotation is telling that you would render that ordered collection as a table (and not a list as by default). This works using as implementation Echo2 or the XHTML-CSS2 module. In the future I'd like to see Swing/GWT/J2ME implementations. The same is for other aspects: portability is real at ZERO cost or low cost if you're using the underlying tool/framework for some works.

I beg your pardon if I haven't chance of better reading the documentation, simply had no time. Will surely do this weekend.

One last comment: this is absolutely personal taste - I did not like the lower-case "i" on the interface names (e.g. iQuery) - wasn't IQuery better?

All classes and interface starts with the capitalized word as Sun coding conventions tell. Maybe iQuery was the name of the parameter of a method. In that case the use is to distinguish input parameters from classes attributes, but it's not the rule.

Fluent interface: many frameworks miss a fluent-interface API - is there one planned for the Roma framework?

Grazie e ciao!

What do you mean for fluent API? Ciao!

For fluent interface I suppose he meant this: http://en.wikipedia.org/wiki/Fluent_interface

Hi Valerio, some component supports a fluent interface. You can execute query using the query by criteria pattern (called query by filter) using a fluent interface: new QueryByFilter(Customer.class).addItem("name", QueryByFilter.EQUALS, "Luca").addOrder("name", QueryByFilter.ORDER_DESC); But, sure, we need to improve the fluent support in each Aspect/Module. Ciao, Luca Garulli

For fluent interface I suppose he meant this:

http://en.wikipedia.org/wiki/Fluent_interface

Absolutely yes, thanks for pointing out, could not read TSS yesterday afternoon :)

Good job guys. Keep on Roma'ing !

Best wishes Luca !!!! Guido

I would not use this, but if this were something comming from java spec like jpa, then it would be worth considering.

I would not use this, but if this were something comming from java spec like jpa, then it would be worth considering.

The module persistence-datanucleus is based on the tool DataNucleus (the most powerful OR mapping tool I saw until now!) and uses JDO 2.2 and JPA. Thus effectly your application works using JDO or JPA standards. However Roma wraps the persistence APIs in the PersistenceAspect interface. The goal is to cover 80-90% of use cases. For the remaining cases you can use the underlying implementation directly knowning that code will be not portable. What would happen to your code if you would migrate to another persistence technology? Roma aims to save the developer investment making all or most of code portable across technologies, tools and frameworks. Luca

I saw that the focus is currently purely on web apps. Is Swing supported?

I saw that the focus is currently purely on web apps. Is Swing supported?

Using ROMA the "presentation" is just an aspect as others. But AFAIK now there are no initiatives to make Swing/SWT implementation of View Aspect. Any volunteers? Luca