Re: Regexp on sourcepath possible?
At 12:58 AM 3/15/2005, Paul Kinnucan wrote: Ole Arndt writes: Hi Lars, But I'm curious as to what kind of a project structure would make regular expressions in source paths useful. The structure that I have at work is one such. We have multiple subprojects side by side: source project1 prj.el com/foo/project1 *.java project2 prj.el com/foo/project2 *.java ... project17 prj.el com/foo/project17 *.java products similar tree with class files Some projects depend on others, but the dependency graph is non-cyclic, so we build and test project 1, then project 2 and so on. Each prj.el sets jde-sourcepath to . and jde-global-classpath to include ../products/projectName/directoriesWithClasses. Which works, except when I try to jump to a source file in a different subproject. What I'd like to do is set jde-sourcepath to (. ../*) but instead, I have to manually do (. ../project1 ../project2 ... ../projectN-1). Which eventually gets built up in each prj.el. And we frequently add more projects, so even if the list is complete, that's only a temporary condition. Whether this is a good coding practice is debatable, but it is what we do. Finally, to handle a path specification like: */src/java the JDEE would have to cycle through every directory on your system, appending /src/java to it, testing whether such a directory exists, and then searching that directory for the source file? Seems like a pretty time-consuming operation that might make finding and opening source files a very slow process. I'd be happy with just something that expands * like a unix wildcard. So */src/java woudn't be the equivalent of a unix find command, but more like the equivalent of ls */src/java. Troy Paul Just be sure to never save your project files with jde-save-project, or you will lose your changes. I have written myself a small module for a related purpose: Read the dependencies from a maven project.xml file and build the jde-global-classpath from this information. My .prj.el files now typically look like this: (setq pom (pom-read-pom)) (jde-set-variables '(jde-global-classpath (pom-get-classpath pom)) '(jde-project-name (pom-get-project-id pom)) '(jde-sourcepath (quote (./src/java ./src/test I have, of course, also a prj.el file for all my default settings in my top level source directory. Ole -- Ole Arndt http://www.sugarshark.com Troy Daniels [EMAIL PROTECTED] 781-273-3388 x218
Re: Regexp on sourcepath possible?
At 12:58 AM 3/15/2005, Paul Kinnucan wrote: Ole Arndt writes: Hi Lars, Lars Degerstedt [EMAIL PROTECTED] writes: Also, I've never understood the big attraction of having to manually find and open a project file, edit it, and then save it, an error-prone and tedious process. Not my idea of a good time but, heck, to each his own. Why do we use JDEE at all instead of just using the customize interface to make emacs perform like we want to? Because there's no option that turns on all the functionality we want. I generally edit prj.el by using the customize interface, but I'll sometimes edit prj.el directly. There's a few cases where I do this, which probably indicates my wish list of prj.el enhancements. I'm copying a prj.el file to a new but related project. I want most of the settings to be the same, but there's some points where the project name is hard-coded. M-x replace-string is actually better than jde-customize-variable, because I know I won't skip a variable. I want to run the program with a different set of arguments, but be able to swap back to the old arguments. Generally, this involves changing the arguments passed to junit.textui.TestRunner from package.SmokeTestSuite to package.NightlyTestSuite. I copy the old value to a comment, and then (usually) uncomment the value from the last time I did this. I want to turn on profiling or remote debugging, so I want to comment/uncomment a fairly complex set of arguments and not have to remember how I set them. Of course, there's always the alternative of proposing a change to the JDEE to enhance the customization interface to support features that you need, e.g., providing the option to specify a function to compute jde-sourcepath or as in this case regular expressions. This is the better long-term solution, assuming somebody has the time and knowledge to implement the solution. Troy Troy Daniels [EMAIL PROTECTED] 781-273-3388 x218
Re: Regexp on sourcepath possible?
But I'm curious as to what kind of a project structure would make regular expressions in source paths useful. Well, perhaps it is not. My problem is that I have ceveral projects that I want to keep separate, but also be able to collect them in one place and compile them all. The reason is that they have two kinds of developers: one like me that are engaged in all/most of them and one type that only looks at a particular project. One way would be to merge the src-trees, but I thought (for CVS-reasons mainly) that it would be better to keep the src-trees as they look in when distributed separately. I can do this with my ant-script, so it works fine on the build-level. And also generate jar-archives etc. But then I thougth that it would be nice to have a common prj.el for the all-projects-developer so that you can work in paralell on many projects, such as if they were one. I agree with you that it is perhaps not the most effecient way to do it by kleene-star...but in my case I don't think it matters so much. Typical number of present projects during development is max 5-7 I would think. Thanks for the respons. Lars
Re: Regexp on sourcepath possible?
Hi Paul, Paul Kinnucan paulk at mathworks.com writes: Ole Arndt writes: (jde-set-variables '(jde-sourcepath (mapcar (lambda (path) (expand-file-name src/java path)) (directory-files I think the directory-files function requires an argument that specifies a directory. This highlights the advantage of using the awkward customization interface; no programming errors. Your are right, directory-files requires an argument. . will do. Please understand that I perfectly agree with the advantages you name for using the customization interface. I could name a few more, i.e. you get an overview of all variables you can change, along with nice explanations in the doc strings. But sometimes it just isn't good enough. And then I resort to some lisp programming. Also, I've never understood the big attraction of having to manually find and open a project file, edit it, and then save it, an error-prone and tedious process. I just find it sometimes more convenient to do: (find-file (jed-find-project-file .)), edit, save, (jde-load-project-file)' especially if you have bound these commands to keys already, than to call: customize-variable jde-..., where is the mouse again, click, click, click, ^C^V^S. Not my idea of a good time but, heck, to each his own. You say it :-) Of course, there's always the alternative of proposing a change to the JDEE to enhance the customization interface to support features that you need, e.g., providing the option to specify a function to compute jde-sourcepath or as in this case regular expressions. That is an thing I missed several times, the possiblity to specify a function to compute the customization value on the fly, depending on context. But there are also cases where you want to execute arbitrary lisp code in the project files. Consider my example: (setq pom (pom-read-pom)) (jde-set-variables '(jde-global-classpath (pom-get-classpath pom)) '(jde-project-name (pom-get-project-id pom)) '(jde-sourcepath (quote (./src/java ./src/test The function pom-read-pom does some rather expensive xml-parsing and property file reading. You dont wan't to do it more often than necessary. So I save it in a variable and pass that to the other functions. I have no idea how to do this with the customization interface. Currently, the JDEE preserves additional code in the project file, but puts it at the end of the file. Can't we just insert jde-set-variables as the last command? That would make this kind of setup code work together with jde-save-project-file. But I'm curious as to what kind of a project structure would make regular expressions in source paths useful. In our case the structure of the sources is dictated by the use of two tools: maven and Eclipse. The gros of the development team is using eclipse and needs to have all projects in a single 'workspace' directory. Our nightly build works with maven, which has a project.xml file for each project, describing the project and its dependencies. The structure looks like this: workspace/ prj.el (defaults) project1/ project.xml prj.el (read classpath from project.xml) src/ java/ test/ target classes test-classes ... project56/ ... where every project can depend on the jars generated by other projects. Ole
