> I am in the design phase of a application that will be deployed on different > offices, each one with almost equal workflows, automatizing, staff and > requisites. Yeah, that "almost" sucks. The idea is to get one big common or > default subset, build some kind of plugin / extension / delegation system > for the specific and deploy different builds without forking the codebase. > That forking should be a nightmare. > > So, your way was the initial idea, and in our project fits. But some kind of > dynamic plugin loading and upgrading, without touching the core install is > ideal, and a very powerful tool. For example, you can do per user plugin > configs. >
But is the dynamic plugin idea to compile each plugin as a seperate gwt-module (compilation unit)? If this is the case the end-user would need to download duplicates of the JRE-emulation (and other common and shared classes/code) which would not be an ideal solution. I will make a server-side framework which manages the deployment of the GWT application, as mentioned it will take minutes to recompile and deploy the updated gwt application after the plugin configuration has changed, but that is not a problem as the idea is not to have different users have different plugins but rather different offices/client of the application. /Andreas --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
