MODULE_DIR problem

Hello Colin,

Do these new paths contain ".."? Did old paths with MODULE_DIR contain ".."?

Thank you

-

Anna Kozlova
JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

Hi all,

We use a USER_HOME path variable in our project, to allow our project
to create libraries which reference the Ivy cache in the home
directory of each developer. I've noticed that with 7549, IDEA has
started replacing paths in the module files which use MODULE_DIR with
paths using USER_HOME. This breaks things, since developers don't all
have the project in the same place in their home dir. If I close the
project and open it in M2, it replaces the values with the correct
ones. Has anyone else seen this? Is there a workaround?

Cheers,
Colin

Yes, the old ones did, so they referred to paths outside the actual module.

Thanks for the quick response,
Colin

Colin,

we override paths with ".." and MODULE_DIR with user macroses in order to
maintain libraries located somewhere (e.g. in USER_HOME exactly). Otherwise
relative path to the USER_HOME must be the same for all team members.

Seems that defining PATH_VARIABLE per library will solve the problem.

Thank you

-

Anna Kozlova
JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

Yes, the old ones did, so they referred to paths outside the actual
module.

Thanks for the quick response,
Colin

Hmm, we have a lot of libraries, and it seems overkill to define a variable for each one. If there are multiple path variables, how does it choose? If I define a PROJECT_ROOT, for example, will it choose that one since it's more specific than USER_HOME?

Thanks,
Colin

It should

-

Anna Kozlova
JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

Hmm, we have a lot of libraries, and it seems overkill to define a
variable for each one. If there are multiple path variables, how does
it choose? If I define a PROJECT_ROOT, for example, will it choose
that one since it's more specific than USER_HOME?

Thanks,
Colin

BTW when was this changed? This is a fairly major change for us due to the way our project is structured, I'm trying to work out where I need to provide support for it.

Thanks,
Colin

Hello Colin,

If I am not mistaken it was changed after 7.0 was out. Seems that if you
can describe your project structore in details I would be able to help ;)

Thank you

-

Anna Kozlova
JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

BTW when was this changed? This is a fairly major change for us due to
the way our project is structured, I'm trying to work out where I need
to provide support for it.

Thanks,
Colin

Ok, sounds great! Basically we have a large project, and the modules are independently versioned. We have about 80 modules, with a structure like this:

project
module
... trunk The MODULE_DIR is actually the version dir within the main module dir, e.g. trunk in the list above. We use Ivy, and the local Ivy cache for each user is at ~/.ivy/cache. We have a USER_HOME path var set to allow paths to be relative to the user's home, principally for the Ivy cache. The problem is that we recently changed our modules to use module libs rather than project libs, it's just easier to keep them in sync. What this means is that using the old scheme the paths are not correct when developers have their project in different locations (since it uses $MODULE_DIR$/../../]]>. I can't insist that everyone has their project in the same place, unfortunately. Some of these paths are outside the module but still within the project, I've fixed that case by adding a PROJECT_ROOT path var, but that still doesn't help the module lib case. Our developers are on a mix of M2, 7.0.1 and 7.0.2 EAP versions so frequently all module files appear as changed when IDEA rewrites the paths.

Is there any way I can fix this without forcing developers to use an EAP version?

Thanks for any advice,
Colin

Colin,

For libraries outside the project setting LIB_ROOT variable resolves the
problem

I believe that for libraries inside the project all developers have the same
structure - thus there is no problem.

May be I didn't get smth. If so please send me your .iml files with the problem

Thank you

-

Anna Kozlova
JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

Ok, sounds great! Basically we have a large project, and the modules
are independently versioned. We have about 80 modules, with a
structure like this:

project
module
<version>...
trunk
<module stuff here>
The MODULE_DIR is actually the version dir within the main module dir,
e.g. trunk in the list above. We use Ivy, and the local Ivy cache for
each user is at ~/.ivy/cache. We have a USER_HOME path var set to
allow paths to be relative to the user's home, principally for the Ivy
cache.

