> -----Original Message-----
> From: Nick Sieger [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 13, 2001 3:25 PM
> To: Abousalh-Neto, Nascif [NCRTP:3X50:EXCH]
> Cc: 'jde'
> Subject: RE: relative paths
>
>
> 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.
I used to do just that a long time ago (before environment variables were supported), be I thought that the recommended approach for project files was to keep them "pure" by using only custom to manipulate its contents.
>
> 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.
Sounds like a great idea!
>
> /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
>
