At 05:51 PM 6/29/00 -0700, you wrote: >Hi Paul! > >I was wondering whether you had any suggestions for incorporating the JDE >project file into a project with multiple developers under RCS. We are quite >taken with the project file, but are distraught that we can't figure out how to >incorporate it in this scenario. > >We have a vanilla source repository with RCS subdirectories and are using emacs >as the source control interface. Unfortunately, we haven't been able to devise >a scheme to retain developer-specific project settings when more than one >person works on the files in one location. This is a fairly pressing need >for sandbox compilation, among other things. I'm not sure what the problem is. Here at the Mathworks every developer has their own sandbox. We use RCS and Emacs and have scripts that create a sandbox by checking the source files out of the sandbox. MATLAB, our main product, is a combination Java, C, and M (our own language) application. I keep my own copy of a prj.el file for doing MATLAB Java development. Whenever I recreate my sandbox version of MATLAB, I copy the prj.el file with all the appropriate settings for MATLAB development into the root directory of the MATLAB Java source. I always create the sandbox at the same directory location on my file system so I never have to modify the prj.el file. This works quite nicely for me. I realize this scenario may not work for you. Please let me know exactly what scenario you would like to have for team development and why each developer maintaining their own prj.el file would not work in your case or what would be more convenient. >The JDE user guide says the >project file is loaded just before the jde-mode buffer is created, so I tried a >substitution approach (dummy prj.el loads real prj.el based on environment >variable), but couldn't get this to work (which may be due to my almost >nonexistent lisp skills). The jde-mode buffer is created by the jde-mode command, which is a Lisp function. The last two things that this function does is load the prj.el file, if found, and the load any jde-mode hook functions that are present. >I also was hoping that setting the >vc-follow-symlinks variable would trick JDE into using the project file in the >sandbox directory, but it seems to wait until the real file is resolved before >looking for a project file. > Hmm, perhaps you are using the sandbox approach where the sandbox is all symlinks except for files that the developer checks out. This is the approach that my previous employer used. At the Mathworks, a sandbox is created by copying the entire source hierarchy. There are no symlinks. Even in this case, there must be a root directory for the sandbox that is real and not a symlink and if each developer put his or her private prj.el file in the real root directory, the JDE should find it. >I read a post on the list from a while ago where you mentioned a project system >under development. > > Is that true and if so have you considered this issue? Yes, I am planning to add a hierarchical project system that would permit true inheritance and overriding of project settings. The system would allow the file that stored the project setting to exist anywhere. It would not have to be in the source tree. > I'd >be interested in any ideas you have that would help me keep the project file >functionality. I'll probably rely on individual .emacs files for the time >being if there isn't an easy solution, but as more multiple-developer projects >come our way, we'll be increasingly interested in the project file as a means >to manage the individual developer settings. Here is one possible solution that would be easy to implement. I add a new customization variable jde-project-override-files that consists of an association list of project file names and project override files. After it loads a prj.el file, jde-mode knows the name of the project. So it would check to see if the current project is mentioned in the override path list. If it is, it loads the override file. Here is how this would work in a multideveloper project. 1. The RCS repository contains a master prj.el file that is included in each developer's sandbox. The master prj.el file contains generic settings that apply for all developers. 2. Developer A creates a sandbox for say the foo application. 3. Developer A opens any Java source file from the foo sandbox. This effectively loads the generic settings from the master prj.el file. 4. Developer customizes any JDE variables that needs to be changed for his sandbox, and saves the values in his .emacs file. 5. Developer A then cuts and pastes the customizations into an override file, e.g, project_foo_overrides.el, and saves the override file in any convenient location, for example, in a jde_overrides directory in his emacs directory. 6. Developer A customizes jde-project-override-files to include the association (foo . /home/developerA/emacs/jde_overrides/project_foo_overrides.el) and saves the customization in his sandbox. Now whenever Developer A opens a Java source file from his foo sandbox, the JDE first loads the master prj.el file with all the generic settings and the loads the overrides file from the overrides directory. Note that it's possible that the overrides file could be created by a simple shell script, avoiding steps 4 & 5 in the above scenario. This proposal is a hack and requires some setup on the individual developer's part but it should work and could serve as stopgap until I can get something more elegant implemented. I'd like feedback from you and others before going ahead to implement this. - Paul
