Hi Carsten,
I'm +1 on doing this.
My suggestion is to create a /portals/portlet-spec svn folder.
Underneath that, we then could have:
/portlet-api-1.0/
/portlet-api-2.0/
/src/site/
/pom.xml
The portlet-api-1.0/src/main/java folder should be a svn *copy* from:
/portals/pluto/tags/import/src/api
The portlet-api-2.0/src/main/java folder should be a svn *move* from:
/portals/pluto/trunk/portlet2-api/src/main/java
The /src/site/resources/javadoc/portlet-api-1.0/ folder should be a svn *move*
from:
/portals/pluto/trunk/src/site/resources/portlet-1.0-apidocs/
The /src/site/resources/javadoc/portlet-api-2.0/ folder should be a svn *move*
from:
/portals/pluto/trunk/src/site/resources/portlet-2.0-apidocs/
And of course, for all the above new appropriate maven 2 build configurations
will need to be setup.
This way, we can publish the portlet-api javadocs through:
http://portals.apache.org/porlet-spec/portlet-api-1.0/
http://portals.apache.org/porlet-spec/portlet-api-2.0/
and of course provide a general overview page (possibly with further pointers
and info) at:
http://portals.apache.org/portlet-spec/
I think that would be *very* helpful.
Finding the right portlet api javadoc online always has been "messy", and using the above would finally give them a very clear and easy to
remember "home".
One more thing with regard to the api *source*: Its obvious we cannot do
"releases" of these as they are JCP spec bound.
So, IMO there is no need for using /trunk, /tags, etc. svn sub folders for them.
However, as you know the portlet-api-2.0 OSGi meta-data configuration currently in pluto trunk is different from the *currently* provided
download at the JCP, but that will be fixed (hopefully soon) by the JSR-286 spec lead with an errata.
Furthermore, the new JSR-286 spec lead (Scott Nicklous) gave his OK for us (Portals) to push out a newly build portlet-api-2.0.jar with
(only) the fixed OSGi configuration to Maven central repository.
This however would still be a "2.0" release.
I know David Jencks suggested some time earlier to maybe get "independent" and instead "release" something like
portlet-api-2.0-pluto-1.0.1.jar (which with the above intended move then probably should become portlet-api-2.0-portals-1.0.1.jar) but I
find that kind of awkward and somewhat too "technical".
In practice, most/all portlet developers will search for, expect and use a
"portlet-api-2.0.jar" anyway.
If an updated JSR-286 portlet-api 2.0 errata "release" is provided with a new minor version, e.g. 2.0.1 (probably with updated javadoc as
well as there are errors in it too), I think we can create a new /portals/portlet-spec/portlet-api-2.0.1/ folder and corresponding
/portlet-spec/site/resources/javadoc/portlet-api-2.0.1/
WDYT?
Regards,
Ate
Carsten Ziegeler wrote:
Hi,
I think we should move the portlet api modules (for 1.0 and 2.0) out of
the respective pluto trees and move them to a "top-level" directory in
svn. While pluto changes over time (and might be branched etc.), these
modules don't. So it seems more logical to me to separate them.
WDYT?
Carsten
