David Jencks wrote:
On Apr 8, 2009, at 1:20 AM, Ate Douma wrote:
<snip/>
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 did a quick check on the geronimo spec jars.
The precise naming convention used by Geronimo actually is:
geronimo-<spec-name>_spec-version>_spec-<release-version>
so with an additional geronimo- prefix.
If we apply this to the portlet specs, we will end up with something like:
portals-portlet_1.0_spec-1.0
portals-portlet_2.0_spec-1.0
right?
Now, to my surprise, I only just now discovered that the official downloadable
specs (both JSR-168 and JSR-286)
from the JCP do *not* contain the ASF headers but SUN/IBM only license
headers...
For the JSR-168 I can understand this as it was developed first by SUN/IBM
before it was donated/imported at Pluto.
But for the JSR-286 the spec was actually developed *first* within Pluto, but
when released by IBM at the JCP they
replaced the license headers. I suppose they are allowed (or even required) to
do that as they are formally
responsible for this spec, but it leaves me wondering what that means for "our"
version of this spec?
Maybe your are right David and we should create and maintain our own version of
these specs, and also give them our
own maven groupId and artifactId
This maybe also means we should not build nor release Pluto or Jetspeed with
the official spec jars but
use only our own. Pluto, Jetspeed, Bridges etc. have been using the
javax.portlet portlet-api-1.0.jar
version throughout every release so far. Have these releases been "invalid"?
I really advise it. It's certainly weird but at least lets you
distinguish between bug fix releases of spec jars.
I think I'm beginning to see the point, but still very much confused.
If all the above is true, I suppose we should release our own spec jars and
start using these for every new release from now on?
Similarly you will
need at least trunk and tags for the source.... don't fight it.
Yeah, this might be required then indeed.
Based upon the above, my original proposal then might need to be changed to
(using Geronimo as example):
/portals/portlet-spec/
/trunk
/portals-portlet-1.0_spec/
/portals-portlet-2.0_spec/
/tags
/portal-portlet-1.0_spec-1.0
/portal-portlet-2.0_spec-1.0
/src/site/resources/javadoc/
/portals-portlet-1.0_spec-1.0
/portals-portlet-2.0_spec-1.0
/pom.xml
Note: I did not put the site resources under trunk and tags!
This is another "thing" I'd plan to propose soon for Portals in general: storing site documentation under trunk and tags never really
appealed to me as its causing irritating maintenance limitations.
Often, *after* a release, site updates are still needed for *that* version, but as its
already "tagged" we'll end up updating the trunk
instead. However, if the trunk code moves quickly, the site documentation (in trunk) quickly gets out of sync or inconsistent with either or
both the trunk code itself and this "old" release version.
IMO, tagging site documentation is useless and bad practice.
Instead I'd propose we maintain it outside any versioning/release process and keep our own version structure however we (the project) thinks
fits best. Then, updating/fixing site documentation for a specific version is painless and can be put online right away without having
"side-effects" on other versions site documentation.
Anyway, this is a different subject of course and I should send out a separate proposal for this soon, but I thought for the above proposed
structure it needed explaining.
Regards,
Ate
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
