Improve portals-pom to use apache 6 master pom and move the developers
information to a new maven-2 portals main site project
-----------------------------------------------------------------------------------------------------------------------------
Key: PORTALS-10
URL: https://issues.apache.org/jira/browse/PORTALS-10
Project: Portals
Issue Type: Improvement
Affects Versions: portals-pom-1.0
Reporter: Ate Douma
Assignee: Vivek Kumar
Fix For: portals-pom-1.1
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
