Maven 2.x and 3.x Site Plugin

Try and unable to resolve org.apache.maven.skins:maven-default-skin:jar:RELEASE when another skin is specified

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.0-beta-5
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

1) My project does not use external repositories for dependencies but only for plugins.
2) For dependencies I have a "stage" folder that is a "legacy structured" local repository I reference this way:

<repository>
      <id>local-james-stage-m1</id>
      <name>Local James stage repository</name>
      <url>file://c:/lab/void/projects/server-trunk-modular/stage</url>
      <layout>legacy</layout>
      <releases>
        <enabled>true</enabled>
        <checksumPolicy>ignore</checksumPolicy>
      </releases>
      <snapshots>
        <enabled>true</enabled>
        <checksumPolicy>ignore</checksumPolicy>
      </snapshots>
    </repository>

3) in my site.xml I have this:

<skin>
    <groupId>org.apache.james</groupId>
    <artifactId>maven-skin</artifactId>
    <version>1.1-SNAPSHOT</version>
  </skin>

4) and in my local stage repository I have the org.apache.james/poms/maven-skin-1.1-SNAPSHOT.pom and org.apache.james/jars/maven-skin-1.1-SNAPSHOT.jar files.

If I try to build the project, package it, run tests and everything else it works, but when I try to build "mvn site" if fails with this error:

[DEBUG] maven-default-skin: using locally installed snapshot
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] 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


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


[INFO] ------------------------------------------------------------------------
[DEBUG] Trace
org.apache.maven.BuildFailureException: 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


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


        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:560)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
        at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
        at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoFailureException: 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


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


        at org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getSkinArtifactFile(AbstractSiteRenderingMojo.java:372)
        at org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:442)
        at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:108)
        at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:92)
        at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
        ... 16 more

I also tried adding to my stage folder the file org.apache.maven.skins/jars/maven-default-skin-1.0.jar and org.apache.maven.skins/poms/maven-default-skin-1.0.pom but it doesn't find the artifact anyway.

Why does it need the default skin when I specified a custome skin? How can I tell maven the version of the default skin (1.0) so it doesn't lookup for "RELEASE"?

Otherwise, how can I solve this issue without using remote repositories or changing my local stage folder to another structure (m2 repository with release number properties, I guess)?

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Stefano Bagnara added a comment -

I found a workaround for this.
Let me explain my full scenario and how I fixed it so maybe it will more clear to you where the bug belongs.

My pom structure is:

james-parent
|- maven-skin
'- james-root
   |- james-server-root
   |  |- james-server-2.2.0
   |  '- james-server:3.0-SNAPSHOT
   |     |- module1
   |     |- module2
   |     '....
   |- jspf
   '.....

The site.xml for james-root is the one specifying the use of the maven-skin as default skin for the project.
I cannot add this directive to james-parent because james-parent is also the parent for maven-skin and it would be a recursive dependency.
I get the error above while trying to build "james-server:3.0-SNAPSHOT".

Adding a site.xml to james-parent and specifying:

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

and then placing in my local "stage" folder the jar and pom for the default skin made the trick.

Probably the bug is that maven is searching for the skin even if the parent artifacts do not need a site generation (they didn't have a site.xml at all).

I don't like too much having to place the maven-default-skin jar (that I don't use) in the james-server:3.0-SNAPSHOT dependencies stage repository, but I can live with it as a workaround.

I hope this give you enough information for fixing this issue.

