Maven 2.x and 3.x Site Plugin

site.xml urls are not always correct

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Incomplete
  • Affects Version/s: 2.0-beta-6
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

This is so completely broken that it must be fixed before another release occurs.

The maven-parent site.xml defines some images as:

  <bannerLeft>
    <name>${project.name}</name>
    <src>http://maven.apache.org/images/apache-maven-project-2.png</src>
    <href>http://maven.apache.org/</href>
  </bannerLeft>
  <bannerRight>
    <src>http://maven.apache.org/images/maven-logo-2.gif</src>
  </bannerRight>

The site plugin somewhere along the line replaces these urls with ../../ repeated based on how far down the inheritence tree you are from maven-parent. This means you can't stage or deploy a site to a different location than the maven-parent because all urls will point back to maven-parent's /images. Worse, every module has its own copy of the css and images so there's no reason for it to depend on the parent at all.

Issue Links

This issue relates to:
MSITE-273 Wrong url in banner left url when page has more 2 sub directories Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Lammert Westerhoff added a comment -

I have the same problem. I really need to get this working. Is there any known work around for this that I can use until it is fixed?

Show
Lammert Westerhoff added a comment - I have the same problem. I really need to get this working. Is there any known work around for this that I can use until it is fixed?
Hide
Permalink
John Allen added a comment -

Over enthusiatsic application or resolveRelativeLinks, probably in assembleInheritance. However the same 'issue' applies to <modules> and parent URLs. relatives URLs are used where ever possible so that you can stage a collection of projects together and they will link to each other but eventually you'll hit a parent say that you've not staged but, if you were deploying to the real location, would be available via a relative, and that link will therefore be invalid in your staged environment.

I presume you're refering to site:stage in this.

I note in the banners those are full URLs and not relatives. What if they were relatives? If my parent site.xml defined that it uses .,/images/foo what should the child have for those resource locations? Is it true that the it will be using the same skin? it may be inherting the parent's site.xml but it could it not be using its own skin that does not contain that specifc image? Is multiple inheritence of skins allowed or does the child's skin override the parents? If its the later then what resource indicator is correct for an image that only exists in the parent?

I expect just not changing them to relatives would best.

Show
John Allen added a comment - Over enthusiatsic application or resolveRelativeLinks, probably in assembleInheritance. However the same 'issue' applies to <modules> and parent URLs. relatives URLs are used where ever possible so that you can stage a collection of projects together and they will link to each other but eventually you'll hit a parent say that you've not staged but, if you were deploying to the real location, would be available via a relative, and that link will therefore be invalid in your staged environment. I presume you're refering to site:stage in this. I note in the banners those are full URLs and not relatives. What if they were relatives? If my parent site.xml defined that it uses .,/images/foo what should the child have for those resource locations? Is it true that the it will be using the same skin? it may be inherting the parent's site.xml but it could it not be using its own skin that does not contain that specifc image? Is multiple inheritence of skins allowed or does the child's skin override the parents? If its the later then what resource indicator is correct for an image that only exists in the parent? I expect just not changing them to relatives would best.
Hide
Permalink
Dennis Lundberg added a comment -

Brian,

Do you have a concrete example project that I can use, to try to fix this issue?

Show
Dennis Lundberg added a comment - Brian, Do you have a concrete example project that I can use, to try to fix this issue?
Hide
Permalink
Stéphane Toussaint added a comment -

In a multi-module project environment I think we can expect that site deployment will :

  • Use the last inherited skin for the current module (That's the way it works right now)
  • Only retrieve skins artifacts (css, images) for the parent or for any module which override the skin (currently all deployed module will receive the skin artifacts)
  • Path to the skin artifacts will be relative from the parent (almost what's it's done now) or the overriding module

As example :

project/pom.xml
project/src/site/site.xml

project/module1/pom.xml

project/module2/pom.xml
project/module2/src/site/site.xml

The project base site.xml will be applied to all modules (expect whose who override it)

<project>
    <skin>
        <groupId>skins</groupId>
        <artifactId>default-skin</artifactId>
    </skin>
    <bannerLeft>
        <name>Default Banner</name>
        <src>images/logo-default.jpg</src>
        <href>...</href>
    </bannerLeft>
    <body>
        <menu ref="modules"/>
        <menu ref="reports"/>
    </body>
</project>

The project/index.html page will display the banner with an image located in project/images//logo-default.jpg

The project/module1/index.html page will display the very same banner with an image located in (../../)project/images//logo-default.jpg. The (../../) path will get out of the modules deployment location, so it doesn't matter if the module is part of the parent (as this example) or near it.

Finally if the module2 site.xml override the skin 

<project>
    <skin>
        <groupId>skins</groupId>
        <artifactId>default-skin-2</artifactId>
    </skin>
    ...
</project>

The project/module2/index.html page will display the banner with an image located in project/module2/images/logo-default.jpg. (which is not necessary the same as the previous one).

Show
Stéphane Toussaint added a comment - In a multi-module project environment I think we can expect that site deployment will :
  • Use the last inherited skin for the current module (That's the way it works right now)
  • Only retrieve skins artifacts (css, images) for the parent or for any module which override the skin (currently all deployed module will receive the skin artifacts)
  • Path to the skin artifacts will be relative from the parent (almost what's it's done now) or the overriding module
As example : project/pom.xml project/src/site/site.xml project/module1/pom.xml project/module2/pom.xml project/module2/src/site/site.xml The project base site.xml will be applied to all modules (expect whose who override it) 
<project>
    <skin>
        <groupId>skins</groupId>
        <artifactId>default-skin</artifactId>
    </skin>
    <bannerLeft>
        <name>Default Banner</name>
        <src>images/logo-default.jpg</src>
        <href>...</href>
    </bannerLeft>
    <body>
        <menu ref="modules"/>
        <menu ref="reports"/>
    </body>
</project>
The project/index.html page will display the banner with an image located in project/images//logo-default.jpg The project/module1/index.html page will display the very same banner with an image located in (../../)project/images//logo-default.jpg. The (../../) path will get out of the modules deployment location, so it doesn't matter if the module is part of the parent (as this example) or near it. Finally if the module2 site.xml override the skin 
<project>
    <skin>
        <groupId>skins</groupId>
        <artifactId>default-skin-2</artifactId>
    </skin>
    ...
</project>
The project/module2/index.html page will display the banner with an image located in project/module2/images/logo-default.jpg. (which is not necessary the same as the previous one).
Hide
Permalink
Lukas Theussl added a comment -

Brian,

I believe this is working with current 2.1-SNAPSHOT, at least on the few maven sites I have tested. Please give me a concrete example if I missed something.

Show
Lukas Theussl added a comment - Brian, I believe this is working with current 2.1-SNAPSHOT, at least on the few maven sites I have tested. Please give me a concrete example if I missed something.

People

Vote (3)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.