Commons All
  1. Commons All
  2. COMMONSSITE-26

Add a /distributionManagement/site element

    Details

    • Type: Improvement Improvement
    • Status: Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Commons Parent Pom
    • Labels:
      None

      Description

      To enable sites to be deployed using the m2 site plugin, we should add this to the Commons Parent POM:

      <distributionManagement>
        <site>
          <id>apache-site</id>
          <name>Apache Commons Website</name>
          <url>${commons.deployment.protocol}://people.apache.org/www/commons.apache.org/${commons.componentid}</url>
        </site>
      </distributionManagement>
      

        Activity

        Hide
        Dennis Lundberg added a comment -

        We should use

          <id>apache.website</id>
        

        as that has evolved into some sort of default for the ASF.

        Aside from that +1.

        Show
        Dennis Lundberg added a comment - We should use <id> apache.website </id> as that has evolved into some sort of default for the ASF. Aside from that +1.
        Hide
        James Carman added a comment -

        The only problem I see here (and this may be why it was never done this way) is that it would be very easy for someone to mistakenly deploy the site when they mean to be staging it. Perhaps we should make the profile name much longer or more involved so that you have to consciously think about it when typing it?

        Show
        James Carman added a comment - The only problem I see here (and this may be why it was never done this way) is that it would be very easy for someone to mistakenly deploy the site when they mean to be staging it. Perhaps we should make the profile name much longer or more involved so that you have to consciously think about it when typing it?
        Hide
        Rahul Akolkar added a comment -

        I believe the general solution to that is having more "robust" sites (as I mentioned before on the mailing list). Also staging and deploying require different mvn commands so we have to ask / document folks to be a little (more?) aware.

        And I wasn't thinking about adding it to any profile. In fact, the more I look at the parent pom, I don't think the distributionManagement sections should be in profiles at all

        Since I haven't followed m2 discussions lately, I followed the profiles through the archives. They came to life in r439540:

        http://svn.apache.org/viewvc?view=rev&revision=439540

        The release profile's original purpose was to deploy to the rsync repo. This is not of interest anymore. This point, as it happens, has been raised before

        http://markmail.org/message/zcktfmnrkzsqgyah

        We should move the distributionManagement section out of profiles, see said section in this pom, for example:

        http://svn.apache.org/repos/asf/struts/struts2/trunk/pom.xml

        Lets suspend this for a few, and I will post a process-level email to the dev list first.

        Show
        Rahul Akolkar added a comment - I believe the general solution to that is having more "robust" sites (as I mentioned before on the mailing list). Also staging and deploying require different mvn commands so we have to ask / document folks to be a little (more?) aware. And I wasn't thinking about adding it to any profile. In fact, the more I look at the parent pom, I don't think the distributionManagement sections should be in profiles at all Since I haven't followed m2 discussions lately, I followed the profiles through the archives. They came to life in r439540: http://svn.apache.org/viewvc?view=rev&revision=439540 The release profile's original purpose was to deploy to the rsync repo. This is not of interest anymore. This point, as it happens, has been raised before http://markmail.org/message/zcktfmnrkzsqgyah We should move the distributionManagement section out of profiles, see said section in this pom, for example: http://svn.apache.org/repos/asf/struts/struts2/trunk/pom.xml Lets suspend this for a few, and I will post a process-level email to the dev list first.
        Hide
        Rahul Akolkar added a comment -

        This will have to wait for a while since its hard to define patterns for distributionManagement/site URLs in parent POMs.

        See:

        https://svn.cargo.codehaus.org/browse/MNG-3244

        https://svn.cargo.codehaus.org/browse/MNG-2872

        Additionally, this one may be a blocker for some:

        http://jira.codehaus.org/browse/MSITE-25

        Seems site information (including alternate site locations for the rc profile) will have to be duplicated in component POMs.

        Show
        Rahul Akolkar added a comment - This will have to wait for a while since its hard to define patterns for distributionManagement/site URLs in parent POMs. See: https://svn.cargo.codehaus.org/browse/MNG-3244 https://svn.cargo.codehaus.org/browse/MNG-2872 Additionally, this one may be a blocker for some: http://jira.codehaus.org/browse/MSITE-25 Seems site information (including alternate site locations for the rc profile) will have to be duplicated in component POMs.
        Hide
        Sebb added a comment -

        No need to do this, now that Nexus is available

        Show
        Sebb added a comment - No need to do this, now that Nexus is available
        Hide
        Dennis Lundberg added a comment -

        This issue is about site deployment, it has nothing to do with Nexus.

        Show
        Dennis Lundberg added a comment - This issue is about site deployment, it has nothing to do with Nexus.
        Hide
        Sebb added a comment -

        It looks like

        http://jira.codehaus.org/browse/MSITE-25 - mvn site:deploy and site:stage-deploy ignores server configuration in settings.xml
        was fixed in 2.0-beta-7 of the site plugin.

        However:

        http://jira.codehaus.org/browse/MNG-3244 - inherited site url not properly handling parameters

        and

        http://jira.codehaus.org/browse/MNG-2872 - Don't append artifactId when parent pom already has artifactId in URL
        has been closed as a duplicate of
        http://jira.codehaus.org/browse/MNG-4508 - No way to avoid adding artifactId to site urls

        are still not fixed

        Show
        Sebb added a comment - It looks like http://jira.codehaus.org/browse/MSITE-25 - mvn site:deploy and site:stage-deploy ignores server configuration in settings.xml was fixed in 2.0-beta-7 of the site plugin. However: http://jira.codehaus.org/browse/MNG-3244 - inherited site url not properly handling parameters and http://jira.codehaus.org/browse/MNG-2872 - Don't append artifactId when parent pom already has artifactId in URL has been closed as a duplicate of http://jira.codehaus.org/browse/MNG-4508 - No way to avoid adding artifactId to site urls are still not fixed

          People

          • Assignee:
            Unassigned
            Reporter:
            Rahul Akolkar
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development