Issue 33 in snee: Unable to build because of broken dependancy

[sn...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 33 by jhe...@googlemail.com: Unable to build because of broken
dependancy
http://code.google.com/p/snee/issues/detail?id=33

What steps will reproduce the problem?
1. Download the source from svn
2. from command line: mvn clean, mvn install
3.

What is the expected output? What do you see instead?

I get a build error:

[INFO] Unable to find artifact.

Embedded error: Unable to download the artifact from any repository

Try downloading the file manually from the project website.

Then, install it using the command:
mvn install:install-file -DgroupId=eu.semsorgrid4env.service.sds
-DartifactId=sds-wsdl -Dversion=0.1.1 -Dpackaging=jar -Dfile=/path/to/file

Alternatively, if you host your own repository you can deploy the file
there:
mvn deploy:deploy-file -DgroupId=eu.semsorgrid4env.service.sds
-DartifactId=sds-wsdl -Dversion=0.1.1 -Dpackaging=jar -Dfile=/path/to/file
-Durl=[url] -DrepositoryId=[id]


eu.semsorgrid4env.service.sds:sds-wsdl:jar:0.1.1

from the specified remote repositories:
central (http://repo1.maven.org/maven2),
ssg4env.internal
(http://ssg4env.techideas.net:8180/archiva/repository/internal)


What version of the product are you using? On what operating system?
ubuntu 12.04 with a fresh checkout of trunk

Please provide any additional information below.

[sn...@googlecode.com]

Updates:
Status: Accepted
Owner: alan.bar...@gmail.com
Cc: alan.bar...@gmail.com

Comment #1 on issue 33 by alan.bar...@gmail.com: Unable to build because of
broken dependancy
http://code.google.com/p/snee/issues/detail?id=33

accepted, and discussing with end user

[sn...@googlecode.com]

Updates:
Owner: alasdair...@gmail.com
Labels: -Priority-Medium Priority-Critical

Comment #2 on issue 33 by alasdair...@gmail.com: Unable to build because of
broken dependancy
http://code.google.com/p/snee/issues/detail?id=33

Reassigned to Alasdair

[sn...@googlecode.com]

Updates:
Status: Fixed

Comment #3 on issue 33 by alasdair...@gmail.com: Unable to build because of
broken dependancy
http://code.google.com/p/snee/issues/detail?id=33

I believe that this issue is now resolved with commit r1360 on the trunk.

Please can others verify that they can build the trunk.

[sn...@googlecode.com]

Comment #4 on issue 33 by alasdair...@gmail.com: Unable to build because of
broken dependancy
http://code.google.com/p/snee/issues/detail?id=33

BTW, for details of the fix see these articles:
*
http://stackoverflow.com/questions/2229757/maven-add-a-dependency-to-a-jar-by-relative-path/2230464#2230464
*
http://brettporter.wordpress.com/2009/06/10/a-maven-friendly-pattern-for-storing-dependencies-in-version-control/

Key thing from the first article is
So, instead, declare a repository local to the project:

<repositories>
<repository>
<id>my-local-repo</id>
<url>file://${basedir}/my-repo</url>
</repository>
</repositories>
Install your third party lib in there using install:install-file with the
localRepositoryPath parameter:


mvn install:install-file -Dfile=<path-to-file> -DgroupId=<myGroup> \
-DartifactId=<myArtifactId> -Dversion=<myVersion> \
-Dpackaging=<myPackaging>
-DlocalRepositoryPath=<path>

Update: It appears that install:install-file ignores the
localRepositoryPath when using the version 2.2 of the plugin. However, it
works with version 2.3 and later of the plugin. So use the fully qualified
name of the plugin to specify the version:

mvn install:install-file \
-Dfile=<path-to-file> -DgroupId=<myGroup> \
-DartifactId=<myArtifactId> -Dversion=<myVersion> \
-Dpackaging=<myPackaging>
-DlocalRepositoryPath=<path>
Finally, declare it like any other dependency (but without the system
scope):

<dependency>
<groupId>your.group.id</groupId>
<artifactId>3rdparty</artifactId>
<version>X.Y.Z</version>
</dependency>

This approach did not work directly since we have a multi-module project
and there was an issue with relative paths. The second article provided a
work around for that. The key part being:
The solution I proposed is to create a repository module specifically for
housing these special dependencies. This can be included in the build like
any other module, and simply needs to be listed first to guarantee that it
is built before any other modules. Let’s see how this might look.

Say we have a parent pom.xml:

01
<project>
02
<groupId>com.example</groupId>
03
<artifactId>parent</artifactId>
04
<version>1.0-SNAPSHOT</version>
05
...
06
<modules>
07
<module>repository</module>
08
<module>modules</module>
09
</modules>
10
</project>
The repository/pom.xml file would then be similar to this:

view sourceprint?
01
<project>
02
<parent>
03
<groupId>com.example</groupId>
04
<artifactId>parent</artifactId>
05
<version>1.0-SNAPSHOT</version>
06
</parent>
07
<artifactId>repository</artifactId>
08
...
09
<dependencies>
10
<dependency>
11
<groupId>ancient-artifact</groupId>
12
<artifactId>ancient-artifact</artifactId>
13
<version>3.1.0.2</version>
14
</dependency>
15
</dependencies>
16
<repositories>
17
<repository>
18
<id>local</id>
19
<url>file:${basedir}/src/repository</url>
20
</repository>
21
</repositories>
22
</project>