Affects Version/s: portals-pom-1.0
Fix Version/s: 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.
|Status||Open [ 1 ]||In Progress [ 3 ]|
|Status||In Progress [ 3 ]||Resolved [ 5 ]|
|Resolution||Fixed [ 1 ]|
|Status||Resolved [ 5 ]||Closed [ 6 ]|