EMF is an object framework/serialization plugin to Eclipse shipped with Eclipse RT - Eclipse's core. It comes with Eclipse-based modelling tools to build object models. The problem is that EMF is not JMI based at this point. The model(s) are called ECore and they are used to generate EObjects instead of POJOs.

I would like to treat EObjects like a POJO and was wondering if anyone had experience doing this. I realize that I could use an ECore to HBM converter (can anyone recommend one?) and then use hbm2java to generate beans but then I am stuck with how to serialize POJOs to XMI in a way that integrates with Eclipse (anyone recommend a plugin for this?).

I would really prefer not having to maintain both EObjects and POJOs for the same model.

One of the basic problems encountered with EObjects (besides the freaky design patterns used by IBM) is that collections are "owned" by the EObject.

For example, say one EObject called Team has a "set" of Player EObjects associated with it. The Team EObject is generated (by default) with method, "EList getPlayers()". There is no "void setPlayers(EList)" method. The only way to insert players is calling Team.getPlayers().add(Player). Won't this cause problems for Hibernate's lazy loading?
There is perhaps a way to change the default ECore genmodel mechanism (I haven't waded thru that yet) but I would like to avoid that too.

Any posts with experiences or recommendations in this area is greatly appreciated.
Thanks,
Mike

Sounds bad to me. Not having set accessors will make this hard. Do you truly have to use EMF objects? What is the gain?

Basically, EObject and Hibernate are different PSM (Platform Specific Modeling) frameworks.

EObject integrates well with Eclipse/XMI/source control systems. Basically, objects are serialized as XML in files in a file system. Eclipse handles revision control. It doesn't handle query at all. Doesn't scale to millions of instances of objects.

Hibernate works well with RDBMS, scales. It doesn't (please correct me if I am wrong) work well serializing as XML in files in a file system. How do people export hibernate object instances as XML in files in an archive - like when you move from one environment to another? There has to be a simple way for non-DBA folks to do this. I have heard of JDBC drivers that store data as XML but this seems like overkill. It would be better to take a java object and serialize it as XMI using reflection - taking into account, for example, the cascade attribute from the HBM file to embed "children" objects.

Consider a portal. Perhaps portlets and portal pages are designed in Eclipse using EMF. They are packaged into an archive and deployed into an app server. Perhaps a user profile that personalizes a portlet is designed using Hibernate. In this case, the user profile in the Hibernate PSM has to reference the portlet in the EMF PSM (instantiated from a WAR ClassLoader, for example).

What are the ways people build these models/applications?

I dont remember the exact details of EObjects implementation requirements but here goes some tips for how to circumvent limitation when persisting "non transparent framework objects".
(this is for Hibernate 3 ... Hibernate 2 has some of this, but I for sure recommend Hibernate 3)

Interceptor.instantiate(String entityName) can be used to create classes that does not have a desfault constructor.

PropertyAccessor can be used to access values in non standard ways. Currently we have Bean, Field and Map access - you can use them, or write your own.

Hibernate only supports Java Collections and as such need to get access to them to be able to wrap it to track changes efficiently and of course for the proxying. That EObject is missing some methods doesnt prevent you from using the underlying field for the collection with hibernate and/or add methods that exposes those part just enough to let hibernate do its thing (i assume these objects actually have a physical collection somewhere)

If that does not work then you might be able to do some more home-made stuff by using the brandnew collection-type attribute or simply write your own version of a Collection persister for this stuff.

I dont remember the exact details of EObjects implementation requirements but here goes some tips for how to circumvent limitation when persisting "non transparent framework objects".
(this is for Hibernate 3 ... Hibernate 2 has some of this, but I for sure recommend Hibernate 3)

Interceptor.instantiate(String entityName) can be used to create classes that does not have a desfault constructor.

PropertyAccessor can be used to access values in non standard ways. Currently we have Bean, Field and Map access - you can use them, or write your own.

Hibernate only supports Java Collections and as such need to get access to them to be able to wrap it to track changes efficiently and of course for the proxying. That EObject is missing some methods doesnt prevent you from using the underlying field for the collection with hibernate and/or add methods that exposes those part just enough to let hibernate do its thing (i assume these objects actually have a physical collection somewhere)

If that does not work then you might be able to do some more home-made stuff by using the brandnew collection-type attribute or simply write your own version of a Collection persister for this stuff.

It must be better to use "EObjects" for code generator, diagram editors and viewers (tool development). Generated application model doe's not need to depend on eclipse and you can can generate any code from "metamodel"

So you havn't noticed UserCollectionType yet? ;-)

Thanks for the tip about UserCollectionType - I will investigate further that route.



True, but then I have to maintain multiple code generations for the same model. Unfortunately, the Eclipse guys didn't decide on using POJOs - they used EObjects so I am forced to generate those.

Here is a quick example on why EMF is useful. Consider two objects - a Team and a Coach. The Coach references the team. Say an instance of each object is serialized to team.xmi and coach.xmi respectively.

team.xmi


coach.xmi


Note that the Coach does not reference a property of the team - it uses a relative file path instead. EMF provides the resolution of these references and the EObject to XMI serialization used above (as well as a funky but workable UI for generating model objects).

I'm lazy - I was hoping for better existing integration. I don't think I can "pitch" supporting two sets of generated model objects. Either I will wait for EMF to support POJOs (not likely soon) or write a bunch of Hibernate extensions to support EObject (likely to happen sooner).

Thanks for your help.
-mike

Sure, didnt you notice my last line ? ,)

Or copy and change JET temlates.

You can use plugin Teneo for Eclipse...
http://www.elver.org/index.html