Show
Stefano Bagnara added a comment - I found a workaround for this. Let me explain my full scenario and how I fixed it so maybe it will more clear to you where the bug belongs. My pom structure is: james-parent |- maven-skin '- james-root |- james-server-root | |- james-server-2.2.0 | '- james-server:3.0-SNAPSHOT | |- module1 | |- module2 | '.... |- jspf '..... The site.xml for james-root is the one specifying the use of the maven-skin as default skin for the project. I cannot add this directive to james-parent because james-parent is also the parent for maven-skin and it would be a recursive dependency. I get the error above while trying to build "james-server:3.0-SNAPSHOT". Adding a site.xml to james-parent and specifying: <skin> <groupId>org.apache.maven.skins</groupId> <artifactId>maven- default -skin</artifactId> <version>1.0</version> </skin> and then placing in my local "stage" folder the jar and pom for the default skin made the trick. Probably the bug is that maven is searching for the skin even if the parent artifacts do not need a site generation (they didn't have a site.xml at all). I don't like too much having to place the maven-default-skin jar (that I don't use) in the james-server:3.0-SNAPSHOT dependencies stage repository, but I can live with it as a workaround. I hope this give you enough information for fixing this issue.
Hide
Permalink
Jennifer Lengel added a comment -

I am using a local folder for my repository so that maven can not get anything from central, and i have a super pom with modules that have their own pom as well. Using my local directories as the only repo maven can access, this work around does not solve my problem. When I allow maven to go to central (repo1.maven.org/maven2/), then it does work.

What I need is a work around for my scenario. I am using maven 2.0.5 - or if this is fixed in a later version that I am not aware of, please let me know.

Thank you,
Jennifer Lengel

Show
Jennifer Lengel added a comment - I am using a local folder for my repository so that maven can not get anything from central, and i have a super pom with modules that have their own pom as well. Using my local directories as the only repo maven can access, this work around does not solve my problem. When I allow maven to go to central (repo1.maven.org/maven2/), then it does work. What I need is a work around for my scenario. I am using maven 2.0.5 - or if this is fixed in a later version that I am not aware of, please let me know. Thank you, Jennifer Lengel
Hide
Permalink
Dennis Lundberg added a comment -

The "Unable to determine the release version" part might have something to do with the fact that your local "stage" repository is using a a legacy layout. Such a layout doesn't have the metadata files that an M2 repo has. Perhaps this is what is causing the site-plugin to not find the release version.

Show
Dennis Lundberg added a comment - The "Unable to determine the release version" part might have something to do with the fact that your local "stage" repository is using a a legacy layout. Such a layout doesn't have the metadata files that an M2 repo has. Perhaps this is what is causing the site-plugin to not find the release version.
Hide
Permalink
Patrick Peck added a comment -

I have a similar setup as Jennifer: override the "central" remote repository with my own local repository, while keeping the "central" plugin repository point to the default central maven repository.

It seems that maven tries to resolve the skins from the remote repositories instead of the plugin repositories, because when I include the central remote repository in my POM, everything works fine (always starting with a clean ~/.m2/repository)

Is this a bug or a feature? If it is a feature, can I override this behaviour so that skins are resolved from the plugin repositories?

Show
Patrick Peck added a comment - I have a similar setup as Jennifer: override the "central" remote repository with my own local repository, while keeping the "central" plugin repository point to the default central maven repository. It seems that maven tries to resolve the skins from the remote repositories instead of the plugin repositories, because when I include the central remote repository in my POM, everything works fine (always starting with a clean ~/.m2/repository) Is this a bug or a feature? If it is a feature, can I override this behaviour so that skins are resolved from the plugin repositories?
Hide
Permalink
Dennis Lundberg added a comment -

Patrick, a skin is not a plugin - so I'd call it a feature, or at least the expected behavior.

Show
Dennis Lundberg added a comment - Patrick, a skin is not a plugin - so I'd call it a feature, or at least the expected behavior.
Hide
Permalink
Erik Husby added a comment -

I am still struggling with this problem even in Maven 2.2.0. What is worse is that it always updates the metadata for the default skin even though the metadata already exists in the user's repository. And the problem is that sometimes the metadata from maven central is correct and sometime it is wrong.

And this problem of getting the wrong metadata breaks my builds.

I tried protecting the ~/.m2/repository/org/apache/maven/skins directory once it had correct metadata but that causes the build to fail because Maven site plugin wants to update the metadata and it can't.

It seems that the fact is skin is sometimes a plugin and sometimes it isn't indicates a design failure. And I would call this instance on updating the metadata every time a bug, not a feature.

My next attempt to work around this problem will be to update all the site.xml to use something else than the default skin.

Show
Erik Husby added a comment - I am still struggling with this problem even in Maven 2.2.0. What is worse is that it always updates the metadata for the default skin even though the metadata already exists in the user's repository. And the problem is that sometimes the metadata from maven central is correct and sometime it is wrong. And this problem of getting the wrong metadata breaks my builds. I tried protecting the ~/.m2/repository/org/apache/maven/skins directory once it had correct metadata but that causes the build to fail because Maven site plugin wants to update the metadata and it can't. It seems that the fact is skin is sometimes a plugin and sometimes it isn't indicates a design failure. And I would call this instance on updating the metadata every time a bug, not a feature. My next attempt to work around this problem will be to update all the site.xml to use something else than the default skin.
Hide
Permalink
Paul Hammant added a comment -

This hack worked for me: https://github.com/jbehave/jbehave-core/commit/492d4ea213d7bdc5a2a3f522c4af4aa2aeed2cb4

Show
Paul Hammant added a comment - This hack worked for me: https://github.com/jbehave/jbehave-core/commit/492d4ea213d7bdc5a2a3f522c4af4aa2aeed2cb4

People

  • Assignee:
    Unassigned
    Reporter:
    Stefano Bagnara
Vote (1)
Watch (4)

Dates

  • Created:
    Updated: