[RT] Moving the portlet api out of pluto tree

[cziegeler]

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
--
Carsten Ziegeler
cziegeler@...

[Eric Dalquist]

+1 I think it could help us have a more stable portlet API website as well.

-Eric

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
>  

[djencks]

I think this is a good idea.

I somewhat doubt it would be a good idea but if you wanted the spec  
jars even farther away we could put them in with the geronimo spec jars.

Are these jars the official spec api jars or does sun (or someone  
else) release those separately?

If it hasn't already been done it might well be a good idea to osgi-
ify these jars (and the rest of pluto for that matter) with the maven  
bundle plugin.

thanks
david jencks



On Apr 7, 2009, at 5:59 AM, 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
> --
> Carsten Ziegeler
> cziegeler@...

[Ate Douma]

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

[Ate Douma]

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.

Oh, one more and very important point: the maven pom.xml for the portlet-api source modules of course needs to be setup independent of the
portals pom and use groupid "javax.portlet" (same as we currently have for the portlet2-api module under pluto/trunk).

>
> 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
>
>

[cziegeler]

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.
>

Good plan! I'll add an issue for this and try to move/copy the stuff in
the next days.

> 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".
Yepp

>
> 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.
Agreed.

> 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.
Which is not really possible as we can change the central maven repo or
any local copies of people, but an updated errata release will fix this.

Carsten

--
Carsten Ziegeler
cziegeler@...

[cziegeler]

David Jencks schrieb:
> I think this is a good idea.
>
> I somewhat doubt it would be a good idea but if you wanted the spec jars
> even farther away we could put them in with the geronimo spec jars.
>
> Are these jars the official spec api jars or does sun (or someone else)
> release those separately?
They're released separately and we are not allowed to release them on
our own.

> If it hasn't already been done it might well be a good idea to osgi-ify
> these jars (and the rest of pluto for that matter) with the maven bundle
> plugin.
The 2.0 api jar is an OSGi bundle already - however the official jar is
buggy
and we're trying to solve this issue. I'm planning to osgi the other
pluto jars
for the release. Thanks to Ate's great work in the past weeks/months we
have a clean package space now, so adding the manifest information is
easy to do.

Carsten
--
Carsten Ziegeler
cziegeler@...

[Ate Douma]

Carsten Ziegeler wrote:
> Ate Douma wrote:
<snip/>

>> 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.
> Which is not really possible as we can change the central maven repo or
> any local copies of people, but an updated errata release will fix this.

I'm not so sure if the upcoming errata will end up with a 2.0.1 version.
At least, the pending "fixes" I'm aware of from the JSR-286 EG so far only concern "textual" corrections, javadoc fixes and the OSGi meta-data.
Anyway, we *can* change the central maven repo jar if we ask the repo team for it (I got that confirmed some time ago).
Of course, that won't fix any local copies of people but at least the current jar at the maven repo would be fixed.
And, as the JSR-286 team lead gave his OK on doing so, I suggest we do.

>
> Carsten
>

[Ate Douma]

Carsten Ziegeler wrote:

> David Jencks schrieb:
>> I think this is a good idea.
>>
>> I somewhat doubt it would be a good idea but if you wanted the spec jars
>> even farther away we could put them in with the geronimo spec jars.
>>
>> Are these jars the official spec api jars or does sun (or someone else)
>> release those separately?
> They're released separately and we are not allowed to release them on
> our own.

They have not been released to the maven repo by sun (JSR-168) or IBM (JSR-286).
The current (but incorrect with respect to OSGi meta-data) portlet-api-2.0.jar was released to the maven repo by myself actually, and we
have confirmation from the JSR-286 team lead we're actually allowed to do this.
The JCP is only concerned with the official download from the JCP site.

>
>> If it hasn't already been done it might well be a good idea to osgi-ify
>> these jars (and the rest of pluto for that matter) with the maven bundle
>> plugin.
> The 2.0 api jar is an OSGi bundle already - however the official jar is
> buggy
> and we're trying to solve this issue. I'm planning to osgi the other
> pluto jars
> for the release. Thanks to Ate's great work in the past weeks/months we
> have a clean package space now, so adding the manifest information is
> easy to do.
>
> Carsten

[djencks]

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
>

[Ate Douma]

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
>>
>
>

[Ate Douma]

Ate Douma wrote:

> 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"?
>

Or, if using and releasing the offical portlet-api jars is allowed (license wise),
we could also simply "ignore" all this.
But then we should no longer "maintain" these sources, nor move them to a managed
area like /portals/portlet-spec.
Maybe publishing the javadoc there might still be valid, but then probably only the
official docs as downloaded from the JCP, not those generated from our "own" source...

As I said before, I'm very much confused now.

>>
>> 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
>>>
>>
>>
>
>