Community
Participate
Working Groups
EDTRuntimeContainerInitializer.initialize adds the JavaRuntime to the project's classpath. This needs to be made extensible so feature plugs can contribute their runtime jars to the project's classpath.
There is much less work here than you might think. What you need to do is allow for the contributions to a generator to also provide runtime containers. It would make sense to change AbstractGenerator.getRuntimeContainers() to return the generator's containers plus all the containers from its contributions. And then update the contributions to support the concept of runtime containers. The rest should "just work". EDTRuntimeContainerInitializer will use this same method to find out all the containers it should initialize, same with the wizard that lets you manually add an EDT library to the Java build path of a project, as well as the Java generator which adds the containers to the build path if necessary. To see how to define a new container, take a look at EDTCompilerIDEPlugin.JAVA_RUNTIME_CONTAINER.
Created attachment 211631 [details] Patch Hi Justin, here is a patch, please review it. Thanks a lot.
I've modified your original fix. The following were modified: Context.java in edt.gen.java FunctionTemplate.java in edt.java.templates.eglx.jtopen EclipseEGL2Java.java and JavaGenerator.java in edt.ide.compiler AbstractGenerator.java, EDTCoreIDEPlugin.java, and GenerationContributorEntry.java in edt.ide.core plugin.properties and plugin.xml in edt.ide.jtopen Now when you generate a part containing IBMi content, its contributed runtime is automatically added to the Java build path.
verified
