IPR-Runner & Path Variables

I'm having a problem with the Ipr-Runner-Type to let it find a module which is
referenced with an absolute path that has been substituted by a Path-Variable:

Cannot load module from file: somemodule.iml Reason: File
doesn't exist File path:
C:\Programme\buildAgent\work\someproject\$PROJECT$\somemodule\somemodule.iml

Where can I specify the path to the IDEA-configuration the runner should use to
resolve the path variable? Is this possible at all? Seems to me like this could
also eliminate the need to specify the paths of all global libraries that are
used which is really inconvenient right now.

Sascha

4 comments
Comment actions Permalink

Ipr runner does not support path variables at the moment. BTW is it really
necessary to use path variables in a module path?

Paths to jdk and global libraries you can specify using workspace parameter.
It should look like this:
]]>
<include name="*/.jar"/>
</fileset>
</path>

There will be more convinient way to configure it, I hope, but now work on
ipr runner is in progress.
Thanks!


"Sascha Weinreuter" <sascha.weinreuter@NOSPAM-cit.de> wrote in message
news:e9i518$dpm$1@is.intellij.net...

I'm having a problem with the Ipr-Runner-Type to let it find a module
which is
referenced with an absolute path that has been substituted by a
Path-Variable:

>

Cannot load module from file: somemodule.iml Reason: File
doesn't exist File path:
C:\Programme\buildAgent\work\someproject\$PROJECT$\somemodule\somemodule.iml

>

Where can I specify the path to the IDEA-configuration the runner should
use to
resolve the path variable? Is this possible at all? Seems to me like this
could
also eliminate the need to specify the paths of all global libraries that
are
used which is really inconvenient right now.

>

Sascha



0
Comment actions Permalink

Hello Olesya,

Ipr runner does not support path variables at the moment.


This is what I already figured ;)

BTW is it really
necessary to use path variables in a module path?


Due to the nature of path variables, I can not really decide whether to use a
path variable or not. I need to have that variable defined and IDEA replaced it
automatically. Changing the module-path from absolute to relative solves that
problem though - in this case.

Paths to jdk and global libraries you can specify using workspace parameter.
<path id="jdk.IDEA jdk.classpath">


Well, I'm a bit confused: This looks like an Ant fragment, but the build
configuration says "Enter workspace file content". I'd interpret this to be the
content of a .iws file, not some Ant code. This should be clarified somehow.

BTW: There is no such textfield for the "Inspection" build type, but I guess it
needs this information as well.

There will be more convinient way to configure it, I hope, but now work on
ipr runner is in progress.


I hope so, because that may be a viable thing when there are only few global
libraries associated with the project, but not for more than 5 or so. After all,
I have the libraries already defined in IDEA and I'd prefer to use the same
configuration (which could also use path variables!) for running the build.

Sascha

0
Comment actions Permalink

Well, I'm a bit confused: This looks like an Ant fragment, but the build
configuration says "Enter workspace file content". I'd interpret this to
be the
content of a .iws file, not some Ant code. This should be clarified
somehow.

>

BTW: There is no such textfield for the "Inspection" build type, but I
guess it
needs this information as well.


It is ant fragment, because ipr is being translated to ant and there has to
be some way to define jdk and global libraries. Inspection runner
configuration expects that all libraries paths will be defined by system
variables and loads all jars under them. But I don't think it's suitable way
because library can contain not all jars in some directory.

I think ant fragment is more convinient compaing to some custom language
because its format is well known for many users.
BTW we're going to add 'Add jdk' and 'Add library' button which will help
you generate this ant (generator cannot generate lib definition using path
variable because global library paths are stored in local user workspace and
not available on agent where translation 'ipr->ant' takes place)

"Sascha Weinreuter" <sascha.weinreuter@NOSPAM-cit.de> wrote in message
news:e9o9us$hjd$1@is.intellij.net...

Hello Olesya,

>
>> Ipr runner does not support path variables at the moment.
>

This is what I already figured ;)

>
>> BTW is it really
>> necessary to use path variables in a module path?
>

Due to the nature of path variables, I can not really decide whether to
use a
path variable or not. I need to have that variable defined and IDEA
replaced it
automatically. Changing the module-path from absolute to relative solves
that
problem though - in this case.

>
>> Paths to jdk and global libraries you can specify using workspace
>> parameter.
>> >>]]>
>

Well, I'm a bit confused: This looks like an Ant fragment, but the build
configuration says "Enter workspace file content". I'd interpret this to
be the
content of a .iws file, not some Ant code. This should be clarified
somehow.

>

BTW: There is no such textfield for the "Inspection" build type, but I
guess it
needs this information as well.

>
>> There will be more convinient way to configure it, I hope, but now work
>> on
>> ipr runner is in progress.
>

I hope so, because that may be a viable thing when there are only few
global
libraries associated with the project, but not for more than 5 or so.
After all,
I have the libraries already defined in IDEA and I'd prefer to use the
same
configuration (which could also use path variables!) for running the
build.

>

Sascha



0
Comment actions Permalink

Olesya Smirnova wrote:

I think ant fragment is more convinient compaing to some custom language
because its format is well known for many users.


Sure. Just the wording on the config page needs some clarification: For most
IDEA users, a "workspace file" is something totally different than an Ant file.
If you want the user to enter Ant code in there, it should be more obvious ;)

Sascha

0

Please sign in to leave a comment.