The skin does not exist: Unable to determine the release version

For some reason Maven is unable to find the default skin from the repository. You could try to add the version for the skin in your site.xml, like this:

  <skin>
    <groupId>org.apache.maven.skins</groupId>
    <artifactId>maven-default-skin</artifactId>
    <version>maven-default-skin</version>
  </skin>

Also encounting this problem.

The workaround worked, but I now have the problem of making sure that people who take over my role as build manager are aware that the default behaviour of the site plugin is broken, and that they cannot expect this plugin to work reliably or repeatably on future builds without manual intervention.

this doesn't appear to be a bug - simply the skin has not been deployed with -DupdateReleaseInfo=true at any point

For anyone else finding this error, see my comment in MNG-3139 as you may have the same issue, especially if upgrading from a previous version of Maven (2.0.5 -> 2.0.8 in my case).

This is really putting egg on the face of this particular maven plugin at a consulting client of mine. I'd like to cure it to get it back in good standing with my customer. Is it really as simple as me deploying to the central repo with -DupdateReleaseInfo=true? How do I get permissions to do that? I'll try to help and fix it (I'm not one of those open source whiners that wants other people to fix everything) but I need to be told how I get permissions to deploy to the central repo.

Thanks in advance,
Matthew McCullough
matthewm@ambientideas.com

I'd like to re-open this issue, because it's a real pain.

We are using Maven 2.0.9 and site 2.0-beta-6
We have maven-default-skin version 1.0 in our repository
we do not allow developers to have their maven proxy open

and then every time a site is built (and this alway happens with mvn release ... ) we get this ?¨?¨&! "SKIN DOES NOT EXIST" ...

We actually have two ways to avoid this:

1) ask every project to add a site directory with site.xml explicitely specifying skin version
or
2) open the proxy

However, i think this is not a real solution
Why cant skin artifact be correctly deployed in repo1 ?

Thanks in advance,

Christian-Luc

Please reopen this.
This should be an easy fix on the plugin.
Sry I haven't been involved enough since Maven 2 beta days to do this myself as a patch.
When I find a free second I'll be more than willing to submit one myself but it doesn't even sound like from Brett's comments that one is necessary.

I'd like to see this reopened too, it started happening for us last night.

There was evidence that for some reason, the repository location of the skins artifact was resolving to java.net. I found this file in the local repository for our site:site build:

maven-metadata-java.net.xml
<?xml version="1.0" encoding="UTF-8"?><metadata>
<groupId>org.apache.maven.skins</groupId>
<artifactId>maven-default-skin</artifactId>
</metadata>

To fix the problem, I removed the maven-default-skin directory in the local repository, as our company repository contains the proper metadata file and the 1.0 resource. After removing the artifacts from the local repository, the correct metadata and artifact were retrieved.

It's a simple fix, but it would be nice if the build didn't break due to this problem in the first place.

I'm using maven 2.0.9 and also face this issue. Please re-open

I worked around this by:
rm -fr $HOME/.m2/repository/org/apache/maven/skins

right after, mvn site:site worked.

I was able to reproduce this when the repo hosting the artifact cannot be accessed, an IT is online.

In case of a TransferFailedException, a repository is blacklisted and the locally cached metadata of blacklisted repos is not consulted in DefaultRepositoryMetadataManager.mergeMetadata().

The problematic code line originates from r306560 where the concept of blacklisting was introduced. The attached patch simply consults locally cached metadata in all cases. While the local metadata can surely be outdated, it provides a best effort to resolve metaversions and to gracefully continue the build. As the metadata is local, that does not present a big performance hit.

Patch applied, thanks Benjamin.

Merged to 2.0.x in r747533.

Merged to 3.x in r747536.

Issue was fixed in 2.1.0 but was encountered again in 2.2.0

Neil, without some more information like a full debug log or an example project, we have no basis for investigation.

Sorry, the issue log and all details are the same (see below) as initially reported by eyal david.
It's just that I encountered the same issue in 2.2.0 even though it was supposed to have been fixed since 2.1.0
Just forgot to merge maybe? Thanks!

[INFO] [site:site

]
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] SiteToolException: ArtifactNotFoundException: The skin does not exist: Unable to determine the release version

Try downloading the file manually from the project website.

Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.maven.skins -DartifactId=maven-default-skin -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file

Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=org.apache.maven.skins -DartifactId=maven-default-skin -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

