At 09:47 AM 11/1/00 -0600, you wrote:
>Hello all, I was thinking about project management in JDE, and wanted to
>share my thoughts around.
>
>The current project management paradigm in JDE seems to be _implicit_ : ie,
>simply visiting a file in a project causes the project to be loaded. This
>can be annoying; sometimes you are just visiting a file to browse around,
>and -- whoops! -- JDE loaded up the associated project file.
>
>This paradigm seems unorthodox when compared with the normal IDE project
>management paradigm, which normally goes something like this:
>
> File Menu -->
> Open -->
> Project -->
> [ Directory Tree GUI ] -->
> Select project
> <<Project loads>>
>
>Here project loading is _explicit_. Similarly, when you want to close a
>project down ( with the idea of loading another ), you do a
>
> File Menu -->
> Close -->
> Project
>
>And all of the files associated with the project will disappear from the
>IDE. In JDE, you _can_ do a JDE --> Project --> Load Project File, but the
>buffers associated with the previous project are still lying around.
>Annoying!
>
>I guess what I'm trying to get at is it would be nice if the JDE project
>manangement environment was more industry-standard IDE-like.
>
I am in the early stages of developing a new project management system for
the JDE. My idea is that the new system would exist as an alternative, not
a replacement, for the current prj.el system. The new system would have the
following new features.
* The project file for a project could be located anywhere.
* The project file would explicily list all the source files.
* 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.
* Automatic creation of skeleton projects for standard project types:
application,
applet, library.
* Automatic build of projects, with the ability to select two basic types
of builds:
debug and release.
* Selectable build engine: either GNU make or ant.
* Automatic package maintenance features, such as copying a package
from one place to another in the package hierarchy.
* Automatic building of javadoc and javahelp files for a project.
* 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.
* Project options set in text dialog boxes, instead of in an Emacs
customization buffer.
My plan is to release this new system incrementally as a series of JDE
2.2.7 beta releases in order to give JDE users an opportunity to try out
the various features and recommend improvements or modifications. I see
this project has being on the same order of magnitude as the first
implementation of JDEbug, taking about as long (6-8 months). When it is
done, I plan to revisit JDEbug and give it a thorough overhaul.
At the moment, I am in the midst of another JDE-related project, namely
converting all of the JDE documentation to XML. I am doing this because
this will allow me to generate HTML, info, and pdf versions of the
documentation from a common source.
I would welcome everybody's suggestions and comments on these plans plus
any help you can give me in implementing them. Detailed design specs, for
example, would be very helpful, e.g., what options should be on the project
menu, what should the directory structure of a skeleton project be and
should this be configurable, etc.
Regards,
Paul
