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
