Community
Participate
Working Groups
We allow user to configure generators, but we don't have a design to ensure what they configured would finally work. Think about you have a RUIHandler using a Record, the Record is in a package which only has JavaGen configured. You won't detect this until you run the handler. Even worse, our RUI runtime error messages did not give meaningful information to help user correct this. It say something like object expected. Will also reports that: Created a new 'web 2.0 client with services' project, then created a service in the 'server' package, referenced BoxLib in my service. Save the file - got no EGL source/compile errors, but generated Java has errors. See screen shot.
The first thing come to my mind is to have our Generation Builder check compiler settings for the referenced part of the part being generated. If the referenced part does not have the same compiler setting of the current part. Report generation errors in the source code like we do for other generation errors. Will need have more logic for each part types, for example Service, Interface, External Types probably should be ignored.
I think this is a 1.0 discussion. We have had always had this "problem", so I think we should work on other issues in the .7 time frame. Also, the same problem could happen if a user generates one part, but forgets to generate another part to the same language (i.e. sets no generators, etc). I am also wondering if this is something we could get right all of the time, and if so, how it would perform. Any solution we implement may also need to consider SDK, which has no 'generator configured on a resource'. If we are to do anything, I think a source level solution might be best, where content assist does not allow people to get into this problem in the first place.
This issue was discovered quite quickly in version EDT .7, so we would like to include this in the .8 release for now, if only to start a discussion about how to best to resolve this issue. I don't think I would like to check the referenced parts during generation, but some other ideas include: * An annotation on a part that indicates what languages should be generated for the part, where specific stereotypes can configure specific languages (i.e. RUIHandler for JavaScript only) * Warnings displayed in the new wizards if the target folder doesn't have a generator specified.
This appears to be related to Bug 360973
I'm trying to think of something that needs least user interactions. Does it sound right to cascade the compiler setting of an Entry part(program, service, handler) to all it's references? Do we always need referenced part to be generated with the same setting of the parent? If this is true, then maybe this rule should be a higher priority one then the Compiler setting of each resource. And it probably could be that we only need compiler setting for entry parts. It seemed that (maybe only in RBD) a record not referenced by anything else will even not be generated.
I have been thinking about this issue, and I am trying to remember the exact reasons we did not implement the CE solution in RBD. To provide some background, EGL CE allowed users to specify a default build descriptor for each target language (Java and JavaScript) on each resource in a project (i.e. Project, EGLSource folder, package, and .egl file). When a part was saved, it was automatically generated using the first set of default build descriptors that were found for the part. If the part could not be generated for a particular target build descriptor in the set, the generation request was ignored for that target. Having the generation framework ignore invalid requests meant that all default build descriptors could be specified (in most cases) on the Project, and all parts would be generated accordingly. In some instances, a Library may have been unnecessarily generated to another language, but this was worth the usability improvement. Also, EGL CE did not allow users to invoke generation outside of a Build, with the generation wizard and generate context menus being removed. When we ported the EGL CE concepts to RBD, we added the same support for specifying multiple target build descriptors on all resources, but we did not update the generation process to ignore requests to generate parts for unsupported target languages. This meant that users had to configure their default build descriptors on individual packages instead of placing them all on the project. I believe this decision was made because previous versions of RBD displayed an error message if a part could not be generated to a particular target, and we did not want to 1) hide this message, and 2) have users see this message every time a project was built by default. Another reason for showing the message is so that users are not confused when a part they expect to generate to a particular target did not generate because it contains something invalid (e.g. a Library cannot be generated to JavaScript because it references a Java External Type). In summary, the only difference between EGL CE and RBD is that invalid target types are ignored in EGL CE, and they are not ignored in RBD. In EDT, we adopted a hybrid of EGL CE and RBD, where generation happens during a build and cannot be invoked manually, but the generation options must also be configured on the appropriate packages to avoid getting error messages during generation. I believe this hybrid was 'accidental', and mostly a result of bug 360973 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=360973), etc, where we currently do not gracefully handle parts being generated to an unsupported target language. I would like to propose that we resolve this defect with the following solution: 1) Implement 360973, etc, so that generation fails gracefully when an invalid part type, stereotype, statement, expression, etc, is used for the specified target language. 2) Add a generator preference to provide the following types of messages when attempting to generate a part to an invalid target: Error, Warning, None. The default would be configured as a Warning. An Error setting means the RBD behavior, and the None setting means EGL CE behavior. 3) Update the project wizards to place all default generation options on the project, instead of the individual packages. 4) Add better support for reporting missing types at runtime, since it may still be possible for a user to forget to generate a part to a particular target, or have a part fail 'silently' when generating to a particular target. With this solution, all parts would be generated when possible, at the risk of generating some parts unnecessarily to a given target language. Users could reduce the number of generations taking place by configuring generation options on the individual packages, like we have today, if that is desired. * NOTE: EGL CE and RBD only generated records as a result of a 'generatable part' being generated. In EDT, Records are generated on their own when built.
One more idea comes to my mind - decorate the package icons with different compiler settings. We also need provide a way for letting 3rd party user to customize the package icons. Currently, we have 3 kinds of package icons in EDT 0.8, - Package icon stands for Java compiler settings. - Package icon stands for JavaScript compiler settings. - Package icon stands for Java + JavaScript compiler settings. - Other package icons that will be supported in future...... This way cannot solve the problem discussed in this bug, but it can somewhat improve the usability of EDT. The EDT users will aware of the different compiler settings without need to check the compiler settings, so it reduces the possibility to reference a part that not correctly configured compiler settings.
When there's just one or two decorators on the icon it would be helpful, but what about when there's 5 generators enabled for a common package? Also, as an aside, I've always felt it would be helpful if there was some context menu on the project that pops up a dialog showing all the generator overrides. While it's easy to tell if pkg1.prog1 is overriding its parent settings, there's no easy way to find every place that's overriding without manually checking every file and folder (slow and tedious). Like I said, this is just an aside, and would be a completely separate enhancement, but your decorator idea reminded me of this.
Here is the brief design, guys, please help to give your suggestions. Problem to solve: User always misses or set a wrong generator setting which will cause runtime errors. For example, if user invokes a record in a RUIHandler, the RUIHandler set to JSGenerator and record set to JavaGenerator, it will get error at runtime. User always hard to find the reason of the errors, that will make user confuse. It will be good EDT can detect these kind of wrong setting and give a user a convenience way to current it. Proposal solution: 1. Every generator has to declare what kind of parts it can support. For example, JSGenerator can support RUIHandler, Record …, and can not support Program, Service …. This can be implemented by make all the generators to implement an interface, which provide a call back function that IDE can use to get the support information. 2. Give every part a default annotation to indicate whether it can be used as an entry of the project, for example, RUIHandler, Program, Service are entries; record, library are not entries. 3. IDE will set default generators for the entry parts, user can also change the default generator settings manually. When generating, IDE will start from the entry parts to iteratively traverse the parts referenced by the entry parts and check if the referenced parts have the same generator setting with the entry part. - If yes, go ahead; - If no, report an error in the problem view. 4. User can click the error to bring up a quick fix. IDE will find if there is any support generator same as the entry part generator. - If yes, auto selects the generator with the same of entry part generator. - If no, it means user write a wrong code, for example, invoke a java external type in a RUIhandler, in this case, IDE will give a message to promote user to change the code.
I like the solution Brian proposes in comment #6. It gets us closer to CE, which I liked a lot from a developer experience perspective, and it's less restrictive than RBD. I think the solution also "scales" as others come up with new generators (and new classifiers, stereotypes, etc).
I agree with Will, Brian's proposal seems a lot less complex and requires less intervention by the user.
Created attachment 210491 [details] design doc
Hi, Brian and Will I discussed Brian's proposal with Tony and find it is a better one. I have attached the design doc for the solution in Comment 6. The design doc covered the 1,2 and 3 points of Comment 6, which are all IDE can do. For point 4, I think we need open a new enhancement to generators that need to properly handle the runtime error. For point 1, it also need a enhancement for generators to properly report a suitable message for this case. Brian and Will, could you help to set suitable words in the preference and chose a suitable message id? Thanks
I have created https://bugs.eclipse.org/bugs/show_bug.cgi?id=370555 to track the extensible generator validation framework.
Thanks for putting together this design document. I see that we have committed the change to the new project wizard. I think this should be reverted until bug 370555 is complete, since we currently do not have a good way of dealing with parts being processed by an unsupported generator, and this would easily break users putting Services and RUIhandlers in the same project. We will most likely have to defer this line item until a future iteration.
Yes, Brian, I have reversed the code changes for 370675
Set it to 0.8 after the depend 370555 finished
370555 will not be solved in 0.8, so this one will defer to future after 370555 is finished.
Setting the Target Milestone correctly for all bugs (set to Future in this case).
