Most popular IDEs are built with modular structure using plug-in which make it easy to control and manage.
|
Plug-in in Intellij
|
Plug-in in Netbeans
|
gwtClassRun as a application works outside the IDE but communicates through a common resource (module descriptor file).
Possibly some will ask why not develop 
gwtClassRun as a IDE plug-in/extension as now it is a popular trend to develop plug-in that work within the IDE leveraging on the environment like auto-update. Initially, the gwtClassRun conceived as a plug-in only to be redesigned as a application. There are many decisions to consider before starting development. In gwtClassRun, among the major consideration includes the ease of IDE plug-in development, time constraint and possibility of porting and extending this feature to other popular IDE. It might be cool to learn and hack new stuff however learning a API takes a lot of time and commitment even though the marketing material will say it otherwise. For example, learning Intellij’s plug-in development takes time to explore and see what possible. In fact, the real thing starts only when one relies on the forum for support rather than on supportive documentation. There always a great contrast between understanding and doing something.
So my reasons for developing gwtClassRun as application:
- time constraint. It costs in term of time and resource to learn something new that does not warrant the investment. Leverage on existing Swing development expertise and experience to create the application as fast as possible.
- Plug-in development takes too much effort and commitment.
- Work with any IDE. Most IDE now having option to automatically detect and accept external changes to file.
- Swing is cool. Contrary to many belief that Swing is bloated, slow and difficult to master, Swing has improved tremendously in term of raw performance. However it takes practice and commitment to learn a flexible and powerful GUI toolkit like Swing just like any other good tool. Once pass that hurdle, Swing can do wonders and amazing thing. I actually prefer to develop Swing application than web application because the full power of desktop capability and function are available without the constriction of by the web technology, and this is done so without using patch or workaround.
- Not affected by major change in IDE. Compatibility issues with plug-in arises when IDE introduce or revamp plug-in architecture, and this will cause plug-in to malfunction, and new version of plug-in must be developed to address the compatibility.
So what’s not with application design:
- no doubt that designing as a plug-in means it knows the current state of IDE since it becomes part of IDE itself. This means that the plug-in can be more intelligent in automating task. For example, the plug-in can detect the active Java Source Window and check if it implements EntryPoint interface, if it does, the plug-in will enable the option of Running the Java Source in context menu or in toolbar, and this is done without user’s intervention. Whereas in application, gwtClassRun does not know about the state of IDE and therefore relies on user to inform it by manually update the database or to switch project manually.
- Not tightly-integrated with IDE.
- Duplicate some features that already exists in IDE. eg AutoUpdate
