1. Portals
  2. PORTALS-10

Improve portals-pom to use apache 6 master pom and move the developers information to a new maven-2 portals main site project


    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: portals-pom-1.0
    • Fix Version/s: portals-pom-1.1
    • Component/s: None
    • Labels:


      The current portals-pom-1.0.pom is using the apache 5 master pom which caused a few issues during the release concerning (automatic) signing of the artifact (the pom itself).
      As result, all depending (child) poms will have the same issue.

      The new apache 6 master pom has this fixed (among other things).
      Before we should start releasing a batch of APA 1.0 projects, Pluto 2.0.0 and Jetspeed 2.2, we need to have the portals-pom updated for these fixes.

      In addition, I propose to remove all portals developers info from this portals master pom.
      That might seems strange at first, but as a master pom, we shouldn't need to update this pom very often anymore (hopefully).
      However, if we want to add a new Portals committer (or contributor), this would require releasing a new master portals-pom just for that purpose.
      And, to actually get this new information to be used, every child project would also need to update to this new version of the portals-pom, even if nothing else changed.

      That clearly isn't a practical nor acceptable solution, which I propose we move all (main) Apache Portals developer information to a new maven-2 based site pom.
      The primary (and AFAIK only) needed usage of the developer information is for publication on the website and in the documentation, and not something tied (only) to a specific project version.
      The current Portals site project (still maven-1 based) isn't under release management (no trunk/tags/branches there) and appropriately so imo.

      For Jetspeed, we've already discussed and decided to move all our project documentation outside the release cycle and thus outside the trunk/tags/branches structure for each version.
      Like with the developers information, project documentation isn't "frozen" when a release is done: usually the documentation trails behind (a bit or a bit more) and additional improvements
      will come in for an released version as well as for latest/trunk based development.

      The plan is to provide one master portals site folder with each subproject having its own site module (or independent) folder underneath.
      The project specific site module/project(s) can extend the main portals site project and thereby automatically inherit the main developers information and/or extend this specifically for the project if whished for.

      I'll also create a new issue for moving the current maven-1 portals site to this new maven-2 based main portals site, and the child projects can then integrate with that as needed.

        Issue Links


          Gavin made changes -
          Link This issue depends upon PORTALS-11 [ PORTALS-11 ]
          Gavin made changes -
          Link This issue depends on PORTALS-11 [ PORTALS-11 ]
          Ate Douma made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Ate Douma made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Vivek Kumar made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Ate Douma made changes -
          Field Original Value New Value
          Link This issue depends on PORTALS-11 [ PORTALS-11 ]
          Ate Douma created issue -


            • Assignee:
              Vivek Kumar
              Ate Douma
            • Votes:
              0 Vote for this issue
              0 Start watching this issue


              • Created: