Seems this is not just a settings.xml way of working,
the same happens if you just define the property in
your pom.
Snippet
<repositories>
<repository>
<id>company.repo</id>
<name>Archiva Managed Internal Repository</name>
<url>${company.maven.repo}</url>
</repository>
</repositories>
<parent>
<groupId>company.pom</groupId>
<artifactId>company-pom</artifactId>
<version>1.0.1-SNAPSHOT</version>
</parent>
Continue
On Thu, Feb 14, 2013 at 2:11 PM, Tonio Caputo <[email protected]> wrote:
> Hi,
>
> I'm trying to be able to configure my project repository URL inside
> settings.xml, here the snippet
>
> <activeProfiles>
> <activeProfile>company.default.profile</activeProfile>
> </activeProfiles>
>
> <profiles>
> <profile>
> <id>company.default.profile</id>
> <properties>
> <company.maven.repo>
> http://maven:8080/repo
> </company.maven.repo>
> </properties>
> </profile>
> </profiles>
>
> my pom snippet (for a none module project).
>
> <repositories>
> <repository>
> <id>company.repo</id>
> <name>Archiva Managed Internal Repository</name>
> <url>${company.maven.repo}</url>
> </repository>
> </repositories>
>
> <parent>
> <groupId>company.pom</groupId>
> <artifactId>company-pom</artifactId>
> <version>1.0.1-SNAPSHOT</version>
> </parent>
>
> when I run my mvn compile command, I get this warning at the very
> beginning
> which implies SNAPSHOT is not updated, and property *company.maven.repo *is
> not resolved
>
> [WARNING] *Could not transfer metadata* *
> company.pom:company-pom:1.0.1-SNAPSHOT*/maven-metadata.xml *from/to
> brovada.repo (${company.maven.repo})*: No connector available to access
> repository company.repo (${company.maven.repo}) of type default using the
> available factories WagonRepositoryConnectorFactory
>
> If I use this approach in a multi-module project, the message will appear,
> but the
> SNAPSHOTs will be solved for the modules without any trouble, (repository
> entry
> is only set in the reactor pom).
>
> My questions (I'm using 3.0.4):
>
> - Am I missing the point here, may be the property should not be resolved
> where I
> expect it to be resolved ?
>
> - May be this is a bug ?
> I've seen something similar happening for transitive dependencies
> version in
> multi-module projects reported as a bug, but nothing close to this one.
>
>
> Thanks in advance
> tonio
>
