Community
Participate
Working Groups
Port the core runtime to GWT and support generating model and edit plugins against the runtime platform.
Created attachment 166334 [details] EMF GWT project set file
*** Bug 209434 has been marked as a duplicate of this bug. ***
*** Bug 209435 has been marked as a duplicate of this bug. ***
*** Bug 211340 has been marked as a duplicate of this bug. ***
I've committed the project set file as emf-GWT-Working-Set.psf in /cvsroot/modeling/org.eclipse.emf/org.eclipse.emf/psf.
Created attachment 166687 [details] updates to make projects compile Ed, I had to make some changes in order to get the resulting model and edit projects to compile. Without these, the JRE reference was missing from the classpath and the dependency on the GWT plug-in (which is not re-exported by any of the EMF GWT plug-ins) was missing from the bundle manifest... Let me know what you think.
I don't think this should be necessary. Did you properly configure your GWT SDK? Once that's configured properly, the classpath should automatically be set up to refer to the GWT libraries without the manifest dependency. The problem with the GWT bundles is you can't install them in the IDE so they're only good as part of the target platform or actually being in the workspace. Given that they're not needed at all if you have the GWT container set properly, I'm not sure if it's good to include them.
(In reply to comment #7) > I don't think this should be necessary. Did you properly configure your GWT > SDK? Once that's configured properly, the classpath should automatically be > set up to refer to the GWT libraries without the manifest dependency. The > problem with the GWT bundles is you can't install them in the IDE so they're > only good as part of the target platform or actually being in the workspace. > Given that they're not needed at all if you have the GWT container set > properly, I'm not sure if it's good to include them. Yeah, I had the GWT bundles checked out into my development workspace (not installed), but I was trying to generate the projects in my runtime workspace, which means (of course) that the GWT container references won't work (as expected). There still seems to be a problem with regenerating the classpath for an existing project, though (even after it's been deleted), but this problem probably existed previously. So, here's how to get this to work: 1. Install the Google plug-in for Eclipse and make sure you have the GWT SDK registered. 2. Install an EMF build with the new support for GWT runtime platform (M7 or later). 3. Check the EMF GWT modules (and dependencies) out, using the project set file, into your development workspace. 4. Generate model and edit projects, from scratch, using the new GWT runtime platform option.
Created attachment 167982 [details] updates to support single model/edit project Ed, here's a patch that ensures that the module is correctly generated in cases where the model and edit plugin are hosted in the same project.
(In reply to comment #9) > Created an attachment (id=167982) > updates to support single model/edit project I've committed the changes with one tweak - it turns out that module sources were already being adjusted if the model and edit project were the same. Now the module name and inherits are as well. :)
(In reply to comment #8) > > So, here's how to get this to work: > > 1. Install the Google plug-in for Eclipse and make sure you have the GWT SDK > registered. > 2. Install an EMF build with the new support for GWT runtime platform (M7 or > later). > 3. Check the EMF GWT modules (and dependencies) out, using the project set > file, into your development workspace. > 4. Generate model and edit projects, from scratch, using the new GWT runtime > platform option. Kenn, is there a requirement/suggestion that GWT be installed in a dedicated IDE ala EMF RAP, or is it pretty safe to install all of the GWT runtime stuff into one's normal (IDE targeting) development environment?
The GWT runtime itself won't function installed in the IDE. It needs to be in the workspace for the GWT compiler to see the source. I've not tried installing it just in the target platform. Not sure that works...
(In reply to comment #12) > The GWT runtime itself won't function installed in the IDE. It needs to be in > the workspace for the GWT compiler to see the source. I've not tried > installing it just in the target platform. Not sure that works... Yeah, it's safe to have the GWT stuff in your development workspace - it doesn't conflict with the normal Eclipse runtime the way RAP does. The Google plug-in for Eclipse is the only thing that needs to be "installed"; the other stuff just needs to be checked out into your workspace, at least for now. The target platform approach doesn't really apply to GWT (certainly not to App Engine) because "deploying" your runtime is a matter of packing your stuff into a war file and running it on the server (or in development mode)...
I have a question about a use case for this functionality...which I'm going to ask on this bug rather than in one of the EMF forums...because the GWT support obviously not finalized yet. A colleague of mine is using these plugins and successfully generating GWT code...and is able to use it to serialize/deserialized with GWT's ajax support. But when he tries to serialize the model instance (using XMI) he gets an UnsupportedOperationException from the doSave() method. Is this because XMI is not supported (rather GWT serialization)? Is there any way to get both GWT and XMI serialization for types generated? Thanksinadvance.
There's no support for SAX in GWT and even the DOM implementation is grossly simplified so getting XMI support seems unlikely. I am working on support for BinaryResourceImpl though....
(In reply to comment #15) > There's no support for SAX in GWT and even the DOM implementation is grossly > simplified so getting XMI support seems unlikely. I am working on support for > BinaryResourceImpl though.... Getting off-topic now, but wow cool, I hadn't noticed Binary support before. Taking caveats in javadoc, this is still reasonably safe to use as long as we don't assume forward compatibility?
(In reply to comment #15) > There's no support for SAX in GWT and even the DOM implementation is grossly > simplified so getting XMI support seems unlikely. I am working on support for > BinaryResourceImpl though.... Of course, there is a longer answer. ;) The current EMF runtime for GWT really only supports serialization via GWT RPC, which is fine for client/server communication but not necessarily ideal on the server side. Depending on what you want to do, several options may make sense on the back end. One approach would be to send EMF objects, based on the current runtime, back and forth between the client and server and translate between those objects on the server to something more appropriate for persistence. Options here might include the use of technologies like Texo to map between "full" EMF objects and lighter-weight POJOs which could be annotated to support persistence with a JPA-compliant data store (for example). Another approach, supported by Ed's current work on the binary resource implementation, would be to "bypass" the typical RPC channel, allowing (but not requiring) a different implementation of the model API to be used on the server side. Such an implementation could very well be a "standard" EMF implementation of the model which could include the usual XML/XMI serialization (if you really want it) and/or be used in an OSGi context...
(In reply to comment #16) > (In reply to comment #15) > > There's no support for SAX in GWT and even the DOM implementation is grossly > > simplified so getting XMI support seems unlikely. I am working on support for > > BinaryResourceImpl though.... > > Getting off-topic now, but wow cool, I hadn't noticed Binary support before. > Taking caveats in javadoc, this is still reasonably safe to use as long as we > don't assume forward compatibility? AFAIK, the binary serialization includes version information so, yes, one should reasonably expect support for backwards (but not forwards) compatibility. Incidentally, we covered the binary resource implementation briefly as part of our EMF tutorial at EclipseCon (http://www.eclipsecon.org/2010/sessions/?page=sessions&id=1463, see pp. 33-35). The performance characteristics of binary serialization are drastically better than those of XML/XMI, as shown on page 34 of the presentation...
(In reply to comment #18) > Incidentally, we covered the binary resource implementation briefly as part of > our EMF tutorial at EclipseCon > (http://www.eclipsecon.org/2010/sessions/?page=sessions&id=1463, see pp. > 33-35). The performance characteristics of binary serialization are drastically > better than those of XML/XMI, as shown on page 34 of the presentation... Great, that was my hope and I was looking to that much more than just the obvious reduction in file size -- obviously if that were the only goal you could achieve the same thing with compression. After all, since you know all of the specifics of your metadata from the model, why spend all of that time parsing a generic representation?! I'm looking at load times of five-ten minutes even with all the performance optimizations so I'm excited to try this out.
The 2.6 work is done. Additional work for 2.7 will be done with new bugzillas.
The fix is available in the latest build for the stream.
