Re: Causeway viewing your E-on-CL traces
"Tyler Close" <[email protected]>
| Newsgroups | gmane.comp.lang.e.general |
|---|---|
| Message-ID | <[email protected]> |
Thinking about the source file identification more... On Tue, Aug 5, 2008 at 1:42 PM, Tyler Close <[email protected]> wrote: > On Tue, Aug 5, 2008 at 11:38 AM, Kevin Reid <[email protected]> wrote: >> If they are to be generated relative, what should they be relative to? > > Assume all source code is found under some root directory. The source > path is then the relative path from this root to the source file. This > way, the Causeway viewer can be configured with a single source folder > from which to lookup any source file. For example, the sample events > shown at: > > http://waterken.sourceforge.net/debug/ > > use a source path of > > "source" : "example/src/org/waterken/bang/Drum.java" > > which assumes a root folder under which each project is stored. > > Obviously this means all the source code in a given interaction must > coordinate their chosen project names. The contention on the project name is unfortunate, given that part of the path name already encodes a globally unique identifier. It might make more sense to make the path be: "source" : "org/waterken/bang/Drum.java" and have the Causeway viewer support a source path, which it searches for the corresponding file. For example, Causeway's source path might be "kpreid/src:someother/src:example/src". To find the referenced source code, Causeway looks under each of the folders in the source path to see if it contains a file named by the relative path in the event. I think this would do a better job of decoupling source packages. Thoughts? --Tyler