We Keep Coding

Is it possible to assign multiple ORM configurations to a Java Model?

We have this situation:
One backend written with Spring.
One native Android app.
They share many of the models.
What it has been done is writing models in a package on the backend and then export it as jar in android.
On android we are using OrmLite to interact with these models on the DB. The models have their proper annotations to achieve this. On the backend we basically write raw crud queries for each model, this is getting crazy as every time we add a field we need to update all the relevant queries.
What we would like to achieve is to use another orm on the server. The problem is that server and tablet for old bad design choices have different column and table names even though the models are the same. Renaming columns and tables cannot be done because it involves too much work.
We need to get things smarter, but we would also like to avoid duplicating the models just to remap the models to a different database schema.
Do you have any idea on a smart way on how to achieve this?

Unfortunately, "Renaming columns and tables cannot be done because it involves too much work" is the best solution to have consistent and managebale code base in the long term.
For the short term, what could be smart is to use XML based configuration on the server and stick to annotations for the tablet app.
Update
You want to look at JPA specification, it defines the persistence mechanism in java. There are multiple implementation providers for it, here is the list for providers of the specificaions latest version.
I only have experience with Hibernate ORM which along with its native API also provides implementation for JPA. It has XML based configuration option in addition to annotations. You will have evaluate which provider suits your requirment.
If the annotation of ORMlite differ from JPA then you can even use the JPA annotation in the entity classes besides the ORMLite annotation. But beware this will make your entity model classes messy and you will need both your selected JPA implemantion library and ORMLite library on the classpath of entity model.

spring restful dto or entity

I am developing a spring restful application that uses hibernate. I am coming across scenarios where i had to place jackson json annotations on entity getters. Ex: One to Many mappings.
Is it a good idea to place jackson json annotations on hibernate entities? Or should i go with DTO pattern to pass data that is just needed by UI? I may end up creating a DTO for every entity.
Below is the application architecture. Common is at root level. DAO has dependency on Common and so on.
Common <- DAO <- Services <- Web
DAO has entities
Services or Web can have DTO's
Please let me know your thoughts or suggestions.

Disclaimer: I am speaking from opinion and experience here
Separate dto and entities are common practice. What you choose to do really depends on it's use. One of the drawbacks of adding DTO annotations on your data model entities is versioning. Versioning becomes hard when your data model is tied to your contract. If your webservice is only used by a consumer you own and its deploy schedule is the same then it's probably not worth separating dto/entities. If you don't need versioning and you mostly have CRUD web services then you may want to look into spring data rest.
If you arn't so lucky, and have multiple consumers, then you may want to think through a few version breaking changes and how you will handle it. This will help you see the value in separating the data and contract.

Separating JPA information from POJO

I am working on a project that will have entities persisted to a database using JPA. We will be using Maven as the project management framework. I am wondering if it would be possible to create one project for the POJOs and another for the persistence definitions and then "combine" the two into a single output that contains the POJOs and their persistence information.
Basically I am trying to separate the code that POJOs from the persistence definition. Because the POJOs may be reused by several different projects that may or may not need to persist them and may or may not want to change the persistence information. (Similar but not quite the same as Is it possible to build a JPA entity by extending a POJO?)
I have two ideas on how I might be able to do it. If I were to use the POJOs in a web application I could provide persistence.xml and map the classes in that project and just add a dependency to the project containing the POJOs. But if I wanted to create a single jar file containing the persistence information and the POJOs, I think I could use the shade plugin?
Is there any other way to essentially merge two maven projects into a single output and is this a reasonable thing to want to do?

If I remember correctly, then annotations do not have to be on the classpath if you're not using them. The annotated classes can still be loaded.
So my recommendation would be:
Stick with the JPA annotations, as this is the easiest way to define the mappings and tooling support is usually better.
Declare the JPA dependencies as optional and probably also as provided.
If you need to override the mappings defined by the annotations, it should be possible to do this using the persistence.xml, AFAIK (never tried).

I do appreciate the input. In the end, the solution for me was to create two projects. The first provided the definition of the POJOs without any JPA information. Yes there are some JPA related members such as id but I will address those. The second project contained the JPA metadata (orm and persistence XML files).
As for the members related to persistence (e.g. id) I could probably live with those in the model classes but using the suggestion in this post (Is it possible to build a JPA entity by extending a POJO?) I extended my POJO classes and declared id in the "entity" sub classes. This does require some consideration when defining the POJO in terms of access to members.
One thing to note, this solution runs into trouble when you have a class hierarchy (inheritance in your model). The classes in your "pure" model inherit from some common class. That class is then extended in the "persistence" model to provide the id and other persistence related members. Now if the persistent subclasses inherit from the classes in the "pure" model, they do not inherit the id and other persistent members.
There may be workarounds in different inheritance mapping such as table per concrete class.

Design pattern for modular application (how to reuse entities)

I have the following scenario:
A JAX-RS Webservice that is responsable for the business logic and database interactions.
A webapp that will be used by the end users.
A webapp that will be used by administrators.
My problem is that I want to reuse the entities from the webservice on the other apps, but it is highly wrapped with frameworks like JPA, JAX-RS, CDI, among others... So I am having a hard time to isolate them. What I want is to know the best workaround and why should I use it instead of others.

Maybe DTO is the way to go (with support from some object mapper library like Dozer)
Please take a look at following article for more details: http://zezutom.blogspot.com/2012/02/thoughts-on-data-transfer-objects.html

Write you entity objects as Plain Old Java Objects (POJOs), with proper constructors, setters, etc. Apply the annotations that allow the JPA to persist them and do the object to relational mapping in such a way that, if those annotations were all stripped away you could still create and manipulate those objects fully, using the public methods of the class. It can be helpful if you create the POJO first, then add the annotations afterwards.
As the POJOs stand alone they are not at all part of your repository layer. You can use them without using the JPA at all.

Spring template engine for rendering JSON

I come from Ruby and have just started testing Spring and find it fairly nice.
However i'm used to being able to customize the rendered JSON output with libraries like rabl and it feels really wrong to expose internal models straight out into the JSON as i do now with the annotation #ResponseBody and just returning the model.
Does anyone have any tips on libraries similar to rabl but for java/spring or is there an existing way to do it easily with spring without manually writing templates in JSON?

Spring uses Jackson to do the JSON (de-)serialisation. Take a look at the Jackson wiki; it describes several ways to customise the way JSON is generated or interpreted.
As I understand from your comment, you have a couple of customisations in mind.
Renaming fields can be achieved by annotating the field with #JsonProperty("name")
Not rendering fields can be achieved by annotating the field with #JsonIgnore
But these do require you to touch your model. As far as I know, there is no way you could achieve that without at least changing your model classes slightly. There's the concept of "views" in Jackson but they still require putting annotations on your model. In practice, I've never experienced problems with Java classes being annotated with both JPA and Jackson annotations, by the way.
Finally, you can consider creating two versions of your model - one that comes from your database (or whatever source of data you have), and one that is used to interact with the user interface. However, that would require a layover of transformers or converters. Whether or not that is an option is up to you.