The problem is that we recently changed our modules to use module libs
rather than project libs, it's just easier to keep them in sync. What
this means is that using the old scheme the paths are not correct when
developers have their project in different locations (since it uses
$MODULE_DIR$/../../<etc>. I can't insist that everyone has their
project in the same place, unfortunately. Some of these paths are
outside the module but still within the project, I've fixed that case
by adding a PROJECT_ROOT path var, but that still doesn't help the
module lib case. Our developers are on a mix of M2, 7.0.1 and 7.0.2
EAP versions so frequently all module files appear as changed when
IDEA rewrites the paths.

Is there any way I can fix this without forcing developers to use an
EAP version?

Thanks for any advice,
Colin

Damn, Cmd-W is my favourite IDEA key, but it's a killer when you've written a long post and you use it and it closes your browser window :(

I'd written a bunch, but here's a diagram that explains it:

Before the EAP, I had:

home_dir <= MODULE_DIR is set here After the EAP, and before using the PROJECT_ROOT variable, I had: home_dir <= USER_HOME is set here __ivy_cache (IDEA used $USER_HOME$/ivy_cache, this is ok) __dev ____project ______some_path (IDEA used $USER_HOME$/dev/project/some_path, this is wrong) ______module ________]]> <= MODULE_DIR is set here

Now with the addition of the PROJECT_ROOT, it works ok in the EAP, but is still broken in previous versions. Additionally, we have to choose one scheme to check in, and users on the other scheme have to ignore all the changes to their module files.

When is 7.0.2 out? :)

Colin Fleming wrote:

Damn, Cmd-W is my favourite IDEA key, but it's a killer when you've written a long post and you use it and it closes your browser window :(

If you're using Firefox you can reopen the last closed tab using
ctrl-shift-T. I just tested (though not with the IntelliJ forums) and
it seems to preserve what you wrote in text areas.

Damn, Cmd-W is my favourite IDEA key, but it's a killer when you've
written a long post and you use it and it closes your browser window
:(

I'd written a bunch, but here's a diagram that explains it:

Before the EAP, I had:

home_dir <= USER_HOME is set here
__ivy_cache (IDEA used $MODULE_DIR$/../../../../ivy_cache, this is
wrong, depends on project)
__dev
____project
______some_path (IDEA used $MODULE_DIR$/../some_path, this is ok)
______module
________<module content> <= MODULE_DIR is set here
After the EAP, and before using the PROJECT_ROOT variable, I had:

home_dir <= USER_HOME is set here
__ivy_cache (IDEA used $USER_HOME$/ivy_cache, this is ok)
__dev
____project
______some_path (IDEA used $USER_HOME$/dev/project/some_path, this is
wrong)
______module
________<module content> <= MODULE_DIR is set here
Now with the addition of the PROJECT_ROOT, it works ok in the EAP, but
is still broken in previous versions. Additionally, we have to choose
one scheme to check in, and users on the other scheme have to ignore
all the changes to their module files.

When is 7.0.2 out? :)

You can introduce the fake module with content root pointing to the "project"
and use absolute paths (instead of relative) for your modules. Seems that
it is a temp solution before 7.0.2

I am afraid that I can't patch your previous versions, please use EAP and
upcoming 7.0.2 I hope it will be available in a week or so.

Thank you

Oh wow, if it preserves textareas, I'll be a happy man! Thanks for the tip...

Cheers,
Colin

Ok, I'll see if I can get everyone either on the EAP or on 7.0.2 when it comes out.

Thanks for all the help!

Cheers,
Colin

TabMix Plus takes it all much further and it definitely preserves text fields and areas. And if you like settings and option dialogs that go on for miles (and lets face it, if you don't, you don't use IDEA), you'll be in heaven.

Randall Schulz

Randall Schulz wrote:

TabMix Plus takes it all much further and it definitely preserves text fields and areas. And if you like settings and option dialogs that go on for miles (and lets face it, if you don't, you don't use IDEA), you'll be in heaven.

Hmmm. I do use TabMix Plus, so I guess I can't guarantee that it works
without that extension. It didn't occur to me that it might have
anything to do with preserving text fields. Still, whether it works
without the extension or not, it can definitely be a life saver in some
situations!

... it can definitely be a life saver in some situations!

Definitely. Years ago I remapped ^W in Vim to :write]]> and when I started using a Wiki, I was "writing" my changes, with disastrous effects. That's when I went looking for a way to protect myself from my own bad habits and found TabMix Plus.


Randall Schulz

BTW I tried it (opening the last closed tab) on plain vanilla Firefox, and it worked a treat. Tip of the week!

Cheers,
Colin