Why not put the code to set environment variables and other non-JDE
variables inside of the project file itself? It will be executed every time
a project switch happens, because the contents of the project file are
evalled. Thus, there should be no need for defadvice. BTW, the
jde-save-project mechanism is smart enough not to clobber custom code when
the project file is (re-)saved.
A more elegant approach would be if it were possible to prepend and append
entries to classpath-like JDE variables in project files. Then hierachical
projects could solve this problem. One or more higher-level project file
could set the locations of shared dependencies, and lower-level/more
specific project files could add individual dependencies to the classpath.
/Nick
-----Original Message-----
From: Nascif Abousalh-Neto [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 13, 2001 2:07 PM
To: Paul Kinnucan; Stefan Heimann
Cc: jde
Subject: RE: relative paths
We have a large system composed by frameworks and client/server
applications; these individual projects share many library and output
directories, hence the need for deep directory structures.
The point is that the contents of the environment variables must be changed
to reflect the directory/drive mapping of the current project. Just
re-evaluating the environment variable is necessary but not sufficient; a
new value must be calculated (based on the project path) and assigned to the
variable *before* the variable is evaluated by JDE. This is where the
defadvice is helpful; it allows me to do just that.
Here is a scenario:
1) working on project A, PRJ_ROOT variable set to A:/my_proj
2) change to a file in project B
3) project is loaded, triggering defadvice (before load), which changes the
contents of PRJ_ROOT to B:/my_proj
4) environment variables are evaluated to set the jde variables, leading to
the desired B:/my_proj/lib/... paths.
Is there a different way to do that without using defadvice? This approach
also gives you the flexibility to change any other environment variable on a
per project basis, like the name of a log output file, or a temporary drive
or machine name. Things like that can't be solved by relative paths.
Thanks,
Nascif
-----Original Message-----
From: Paul Kinnucan [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 13, 2001 1:51 PM
To: Abousalh-Neto, Nascif [NCRTP:3X50:EXCH]; Stefan Heimann
Cc: jde
Subject: Re: relative paths
----- Original Message -----
From: Nascif Abousalh-Neto
To: Paul Kinnucan ; Stefan Heimann
Cc: jde
Sent: Monday, August 13, 2001 11:56 AM
Subject: RE: relative paths
Hi,
Wow, calm down! I was just trying to help. I was not criticizing JDE
or anything.
Anyway, let's see: yes on a second thought I agree that Stefan's
problem is different then mine, and I agree that creating a prj.el on the
project root is a much less "esoteric" solution. That is precisely how I use
pry.el in my projects. I should have recognized that, I apologize.
But I stand by my assertion that using relative paths can be error
prone in some scenarios. If they start to get too big (six, seven layers)
they become cumbersome and hard to get right, and if you change any
directory strutcture in your project you have to go back changing all
affected relative paths.
In my case in particular - which may not be very common - we use
ClearCase for source control on Windows boxes. That means that I may want to
work on different project trees with the same structure but mapped to
different drives (depending on which release/bug fix/view you're working at
the moment). Yes I could use relative paths, but using defadvice I was able
to use an environment variable to point to specific points in my project
tree. So instead of
../../../../../lib/proj1/jars
../../../../../out/file1.jar
I can have
$PROJ_ROOT/lib/proj1/jars
$PROJ_ROOT/out/file1.jar
Which IMHO is much more readable and easier to maintain. If you need
to change the structure of your project you just have one place to change -
not every place where you use a relative path.
Well, I have a hard time imagining a situation where I would want to put my
jar files six directories below my source directory. Also, on all the
projects I work on, the project directory at the root level is pretty stable
(e.g., root/src, root/class/ root/lib/, root/doc/, root/help. There is
almost never a change except to add a directory at the root level. So the
problem you face has never arisen for me. Even if it did, I'd prefer the
relative path approach as it allows other developers to use a common project
file without first ensuring that the requisite environment variable(s) are
set on each developer's system.
I only used defadvice on jde-load-project-file because there was no
jde hook - and I searched for them, in the source code - that would do what
I wanted. I had to ensure that every time a project was (re)loaded that the
environment variables would be reset based on the current path. Which hook
should I use? Could a new jde hook be created for that purpose?
I don't understand the problem you are trying to solve with defadvice.
Environment variables in paths are evaluated by the JDE everytime the path
is used, e.g., to generate a compile command, not when the project file is
loaded. Thus, if you have a project loaded and you change the environment
variable, the next time you compile, the classpath will reflect the new
value of the environment variable.
- Paul
