Community
Participate
Working Groups
The super classes for Project wizards exist twice. Code has been duplicated: PluginTemplateProjectWizard.java PluginProjectWizard.java I propose to refactor. Eliminated code duplication, pull up a new abstract class into org.eclipse.amp.amf.ide.
Created attachment 193236 [details] Proposed refactoring This is the poposed refactoring. This includes the "newProjectWizardConfigurations" extension point having to be moved to org.eclipse.amp.amf.ide. Code duplication will be eliminated.
I *think* there might have been a reason that I had to do things this way at the time. Something to do with not creating un neccessary dependencies. Ah... I think it is because we use the same technique for creating new Ascape projects and there shouldn't be any AMF dependencies there. IOTW, you should be able to work with Ascape and Escape java projects without having to have any of the AMF stuff. Is there a way to still support that?
All right. I still think code duplication is a bad idea. So how about this... Keep generic Wizards in org.eclipse.amp.amf.gen.ide. Move EscapeJavaPluginProjectWizard to org.eclipse.amp.escape.amf.ide (instead of org.eclipse.amp.escape.ide). Now, there might still be a problem in org.eclipse.amp.escape.testing.ide. EscapeJavaPluginProjectWizard is not available in this plugin anymore. Should it? (In reply to comment #2) > I *think* there might have been a reason that I had to do things this way at > the time. Something to do with not creating un neccessary dependencies. Ah... I > think it is because we use the same technique for creating new Ascape projects > and there shouldn't be any AMF dependencies there. IOTW, you should be able to > work with Ascape and Escape java projects without having to have any of the AMF > stuff. Is there a way to still support that?
Created attachment 193331 [details] Proposed refactoring
Forgot to mention this: This refactoring will cause no new dependencies. Ascape still has no dependencies to AMF! Sometimes code speaks more than thousand words. I've attached a patch...
(In reply to comment #3) > All right. I still think code duplication is a bad idea. So how about this... Agreed. > > Keep generic Wizards in org.eclipse.amp.amf.gen.ide. Move > EscapeJavaPluginProjectWizard to org.eclipse.amp.escape.amf.ide (instead of > org.eclipse.amp.escape.ide). But that means that Escape (Pure Java Version) still has a dependency on AMF. == not good because we want people to be able to create pure Java projects. Worst case, I think we'll have to move this into a little separate project of its own.
Ok, I see. The greatest common denominator in the AMP universe between "org.eclipse.amp.amf.ide.ascape" and "org.eclipse.amp.escape.amf.ide" seems to be "org.eclipse.amp.amf.gen.ide". Including "org.eclipse.amp.escape.ide" I think it's "org.ascape.core". And that one shouldn't have any user interface. In that case I only see the solution of a new plugin. One more again, but still better than duplicated code. Another idea... I can see that only "org.eclipse.amp.escape.ide" requires "org.ascape.ui.amp". How about moving all basic project wizard classes into this plugin and make "org.eclipse.amp.amf.ide.ascape" and "org.eclipse.amp.escape.amf.ide" dependent on "org.eclipse.amp.escape.ide"? (In reply to comment #6) > (In reply to comment #3) > > All right. I still think code duplication is a bad idea. So how about this... > > Agreed. > > > > > Keep generic Wizards in org.eclipse.amp.amf.gen.ide. Move > > EscapeJavaPluginProjectWizard to org.eclipse.amp.escape.amf.ide (instead of > > org.eclipse.amp.escape.ide). > > But that means that Escape (Pure Java Version) still has a dependency on AMF. > == not good because we want people to be able to create pure Java projects. > Worst case, I think we'll have to move this into a little separate project of > its own.
(In reply to comment #7) > Another idea... > I can see that only "org.eclipse.amp.escape.ide" requires "org.ascape.ui.amp". > How about moving all basic project wizard classes into this plugin and make > "org.eclipse.amp.amf.ide.ascape" and "org.eclipse.amp.escape.amf.ide" dependent > on "org.eclipse.amp.escape.ide"? Yes, that makes sense! I think.. Obviously if this creates any circular dependencies you'll see them. BTW -- in case this is confusing -- the amp.amf.ide.ascape stuff is to produce non-Eclipse based Ascape model code. For example, you can create a model applet w/ approximately 8MB code base. But as long as we don't introduce any runtime dependencies that won't be a concern.
Created attachment 193583 [details] Proposed Refactoring All right. Here's another try. Done as discussed above. I think this way we could get around introducing a new plugin...
Proposed changes committed to repository.
Committed bug fix.
