[BUILD-114] Simplify distributionManagement sections, and provide way to fix site URLs Created: 02/Jul/12  Updated: 13/Apr/17  Resolved: 02/Jul/12

Status: Closed
Project: Build
Component/s: Poms
Affects Version/s: None
Fix Version/s: POMs 24

Type: Improvement Priority: Major
Reporter: Magnolia International Assignee: Magnolia International
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to BUILD-155 Links to sub-sub-modules in sites of ... Closed
causality
is causing MAGNOLIA-5660 Links to submodules in ce-bundle docu... Closed
is causing MGNLEE-355 Links to submodules in ee-bundle docu... Closed
is causing MGNLREST-49 Links to submodules in magnolia-rest ... Closed
Template:
Acceptance criteria:
Empty

 Description   

Due to how our parent poms are configured (because we want to deploy sites in a directory named after the project's version), combined with Maven's I-know-better-than-you attitude, sites get deployed in what seems like an unnecessary directory: the website for foobar-1.0 will get deployed under http://nexus.magnolia-cms.com/content/sites/magnolia.public.sites/foobar/1.0/foobar/

While that's fine for single-module projects, it's not so good for multi-module projects, because their modules are the seemingly spread around: http://nexus.magnolia-cms.com/content/sites/magnolia.public.sites/module-a/1.0/foobar/module-a/, http://nexus.magnolia-cms.com/content/sites/magnolia.public.sites/module-b/1.0/foobar/module-b/, and so on ...



 Comments   
Comment by Magnolia International [ 02/Jul/12 ]

Defining the distributionManagement/site/url in parent poms has the side-effect that <artifactId>/ path elements are added to the target url, for each level of parent pom. So in our case, if we'd define the url in our top-most parent pom, we'd end up with URLs like http://nexus.magnolia-cms.com/content/sites/magnolia.public.sites/foobar/1.0/magnolia-parent-pom/magnolia-parent-pom-abstract/foobar. Not exactly what we want. It's unclear how/why inheritance is handled in those case, but it is clearly to convey to multi-module projects. The notion of parent-pom vs reactor is perhaps too often mixed up. I have not tried to see how Maven would react if we split those two notions in our multi-module projects.

I tried newer versions of maven-site-plugin, up to 3.1, without success. Their behavior seems to be going in a right direction, but, among other things, it generates un-normalized paths, which don't seem to be handled properly by our current version of Nexus or the dav wagon - something like http://nexus.magnolia-cms.com/content/sites/magnolia.public.sites/foobar/1.0/magnolia-parent-pom/magnolia-parent-pom-abstract/../../foobar. A simple test in the browser seems to work (it redirects where expected, at least when /foobar exists), so it's still a little unclear what failed and why.

For the time being:

  • Kept maven-site-plugin on version 2.1.1
  • Simplified <distributionManagement> sections of all poms by introducing the <distribRepoPrefix>, <distribSiteId> and <distribSiteRoot> properties.
  • Multi-module sites can now properly deploy their sites with the following snippet:
      <distributionManagement>
        <site>
          <id>${distribSiteId}</id>
          <url>${distribSiteRoot}/magnolia-foo/${project.version}/</url>
        </site>
      </distributionManagement>
    

    ... where magnolia-foo should of course be substituted by an appropriate folder name for the project.

Generated at Sun Feb 11 23:38:53 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.