> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On
> Behalf Of Nic Ferrier
> Sent: Wednesday, November 01, 2000 1:35 PM
> To: [EMAIL PROTECTED]
> Subject: Re: JDE Project Management
>
>
> >>> 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 agree. I have no interest in a "project IDE". I greatly dislike having
to add files that are already in a Java package that makes up the "project".
This is one of my peeves with products like Cafe and JBuilder.
>
> 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.
Not everyone on a project may use Emacs and JDE, so they may object to this
extraneous info for tools they do not use. And I do not like things like
this in source files for non-compiler tool direction.
>
>
> >* 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.
I agree the project context switch with debugging needs changing. I am
afraid of this "project" concept for the files ruining a fast, easy
environment.
Paul - can you explain this item more? Are you thinking of a list being
manually maintained - the "add a file to the project so it is considered"?
I hope I am misunderstanding something...
> >* 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).
or Odin?!
> >* 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.
Handling configuration/settings like this is great. Default settings that
are settable per project is perfect.
Perhaps use XML for the format of the config files?
> 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
>