org.apache.maven.skins:maven-default-skin:jar:RELEASE

Well, we have an IT that says this issue is fixed in 2.2.0, too. There's always a chance that the IT doesn't cover all erroneous code paths that would exhibit the problem but that's hard to find out without more information like debug logs. With debug log I mean the output from running "mvn ... -X > debug.log", this usually produces several KB of output and is far more informative than the few lines around "[ERROR] BUILD ERROR".

Thanks. I've attached a debug log using mvn 2.2.1

Just to add, I also did rm -fr $HOME/.m2/repository/org/apache/maven/skins but it just fixed the issue for some number of builds and then came back.
So from what I've experienced, 2.2.0 and 2.2.1 both have this issue. Thank you.

From the log, I see the project has two remote repos configured, "internal" and "central". Could you check whether {{$

/.m2/repository/org/apache/maven/skins/maven-default-skin/maven-metadata-central.xml}} equals the remote version of this file? In particular, <release>1.0</release> must be present in the metadata file.

This defect is occurring again as of February 1st, 2010. Last Friday, the "site" mojo worked perfectly, and this Monday morning, it's broken with the original error message:

— clip —

[INFO] SiteToolException: ArtifactNotFoundException: The skin does not exist: Unable to determine the release version

Try downloading the file manually from the project website.

Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.maven.skins -DartifactId=maven-default-skin -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file

Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=org.apache.maven.skins -DartifactId=maven-default-skin -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

org.apache.maven.skins:maven-default-skin:jar:RELEASE

— /clip —

Since we do not require any special configuration for the site, we do not have a site.xml file, and shouldn't need one, right? CoC, anyone?

I'm running Maven v2.2.1, with Java 1.6.0_17, on Windows XP SP2 64bit, but it seems to occur for everyone (we all have Maven v2.2.1) on all platforms here when attempting to call "mvn site" on our project.

Maven needs to be a bit more stable going forward... When things work fine one day, and the next day it's all broken because a single person can screw up some essential part of Maven in the central repo. We are seriously considering moving back to Ant at this point, as our business cannot be hindered and held hostage by some maverick developer messing up the central repo of core plugins. Reopen this ticket, and fix it, so we can build again, please.

Yup, two days after a successful release and site deployment, I try another minor release (Java == same, Maven == same, Project Checkout == same, bar a CPE bugfix) and builds with site fail now.

> [INFO] SiteToolException: ArtifactNotFoundException: The skin does not exist: Unable to determine the release version

I'm guessing that I have an unfixed dependency somewhere, that if I fix to a prior version, it'll work again. I've tried the following but it does not work :-

org.apache.maven.plugins:maven-site-plugin:2.1

• Paul

Blowing away the LOCAL-REPO/org/apache/maven/skins/* worked.

In the past I've seen maven artifacts downloaded in hotels/cafes over wifi screw up the local repo because the wifi software is wanting your to buy service or click-thru some forms before it's return actual pages rather than intercept. Maven is (or was) unable to see that foo.jar coming down over these services is actually intercepted HTML from T-Mobile or other.

This issue is happening again. Upgraded to 2.0.11 assuming this would no longer occur and it happened again - although its a little different this time:

SiteToolException: ArtifactNotFoundException: The skin does not exist: Unable to determine the release version

Try downloading the file manually from the project website.

Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.maven.skins -DartifactId=maven-default-skin -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file

Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=org.apache.maven.skins -DartifactId=maven-default-skin -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

org.apache.maven.skins:maven-default-skin:jar:RELEASE

I'm also experiencing the same bug on our hudson server with 2.2.1. Removing LOCAL-REPO/org/apache/maven/skins/* does help for a few days, but not for long

maven-metadata-central.xml did not contain any version metadata, just group and artifactid ..

I'm also experiencing the same bug on our Jenkins server (v 1.405) with Maven 2.2.1. Removing LOCAL-REPO/org/apache/maven/skins/* does help for a few days, but not for long

Another workaround for now (as the others don't work for me / anymore):
Install the downloaded skin as version DEFAULT, so you get:
<M2_repo>/org/apache/maven/skins/maven-default-skin/DEFAULT/maven-default-skin-DEFAULT.jar

Please try using Maven Site Plugin 2.2.
Might be related to DOXIASITETOOLS-38.