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
