System dependencies specified with a property

[Thomas Cherel <tc...@yahoo.com>]

I am trying to use maven 3.0 system dependencies.

In a maven 3.0 project called projectA, in the pom.xml, I have the following dependency setup:


    <dependency>
        <groupId>a.b.c</groupId>
        <artifactId>common-util<artifactId>
        <version>1.0</version>
        <scope>system</scope>
        <systemPath>${abc.install}/lib/common-util.jar</systemPath>
    </dependency>

If I define the abc.install variable in the <properties> section of the projectA pom.xml or in the pom.xml of a parent maven project (inheritance) or even in my settings.xml (in a specific profile that is activated), the compilation of my project works just fine as expected.

The issue is if I have another maven project, let's call it projectB, that is dependent from this one.
If the abc.install variable is declared in the projectA pom.xml, no issues, things are still working just fine.
But if the abc.install variable is declared in the pom.xml of the projectA parent or in my settings.xml, when building projectB, I get the following warning (and error in debug mode):


[WARNING] The POM for projectA:xyz:jar:1.0 is invalid, transitive dependencies (if any) will not be available: 1 problem were encountered while building the effective model for projectA:xyz:jar:1.0
[ERROR] 'dependencies.dependency.systemPath' for projectA:xyz:jar must specify an absolute path but is ${abc.install}/lib/common-util.jar

It is like if the abc.install variable was not resolved any longer as soon as it is found through a project dependency (unless it is defined in the pom.xml).
The problem is that it breaks the transitive dependencies completely.
If projectA has other dependencies (that are not system dependencies), maven will not do transitive dependencies for these when building projectB.

Only option I found so far (short of defining abc.install in projectA pom.xml) is to define abc.install as a -D option to the maven command.

A bit more background on what I am trying to do that will explain why I would like to use system dependencies and be able to specific in a single place (ideally settings.xml) the property value(s) used to resolved these system dependencies:

- I want to put in place a set of maven projects to test a given product installation
- Since I need to test a specific product installation, I want to point directly to all the jar files of that specific product installation so I am 100% sure that I am actually testing what has been installed. This is why I want to use the maven system dependency.
- I also want to be able to very quickly switch from one product installation to another (think automated QA suite) which means that I want to be able to define in a single place (settings.xml through one or more profiles) the location of that installation
- I was thinking that I could simply specify in my settings.xml the location of the product installation to test and then all the system dependencies would be resolved from that definition. That part is actually working as expected but if I start having dependencies between my different test projects (which I definitely need to do some code sharing between the different tests), then the transitive dependency mechanism is broken.

Re : System dependencies specified with a property

[Thomas Cherel <tc...@yahoo.com>]

Thanks Wayne.

I do not disagree that if we use GAV coordinates with locked-down versions, you are supposed to know what you are testing.

But between what you have in the maven repository at the end of a product build and what you end-up with after installing the product (that was packaged from the build result), many many things can still go wrong (bugs in the packaging and installation process).
If I am putting a QA suite together to validate what the end-user will get on his machine after installing the product, I want to run the test against an installed product and nothing else.
All jar files used by the tests that are related to the product should/must come from the installed product.
Thanks for tour suggested scenario below. I guess I can have an initial processing goal that will grab all the jar I need from my installed product and create a local repository and a settings.xml file as you suggested that can then be used to run my tests. Some extra work but definitely doable.
I am going to play a bit more with the explicit -D option to the maven command (to define the installation path). It might be good enough for  what I need but your proposed solution is next on the list.


In any cases, I think it is definitely strange 
that properties used as part of a system dependency are not properly 
resolved in a multi-projec dependency scenario if the property itself is not defined 
in the pom.xml that is using it. I personally find that fairly limiting.





________________________________
 De : Wayne Fay <wa...@gmail.com>
À : Maven Users List <us...@maven.apache.org> 
Envoyé le : Jeudi 9 février 2012 16h59
Objet : Re: System dependencies specified with a property
 
> I am trying to use maven 3.0 system dependencies.

Here's your solution: don't use system scope. Find another route to
the same solution. For me, system scope is another type of profile,
and profiles are (can be) evil.

> Only option I found so far (short of defining abc.install in projectA
> pom.xml) is to define abc.install as a -D option to the maven command.

Then do this.

> - Since I need to test a specific product installation, I want to point
> directly to all the jar files of that specific product installation so I am
> 100% sure that I am actually testing what has been installed. This is why I
> want to use the maven system dependency.

If you use GAV coordinates with locked-down versions [1.2.3] there
should be no question about you "actually testing" something specific.

> - I also want to be able to very quickly switch from one product
> installation to another (think automated QA suite) which means that I want
> to be able to define in a single place (settings.xml through one or more
> profiles) the location of that installation

I actually think the best scenario would be if you just used the -s
parameter to Maven to specify an alternative settings.xml, one per
"installation" of your product or libraries, and then used the
localRepository configuration for a given localRepo that has been
initialized with the specific libraries you are wanting to test:
http://maven.apache.org/settings.html#Simple_Values

Wayne

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: System dependencies specified with a property

[Wayne Fay <wa...@gmail.com>]

> I am trying to use maven 3.0 system dependencies.

Here's your solution: don't use system scope. Find another route to
the same solution. For me, system scope is another type of profile,
and profiles are (can be) evil.

> Only option I found so far (short of defining abc.install in projectA
> pom.xml) is to define abc.install as a -D option to the maven command.

Then do this.

> - Since I need to test a specific product installation, I want to point
> directly to all the jar files of that specific product installation so I am
> 100% sure that I am actually testing what has been installed. This is why I
> want to use the maven system dependency.

If you use GAV coordinates with locked-down versions [1.2.3] there
should be no question about you "actually testing" something specific.

> - I also want to be able to very quickly switch from one product
> installation to another (think automated QA suite) which means that I want
> to be able to define in a single place (settings.xml through one or more
> profiles) the location of that installation

I actually think the best scenario would be if you just used the -s
parameter to Maven to specify an alternative settings.xml, one per
"installation" of your product or libraries, and then used the
localRepository configuration for a given localRepo that has been
initialized with the specific libraries you are wanting to test:
http://maven.apache.org/settings.html#Simple_Values

Wayne

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org