Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
portals-pom-1.0
-
None
-
None
Description
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.
Attachments
Issue Links
- depends upon
-
PORTALS-11 Migrate current Portals maven-1 based site to a new maven-2 based site
-
- Open
-