Ahh, here's your problem, you need to learn to write prj.el files with
everything setup using elisp variables. I've got some prj.el files that I
put in the source repository and just have all the developers define a root
for each project and the prj.el automatically works. Let me know if you
want me to send you one.
> -----Original Message-----
> From: Nic Ferrier [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 01, 2000 11:11 AM
> To: [EMAIL PROTECTED]
> Subject: RE: JDE Project Management
>
>
> >>> "Schewe, Jon (MN65)" <[EMAIL PROTECTED]> 01-Nov-00
> 3:56:54 PM >>>
>
> >You're making the assumption that the users of JDE like
> >the industry standard for IDEs. This is not always true.
> >Personally I like to be able to just open up a java file and
> >the classpath etc. is set correctly for that buffer. This is
> >very helpful when I work on multiple projects at once with
> >different classpaths. I don't have to close a project and
> >open it, I can just switch buffers.
>
> Yes... but there are weaknesses.
>
> When you start a new project you have to fill in a whole load of
> stuff multiple times.
>
> For example: source directories, compilation directories, etc... they
> all have a common root which you have to enter over and over again.
>
> I would like the JDE to offer a sort of "project root" directory
> which got refered to by all the other bits and pieces by some
> convention.
>
> Auto-discovery of that project root would be a nice feature... the
> JDE could do that by looking at the package statement of a file it was
> producing a project for and checking the packages against the
> directory structure... the top of the package structure would be the
> suggested project root.
>
> If the app could guess a project root it could also guess some
> defaults for other variables..
> eg:
> - classes destination would be ${PRJROOT}/dest
> - documetation would be: ${PRJROOT}/docs
> - classpath could be worked out by scanning for jar files in certain
> directories
> etc...
>
> One way to achieve this might be a set of defaults that the JDE could
> use site wide. They could be specified in .emacs or site-lisp files.
>
> The other thing that JDE project management is weak at is different
> compilation methods. I use a batch compilation method that works by
> collecting together all the files for compilation and doing:
>
> javac -classpath LIST -d destination @filelist
>
> This is easier to organise than using Makefiles but is a pain to
> integrate into the JDE (I rewrote the compilation routines to do it).
>
> I'd like to see some compilation hooks used so that it would be easy
> to implement this sort of functionality.
>
> eg jde-compile would become:
>
> (execute
> (compile-hook
> project-compiler-name
> project-classpath-list
> project-destination-dir
> target-filename)
> )
>
> (compile-hook) would be required to return a compilation command
> line.
>
> target-filename would be the filename to be compiled if a single file
> or "/" (or some other indicator) for a mass build.
>
> The Makefile stuff could then be removed from most of JDE and
> re-written as a hook which could be turned on or off by a preference.
>
>
> Perhaps I should do something about this /8->
>
>
> Nic
>
