On Apr 8, 2009, at 1:20 AM, Ate Douma wrote:
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.
In geronimo we've found that the 100% compliant released spec jars are
quite capable of containing bugs that need to be fixed. You've
already discovered this with the incorrect osgi metadata. Since it's
really not advisable to update released jars, even if the maven guys
will make exceptions and let you do it, geronimo decided on the
slightly peculiar naming convention <spec-name>_<spec-version>_spec-
<release version>
I really advise it. It's certainly weird but at least lets you
distinguish between bug fix releases of spec jars. Similarly you will
need at least trunk and tags for the source.... don't fight it.
thanks
david jencks
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
