Split Modules for Development and Production

[the.wizard]

Hi everyone, 

I was using Mvp4g 1.5.0 right now and GWT 2.7.0. In my project, I have a parent module which contains a lot of child modules (more than 50 modules), and whenever I start the super dev mode, it takes some time to compile it before it can run in my browser. Sometimes it even failed to compile because it run out of memory. 

Now I need to find a better way for my development, since this problem really slow down my development. In normal GWT project, we could simply split our module into one gwt.xml file, then I create 2 root gwt.xml file. The first one (let's call it Original.gwt.xml) will consist all the gwt.xml module in my project and will be used for production build. The second one (let's call it Dev.gwt.xml) will only consist the gxt.xml module I was working on (simply to say, it will only contains 1 inherits gwt xml file). 

But since Mvp4g multi modules feature was using java interface that inherits Mvp4gModule, this approach was not working. It keeps compile all modules that exist (or registered in root module). Is there any way to only compile the root module and one selected child module? Of course without comment and uncomment the child modules registration in root event bus.

Any suggestion and comment will be appreciated.

Thanks and regards.

[Frank Hossfeld]

Sorry for the delay.

Before I answer, I wanted to look into it. And yes, you are right, as long as your childmodules are referenced in the eventbus, the compiler will compile all childmodules. The only way to avoid this, is to comment the child modules in the eventbus. This behavoir is implemented in the Mvp4gConfigurationFileWriter. All child modules will be created during the start of the application and because of this, the compiler has to translate all the code. 

I see no chance to avoid this behavior with a quick fix.

Looking into the future this might be a good feature request for the next version of mvp4g. I have started implementing it. This version will have a eventbus interface similar to the current version, but uses an eventbus internally. This will decouple the modules, so that it might be possible to work with modules by just adding them in the module descriptor. 

[the.wizard]

Hi Frank, 

Thank you for your reply. Yes, I think this could be a good feature, since more GWT development will use Super Dev Mode, this requirement is a must. We really need to split our module for development and for production to keep our developers productivity. 

Comment and uncomment the child module registration in root module is not really a good choice, since it could lead us to another problem when we forgot to uncomment our child module registration and build the project for production deployment. 

I wish mvp4g could provide us a better way to configure child module registration beside writing it down in root event bus, something like configuration from gwt.xml file would be a good start. 

Thanks and regards. 

[Frank Hossfeld]

Changing the child module handling has a huge impact for the current implementation of mvp4g. So I think I will add it to the feature requests of the next version of mvp4g (which will also work with GWT 3).  

[the.wizard]

Should I write down this feature request to a wishlist? If so, could you please give me the link? Thanks and regards.

[Frank Hossfeld]

I will open a new thread during the next days to collect feature requests for the next version. Also I would like to see, which parts of current version of mvp4g should be in the new version. 

In the future there will be two versions of the framework. The current version to support existing programs and the next version which will support GWT 3.0. The new version will have significant changes in the implementation and I think some parts of the framework will not survive. To get this parts defined, it would be good, to start a new discussion. 

 

[the.wizard]

Ok Frank, please let me know when you have open a new thread for a new discussion. I would love to write it down my request in that new thread.

Thanks and regards.

[Frank Hossfeld]

I have opened a new discussion at the beginning of the group.