Bugzilla – Full Text Bug Listing
| Summary: | Project explorer should show System Libraries (eglars) for a project | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Paul Harmon <pharmon> |
| Component: | EDT | Assignee: | Song Fan <songfan> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | jinfahua, jspadea, pharmon, songfan, svihovec, tww, xiaobinc, zhuzhi |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | EGLAR EXPLORER | ||
| Bug Depends on: | 377140, 377139, 377589, 377590 | ||
| Bug Blocks: | 347001 | ||
|
Description
Paul Harmon
Paul, could you elaborate on this? I traverse EGL project in Navigator view, does not see where System Libraries is. What consist of system libraries for a project? just edtCompiler.eglar ? The system libraries are all the eglars and mofars that come with the compiler, more than just edtCompiler.eglar (for example there's some for SQL and IBM i support). A project has an ICompiler set on it and that will tell you the system environment. We should not be adding this display to the Navigator view, just Project Explorer. You don't see System Libraries yet because it needs to be added. I mean currently where can we found those system libraries in OS folder, not related to IDE. Do you mean we need to add an entry to .eglpath similar to: <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> and show system Libraries in 'Project Explorer' view, similar to 'JRE system library' in 'Project Explorer' view. After showing system libraries in Project Explorer, do we have requirements to open its IR file in some kind of editor? The current set of eglars and mofars are: org.eclipse.edt.mof.eglx.persistence.sql/egllib/sql.mofar org.eclipse.edt.mof.eglx.services/egllib/services.mofar org.eclipse.edt.mof.eglx.jtopen/egllib/jtopen.mofar org.eclipse.edt.mof.egl/lib/egl.mofar org.eclipse.edt.compiler/lib/edtCompiler.eglar org.eclipse.edt.mof.eglx.jtopen/egllib/jtopen.eglar org.eclipse.edt.mof.eglx.jtopen/egllib/externalTypes.eglar You shouldn't be adding any new entries to .eglpath, the compiler setting is a project-level preference in the .settings/ directory. This enhancement doesn't change settings, it just uses the settings to display the system libraries in a usable manner (so the user can see what's included in the system parts, open the contained files in readonly editors, etc). The system .eglar files displayed in the project explorer should act exactly like user defined eglars in this view. They should be expandible to show the IRs and when selected, should bring up a read/only editor showing the source or some other R/O information about the IR. The .mofar files are only interesting to developers who wish to extend the language in some way. It may be useful to provide a filter to hide these files for the common user. In RBD, we had discussed adding an entry for the system libraries into the .eglpath file (similar to the JRE library entry for the java .classpath), but I dont think this is relevant to EDT, (as Justin pointed out), the system EGLARs are contributed via the compiler and are not changeable in the project properties. Another question is from system we cannot get source code for those system libraries, should user attach them manually if they want to see source code for those system libraries? or some other way? (In reply to comment #8) > Another question is from system we cannot get source code for those system > libraries, should user attach them manually if they want to see source code for > those system libraries? or some other way? I think the following 3 solutions could be provided: 1. Add the EGL source files into the same folder with IR files in the EGLAR file when making the EGLAR file. For all system library EGLAR files, we need to add all source files into the EGLAR files when making the EDT build, and then it is easy to find the coresponding source file. The export wizard and the EGLAR set up wizard in EGL build path window are NOT needed for this solution. 2. Attach a folder which contains all EGL source files to an EGLAR file 3. Add the EGL source file into a zip file, then attach it via a wizard For 2&3, we need to design a specification about the mapping between source file and IR file. We also need to modify the EGL Build path to show the system EGLAR, and a wizard to attach the source code zip file/folder. I prefer to implement solution 1 at first in 0.8.1 I1 because I think solution 2&3 are more complex than solution 1, solution 1 is enough to meet the requirement about "Make F3 work for system parts". For solution 2 & 3, we can implement them later if we think it is valuable to customer and more EGLAR feature need to be introduced into EDT. I mostly agree with Fan's comment. I like #1 the best for now, and we can add source attachment in the future, once the rest of the eglar support is stable.
> We also need to modify the EGL Build path to show the system EGLAR.
Are you talking about modifying the .eglPath file, or modifying what gets displayed in the EGL Build Path property page? I'm okay with displaying the system eglars in the property page (as non-modifiable), but the .eglPath file should not be modified for them.
I agree with putting the source files in our system Eglar files for now, assuming the EGLAR specification allows for this.
To be clear, I had the following project explorer enhancements in mind:
Project1
EDT System Libraries <name tbd>
edtCompiler.eglar
jtopen.eglar
externalTypes.eglar
With each one of those eglars being expandable to show the types.
Agree with comments from Brian and Justin, one question from me: if we do not add those system libraries to egl class path, can we search those libraries? I am not sure of this, just speak it out. (In reply to comment #11) > I agree with putting the source files in our system Eglar files for now, > assuming the EGLAR specification allows for this. > > To be clear, I had the following project explorer enhancements in mind: > > Project1 > EDT System Libraries <name tbd> > edtCompiler.eglar > jtopen.eglar > externalTypes.eglar > > With each one of those eglars being expandable to show the types. Brian, for display structure of system libraries, Fan,XiaoBin and I also has discussion about it,and what you described here is what we want, in a word, the display structure of EGL system libraries will be similar to that of Java system libraries. > > We also need to modify the EGL Build path to show the system EGLAR.
>
> Are you talking about modifying the .eglPath file, or modifying what gets
> displayed in the EGL Build Path property page? I'm okay with displaying the
> system eglars in the property page (as non-modifiable), but the .eglPath file
> should not be modified for them.
Hi Justin,
I mean "modifying what gets displayed in the EGL Build Path property page"
If we select solution 2&3, we need to modify the EGL Build Path window in the property page to let it show all system eglars so that developer can select one eglar and then attach the source code.
I would like to use an example to clarify the EGLAR structure: egl.mofar -->META-INF -->egl ----->lang ------->reflect ----------->Interfaces.mofxml ----------->Interfaces.egl ----------->DefaultSuperType.mofxml ----------->DefaultSuperType.egl Hi Justin, If you and others agree with the structure design, would you please add the egl source code in the EGLARs when making the EDT build? Thanks very much for your help! Song Fan I have a question for readonly source editor to get the source file from *.eglxml. In EDT: Most of *.eglxml have "fileName" field which contains the source file path if the part name is not same with part name. like event.eglxml <ExternalType ID="1" eClass="org.eclipse.edt.mof.egl.ExternalType" name="Event" fileName="eglx/ui/rui/ExternalTypes.egl" hasCompileErrors="false" packageName="eglx.ui.rui" isAbstract="false" > But there are some *.eglxml do not contains this information. e.g. ruiHandler.eglxml <StereotypeType ID="1" eClass="org.eclipse.edt.mof.egl.StereotypeType" isAbstract="false" isInterface="false" validationProxy="org.eclipse.edt.compiler.binding.annotationType.RUIHandlerAnnotationTypeBinding" name="RUIHandler" hasCompileErrors="false" packageName="eglx.ui.rui" referenceType="false" defaultSuperType="egl:eglx.ui.rui.view" > does not has the source file path information. The ruiHandler was defined in "eglx/ui/rui/ExternalTypes.egl" source file. So my question is : How to get the source file of a *.eglxml in EDT? Thanks xiaobin The ruiHandler was defined in "eglx/ui/rui/Stereotypes.egl" source file. Okay, lots to respond to in this thread... Comment 12: That's a good question, and off the top of my head I'm not sure (I can justify both "yes" and "no"). Comment 14: How would a user attach source to the eglars? There is no entry in .eglPath. Maybe we don't make this option available, but include source in the EDT system eglars so that it's not necessary, and anyone who writes their own compiler extensions could do the same if they want the source available to the tooling. Comment 15: I think it would look better if we displayed the eglars/mofars in package format instead of directory format, like what you see under "EGLSource". For example: egl.mofar -->META-INF -->egl.lang.reflect ---->Interfaces.mofxml Please open a separate bug (against Compiler) to add the source to the eglars/mofars. Comment 16: All compiled IRs (meaning non-bootstrapped IRs) should have the fileName attribute set, so what you pasted looks like a bug (please open one). (In reply to comment #18) > Okay, lots to respond to in this thread... > > Comment 12: That's a good question, and off the top of my head I'm not sure (I > can justify both "yes" and "no"). From Paul's comment in bug 376476, we need to add EGL system libraries to EGL class path. (In reply to comment #16) We need to add a filename field to AnnotationType, please open a bug (as Justin suggests in comment #18. It looks like enumerations have a problem (look at the IR for FilterKind). The fileName is there, but there is not location information. The IRs from the .MOFAR do not have filename information in them either, but I dont think we want to add a field for this to EClass. If we decided not to display the .mofar files in the project explorer, then there is no problem. Otherwise we will probably have to add the filename as a metatdata object to the MOF type IRs. (In reply to comment #20) > (In reply to comment #16) > We need to add a filename field to AnnotationType, please open a bug (as Justin > suggests in comment #18. It looks like enumerations have a problem (look at the > IR for FilterKind). The fileName is there, but there is not location > information. > > The IRs from the .MOFAR do not have filename information in them either, but I > dont think we want to add a field for this to EClass. If we decided not to > display the .mofar files in the project explorer, then there is no problem. > Otherwise we will probably have to add the filename as a metatdata object to > the MOF type IRs. Paul, I have opened a defect for it:377590 resolve verified |