Hi all, I'm Javier Paniza, project lead of OpenXava project, http://www.openxava.org/ and I have a proposal for JMatter team and community. OpenXava and JMatter are very alike products, in fact, OpenXava compete against JMatter. Even though, I think that JMatter and OpenXava can cooperate in some way, and this can be profitable for both, this can help us to gain ground against MVC _frame_works. But, How ? We can concentrate in portability. The idea is that a develeper develops an applicaton for OpenXava, and in any moment he could migrate it with a minimun effort to JMatter. The same application, different engine for running it. Even, if we will achieve a high level of portability, the developer can have the application on OpenXava (to use it inside a Java Portal) or in JMatter to use it as a Java Client Application. How we can obtain this portability ? We can start using standard Java API as JPA for persistence, and bean validation (JSR-303) for validation. Removing from our _frame_works all propietary annotation about these issues. Then, we can try to create a common specification for layout, currently OX does it in this way: http://openxava.wikispaces.com/view_en and controller, OX does it in this way: http://openxava.wikispaces.com/controllers_en Maybe, this proposal is technically impossible, or it's outside of the JMatter strategy. But, maybe not. This offer can include other model driven _frame_works as Trails, Roma_frame_works or Naked _object_s. What think about this the JMatter team ? What think about this the JMatter community ? Regards, Javier Paniza P.D.: I apologize if this is not the correct place for this issue. I was looking for a Discussion forum or so.

if it helps us create 3 tier apps then I'm IN.

here are my thoughts: 1. i agree that our like _frame_works should try to work together 2. i think one way to make apps more portable across the    various like-_frame_works is to define a standard way    to digest a model definition.  i.e. it could be as simple    as export my model to the common definition and     import this common definition model into jmatter.    ( the umlc product from ryan ramage (ultraviolet)       i feel is a good candidate. )    i've often considered experimenting with other languages as    a more malleable substrate in which to define models.    in such a circumstance, jsr's may not work out as a    basis for a common definition 3. frieddust's comment below echoes what is probably the    most important feature lacking in jmatter:  making it    work 3-tier.  i do feel this is probably where the    majority of the dev effort in jmatter should focus.    it's been a long time since i've looked at OX.  i will    need to spend a little time with it and get more familiar    to see if this is a possible area for collaboration. thanks, / eitan On May 4, 1:55 am, FriedDust < This e-mail address is being protected from spam bots, you need JavaScript enabled to view it wrote: - Hide quoted text -- Show quoted text - if it helps us create 3 tier apps then I'm IN.

3. frieddust's comment below echoes what is probably the    most important feature lacking in jmatter:  making it    work 3-tier.  i do feel this is probably where the    majority of the dev effort in jmatter should focus.    it's been a long time since i've looked at OX.  i will    need to spend a little time with it and get more familiar    to see if this is a possible area for collaboration. I know that JMatter is a very good a mature product with a lot of specific features outside of the scope of OpenXava. My goal is not to mix OX and JMatter, or collobarate at code level, but creating a common way for writting the model classes for our _frame_works, In this way, we can achieve more portability. Moreover, we add value to our _frame_works. The users of JMatter will not write application for JMatter anymore, but they will write standard Java applications that JMatter can be run. For example, you use @Persist propietary annotation. Why not do you use @Entity from JPA ? Why not to embrace JPA for collections, relationships, inheritance, etc ? And instead of using your own validation _frame_work, why not to use Hibernate Validator ? Or JSR-303 when available. If you do so, an application written for OpenXava (that uses JPA and Hibernate Validator) can be ported to JMatter easily. OpenXava uses JPA since version 3, before it used a propietary _xml_ format. OpenXava uses Hibernate Validator since version 3.0.1, before it used a propietary validator. We changed OX in order to be more standard. Are you willing to do the same with JMatter ? What do you think ? Cheers Javier

relationships, inheritance, etc ? And instead of using your own validation _frame_work, why not to use Hibernate Validator ? Or JSR-303 when available. If you do so, an application written for OpenXava (that uses JPA and Hibernate Validator) can be ported to JMatter easily. OpenXava uses JPA since version 3, before it used a propietary _xml_ format. OpenXava uses Hibernate Validator since version 3.0.1, before it used a propietary validator. We changed OX in order to be more standard. Are you willing to do the same with JMatter ? What do you think ? i wonder whether differences in opinion on design might get in the way of abiding by a single standard.  for example i'm big on using the equivalent of scala's val declaration (final members in java) to model child fields.  whereas i get the feeling that most java developers prefer the javabeans convention. moving to the jpa has been on my todo list for a long time.   i do intend to get there.  i think it's mostly an issue of prioritization. hibernate validator is relatively new.  i haven't yet looked at it. hibernate projects do seem to quickly gain defacto standard status. i'm not sure how i feel about the whole standards game.  how you design something to a great deal defines what it is.  some things are mundane, like the jpa annotations, so going with it is a fairly straightforward decision. i will try to get there.  the main friction points for me at the moment are not so much willingness, but time constraints and prioritization of tasks (i.e. other tasks may get worked on before the ones you propose). anyhow, the first thing i should do is get up to speed on openxava and see how ox models are defined and how they differ from jmatter's. thanks, / eitan