>>> Paul Kinnucan <[EMAIL PROTECTED]> 01-Nov-00 6:24:39 PM >>>
Your ideas sound cool... I'm not sure about using a traditional IDE
viewpoint. Trad IDE project management grew out of poor make
implementations. I personally don't like that approach (make for Java
just doesn't work IMHO).
I've made some comments on your mail:
>* The project file for a project could be located anywhere.
This is a big problem of the current system but could be solved by
having a per-file setting for the project file... this would be an
automatically inserted config comment at the beginning of the file,
eg:
/* -*- project-file: path -*- */
I don't think that's too onerous a change.
>* The project file would explicily list all the source files.
This *is* traditional IDE. I prefer the current system of finding
files dynamically. It would be good to have an exclude pattern to
exclude files or directories from compiles and such like.
>* Projects must be explicitly opened and closed and only
>one project can be open at a time. This simplifies debugging
>by not triggering a project context change when stepping
>through code belonging to different projects.
Yes - the context change when editing code is a great big pain. It
would be good if the debug mode could stop context changes from
happening.
Another pain with debug is that you have to carry around a whole
bunch of standard source directories in every project file... it would
be usefull to have a .emacs or site-lisp default that could then be
appended to by project specific directories.
>* Automatic build of projects, with the ability to select two
>basic types of builds: debug and release.
I like that idea a lot!
>* Selectable build engine: either GNU make or ant.
See my mail a few hours ago... a lisp fn for doing compilation would
be great... I don't use eitrher of these compilation systems (both are
flawed IMHO).
>* Automatic building of javadoc and javahelp files for a project.
Another good one.
>* Master project files. Every project file would be an instance
>of a master project file.
> Instances can override settings in the masters. Changes in the
>master propagate to the instances unless overridden. This is
>intended to facilitate team development.
It would be good to have this feature with the existing system... it
would be analternative to what we've been talking about in terms of
defining defaults in .emacs or site-lisp.
I've been using JDE for quite a while now and I've spent a bit of
time hacking it to make it work for me and my requirements (team of
web developers working with servlets)... but I've never really had the
time to formalise the stuff I've done and make it usable but this
thread has galvanised me - I'll see if I can hack this stuff
together.
Nic
