[
http://jira.codehaus.org/browse/MSITE-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102638
]
Mykel Alvis edited comment on MSITE-229 at 7/18/07 4:55 PM:
------------------------------------------------------------
For the most recent one:
<site>
<id>sites</id>
<url>scp://sirdsite.dsths.ad.dstcorp.net/var/www/html/maven2-sites/common/ConstraintEngine-1.0.6-SNAPSHOT</url>
</site>
Actually, I sort of worked this one out for myself. The problem, I think, was
that I was deploying to a host alias and referencing a FQDN in a link (or vice
versa). Things got a little confusing when I tried to view the generated site
documentation off the filesystem (oops). Since I now deploy all sites to a
standardized location and all URLs are standardized to reference that location,
it all works.
I think the issue I really had wasn't that it didn't work but rather that it
violates the Principle of Least Astonishment.
This may be the right way to handle this, although based on my minor experience
with multi-module builds it's probably designed to handle those cases
specifically (I guess?).
I now understand the issue and have been able to provide appropriate changes to
my poms to conform to "The Way" and the dependencies report produces the
correct links to our internal sites.
Perhaps the thing that is needed the most is a bit of documentation that
explains actually what transpires within the site generation process? I would
be happy to write that documentation but I don't actually know for sure exactly
what happens, although I do seem to know a bit more than I did a couple of
months ago.
What else can I do to help?
was:
For the most recent one:
<site>
<id>sites</id>
<url>scp://sirdsite.dsths.ad.dstcorp.net/var/www/html/maven2-sites/common/ConstraintEngine-1.0.6-SNAPSHOT</url>
</site>
Actually, I sort of worked this one out for myself. The problem, I think, was
that I was deploying to a host alias and referencing a FQDN in a link (or vice
versa). Things got a little confusing when I tried to view the generated site
documentation off the filesystem (oops). Since I now deploy all sites to a
standardized location and all URLs are standardized to reference that location,
it all works.
I think the issue I really had wasn't that it didn't work but rather that it
violates the Principle of Least Astonishment.
This may be the right way to handle this, although based on my minor experience
with multi-module builds it's probably designed to handle those cases
specifically (I guess?).
I now understand the issue and have been able to provide appropriate changes to
my poms to conform to "The Way" and the dependencies report produces the
correct links to our internal sites.
Perhaps the thing that is needed the most is a bit of documentation that
explains actually what transpires within the site generation process? I would
be happy to write that documentation but I don't actually know for sure exactly
what happens, although I do seem to know a bit more than I did a couple of
months ago.
What
> Links in site.xml get translated to ../../../
> ---------------------------------------------
>
> Key: MSITE-229
> URL: http://jira.codehaus.org/browse/MSITE-229
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Affects Versions: 2.0-beta-5
> Environment: Linux FC6 Sun Java (build 1.5.0_10-b03, mixed mode,
> sharing)
> Reporter: Mykel Alvis
> Priority: Minor
> Attachments: site.xml
>
>
> In Site.xml for a project (that has a parent POM)
> <links>
> <item name="SIRD Site" href="http://sirdsite.dsths.ad.dstcorp.net/"; />
> <item name="Apache" href="http://www.apache.org/"; />
> <item name="Maven 2" href="http://maven.apache.org/maven2/"/>
> </links>
> Gets rendered as
>
> <div class="xright"> <a href="../../../">SIRD Site</a>
> |
> <a href="http://www.apache.org/";>Apache</a>
> |
> <a href="http://maven.apache.org/maven2/";>Maven 2</a>
>
> " http://sirdsite.dsths.ad.dstcorp.net/"; != "../../.."
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
