Hi Nic,
I agree with you that most projects have similar directory
structure. I had to overcome this problem by having a template prj.el
file which just had the following entry
(simple-jde-set-variables <directory name>
<projectName>)
and copying the prj.el file to each of the project directory and hard
coding values like
(simple-jde-set-variables "/home/kps/projects/test"
"test")
The simple-jde-set-variables function present in the .emacs just sets
the necessary variables
(defun simple-jde-set-variables (rootdir projectname)
"Sets the jde variables according to the root directory of the project"
(let ()
(jde-set-project-name projectname)
(jde-set-variables
'(jde-compile-option-directory (concat rootdir "/classes"))
'(jde-global-classpath (append (list (concat rootdir "/classes"))
(jde-path-string-to-list (getenv "CLASSPATH")))
'(jde-run-working-directory rootdir)))))
It would be helpful if jde itself has the option of
specifying the root directory and template project directory structure.
Also is it possible to know from which file a lisp
function is being called from within that function itself?? So that
instead of hard coding the directory for each project we can take the
root directory from where the prj.el file is present. This will be
helpful when we are moving the project location.
regards,
-kps-
Nic Ferrier wrote:
> >>> "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
