[MSITE-738] SiteDeployMojo#determineDeploySite code/javadoc inconsistent. Javadoc seems more correct

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Incomplete
• Affects Version/s: 3.4
• Component/s: site:deploy
• Assignee: Unassigned
• Reporter: Grégory Joseph
• Created: 20/Jan/15 09:33
• Updated: 31/Jan/23 21:06
• Resolved: 31/Jan/23 21:06

Description

The javadoc of this method seems to be the desired behavior:

    /**
     * Deploy directly to the current project's distribution management site.
     */
    @Override
    protected Site determineDeploySite()
        throws MojoExecutionException
    {
        return getSite( getTopLevelProject( project ) );
    }

However, the code indicates it goes all the way in the parent pom hierarchy ? Why ?

• The outcome is inconsistent with the effective-pom
• I'd assume if my pom declares a distributionManagement/site section, it should be used, rather than the site plugin trying to be smarter and use the parent pom's info then somewhat relativize ? This leads to the same issues I bumped into a couple years ago (when I didn't bother plugging my debugger in) : http://maven.40175.n5.nabble.com/Site-deployment-url-and-inheritance-td5712737.html

This can cause at least two problems:

• One can't deploy a site to a host that's different than that of the parent pom
• Permissions on the server-side might not be applied correctly (perhaps the project's deployer doesn't have permissions to deploy into the path configured in the parent, but does in the path of his project.. however we try to deploy to ...parent/../../project/....

Additionally, this just get confusing, because mvn help:effective-pom gives me the distributionManagement/site section I expect, but the site plugin ends up doing something else.

Reverting to

 protected Site determineDeploySite()
        throws MojoExecutionException
    {
        return getSite( project );
    }
 

Fixes the problem as far as I can tell, since project is already resolved/effective model, isn't it ? I'm not sure what sure what commit #1480820 was fixing.