Should or must Apache Portals create and maintain its own Portlet API (JSR-168/286) spec implementation?

[Ate Douma]

This issue has come up in a discussion on the Pluto dev list last week, and as I think it concerns Apache Portals in general, I'm bringing
this to the general list now for further discussion and hopefully a quick resolution.
We're getting very close to finalizing both Pluto 2.0 and Jetspeed 2.2, both implementing the new JSR-286 spec, so we better decide what to
do with this ASAP.

Please all read and review the original discussion here:

   http://www.nabble.com/-RT--Moving-the-portlet-api-out-of-pluto-tree-td22928540.html

The main question to decide upon is:

Should we create and maintain our own Apache Portals Portlet API spec sources and jars

This would mean we apply our own maven groupId:
   <groupId>org.apache.portals</groupId>

and for the artifactId something like:
   <artifactId>portals-portlet-api_1.0_spec</artifactId>
   <artifactId>portals-portlet-api_2.0_spec</artifactId>

This then will allow us to maintain independent releases of our own spec jars, javadoc, etc.

When we decide the above, we should no longer build against nor release any of the JCP provided spec jars but only use our own.
This will have little consequences for our projects other than some minor maven pom changes and changing our deploy/installation strategies.

Furthermore, the new "home" for our portlet api projects (already started with http://issues.apache.org/jira/browse/PLUTO-548) allows us to
provide easy available online references for (our) portlet api javadoc at http://portals.apache.org/portlet-spec

The critical question however is: are we legally (and license wise) allowed to do the above?
Especially, would "certification" against the JSR-168/JSR-286 by passing their respective TCKs still be still valid, or requires the JCP
(and or TCK) to only use the official spec jars for that?
The sources for the JSR-286 spec are originally created/developed at Pluto and those for the JSR-168 were formally donated by SUN/IBM.
IMO, these sources belong to the "ASF" and we are free to do with them as we decide ourselves, right?

As Geronimo has been doing the same already for years maybe David Jenks can provide a clear answer!

Regards,

Ate

[djencks]

On Apr 15, 2009, at 1:09 AM, Ate Douma wrote:

> This issue has come up in a discussion on the Pluto dev list last  
> week, and as I think it concerns Apache Portals in general, I'm  
> bringing this to the general list now for further discussion and  
> hopefully a quick resolution.
> We're getting very close to finalizing both Pluto 2.0 and Jetspeed  
> 2.2, both implementing the new JSR-286 spec, so we better decide  
> what to do with this ASAP.
>
> Please all read and review the original discussion here:
>
>  http://www.nabble.com/-RT--Moving-the-portlet-api-out-of-pluto-tree-td22928540.html
>
> The main question to decide upon is:
>
> Should we create and maintain our own Apache Portals Portlet API  
> spec sources and jars
>
> This would mean we apply our own maven groupId:
>  <groupId>org.apache.portals</groupId>
>
> and for the artifactId something like:
>  <artifactId>portals-portlet-api_1.0_spec</artifactId>
>  <artifactId>portals-portlet-api_2.0_spec</artifactId>
>
> This then will allow us to maintain independent releases of our own  
> spec jars, javadoc, etc.
>
> When we decide the above, we should no longer build against nor  
> release any of the JCP provided spec jars but only use our own.
> This will have little consequences for our projects other than some  
> minor maven pom changes and changing our deploy/installation  
> strategies.
>
> Furthermore, the new "home" for our portlet api projects (already  
> started with http://issues.apache.org/jira/browse/PLUTO-548) allows  
> us to provide easy available online references for (our) portlet api  
> javadoc at http://portals.apache.org/portlet-spec
>
> The critical question however is: are we legally (and license wise)  
> allowed to do the above?
> Especially, would "certification" against the JSR-168/JSR-286 by  
> passing their respective TCKs still be still valid, or requires the  
> JCP (and or TCK) to only use the official spec jars for that?
> The sources for the JSR-286 spec are originally created/developed at  
> Pluto and those for the JSR-168 were formally donated by SUN/IBM.
> IMO, these sources belong to the "ASF" and we are free to do with  
> them as we decide ourselves, right?
>
> As Geronimo has been doing the same already for years maybe David  
> Jenks can provide a clear answer!

IANAL :-)

I think its a good idea to have apache licensed and distributed spec  
jars. I think that Apache's license to implement the spec includes the  
right to write and distribute our own spec jars.  Sun hasn't objected  
to all the geronimo spec jars and they've been clearly visible for  
years.  I haven't looked at the portlet tcks recently but the ee tck  
certainly includes a signature test to make sure that all the specs  
are present with the correct class signatures.  WIth such tests in the  
tck I can't see any possible problems with our own spec jars.

thanks
david jencks

>
>
> Regards,
>
> Ate
>
>

[David Sean Taylor]

On Apr 15, 2009, at 10:10 AM, David Jencks wrote:

On Apr 15, 2009, at 1:09 AM, Ate Douma wrote:

This issue has come up in a discussion on the Pluto dev list last week, and as I think it concerns Apache Portals in general, I'm bringing this to the general list now for further discussion and hopefully a quick resolution.

We're getting very close to finalizing both Pluto 2.0 and Jetspeed 2.2, both implementing the new JSR-286 spec, so we better decide what to do with this ASAP.

Please all read and review the original discussion here:

http://www.nabble.com/-RT--Moving-the-portlet-api-out-of-pluto-tree-td22928540.html

The main question to decide upon is:

Should we create and maintain our own Apache Portals Portlet API spec sources and jars

This would mean we apply our own maven groupId:

<groupId>org.apache.portals</groupId>

and for the artifactId something like:

<artifactId>portals-portlet-api_1.0_spec</artifactId>

<artifactId>portals-portlet-api_2.0_spec</artifactId>

This then will allow us to maintain independent releases of our own spec jars, javadoc, etc.

When we decide the above, we should no longer build against nor release any of the JCP provided spec jars but only use our own.

This will have little consequences for our projects other than some minor maven pom changes and changing our deploy/installation strategies.

Furthermore, the new "home" for our portlet api projects (already started with http://issues.apache.org/jira/browse/PLUTO-548) allows us to provide easy available online references for (our) portlet api javadoc at http://portals.apache.org/portlet-spec

The critical question however is: are we legally (and license wise) allowed to do the above?

Especially, would "certification" against the JSR-168/JSR-286 by passing their respective TCKs still be still valid, or requires the JCP (and or TCK) to only use the official spec jars for that?

The sources for the JSR-286 spec are originally created/developed at Pluto and those for the JSR-168 were formally donated by SUN/IBM.

IMO, these sources belong to the "ASF" and we are free to do with them as we decide ourselves, right?

As Geronimo has been doing the same already for years maybe David Jenks can provide a clear answer!

IANAL :-)

I think its a good idea to have apache licensed and distributed spec jars. I think that Apache's license to implement the spec includes the right to write and distribute our own spec jars.  Sun hasn't objected to all the geronimo spec jars and they've been clearly visible for years.  I haven't looked at the portlet tcks recently but the ee tck certainly includes a signature test to make sure that all the specs are present with the correct class signatures.  WIth such tests in the tck I can't see any possible problems with our own spec jars.

I thought this wasn't going to be a can of worms ;-)  We have precedence at Geronimo, if we want to take that approach. However, I believe it is safe to JCP jars since they are developed here at Apache,  as you say 

IMO, these sources belong to the "ASF" and we are free to do with them as we decide ourselves, right?

I agree.

But then again, IANAL :-)

[cziegeler]

I've no real strong opinion about this atm; it would be nice if we are
able to release our own portlet api to fix stuff if required; on the
other hand it would be nice if we could just use the official jars.

But I noticed that the source for the portlet api 2.0 in our svn
contains this disclaimer:

/*
 * NOTE: this source code is based on an early draft version of JSR 286
and not intended for product
 * implementations. This file may change or vanish in the final version
of the JSR 286 specification.
 */

I guess we have to change this anyway, right?

Carsten

--
Carsten Ziegeler
cziegeler@...

[Ate Douma]

Carsten Ziegeler wrote:
> I've no real strong opinion about this atm; it would be nice if we are
> able to release our own portlet api to fix stuff if required; on the
> other hand it would be nice if we could just use the official jars.
Well, AFAIK we can use the official jars if we want to, but the problem is where to get them from during a (maven) build.
Although both the portlet-api 1.0 and 2.0 jars are now available from the central repository (the 2.0 pushed out by myself), I now think
that actually was a mistake...
If we can/should (request to) remove those jars or not is a different subject, but from an ASF POV I think we better opt for switching to
using our own spec jars from now on.
So, if you're fine with that, and David Jencks, David Taylor and myself are +1 and nobody else objects, I think we should just go for it.

>
> But I noticed that the source for the portlet api 2.0 in our svn
> contains this disclaimer:
>
> /*
>  * NOTE: this source code is based on an early draft version of JSR 286
> and not intended for product
>  * implementations. This file may change or vanish in the final version
> of the JSR 286 specification.
>  */
>
> I guess we have to change this anyway, right?

That disclaimer clearly is a leftover from when the JSR 286 was still under development.
Yes, I think we should remove/change that now as well.

In addition, there is this license.txt within the source tree containing the following:

   � Copyright IBM Corp. 2006, 2007
   All rights reserved.

Should that file remain or maybe should we move that statement to our NOTICE.txt instead?

Furthermore, every portlet-api-2.0 source file also contains the "Copyright 2006 IBM Corporation." in the header.

Note that none of such copyright statements are found in the portlet-api-1.0 source, not even from SUN.
On the other hand, the portlet-api-1.0 sources do have the ASF 1.1 license header, not the 2.0 license header.
I'm not too familiar with what is required when a new release is put out, but I think if we would do this, those need to be replaced with
ASF 2.0 license headers now, right?

Regards,

Ate

>
> Carsten
>

[djencks]

On Apr 18, 2009, at 1:37 PM, Ate Douma wrote:

> Carsten Ziegeler wrote:
>> I've no real strong opinion about this atm; it would be nice if we  
>> are
>> able to release our own portlet api to fix stuff if required; on the
>> other hand it would be nice if we could just use the official jars.
> Well, AFAIK we can use the official jars if we want to, but the  
> problem is where to get them from during a (maven) build.
> Although both the portlet-api 1.0 and 2.0 jars are now available  
> from the central repository (the 2.0 pushed out by myself), I now  
> think that actually was a mistake...
> If we can/should (request to) remove those jars or not is a  
> different subject, but from an ASF POV I think we better opt for  
> switching to using our own spec jars from now on.
> So, if you're fine with that, and David Jencks, David Taylor and  
> myself are +1 and nobody else objects, I think we should just go for  
> it.
>
>> But I noticed that the source for the portlet api 2.0 in our svn
>> contains this disclaimer:
>> /*
>> * NOTE: this source code is based on an early draft version of JSR  
>> 286
>> and not intended for product
>> * implementations. This file may change or vanish in the final  
>> version
>> of the JSR 286 specification.
>> */
>> I guess we have to change this anyway, right?
> That disclaimer clearly is a leftover from when the JSR 286 was  
> still under development.
> Yes, I think we should remove/change that now as well.
>
> In addition, there is this license.txt within the source tree  
> containing the following:
>
>  � Copyright IBM Corp. 2006, 2007
>  All rights reserved.
>
> Should that file remain or maybe should we move that statement to  
> our NOTICE.txt instead?
>
> Furthermore, every portlet-api-2.0 source file also contains the  
> "Copyright 2006 IBM Corporation." in the header.

IIUC the recommended route is to move these copyright notices to the  
NOTICE file.  However someone from IBM has to do it.  I'm from IBM but  
right now I wouldn't be comfortable removing them without input from  
at least one author or IBM legal.  I'll ask my boss and see what  
happens.

>
>
> Note that none of such copyright statements are found in the portlet-
> api-1.0 source, not even from SUN.
> On the other hand, the portlet-api-1.0 sources do have the ASF 1.1  
> license header, not the 2.0 license header.
> I'm not too familiar with what is required when a new release is put  
> out, but I think if we would do this, those need to be replaced with  
> ASF 2.0 license headers now, right?

yes, and I think we can do that without any legal arguments from anyone.

thanks
david jencks

>
>
> Regards,
>
> Ate
>
>> Carsten
>
>

[cziegeler]

Ate Douma wrote:

> Well, AFAIK we can use the official jars if we want to, but the problem
> is where to get them from during a (maven) build.
> Although both the portlet-api 1.0 and 2.0 jars are now available from
> the central repository (the 2.0 pushed out by myself), I now think that
> actually was a mistake...
> If we can/should (request to) remove those jars or not is a different
> subject, but from an ASF POV I think we better opt for switching to
> using our own spec jars from now on.
> So, if you're fine with that, and David Jencks, David Taylor and myself
> are +1 and nobody else objects, I think we should just go for it.

Yes, rethinking this, I agree, so +1.

Carsten


--
Carsten Ziegeler
cziegeler@...

[Ate Douma]

David Jencks wrote:
>
> On Apr 18, 2009, at 1:37 PM, Ate Douma wrote:
>

<snip/>

>>
>> In addition, there is this license.txt within the source tree
>> containing the following:
>>
>>  � Copyright IBM Corp. 2006, 2007
>>  All rights reserved.
>>
>> Should that file remain or maybe should we move that statement to our
>> NOTICE.txt instead?
>>
>> Furthermore, every portlet-api-2.0 source file also contains the
>> "Copyright 2006 IBM Corporation." in the header.
>
> IIUC the recommended route is to move these copyright notices to the
> NOTICE file.  However someone from IBM has to do it.  I'm from IBM but
> right now I wouldn't be comfortable removing them without input from at
> least one author or IBM legal.  I'll ask my boss and see what happens.

David Jencks, do you have any feedback on this issue?
I'd like to move forward with this proposal ASAP but its a little unclear to me how we can and/or are allowed to proceed now.

I would think at least we are allowed to *add* the ASF licence header to the sources while (for now) retaining the the IBM copyright notices
therein.
And the license.txt file I would think should be fine to be removed when we move the content to our own NOTICE file.
The remaining question for me is, should we only provide the standard ASF LICENSE file, or should that in addition *also* contain the
content of the original IBM license.txt?

Thanks,

Ate

>
>>
>>
>> Note that none of such copyright statements are found in the
>> portlet-api-1.0 source, not even from SUN.
>> On the other hand, the portlet-api-1.0 sources do have the ASF 1.1
>> license header, not the 2.0 license header.
>> I'm not too familiar with what is required when a new release is put
>> out, but I think if we would do this, those need to be replaced with
>> ASF 2.0 license headers now, right?
>
> yes, and I think we can do that without any legal arguments from anyone.
>
> thanks
> david jencks
>
>>
>>
>> Regards,
>>
>> Ate
>>
>>> Carsten
>>
>>
>
>

[djencks]

Hi Ate,

I haven't heard back from my manager yet, I pinged him again.  I think  
it's ok to add the apache license header for now, but it would  
definitely be better to get it fixed, especially as the existing  
license.txt file does not contain a license at all.

thanks
david jencks

On May 4, 2009, at 3:26 AM, Ate Douma wrote:

> David Jencks wrote:
>> On Apr 18, 2009, at 1:37 PM, Ate Douma wrote:
>
> <snip/>
>
>>>
>>> In addition, there is this license.txt within the source tree  
>>> containing the following:
>>>
>>> � Copyright IBM Corp. 2006, 2007
>>> All rights reserved.
>>>
>>> Should that file remain or maybe should we move that statement to  
>>> our NOTICE.txt instead?
>>>
>>> Furthermore, every portlet-api-2.0 source file also contains the  
>>> "Copyright 2006 IBM Corporation." in the header.
>> IIUC the recommended route is to move these copyright notices to  
>> the NOTICE file.  However someone from IBM has to do it.  I'm from  
>> IBM but right now I wouldn't be comfortable removing them without  
>> input from at least one author or IBM legal.  I'll ask my boss and  
>> see what happens.
>
> David Jencks, do you have any feedback on this issue?
> I'd like to move forward with this proposal ASAP but its a little  
> unclear to me how we can and/or are allowed to proceed now.
>
> I would think at least we are allowed to *add* the ASF licence  
> header to the sources while (for now) retaining the the IBM  
> copyright notices therein.
> And the license.txt file I would think should be fine to be removed  
> when we move the content to our own NOTICE file.
> The remaining question for me is, should we only provide the  
> standard ASF LICENSE file, or should that in addition *also* contain  
> the content of the original IBM license.txt?
>
> Thanks,
>
> Ate
>
>>>
>>>
>>> Note that none of such copyright statements are found in the  
>>> portlet-api-1.0 source, not even from SUN.
>>> On the other hand, the portlet-api-1.0 sources do have the ASF 1.1  
>>> license header, not the 2.0 license header.
>>> I'm not too familiar with what is required when a new release is  
>>> put out, but I think if we would do this, those need to be  
>>> replaced with ASF 2.0 license headers now, right?
>> yes, and I think we can do that without any legal arguments from  
>> anyone.
>> thanks
>> david jencks
>>>
>>>
>>> Regards,
>>>
>>> Ate
>>>
>>>> Carsten
>>>
>>>
>
>

[djencks]

My manager thinks it's OK for me, as an IBM employee, to update the  
sources to conform with apache standards, I will try to get to it  
today or tomorrow.

thanks
david jencks

On May 4, 2009, at 4:35 PM, David Jencks wrote:

> Hi Ate,
>
> I haven't heard back from my manager yet, I pinged him again.  I  
> think it's ok to add the apache license header for now, but it would  
> definitely be better to get it fixed, especially as the existing  
> license.txt file does not contain a license at all.
>
> thanks
> david jencks
>
> On May 4, 2009, at 3:26 AM, Ate Douma wrote:
>
>> David Jencks wrote:
>>> On Apr 18, 2009, at 1:37 PM, Ate Douma wrote:
>>
>> <snip/>
>>
>>>>
>>>> In addition, there is this license.txt within the source tree  
>>>> containing the following:
>>>>
>>>> � Copyright IBM Corp. 2006, 2007
>>>> All rights reserved.
>>>>
>>>> Should that file remain or maybe should we move that statement to  
>>>> our NOTICE.txt instead?
>>>>
>>>> Furthermore, every portlet-api-2.0 source file also contains the  
>>>> "Copyright 2006 IBM Corporation." in the header.
>>> IIUC the recommended route is to move these copyright notices to  
>>> the NOTICE file.  However someone from IBM has to do it.  I'm from  
>>> IBM but right now I wouldn't be comfortable removing them without  
>>> input from at least one author or IBM legal.  I'll ask my boss and  
>>> see what happens.
>>
>> David Jencks, do you have any feedback on this issue?
>> I'd like to move forward with this proposal ASAP but its a little  
>> unclear to me how we can and/or are allowed to proceed now.
>>
>> I would think at least we are allowed to *add* the ASF licence  
>> header to the sources while (for now) retaining the the IBM  
>> copyright notices therein.
>> And the license.txt file I would think should be fine to be removed  
>> when we move the content to our own NOTICE file.
>> The remaining question for me is, should we only provide the  
>> standard ASF LICENSE file, or should that in addition *also*  
>> contain the content of the original IBM license.txt?
>>
>> Thanks,
>>
>> Ate
>>
>>>>
>>>>
>>>> Note that none of such copyright statements are found in the  
>>>> portlet-api-1.0 source, not even from SUN.
>>>> On the other hand, the portlet-api-1.0 sources do have the ASF  
>>>> 1.1 license header, not the 2.0 license header.
>>>> I'm not too familiar with what is required when a new release is  
>>>> put out, but I think if we would do this, those need to be  
>>>> replaced with ASF 2.0 license headers now, right?
>>> yes, and I think we can do that without any legal arguments from  
>>> anyone.
>>> thanks
>>> david jencks
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Ate
>>>>
>>>>> Carsten
>>>>
>>>>
>>
>>
>

[Ate Douma]

David Jencks wrote:
> My manager thinks it's OK for me, as an IBM employee, to update the
> sources to conform with apache standards, I will try to get to it today
> or tomorrow.
Cool!

Thanks for helping out with this David.

Regards,

Ate

>
> thanks
> david jencks
>
> On May 4, 2009, at 4:35 PM, David Jencks wrote:
>
>> Hi Ate,
>>
>> I haven't heard back from my manager yet, I pinged him again.  I think
>> it's ok to add the apache license header for now, but it would
>> definitely be better to get it fixed, especially as the existing
>> license.txt file does not contain a license at all.
>>
>> thanks
>> david jencks
>>
>> On May 4, 2009, at 3:26 AM, Ate Douma wrote:
>>
>>> David Jencks wrote:
>>>> On Apr 18, 2009, at 1:37 PM, Ate Douma wrote:
>>>
>>> <snip/>
>>>
>>>>>
>>>>> In addition, there is this license.txt within the source tree
>>>>> containing the following:
>>>>>
>>>>> � Copyright IBM Corp. 2006, 2007
>>>>> All rights reserved.
>>>>>
>>>>> Should that file remain or maybe should we move that statement to
>>>>> our NOTICE.txt instead?
>>>>>
>>>>> Furthermore, every portlet-api-2.0 source file also contains the
>>>>> "Copyright 2006 IBM Corporation." in the header.
>>>> IIUC the recommended route is to move these copyright notices to the
>>>> NOTICE file.  However someone from IBM has to do it.  I'm from IBM
>>>> but right now I wouldn't be comfortable removing them without input
>>>> from at least one author or IBM legal.  I'll ask my boss and see
>>>> what happens.
>>>
>>> David Jencks, do you have any feedback on this issue?
>>> I'd like to move forward with this proposal ASAP but its a little
>>> unclear to me how we can and/or are allowed to proceed now.
>>>
>>> I would think at least we are allowed to *add* the ASF licence header
>>> to the sources while (for now) retaining the the IBM copyright
>>> notices therein.
>>> And the license.txt file I would think should be fine to be removed
>>> when we move the content to our own NOTICE file.
>>> The remaining question for me is, should we only provide the standard
>>> ASF LICENSE file, or should that in addition *also* contain the
>>> content of the original IBM license.txt?
>>>
>>> Thanks,
>>>
>>> Ate
>>>
>>>>>
>>>>>
>>>>> Note that none of such copyright statements are found in the
>>>>> portlet-api-1.0 source, not even from SUN.
>>>>> On the other hand, the portlet-api-1.0 sources do have the ASF 1.1
>>>>> license header, not the 2.0 license header.
>>>>> I'm not too familiar with what is required when a new release is
>>>>> put out, but I think if we would do this, those need to be replaced
>>>>> with ASF 2.0 license headers now, right?
>>>> yes, and I think we can do that without any legal arguments from
>>>> anyone.
>>>> thanks
>>>> david jencks
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Ate
>>>>>
>>>>>> Carsten
>>>>>
>>>>>
>>>
>>>
>>
>
>

[djencks]

See https://issues.apache.org/jira/browse/PORTALS-12 and https://issues.apache.org/jira/browse/PORTALS-13

portlet 2.0:
I removed the ibm copyrights from the source files and the license.txt  
file and added the copyright notice to the NOTICE file. I added the  
portals-pom as parent and used the maven-remote-resources plugin to  
generate the LICENSE and NOTICE files.  I also added the LICENSE and  
NOTICE files to the root of the svn source.

portlet 1.0:
I changed the license header from apache 1.1 to the current header,  
allowing its release post- march-2004 :-).  I also added the portals-
pom as parent and used the maven-remote-resources plugin to generate  
the requred LICENSE and NOTICE files, and added these at the root of  
svn source.

Other stuff I think needs to happen:

1. remove the portlet.xml.txt files unless they serve some actual  
purpose.
2. in 2.0, remove the statement that the spec is provisional found in  
every file
3. remove the portal-site src and pom completely, use the maven  
generated site instead for each spec level.
4. make the svn tree look like:

https://svn.apache.org/repos/asf/portals/portlet-spec
   +tags
   \trunk
     +portlet-api-1.0
     \portlet-api-2.0

Somewhat to my surprise we've found this structure to work fine with  
the geronimo specs and the release plugin.

5. use the felix bundle plugin to insert osgi metadata
6. remove just about everything from the poms and use the release  
profile instead
7. make the portals-pom specify use of m-r-r-plugin always.
8 update portals-pom to use apache 6 pom as soon as it's available.

9. (maybe) maybe I'm biased :-) but I prefer to use geronimo servlet  
specs because I know a bit about their quality.  I'd rather build  
against the geronimo servlet 2.5 spec even though it's uplevel for  
what's needed than the 2.3 and 2.4 servlet specs that I don't know  
much about.

If everyone agrees these are good changes I think I could find the  
time to do them soon.  I'd also be happy if someone else does them :-)

thanks
david jencks

On May 6, 2009, at 1:00 PM, Ate Douma wrote:

> David Jencks wrote:
>> My manager thinks it's OK for me, as an IBM employee, to update the  
>> sources to conform with apache standards, I will try to get to it  
>> today or tomorrow.
> Cool!
>
> Thanks for helping out with this David.
>
> Regards,
>
> Ate
>
>> thanks
>> david jencks
>> On May 4, 2009, at 4:35 PM, David Jencks wrote:
>>> Hi Ate,
>>>
>>> I haven't heard back from my manager yet, I pinged him again.  I  
>>> think it's ok to add the apache license header for now, but it  
>>> would definitely be better to get it fixed, especially as the  
>>> existing license.txt file does not contain a license at all.
>>>
>>> thanks
>>> david jencks
>>>
>>> On May 4, 2009, at 3:26 AM, Ate Douma wrote:
>>>
>>>> David Jencks wrote:
>>>>> On Apr 18, 2009, at 1:37 PM, Ate Douma wrote:
>>>>
>>>> <snip/>
>>>>
>>>>>>
>>>>>> In addition, there is this license.txt within the source tree  
>>>>>> containing the following:
>>>>>>
>>>>>> � Copyright IBM Corp. 2006, 2007
>>>>>> All rights reserved.
>>>>>>
>>>>>> Should that file remain or maybe should we move that statement  
>>>>>> to our NOTICE.txt instead?
>>>>>>
>>>>>> Furthermore, every portlet-api-2.0 source file also contains  
>>>>>> the "Copyright 2006 IBM Corporation." in the header.
>>>>> IIUC the recommended route is to move these copyright notices to  
>>>>> the NOTICE file.  However someone from IBM has to do it.  I'm  
>>>>> from IBM but right now I wouldn't be comfortable removing them  
>>>>> without input from at least one author or IBM legal.  I'll ask  
>>>>> my boss and see what happens.
>>>>
>>>> David Jencks, do you have any feedback on this issue?
>>>> I'd like to move forward with this proposal ASAP but its a little  
>>>> unclear to me how we can and/or are allowed to proceed now.
>>>>
>>>> I would think at least we are allowed to *add* the ASF licence  
>>>> header to the sources while (for now) retaining the the IBM  
>>>> copyright notices therein.
>>>> And the license.txt file I would think should be fine to be  
>>>> removed when we move the content to our own NOTICE file.
>>>> The remaining question for me is, should we only provide the  
>>>> standard ASF LICENSE file, or should that in addition *also*  
>>>> contain the content of the original IBM license.txt?
>>>>
>>>> Thanks,
>>>>
>>>> Ate
>>>>
>>>>>>
>>>>>>
>>>>>> Note that none of such copyright statements are found in the  
>>>>>> portlet-api-1.0 source, not even from SUN.
>>>>>> On the other hand, the portlet-api-1.0 sources do have the ASF  
>>>>>> 1.1 license header, not the 2.0 license header.
>>>>>> I'm not too familiar with what is required when a new release  
>>>>>> is put out, but I think if we would do this, those need to be  
>>>>>> replaced with ASF 2.0 license headers now, right?
>>>>> yes, and I think we can do that without any legal arguments from  
>>>>> anyone.
>>>>> thanks
>>>>> david jencks
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Ate
>>>>>>
>>>>>>> Carsten
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>
>

[Ate Douma]

Hi David,

First of all, thanks again for helping out on this!

I have some inline comments below.

Regards,

Ate

David Jencks wrote:

> See https://issues.apache.org/jira/browse/PORTALS-12 and
> https://issues.apache.org/jira/browse/PORTALS-13
>
> portlet 2.0:
> I removed the ibm copyrights from the source files and the license.txt
> file and added the copyright notice to the NOTICE file. I added the
> portals-pom as parent and used the maven-remote-resources plugin to
> generate the LICENSE and NOTICE files.  I also added the LICENSE and
> NOTICE files to the root of the svn source.
>
> portlet 1.0:
> I changed the license header from apache 1.1 to the current header,
> allowing its release post- march-2004 :-).  I also added the portals-pom
> as parent and used the maven-remote-resources plugin to generate the
> requred LICENSE and NOTICE files, and added these at the root of svn
> source.
>
> Other stuff I think needs to happen:
>
> 1. remove the portlet.xml.txt files unless they serve some actual purpose.

+1, I don't see any purpose at all.
It is just an example portlet.xml which I think accidentally landed in the source tree.

> 2. in 2.0, remove the statement that the spec is provisional found in
> every file
+1

> 3. remove the portal-site src and pom completely, use the maven
> generated site instead for each spec level.
We have some other plans about site management for all of portals by moving that out of the main release cycle svn trees for each project
and instead maintain it separately (without trunk/tags folders) based off /portals/site, with a master portals-site pom and sub projects
inherit from it (but not necessarily as parent pom modules as maven-site plugin is too broken to deal with that correctly).
This does pose a problem for code based generated docs like reports and javadoc, but I think we can and should simply check those in and
integrate them manually in the corresponding (sub) project site xdocs.
Anyway, I'll write a formal proposal/vote email for doing this for all Portals projects shortly, and then in more detail.

> 4. make the svn tree look like:
>
> https://svn.apache.org/repos/asf/portals/portlet-spec
>   +tags
>   \trunk
>     +portlet-api-1.0
>     \portlet-api-2.0
+1

>
> Somewhat to my surprise we've found this structure to work fine with the
> geronimo specs and the release plugin.
>
> 5. use the felix bundle plugin to insert osgi metadata
+0, we already do this for portlet-api-2.0 within the pom itself, not sure if more is needed here.
I guess Carsten might have some additional ideas about this.

> 6. remove just about everything from the poms and use the release
> profile instead
+1, we're about to provide a vote on an updated portals-pom-1.1 which will use apache 6 pom

> 7. make the portals-pom specify use of m-r-r-plugin always.
You mean maven-remote-resources-plugin, right?
Probably +1, haven't reviewed in detail what possible side-effects that could have though.

> 8 update portals-pom to use apache 6 pom as soon as it's available.
See above, and FYI: apache 6 pom is already released and available

>
> 9. (maybe) maybe I'm biased :-) but I prefer to use geronimo servlet
> specs because I know a bit about their quality.  I'd rather build
> against the geronimo servlet 2.5 spec even though it's uplevel for
> what's needed than the 2.3 and 2.4 servlet specs that I don't know much
> about.
-1
Not all end users are using a servlet 2.5 container yet, and adding a dependency on that could cause problems if they inadvertently then
would use features from that not supported in their runtime environment.

>
> If everyone agrees these are good changes I think I could find the time
> to do them soon.  I'd also be happy if someone else does them :-)
Whoever gets there first :)
You're very welcome to help out further with this, much appreciated.

>
> thanks
> david jencks
>
> On May 6, 2009, at 1:00 PM, Ate Douma wrote:
>
>> David Jencks wrote:
>>> My manager thinks it's OK for me, as an IBM employee, to update the
>>> sources to conform with apache standards, I will try to get to it
>>> today or tomorrow.
>> Cool!
>>
>> Thanks for helping out with this David.
>>
>> Regards,
>>
>> Ate
>>
>>> thanks
>>> david jencks
>>> On May 4, 2009, at 4:35 PM, David Jencks wrote:
>>>> Hi Ate,
>>>>
>>>> I haven't heard back from my manager yet, I pinged him again.  I
>>>> think it's ok to add the apache license header for now, but it would
>>>> definitely be better to get it fixed, especially as the existing
>>>> license.txt file does not contain a license at all.
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On May 4, 2009, at 3:26 AM, Ate Douma wrote:
>>>>
>>>>> David Jencks wrote:
>>>>>> On Apr 18, 2009, at 1:37 PM, Ate Douma wrote:
>>>>>
>>>>> <snip/>
>>>>>
>>>>>>>
>>>>>>> In addition, there is this license.txt within the source tree
>>>>>>> containing the following:
>>>>>>>
>>>>>>> � Copyright IBM Corp. 2006, 2007
>>>>>>> All rights reserved.
>>>>>>>
>>>>>>> Should that file remain or maybe should we move that statement to
>>>>>>> our NOTICE.txt instead?
>>>>>>>
>>>>>>> Furthermore, every portlet-api-2.0 source file also contains the
>>>>>>> "Copyright 2006 IBM Corporation." in the header.
>>>>>> IIUC the recommended route is to move these copyright notices to
>>>>>> the NOTICE file.  However someone from IBM has to do it.  I'm from
>>>>>> IBM but right now I wouldn't be comfortable removing them without
>>>>>> input from at least one author or IBM legal.  I'll ask my boss and
>>>>>> see what happens.
>>>>>
>>>>> David Jencks, do you have any feedback on this issue?
>>>>> I'd like to move forward with this proposal ASAP but its a little
>>>>> unclear to me how we can and/or are allowed to proceed now.
>>>>>
>>>>> I would think at least we are allowed to *add* the ASF licence
>>>>> header to the sources while (for now) retaining the the IBM
>>>>> copyright notices therein.
>>>>> And the license.txt file I would think should be fine to be removed
>>>>> when we move the content to our own NOTICE file.
>>>>> The remaining question for me is, should we only provide the
>>>>> standard ASF LICENSE file, or should that in addition *also*
>>>>> contain the content of the original IBM license.txt?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Ate
>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Note that none of such copyright statements are found in the
>>>>>>> portlet-api-1.0 source, not even from SUN.
>>>>>>> On the other hand, the portlet-api-1.0 sources do have the ASF
>>>>>>> 1.1 license header, not the 2.0 license header.
>>>>>>> I'm not too familiar with what is required when a new release is
>>>>>>> put out, but I think if we would do this, those need to be
>>>>>>> replaced with ASF 2.0 license headers now, right?
>>>>>> yes, and I think we can do that without any legal arguments from
>>>>>> anyone.
>>>>>> thanks
>>>>>> david jencks
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Ate
>>>>>>>
>>>>>>>> Carsten
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>
>

[djencks]

I've been working on this, see PORTALS-14.

I updated to use the portals 1.1 pom now under vote.  I have some  
comments in that thread.

It may or may not be a good idea, but I updated the names to portlet-
api_x.0_spec with version 1.0-SNAPSHOT for both specs.  If we don't  
like it we can change it back.

I added use of the felix bundle plugin for osgi metadata.  It is  
generating different info than the hand-supplied info previously in  
the 2.0 spec.  Here's what the bundle plugin comes up with:

Manifest-Version: 1.0
Export-Package: javax.portlet.filter;uses:="javax.portlet,org.w3c.dom,
  javax.servlet.http,javax.xml.namespace";version="1.0.0.SNAPSHOT",java
  x.portlet;uses:="org.w3c.dom,javax.servlet.http,javax.xml.namespace";
  version="1.0.0.SNAPSHOT"
Implementation-Title: Java Portlet Specification V2.0
Implementation-Version: 1.0-SNAPSHOT
Tool: Bnd-0.0.227
Bundle-Name: portlet-api_2.0_spec
Created-By: 1.6.0_07 (Apple Inc.)
Bundle-Vendor: Apache Software Foundation
Bundle-Version: 1.0.0.SNAPSHOT
Bnd-LastModified: 1241824729053
Bundle-ManifestVersion: 2
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.html
Bundle-Description: The Java Portlet API version 2.0 developed by the
  Java Community Process JSR-286 Expert Group.
Import-Package: javax.portlet;version="1.0.0.SNAPSHOT",javax.portlet.f
  ilter;version="1.0.0.SNAPSHOT",javax.servlet.http,javax.xml.namespace
  ,org.w3c.dom
Bundle-SymbolicName: javax.portlet.portlet-api_2.0_spec
Bundle-DocURL: http://portals.apache.org/

Here's the manually constructed manifest:

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: david
Build-Jdk: 1.6.0_07
Specification-Title: Java Portlet Specification V2.0
Specification-Version: 1.0-SNAPSHOT
Specification-Vendor: Apache Software Foundation
Implementation-Title: Java Portlet Specification V2.0
Implementation-Version: 1.0-SNAPSHOT
Implementation-Vendor-Id: javax.portlet
Implementation-Vendor: Apache Software Foundation
Bundle-DocURL: http://www.jcp.org/en/jsr/detail?id=286
Bundle-ManifestVersion: 2
Bundle-Name: JSR 286
Bundle-SymbolicName: javax.portlet
Bundle-Version: 2.0
Export-Package: javax.portlet;version="2.0.0",
                    javax.portlet.filter;version="2.0.0"
Import-Package: org.w3c.dom,
                    javax.xml.namespace,
                    javax.servlet.http; version="2.4.0"


I'm not enough of an osgi expert to completely understand these  
but..... there are some obvious problems with the felix-generated  
entries in the version of import/exports.  However at this point I'd  
like to investigate what's going on with this a bit more before  
recommending one or the other approach.

thanks
david jencks

On May 8, 2009, at 12:55 AM, Ate Douma wrote:

> Hi David,
>
> First of all, thanks again for helping out on this!
>
> I have some inline comments below.
>
> Regards,
>
> Ate
>
> David Jencks wrote:
>> See https://issues.apache.org/jira/browse/PORTALS-12 and https://issues.apache.org/jira/browse/PORTALS-13
>> portlet 2.0:
>> I removed the ibm copyrights from the source files and the  
>> license.txt file and added the copyright notice to the NOTICE file.  
>> I added the portals-pom as parent and used the maven-remote-
>> resources plugin to generate the LICENSE and NOTICE files.  I also  
>> added the LICENSE and NOTICE files to the root of the svn source.
>> portlet 1.0:
>> I changed the license header from apache 1.1 to the current header,  
>> allowing its release post- march-2004 :-).  I also added the  
>> portals-pom as parent and used the maven-remote-resources plugin to  
>> generate the requred LICENSE and NOTICE files, and added these at  
>> the root of svn source.
>> Other stuff I think needs to happen:
>> 1. remove the portlet.xml.txt files unless they serve some actual  
>> purpose.
> +1, I don't see any purpose at all.
> It is just an example portlet.xml which I think accidentally landed  
> in the source tree.
>
>> 2. in 2.0, remove the statement that the spec is provisional found  
>> in every file
> +1
>
>> 3. remove the portal-site src and pom completely, use the maven  
>> generated site instead for each spec level.
> We have some other plans about site management for all of portals by  
> moving that out of the main release cycle svn trees for each project  
> and instead maintain it separately (without trunk/tags folders)  
> based off /portals/site, with a master portals-site pom and sub  
> projects inherit from it (but not necessarily as parent pom modules  
> as maven-site plugin is too broken to deal with that correctly).
> This does pose a problem for code based generated docs like reports  
> and javadoc, but I think we can and should simply check those in and  
> integrate them manually in the corresponding (sub) project site xdocs.
> Anyway, I'll write a formal proposal/vote email for doing this for  
> all Portals projects shortly, and then in more detail.
>
>> 4. make the svn tree look like:
>> https://svn.apache.org/repos/asf/portals/portlet-spec
>>  +tags
>>  \trunk
>>    +portlet-api-1.0
>>    \portlet-api-2.0
> +1
>
>> Somewhat to my surprise we've found this structure to work fine  
>> with the geronimo specs and the release plugin.
>> 5. use the felix bundle plugin to insert osgi metadata
> +0, we already do this for portlet-api-2.0 within the pom itself,  
> not sure if more is needed here.
> I guess Carsten might have some additional ideas about this.
>
>> 6. remove just about everything from the poms and use the release  
>> profile instead
> +1, we're about to provide a vote on an updated portals-pom-1.1  
> which will use apache 6 pom
>
>> 7. make the portals-pom specify use of m-r-r-plugin always.
> You mean maven-remote-resources-plugin, right?
> Probably +1, haven't reviewed in detail what possible side-effects  
> that could have though.
>
>> 8 update portals-pom to use apache 6 pom as soon as it's available.
> See above, and FYI: apache 6 pom is already released and available
>
>> 9. (maybe) maybe I'm biased :-) but I prefer to use geronimo  
>> servlet specs because I know a bit about their quality.  I'd rather  
>> build against the geronimo servlet 2.5 spec even though it's  
>> uplevel for what's needed than the 2.3 and 2.4 servlet specs that I  
>> don't know much about.
> -1
> Not all end users are using a servlet 2.5 container yet, and adding  
> a dependency on that could cause problems if they inadvertently then  
> would use features from that not supported in their runtime  
> environment.
>
>> If everyone agrees these are good changes I think I could find the  
>> time to do them soon.  I'd also be happy if someone else does  
>> them :-)
> Whoever gets there first :)
> You're very welcome to help out further with this, much appreciated.
>
>> thanks
>> david jencks
>> On May 6, 2009, at 1:00 PM, Ate Douma wrote:
>>> David Jencks wrote:
>>>> My manager thinks it's OK for me, as an IBM employee, to update  
>>>> the sources to conform with apache standards, I will try to get  
>>>> to it today or tomorrow.
>>> Cool!
>>>
>>> Thanks for helping out with this David.
>>>
>>> Regards,
>>>
>>> Ate
>>>
>>>> thanks
>>>> david jencks
>>>> On May 4, 2009, at 4:35 PM, David Jencks wrote:
>>>>> Hi Ate,
>>>>>
>>>>> I haven't heard back from my manager yet, I pinged him again.  I  
>>>>> think it's ok to add the apache license header for now, but it  
>>>>> would definitely be better to get it fixed, especially as the  
>>>>> existing license.txt file does not contain a license at all.
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>> On May 4, 2009, at 3:26 AM, Ate Douma wrote:
>>>>>
>>>>>> David Jencks wrote:
>>>>>>> On Apr 18, 2009, at 1:37 PM, Ate Douma wrote:
>>>>>>
>>>>>> <snip/>
>>>>>>
>>>>>>>>
>>>>>>>> In addition, there is this license.txt within the source tree  
>>>>>>>> containing the following:
>>>>>>>>
>>>>>>>> � Copyright IBM Corp. 2006, 2007
>>>>>>>> All rights reserved.
>>>>>>>>
>>>>>>>> Should that file remain or maybe should we move that  
>>>>>>>> statement to our NOTICE.txt instead?
>>>>>>>>
>>>>>>>> Furthermore, every portlet-api-2.0 source file also contains  
>>>>>>>> the "Copyright 2006 IBM Corporation." in the header.
>>>>>>> IIUC the recommended route is to move these copyright notices  
>>>>>>> to the NOTICE file.  However someone from IBM has to do it.  
>>>>>>> I'm from IBM but right now I wouldn't be comfortable removing  
>>>>>>> them without input from at least one author or IBM legal.  
>>>>>>> I'll ask my boss and see what happens.
>>>>>>
>>>>>> David Jencks, do you have any feedback on this issue?
>>>>>> I'd like to move forward with this proposal ASAP but its a  
>>>>>> little unclear to me how we can and/or are allowed to proceed  
>>>>>> now.
>>>>>>
>>>>>> I would think at least we are allowed to *add* the ASF licence  
>>>>>> header to the sources while (for now) retaining the the IBM  
>>>>>> copyright notices therein.
>>>>>> And the license.txt file I would think should be fine to be  
>>>>>> removed when we move the content to our own NOTICE file.
>>>>>> The remaining question for me is, should we only provide the  
>>>>>> standard ASF LICENSE file, or should that in addition *also*  
>>>>>> contain the content of the original IBM license.txt?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Ate
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Note that none of such copyright statements are found in the  
>>>>>>>> portlet-api-1.0 source, not even from SUN.
>>>>>>>> On the other hand, the portlet-api-1.0 sources do have the  
>>>>>>>> ASF 1.1 license header, not the 2.0 license header.
>>>>>>>> I'm not too familiar with what is required when a new release  
>>>>>>>> is put out, but I think if we would do this, those need to be  
>>>>>>>> replaced with ASF 2.0 license headers now, right?
>>>>>>> yes, and I think we can do that without any legal arguments  
>>>>>>> from anyone.
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Ate
>>>>>>>>
>>>>>>>>> Carsten
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>
>

[djencks]

Also, does apache have an appropriately licensed copy of one or both  
portlet xsds?  In geronimo IIRC we ended up typing up the schemas  
without any comments. This was unpleasant.... if there's a real copy  
we can have in svn that would be great.

thanks
david jencks


On May 8, 2009, at 4:38 PM, David Jencks wrote:

> I've been working on this, see PORTALS-14.
>
> I updated to use the portals 1.1 pom now under vote.  I have some  
> comments in that thread.
>
> It may or may not be a good idea, but I updated the names to portlet-
> api_x.0_spec with version 1.0-SNAPSHOT for both specs.  If we don't  
> like it we can change it back.
>
> I added use of the felix bundle plugin for osgi metadata.  It is  
> generating different info than the hand-supplied info previously in  
> the 2.0 spec.  Here's what the bundle plugin comes up with:
>
> Manifest-Version: 1.0
> Export-Package: javax.portlet.filter;uses:="javax.portlet,org.w3c.dom,
> javax.servlet.http,javax.xml.namespace";version="1.0.0.SNAPSHOT",java
> x.portlet;uses:="org.w3c.dom,javax.servlet.http,javax.xml.namespace";
> version="1.0.0.SNAPSHOT"
> Implementation-Title: Java Portlet Specification V2.0
> Implementation-Version: 1.0-SNAPSHOT
> Tool: Bnd-0.0.227
> Bundle-Name: portlet-api_2.0_spec
> Created-By: 1.6.0_07 (Apple Inc.)
> Bundle-Vendor: Apache Software Foundation
> Bundle-Version: 1.0.0.SNAPSHOT
> Bnd-LastModified: 1241824729053
> Bundle-ManifestVersion: 2
> Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.html
> Bundle-Description: The Java Portlet API version 2.0 developed by the
> Java Community Process JSR-286 Expert Group.
> Import-Package: javax.portlet;version="1.0.0.SNAPSHOT",javax.portlet.f
> ilter;version="1.0.0.SNAPSHOT",javax.servlet.http,javax.xml.namespace
> ,org.w3c.dom
> Bundle-SymbolicName: javax.portlet.portlet-api_2.0_spec
> Bundle-DocURL: http://portals.apache.org/
>
> Here's the manually constructed manifest:
>
> Manifest-Version: 1.0
> Archiver-Version: Plexus Archiver
> Created-By: Apache Maven
> Built-By: david
> Build-Jdk: 1.6.0_07
> Specification-Title: Java Portlet Specification V2.0
> Specification-Version: 1.0-SNAPSHOT
> Specification-Vendor: Apache Software Foundation
> Implementation-Title: Java Portlet Specification V2.0
> Implementation-Version: 1.0-SNAPSHOT
> Implementation-Vendor-Id: javax.portlet
> Implementation-Vendor: Apache Software Foundation
> Bundle-DocURL: http://www.jcp.org/en/jsr/detail?id=286
> Bundle-ManifestVersion: 2
> Bundle-Name: JSR 286
> Bundle-SymbolicName: javax.portlet
> Bundle-Version: 2.0
> Export-Package: javax.portlet;version="2.0.0",
>                   javax.portlet.filter;version="2.0.0"
> Import-Package: org.w3c.dom,
>                   javax.xml.namespace,
>                   javax.servlet.http; version="2.4.0"
>
>
> I'm not enough of an osgi expert to completely understand these  
> but..... there are some obvious problems with the felix-generated  
> entries in the version of import/exports.  However at this point I'd  
> like to investigate what's going on with this a bit more before  
> recommending one or the other approach.
>
> thanks
> david jencks
>
> On May 8, 2009, at 12:55 AM, Ate Douma wrote:
>
>> Hi David,
>>
>> First of all, thanks again for helping out on this!
>>
>> I have some inline comments below.
>>
>> Regards,
>>
>> Ate
>>
>> David Jencks wrote:
>>> See https://issues.apache.org/jira/browse/PORTALS-12 and https://issues.apache.org/jira/browse/PORTALS-13
>>> portlet 2.0:
>>> I removed the ibm copyrights from the source files and the  
>>> license.txt file and added the copyright notice to the NOTICE  
>>> file. I added the portals-pom as parent and used the maven-remote-
>>> resources plugin to generate the LICENSE and NOTICE files.  I also  
>>> added the LICENSE and NOTICE files to the root of the svn source.
>>> portlet 1.0:
>>> I changed the license header from apache 1.1 to the current  
>>> header, allowing its release post- march-2004 :-).  I also added  
>>> the portals-pom as parent and used the maven-remote-resources  
>>> plugin to generate the requred LICENSE and NOTICE files, and added  
>>> these at the root of svn source.
>>> Other stuff I think needs to happen:
>>> 1. remove the portlet.xml.txt files unless they serve some actual  
>>> purpose.
>> +1, I don't see any purpose at all.
>> It is just an example portlet.xml which I think accidentally landed  
>> in the source tree.
>>
>>> 2. in 2.0, remove the statement that the spec is provisional found  
>>> in every file
>> +1
>>
>>> 3. remove the portal-site src and pom completely, use the maven  
>>> generated site instead for each spec level.
>> We have some other plans about site management for all of portals  
>> by moving that out of the main release cycle svn trees for each  
>> project and instead maintain it separately (without trunk/tags  
>> folders) based off /portals/site, with a master portals-site pom  
>> and sub projects inherit from it (but not necessarily as parent pom  
>> modules as maven-site plugin is too broken to deal with that  
>> correctly).
>> This does pose a problem for code based generated docs like reports  
>> and javadoc, but I think we can and should simply check those in  
>> and integrate them manually in the corresponding (sub) project site  
>> xdocs.
>> Anyway, I'll write a formal proposal/vote email for doing this for  
>> all Portals projects shortly, and then in more detail.
>>
>>> 4. make the svn tree look like:
>>> https://svn.apache.org/repos/asf/portals/portlet-spec
>>> +tags
>>> \trunk
>>>   +portlet-api-1.0
>>>   \portlet-api-2.0
>> +1
>>
>>> Somewhat to my surprise we've found this structure to work fine  
>>> with the geronimo specs and the release plugin.
>>> 5. use the felix bundle plugin to insert osgi metadata
>> +0, we already do this for portlet-api-2.0 within the pom itself,  
>> not sure if more is needed here.
>> I guess Carsten might have some additional ideas about this.
>>
>>> 6. remove just about everything from the poms and use the release  
>>> profile instead
>> +1, we're about to provide a vote on an updated portals-pom-1.1  
>> which will use apache 6 pom
>>
>>> 7. make the portals-pom specify use of m-r-r-plugin always.
>> You mean maven-remote-resources-plugin, right?
>> Probably +1, haven't reviewed in detail what possible side-effects  
>> that could have though.
>>
>>> 8 update portals-pom to use apache 6 pom as soon as it's available.
>> See above, and FYI: apache 6 pom is already released and available
>>
>>> 9. (maybe) maybe I'm biased :-) but I prefer to use geronimo  
>>> servlet specs because I know a bit about their quality.  I'd  
>>> rather build against the geronimo servlet 2.5 spec even though  
>>> it's uplevel for what's needed than the 2.3 and 2.4 servlet specs  
>>> that I don't know much about.
>> -1
>> Not all end users are using a servlet 2.5 container yet, and adding  
>> a dependency on that could cause problems if they inadvertently  
>> then would use features from that not supported in their runtime  
>> environment.
>>
>>> If everyone agrees these are good changes I think I could find the  
>>> time to do them soon.  I'd also be happy if someone else does  
>>> them :-)
>> Whoever gets there first :)
>> You're very welcome to help out further with this, much appreciated.
>>
>>> thanks
>>> david jencks
>>> On May 6, 2009, at 1:00 PM, Ate Douma wrote:
>>>> David Jencks wrote:
>>>>> My manager thinks it's OK for me, as an IBM employee, to update  
>>>>> the sources to conform with apache standards, I will try to get  
>>>>> to it today or tomorrow.
>>>> Cool!
>>>>
>>>> Thanks for helping out with this David.
>>>>
>>>> Regards,
>>>>
>>>> Ate
>>>>
>>>>> thanks
>>>>> david jencks
>>>>> On May 4, 2009, at 4:35 PM, David Jencks wrote:
>>>>>> Hi Ate,
>>>>>>
>>>>>> I haven't heard back from my manager yet, I pinged him again.  
>>>>>> I think it's ok to add the apache license header for now, but  
>>>>>> it would definitely be better to get it fixed, especially as  
>>>>>> the existing license.txt file does not contain a license at all.
>>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>>
>>>>>> On May 4, 2009, at 3:26 AM, Ate Douma wrote:
>>>>>>
>>>>>>> David Jencks wrote:
>>>>>>>> On Apr 18, 2009, at 1:37 PM, Ate Douma wrote:
>>>>>>>
>>>>>>> <snip/>
>>>>>>>
>>>>>>>>>
>>>>>>>>> In addition, there is this license.txt within the source  
>>>>>>>>> tree containing the following:
>>>>>>>>>
>>>>>>>>> � Copyright IBM Corp. 2006, 2007
>>>>>>>>> All rights reserved.
>>>>>>>>>
>>>>>>>>> Should that file remain or maybe should we move that  
>>>>>>>>> statement to our NOTICE.txt instead?
>>>>>>>>>
>>>>>>>>> Furthermore, every portlet-api-2.0 source file also contains  
>>>>>>>>> the "Copyright 2006 IBM Corporation." in the header.
>>>>>>>> IIUC the recommended route is to move these copyright notices  
>>>>>>>> to the NOTICE file.  However someone from IBM has to do it.  
>>>>>>>> I'm from IBM but right now I wouldn't be comfortable removing  
>>>>>>>> them without input from at least one author or IBM legal.  
>>>>>>>> I'll ask my boss and see what happens.
>>>>>>>
>>>>>>> David Jencks, do you have any feedback on this issue?
>>>>>>> I'd like to move forward with this proposal ASAP but its a  
>>>>>>> little unclear to me how we can and/or are allowed to proceed  
>>>>>>> now.
>>>>>>>
>>>>>>> I would think at least we are allowed to *add* the ASF licence  
>>>>>>> header to the sources while (for now) retaining the the IBM  
>>>>>>> copyright notices therein.
>>>>>>> And the license.txt file I would think should be fine to be  
>>>>>>> removed when we move the content to our own NOTICE file.
>>>>>>> The remaining question for me is, should we only provide the  
>>>>>>> standard ASF LICENSE file, or should that in addition *also*  
>>>>>>> contain the content of the original IBM license.txt?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Ate
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Note that none of such copyright statements are found in the  
>>>>>>>>> portlet-api-1.0 source, not even from SUN.
>>>>>>>>> On the other hand, the portlet-api-1.0 sources do have the  
>>>>>>>>> ASF 1.1 license header, not the 2.0 license header.
>>>>>>>>> I'm not too familiar with what is required when a new  
>>>>>>>>> release is put out, but I think if we would do this, those  
>>>>>>>>> need to be replaced with ASF 2.0 license headers now, right?
>>>>>>>> yes, and I think we can do that without any legal arguments  
>>>>>>>> from anyone.
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Ate
>>>>>>>>>
>>>>>>>>>> Carsten
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>

[Ate Douma]

Hi David,

Thanks for the work on this, and especially for cleaning up the license headers mess :)
We're now much closer to what is needed I think, but there are still a few things to sort out before we can start releasing these.

First of all, I think the current groupId which is still javax.portlet, need to be changed to org.apache.portals.
Once that's done, we can start updating Pluto, Jetspeed and APA (trunks) to use our own portlet-api artifacts.

Secondly, the /portals/portlet-spec/site folder should be moved to /portals/site/portlet-spec, where it can be cleaned up restructured as
much as we like. But at least, by moving it from here it won't be in the way anymore for the planned release.

And thirdly, I think we need to decide about the OSGi bundle generation.
To be honest, I'm not very much in favor *right now* to use the Felix plugin for this.
As you're already detected, the result is not quite similar to what was produced manually (for portlet-api-2.0).
AFAIK, the manually produced OSGi meta-data *is* correct and how it should be.
For instance, I think the two most important OSGi tags, Bundle-SymbolicName and Bundle-Version, should be (and remain) java.portlet and 2.0
respectively, independent of our our groupId/artifactId/version, as this jar (OSGi bundle) is expected to be a "drop in" for specifically
this *spec* version.
To me, the Felix plugin doesn't seem to provide much added value but instead a higher degree of complexity and unsureness how to use it
properly and correctly.

With the rather critical amount of release steps coming up (portals-pom-1.1 -> these portlet-specs -> Pluto 2.0 -> multiple APA-1.0 projects
-> Jetspeed 2.2) which are all depending on the previous release step, I strongly urge everyone involved to keep the amount of remaining
tasks to the minimum and most practical. Switching back to the manual OSGi bundle generation should be good enough for now IMO.

Once the whole of these planned releases are done and over, I have no objections to further investigate how to do this "right" (if needed)
and release an update of the spec jars later on. Which is the whole point of now maintaining these ourselves. But lets start out with the
minimum required to get rolling.

If nobody objects, I think we can do the above 3 steps by tomorrow and create a release 1.0 proposal right after portals-pom-1.1 has been
released itself.

Regards,

Ate

David Jencks wrote:

> I've been working on this, see PORTALS-14.
>
> I updated to use the portals 1.1 pom now under vote.  I have some
> comments in that thread.
>
> It may or may not be a good idea, but I updated the names to
> portlet-api_x.0_spec with version 1.0-SNAPSHOT for both specs.  If we
> don't like it we can change it back.
>
> I added use of the felix bundle plugin for osgi metadata.  It is
> generating different info than the hand-supplied info previously in the
> 2.0 spec.  Here's what the bundle plugin comes up with:
>
> Manifest-Version: 1.0
> Export-Package: javax.portlet.filter;uses:="javax.portlet,org.w3c.dom,
>  javax.servlet.http,javax.xml.namespace";version="1.0.0.SNAPSHOT",java
>  x.portlet;uses:="org.w3c.dom,javax.servlet.http,javax.xml.namespace";
>  version="1.0.0.SNAPSHOT"
> Implementation-Title: Java Portlet Specification V2.0
> Implementation-Version: 1.0-SNAPSHOT
> Tool: Bnd-0.0.227
> Bundle-Name: portlet-api_2.0_spec
> Created-By: 1.6.0_07 (Apple Inc.)
> Bundle-Vendor: Apache Software Foundation
> Bundle-Version: 1.0.0.SNAPSHOT
> Bnd-LastModified: 1241824729053
> Bundle-ManifestVersion: 2
> Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.html
> Bundle-Description: The Java Portlet API version 2.0 developed by the
>  Java Community Process JSR-286 Expert Group.
> Import-Package: javax.portlet;version="1.0.0.SNAPSHOT",javax.portlet.f
>  ilter;version="1.0.0.SNAPSHOT",javax.servlet.http,javax.xml.namespace
>  ,org.w3c.dom
> Bundle-SymbolicName: javax.portlet.portlet-api_2.0_spec
> Bundle-DocURL: http://portals.apache.org/
>
> Here's the manually constructed manifest:
>
> Manifest-Version: 1.0
> Archiver-Version: Plexus Archiver
> Created-By: Apache Maven
> Built-By: david
> Build-Jdk: 1.6.0_07
> Specification-Title: Java Portlet Specification V2.0
> Specification-Version: 1.0-SNAPSHOT
> Specification-Vendor: Apache Software Foundation
> Implementation-Title: Java Portlet Specification V2.0
> Implementation-Version: 1.0-SNAPSHOT
> Implementation-Vendor-Id: javax.portlet
> Implementation-Vendor: Apache Software Foundation
> Bundle-DocURL: http://www.jcp.org/en/jsr/detail?id=286
> Bundle-ManifestVersion: 2
> Bundle-Name: JSR 286
> Bundle-SymbolicName: javax.portlet
> Bundle-Version: 2.0
> Export-Package: javax.portlet;version="2.0.0",
>                    javax.portlet.filter;version="2.0.0"
> Import-Package: org.w3c.dom,
>                    javax.xml.namespace,
>                    javax.servlet.http; version="2.4.0"
>
>
> I'm not enough of an osgi expert to completely understand these but.....
> there are some obvious problems with the felix-generated entries in the
> version of import/exports.  However at this point I'd like to
> investigate what's going on with this a bit more before recommending one
> or the other approach.
>
> thanks
> david jencks
>
> On May 8, 2009, at 12:55 AM, Ate Douma wrote:
>
>> Hi David,
>>
>> First of all, thanks again for helping out on this!
>>
>> I have some inline comments below.
>>
>> Regards,
>>
>> Ate
>>
>> David Jencks wrote:
>>> See https://issues.apache.org/jira/browse/PORTALS-12 and
>>> https://issues.apache.org/jira/browse/PORTALS-13
>>> portlet 2.0:
>>> I removed the ibm copyrights from the source files and the
>>> license.txt file and added the copyright notice to the NOTICE file. I
>>> added the portals-pom as parent and used the maven-remote-resources
>>> plugin to generate the LICENSE and NOTICE files.  I also added the
>>> LICENSE and NOTICE files to the root of the svn source.
>>> portlet 1.0:
>>> I changed the license header from apache 1.1 to the current header,
>>> allowing its release post- march-2004 :-).  I also added the
>>> portals-pom as parent and used the maven-remote-resources plugin to
>>> generate the requred LICENSE and NOTICE files, and added these at the
>>> root of svn source.
>>> Other stuff I think needs to happen:
>>> 1. remove the portlet.xml.txt files unless they serve some actual
>>> purpose.
>> +1, I don't see any purpose at all.
>> It is just an example portlet.xml which I think accidentally landed in
>> the source tree.
>>
>>> 2. in 2.0, remove the statement that the spec is provisional found in
>>> every file
>> +1
>>
>>> 3. remove the portal-site src and pom completely, use the maven
>>> generated site instead for each spec level.
>> We have some other plans about site management for all of portals by
>> moving that out of the main release cycle svn trees for each project
>> and instead maintain it separately (without trunk/tags folders) based
>> off /portals/site, with a master portals-site pom and sub projects
>> inherit from it (but not necessarily as parent pom modules as
>> maven-site plugin is too broken to deal with that correctly).
>> This does pose a problem for code based generated docs like reports
>> and javadoc, but I think we can and should simply check those in and
>> integrate them manually in the corresponding (sub) project site xdocs.
>> Anyway, I'll write a formal proposal/vote email for doing this for all
>> Portals projects shortly, and then in more detail.
>>
>>> 4. make the svn tree look like:
>>> https://svn.apache.org/repos/asf/portals/portlet-spec
>>>  +tags
>>>  \trunk
>>>    +portlet-api-1.0
>>>    \portlet-api-2.0
>> +1
>>
>>> Somewhat to my surprise we've found this structure to work fine with
>>> the geronimo specs and the release plugin.
>>> 5. use the felix bundle plugin to insert osgi metadata
>> +0, we already do this for portlet-api-2.0 within the pom itself, not
>> sure if more is needed here.
>> I guess Carsten might have some additional ideas about this.
>>
>>> 6. remove just about everything from the poms and use the release
>>> profile instead
>> +1, we're about to provide a vote on an updated portals-pom-1.1 which
>> will use apache 6 pom
>>
>>> 7. make the portals-pom specify use of m-r-r-plugin always.
>> You mean maven-remote-resources-plugin, right?
>> Probably +1, haven't reviewed in detail what possible side-effects
>> that could have though.
>>
>>> 8 update portals-pom to use apache 6 pom as soon as it's available.
>> See above, and FYI: apache 6 pom is already released and available
>>
>>> 9. (maybe) maybe I'm biased :-) but I prefer to use geronimo servlet
>>> specs because I know a bit about their quality.  I'd rather build
>>> against the geronimo servlet 2.5 spec even though it's uplevel for
>>> what's needed than the 2.3 and 2.4 servlet specs that I don't know
>>> much about.
>> -1
>> Not all end users are using a servlet 2.5 container yet, and adding a
>> dependency on that could cause problems if they inadvertently then
>> would use features from that not supported in their runtime environment.
>>
>>> If everyone agrees these are good changes I think I could find the
>>> time to do them soon.  I'd also be happy if someone else does them :-)
>> Whoever gets there first :)
>> You're very welcome to help out further with this, much appreciated.
>>
>>> thanks
>>> david jencks
>>> On May 6, 2009, at 1:00 PM, Ate Douma wrote:
>>>> David Jencks wrote:
>>>>> My manager thinks it's OK for me, as an IBM employee, to update the
>>>>> sources to conform with apache standards, I will try to get to it
>>>>> today or tomorrow.
>>>> Cool!
>>>>
>>>> Thanks for helping out with this David.
>>>>
>>>> Regards,
>>>>
>>>> Ate
>>>>
>>>>> thanks
>>>>> david jencks
>>>>> On May 4, 2009, at 4:35 PM, David Jencks wrote:
>>>>>> Hi Ate,
>>>>>>
>>>>>> I haven't heard back from my manager yet, I pinged him again.  I
>>>>>> think it's ok to add the apache license header for now, but it
>>>>>> would definitely be better to get it fixed, especially as the
>>>>>> existing license.txt file does not contain a license at all.
>>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>>
>>>>>> On May 4, 2009, at 3:26 AM, Ate Douma wrote:
>>>>>>
>>>>>>> David Jencks wrote:
>>>>>>>> On Apr 18, 2009, at 1:37 PM, Ate Douma wrote:
>>>>>>>
>>>>>>> <snip/>
>>>>>>>
>>>>>>>>>
>>>>>>>>> In addition, there is this license.txt within the source tree
>>>>>>>>> containing the following:
>>>>>>>>>
>>>>>>>>> � Copyright IBM Corp. 2006, 2007
>>>>>>>>> All rights reserved.
>>>>>>>>>
>>>>>>>>> Should that file remain or maybe should we move that statement
>>>>>>>>> to our NOTICE.txt instead?
>>>>>>>>>
>>>>>>>>> Furthermore, every portlet-api-2.0 source file also contains
>>>>>>>>> the "Copyright 2006 IBM Corporation." in the header.
>>>>>>>> IIUC the recommended route is to move these copyright notices to
>>>>>>>> the NOTICE file.  However someone from IBM has to do it.  I'm
>>>>>>>> from IBM but right now I wouldn't be comfortable removing them
>>>>>>>> without input from at least one author or IBM legal.  I'll ask
>>>>>>>> my boss and see what happens.
>>>>>>>
>>>>>>> David Jencks, do you have any feedback on this issue?
>>>>>>> I'd like to move forward with this proposal ASAP but its a little
>>>>>>> unclear to me how we can and/or are allowed to proceed now.
>>>>>>>
>>>>>>> I would think at least we are allowed to *add* the ASF licence
>>>>>>> header to the sources while (for now) retaining the the IBM
>>>>>>> copyright notices therein.
>>>>>>> And the license.txt file I would think should be fine to be
>>>>>>> removed when we move the content to our own NOTICE file.
>>>>>>> The remaining question for me is, should we only provide the
>>>>>>> standard ASF LICENSE file, or should that in addition *also*
>>>>>>> contain the content of the original IBM license.txt?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Ate
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Note that none of such copyright statements are found in the
>>>>>>>>> portlet-api-1.0 source, not even from SUN.
>>>>>>>>> On the other hand, the portlet-api-1.0 sources do have the ASF
>>>>>>>>> 1.1 license header, not the 2.0 license header.
>>>>>>>>> I'm not too familiar with what is required when a new release
>>>>>>>>> is put out, but I think if we would do this, those need to be
>>>>>>>>> replaced with ASF 2.0 license headers now, right?
>>>>>>>> yes, and I think we can do that without any legal arguments from
>>>>>>>> anyone.
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Ate
>>>>>>>>>
>>>>>>>>>> Carsten
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>
>

[Ate Douma]

David Jencks wrote:
> Also, does apache have an appropriately licensed copy of one or both
> portlet xsds?  
Not that I'm aware of.
However, why would we need them as we're not distributing them either?

> In geronimo IIRC we ended up typing up the schemas
> without any comments. This was unpleasant.... if there's a real copy we
> can have in svn that would be great.
It might be useful I guess, but the porlet specs (pdf) already contains them verbatim too.
Why would we need to "type up" these schema's?

Regards,

Ate

>
> thanks
> david jencks
>
>
> On May 8, 2009, at 4:38 PM, David Jencks wrote:
>
>> I've been working on this, see PORTALS-14.
>>
>> I updated to use the portals 1.1 pom now under vote.  I have some
>> comments in that thread.
>>
>> It may or may not be a good idea, but I updated the names to
>> portlet-api_x.0_spec with version 1.0-SNAPSHOT for both specs.  If we
>> don't like it we can change it back.
>>
>> I added use of the felix bundle plugin for osgi metadata.  It is
>> generating different info than the hand-supplied info previously in
>> the 2.0 spec.  Here's what the bundle plugin comes up with:
>>
>> Manifest-Version: 1.0
>> Export-Package: javax.portlet.filter;uses:="javax.portlet,org.w3c.dom,
>> javax.servlet.http,javax.xml.namespace";version="1.0.0.SNAPSHOT",java
>> x.portlet;uses:="org.w3c.dom,javax.servlet.http,javax.xml.namespace";
>> version="1.0.0.SNAPSHOT"
>> Implementation-Title: Java Portlet Specification V2.0
>> Implementation-Version: 1.0-SNAPSHOT
>> Tool: Bnd-0.0.227
>> Bundle-Name: portlet-api_2.0_spec
>> Created-By: 1.6.0_07 (Apple Inc.)
>> Bundle-Vendor: Apache Software Foundation
>> Bundle-Version: 1.0.0.SNAPSHOT
>> Bnd-LastModified: 1241824729053
>> Bundle-ManifestVersion: 2
>> Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.html
>> Bundle-Description: The Java Portlet API version 2.0 developed by the
>> Java Community Process JSR-286 Expert Group.
>> Import-Package: javax.portlet;version="1.0.0.SNAPSHOT",javax.portlet.f
>> ilter;version="1.0.0.SNAPSHOT",javax.servlet.http,javax.xml.namespace
>> ,org.w3c.dom
>> Bundle-SymbolicName: javax.portlet.portlet-api_2.0_spec
>> Bundle-DocURL: http://portals.apache.org/
>>
>> Here's the manually constructed manifest:
>>
>> Manifest-Version: 1.0
>> Archiver-Version: Plexus Archiver
>> Created-By: Apache Maven
>> Built-By: david
>> Build-Jdk: 1.6.0_07
>> Specification-Title: Java Portlet Specification V2.0
>> Specification-Version: 1.0-SNAPSHOT
>> Specification-Vendor: Apache Software Foundation
>> Implementation-Title: Java Portlet Specification V2.0
>> Implementation-Version: 1.0-SNAPSHOT
>> Implementation-Vendor-Id: javax.portlet
>> Implementation-Vendor: Apache Software Foundation
>> Bundle-DocURL: http://www.jcp.org/en/jsr/detail?id=286
>> Bundle-ManifestVersion: 2
>> Bundle-Name: JSR 286
>> Bundle-SymbolicName: javax.portlet
>> Bundle-Version: 2.0
>> Export-Package: javax.portlet;version="2.0.0",
>>                   javax.portlet.filter;version="2.0.0"
>> Import-Package: org.w3c.dom,
>>                   javax.xml.namespace,
>>                   javax.servlet.http; version="2.4.0"
>>
>>
>> I'm not enough of an osgi expert to completely understand these
>> but..... there are some obvious problems with the felix-generated
>> entries in the version of import/exports.  However at this point I'd
>> like to investigate what's going on with this a bit more before
>> recommending one or the other approach.
>>
>> thanks
>> david jencks
>>
>> On May 8, 2009, at 12:55 AM, Ate Douma wrote:
>>
>>> Hi David,
>>>
>>> First of all, thanks again for helping out on this!
>>>
>>> I have some inline comments below.
>>>
>>> Regards,
>>>
>>> Ate
>>>
>>> David Jencks wrote:
>>>> See https://issues.apache.org/jira/browse/PORTALS-12 and
>>>> https://issues.apache.org/jira/browse/PORTALS-13
>>>> portlet 2.0:
>>>> I removed the ibm copyrights from the source files and the
>>>> license.txt file and added the copyright notice to the NOTICE file.
>>>> I added the portals-pom as parent and used the
>>>> maven-remote-resources plugin to generate the LICENSE and NOTICE
>>>> files.  I also added the LICENSE and NOTICE files to the root of the
>>>> svn source.
>>>> portlet 1.0:
>>>> I changed the license header from apache 1.1 to the current header,
>>>> allowing its release post- march-2004 :-).  I also added the
>>>> portals-pom as parent and used the maven-remote-resources plugin to
>>>> generate the requred LICENSE and NOTICE files, and added these at
>>>> the root of svn source.
>>>> Other stuff I think needs to happen:
>>>> 1. remove the portlet.xml.txt files unless they serve some actual
>>>> purpose.
>>> +1, I don't see any purpose at all.
>>> It is just an example portlet.xml which I think accidentally landed
>>> in the source tree.
>>>
>>>> 2. in 2.0, remove the statement that the spec is provisional found
>>>> in every file
>>> +1
>>>
>>>> 3. remove the portal-site src and pom completely, use the maven
>>>> generated site instead for each spec level.
>>> We have some other plans about site management for all of portals by
>>> moving that out of the main release cycle svn trees for each project
>>> and instead maintain it separately (without trunk/tags folders) based
>>> off /portals/site, with a master portals-site pom and sub projects
>>> inherit from it (but not necessarily as parent pom modules as
>>> maven-site plugin is too broken to deal with that correctly).
>>> This does pose a problem for code based generated docs like reports
>>> and javadoc, but I think we can and should simply check those in and
>>> integrate them manually in the corresponding (sub) project site xdocs.
>>> Anyway, I'll write a formal proposal/vote email for doing this for
>>> all Portals projects shortly, and then in more detail.
>>>
>>>> 4. make the svn tree look like:
>>>> https://svn.apache.org/repos/asf/portals/portlet-spec
>>>> +tags
>>>> \trunk
>>>>   +portlet-api-1.0
>>>>   \portlet-api-2.0
>>> +1
>>>
>>>> Somewhat to my surprise we've found this structure to work fine with
>>>> the geronimo specs and the release plugin.
>>>> 5. use the felix bundle plugin to insert osgi metadata
>>> +0, we already do this for portlet-api-2.0 within the pom itself, not
>>> sure if more is needed here.
>>> I guess Carsten might have some additional ideas about this.
>>>
>>>> 6. remove just about everything from the poms and use the release
>>>> profile instead
>>> +1, we're about to provide a vote on an updated portals-pom-1.1 which
>>> will use apache 6 pom
>>>
>>>> 7. make the portals-pom specify use of m-r-r-plugin always.
>>> You mean maven-remote-resources-plugin, right?
>>> Probably +1, haven't reviewed in detail what possible side-effects
>>> that could have though.
>>>
>>>> 8 update portals-pom to use apache 6 pom as soon as it's available.
>>> See above, and FYI: apache 6 pom is already released and available
>>>
>>>> 9. (maybe) maybe I'm biased :-) but I prefer to use geronimo servlet
>>>> specs because I know a bit about their quality.  I'd rather build
>>>> against the geronimo servlet 2.5 spec even though it's uplevel for
>>>> what's needed than the 2.3 and 2.4 servlet specs that I don't know
>>>> much about.
>>> -1
>>> Not all end users are using a servlet 2.5 container yet, and adding a
>>> dependency on that could cause problems if they inadvertently then
>>> would use features from that not supported in their runtime environment.
>>>
>>>> If everyone agrees these are good changes I think I could find the
>>>> time to do them soon.  I'd also be happy if someone else does them :-)
>>> Whoever gets there first :)
>>> You're very welcome to help out further with this, much appreciated.
>>>
>>>> thanks
>>>> david jencks
>>>> On May 6, 2009, at 1:00 PM, Ate Douma wrote:
>>>>> David Jencks wrote:
>>>>>> My manager thinks it's OK for me, as an IBM employee, to update
>>>>>> the sources to conform with apache standards, I will try to get to
>>>>>> it today or tomorrow.
>>>>> Cool!
>>>>>
>>>>> Thanks for helping out with this David.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Ate
>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>> On May 4, 2009, at 4:35 PM, David Jencks wrote:
>>>>>>> Hi Ate,
>>>>>>>
>>>>>>> I haven't heard back from my manager yet, I pinged him again.  I
>>>>>>> think it's ok to add the apache license header for now, but it
>>>>>>> would definitely be better to get it fixed, especially as the
>>>>>>> existing license.txt file does not contain a license at all.
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>> On May 4, 2009, at 3:26 AM, Ate Douma wrote:
>>>>>>>
>>>>>>>> David Jencks wrote:
>>>>>>>>> On Apr 18, 2009, at 1:37 PM, Ate Douma wrote:
>>>>>>>>
>>>>>>>> <snip/>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In addition, there is this license.txt within the source tree
>>>>>>>>>> containing the following:
>>>>>>>>>>
>>>>>>>>>> � Copyright IBM Corp. 2006, 2007
>>>>>>>>>> All rights reserved.
>>>>>>>>>>
>>>>>>>>>> Should that file remain or maybe should we move that statement
>>>>>>>>>> to our NOTICE.txt instead?
>>>>>>>>>>
>>>>>>>>>> Furthermore, every portlet-api-2.0 source file also contains
>>>>>>>>>> the "Copyright 2006 IBM Corporation." in the header.
>>>>>>>>> IIUC the recommended route is to move these copyright notices
>>>>>>>>> to the NOTICE file.  However someone from IBM has to do it.  
>>>>>>>>> I'm from IBM but right now I wouldn't be comfortable removing
>>>>>>>>> them without input from at least one author or IBM legal.  I'll
>>>>>>>>> ask my boss and see what happens.
>>>>>>>>
>>>>>>>> David Jencks, do you have any feedback on this issue?
>>>>>>>> I'd like to move forward with this proposal ASAP but its a
>>>>>>>> little unclear to me how we can and/or are allowed to proceed now.
>>>>>>>>
>>>>>>>> I would think at least we are allowed to *add* the ASF licence
>>>>>>>> header to the sources while (for now) retaining the the IBM
>>>>>>>> copyright notices therein.
>>>>>>>> And the license.txt file I would think should be fine to be
>>>>>>>> removed when we move the content to our own NOTICE file.
>>>>>>>> The remaining question for me is, should we only provide the
>>>>>>>> standard ASF LICENSE file, or should that in addition *also*
>>>>>>>> contain the content of the original IBM license.txt?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Ate
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Note that none of such copyright statements are found in the
>>>>>>>>>> portlet-api-1.0 source, not even from SUN.
>>>>>>>>>> On the other hand, the portlet-api-1.0 sources do have the ASF
>>>>>>>>>> 1.1 license header, not the 2.0 license header.
>>>>>>>>>> I'm not too familiar with what is required when a new release
>>>>>>>>>> is put out, but I think if we would do this, those need to be
>>>>>>>>>> replaced with ASF 2.0 license headers now, right?
>>>>>>>>> yes, and I think we can do that without any legal arguments
>>>>>>>>> from anyone.
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Ate
>>>>>>>>>>
>>>>>>>>>>> Carsten
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
>

[djencks]

On May 10, 2009, at 3:04 PM, Ate Douma wrote:

> Hi David,
>
> Thanks for the work on this, and especially for cleaning up the  
> license headers mess :)
> We're now much closer to what is needed I think, but there are still  
> a few things to sort out before we can start releasing these.
>
> First of all, I think the current groupId which is still  
> javax.portlet, need to be changed to org.apache.portals.
> Once that's done, we can start updating Pluto, Jetspeed and APA  
> (trunks) to use our own portlet-api artifacts.

done.
>
>
> Secondly, the /portals/portlet-spec/site folder should be moved to /
> portals/site/portlet-spec, where it can be cleaned up restructured  
> as much as we like. But at least, by moving it from here it won't be  
> in the way anymore for the planned release.

It's at portlet-specs/trunk/site now so it won't interfere with the  
release.  Moving it is probably a good idea anyway.

>
>
> And thirdly, I think we need to decide about the OSGi bundle  
> generation.
> To be honest, I'm not very much in favor *right now* to use the  
> Felix plugin for this.
> As you're already detected, the result is not quite similar to what  
> was produced manually (for portlet-api-2.0).
> AFAIK, the manually produced OSGi meta-data *is* correct and how it  
> should be.
> For instance, I think the two most important OSGi tags, Bundle-
> SymbolicName and Bundle-Version, should be (and remain) java.portlet  
> and 2.0 respectively, independent of our our groupId/artifactId/
> version, as this jar (OSGi bundle) is expected to be a "drop in" for  
> specifically this *spec* version.

I learned more about osgi the last couple of days :-)
bundle-symbolic-name needs to identify these bundles as different from  
the ones sun may or may not supply.  It doesn't have anything to do  
with what's inside :-)  So I think we should continue with the default  
from the maven-bundle-plugin of <groupId>.<artifactId>, here  
org.apache.portals.portlet-api_1.0_spec etc.

bundle version identities the version of the bundle, not the package  
version of anything inslde.  So I think the standard procedure is to  
start at 1.0.0.

We do need to make sure that the packages inside have version either  
2.0 or 2.0.0.  After a lot of headaches I discovered that the bundle-
version and the versions for each exported package have nothing to do  
with one another.

>
> To me, the Felix plugin doesn't seem to provide much added value but  
> instead a higher degree of complexity and unsureness how to use it  
> properly and correctly.

If we can get it to produce slightly more reasonable output by the end  
of tomorrow I think we should use it.  For instance it has pointed out  
that the packages in Export-Packages should have uses clauses, at  
least for the servlet package needed.  If no answer from feiix arrives  
by tomorrow then I agree we should use the manual manifest setup.....  
but informed by the bundle plugin output.

thanks
david jencks

>
>
> With the rather critical amount of release steps coming up (portals-
> pom-1.1 -> these portlet-specs -> Pluto 2.0 -> multiple APA-1.0  
> projects -> Jetspeed 2.2) which are all depending on the previous  
> release step, I strongly urge everyone involved to keep the amount  
> of remaining tasks to the minimum and most practical. Switching back  
> to the manual OSGi bundle generation should be good enough for now  
> IMO.
>
> Once the whole of these planned releases are done and over, I have  
> no objections to further investigate how to do this "right" (if  
> needed) and release an update of the spec jars later on. Which is  
> the whole point of now maintaining these ourselves. But lets start  
> out with the minimum required to get rolling.
>
> If nobody objects, I think we can do the above 3 steps by tomorrow  
> and create a release 1.0 proposal right after portals-pom-1.1 has  
> been released itself.
>
> Regards,
>
> Ate
>
> David Jencks wrote:
>> I've been working on this, see PORTALS-14.
>> I updated to use the portals 1.1 pom now under vote.  I have some  
>> comments in that thread.
>> It may or may not be a good idea, but I updated the names to  
>> portlet-api_x.0_spec with version 1.0-SNAPSHOT for both specs.  If  
>> we don't like it we can change it back.
>> I added use of the felix bundle plugin for osgi metadata.  It is  
>> generating different info than the hand-supplied info previously in  
>> the 2.0 spec.  Here's what the bundle plugin comes up with:
>> Manifest-Version: 1.0
>> Export-Package:  
>> javax.portlet.filter;uses:="javax.portlet,org.w3c.dom,
>> javax.servlet.http,javax.xml.namespace";version="1.0.0.SNAPSHOT",java
>> x.portlet;uses:="org.w3c.dom,javax.servlet.http,javax.xml.namespace";
>> version="1.0.0.SNAPSHOT"
>> Implementation-Title: Java Portlet Specification V2.0
>> Implementation-Version: 1.0-SNAPSHOT
>> Tool: Bnd-0.0.227
>> Bundle-Name: portlet-api_2.0_spec
>> Created-By: 1.6.0_07 (Apple Inc.)
>> Bundle-Vendor: Apache Software Foundation
>> Bundle-Version: 1.0.0.SNAPSHOT
>> Bnd-LastModified: 1241824729053
>> Bundle-ManifestVersion: 2
>> Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.html
>> Bundle-Description: The Java Portlet API version 2.0 developed by the
>> Java Community Process JSR-286 Expert Group.
>> Import-Package:  
>> javax.portlet;version="1.0.0.SNAPSHOT",javax.portlet.f
>> ilter;version="1.0.0.SNAPSHOT",javax.servlet.http,javax.xml.namespace
>> ,org.w3c.dom
>> Bundle-SymbolicName: javax.portlet.portlet-api_2.0_spec
>> Bundle-DocURL: http://portals.apache.org/
>> Here's the manually constructed manifest:
>> Manifest-Version: 1.0
>> Archiver-Version: Plexus Archiver
>> Created-By: Apache Maven
>> Built-By: david
>> Build-Jdk: 1.6.0_07
>> Specification-Title: Java Portlet Specification V2.0
>> Specification-Version: 1.0-SNAPSHOT
>> Specification-Vendor: Apache Software Foundation
>> Implementation-Title: Java Portlet Specification V2.0
>> Implementation-Version: 1.0-SNAPSHOT
>> Implementation-Vendor-Id: javax.portlet
>> Implementation-Vendor: Apache Software Foundation
>> Bundle-DocURL: http://www.jcp.org/en/jsr/detail?id=286
>> Bundle-ManifestVersion: 2
>> Bundle-Name: JSR 286
>> Bundle-SymbolicName: javax.portlet
>> Bundle-Version: 2.0
>> Export-Package: javax.portlet;version="2.0.0",
>>                   javax.portlet.filter;version="2.0.0"
>> Import-Package: org.w3c.dom,
>>                   javax.xml.namespace,
>>                   javax.servlet.http; version="2.4.0"
>> I'm not enough of an osgi expert to completely understand these  
>> but..... there are some obvious problems with the felix-generated  
>> entries in the version of import/exports.  However at this point  
>> I'd like to investigate what's going on with this a bit more before  
>> recommending one or the other approach.
>> thanks
>> david jencks
>> On May 8, 2009, at 12:55 AM, Ate Douma wrote:
>>> Hi David,
>>>
>>> First of all, thanks again for helping out on this!
>>>
>>> I have some inline comments below.
>>>
>>> Regards,
>>>
>>> Ate
>>>
>>> David Jencks wrote:
>>>> See https://issues.apache.org/jira/browse/PORTALS-12 and https://issues.apache.org/jira/browse/PORTALS-13
>>>> portlet 2.0:
>>>> I removed the ibm copyrights from the source files and the  
>>>> license.txt file and added the copyright notice to the NOTICE  
>>>> file. I added the portals-pom as parent and used the maven-remote-
>>>> resources plugin to generate the LICENSE and NOTICE files.  I  
>>>> also added the LICENSE and NOTICE files to the root of the svn  
>>>> source.
>>>> portlet 1.0:
>>>> I changed the license header from apache 1.1 to the current  
>>>> header, allowing its release post- march-2004 :-).  I also added  
>>>> the portals-pom as parent and used the maven-remote-resources  
>>>> plugin to generate the requred LICENSE and NOTICE files, and  
>>>> added these at the root of svn source.
>>>> Other stuff I think needs to happen:
>>>> 1. remove the portlet.xml.txt files unless they serve some actual  
>>>> purpose.
>>> +1, I don't see any purpose at all.
>>> It is just an example portlet.xml which I think accidentally  
>>> landed in the source tree.
>>>
>>>> 2. in 2.0, remove the statement that the spec is provisional  
>>>> found in every file
>>> +1
>>>
>>>> 3. remove the portal-site src and pom completely, use the maven  
>>>> generated site instead for each spec level.
>>> We have some other plans about site management for all of portals  
>>> by moving that out of the main release cycle svn trees for each  
>>> project and instead maintain it separately (without trunk/tags  
>>> folders) based off /portals/site, with a master portals-site pom  
>>> and sub projects inherit from it (but not necessarily as parent  
>>> pom modules as maven-site plugin is too broken to deal with that  
>>> correctly).
>>> This does pose a problem for code based generated docs like  
>>> reports and javadoc, but I think we can and should simply check  
>>> those in and integrate them manually in the corresponding (sub)  
>>> project site xdocs.
>>> Anyway, I'll write a formal proposal/vote email for doing this for  
>>> all Portals projects shortly, and then in more detail.
>>>
>>>> 4. make the svn tree look like:
>>>> https://svn.apache.org/repos/asf/portals/portlet-spec
>>>> +tags
>>>> \trunk
>>>>   +portlet-api-1.0
>>>>   \portlet-api-2.0
>>> +1
>>>
>>>> Somewhat to my surprise we've found this structure to work fine  
>>>> with the geronimo specs and the release plugin.
>>>> 5. use the felix bundle plugin to insert osgi metadata
>>> +0, we already do this for portlet-api-2.0 within the pom itself,  
>>> not sure if more is needed here.
>>> I guess Carsten might have some additional ideas about this.
>>>
>>>> 6. remove just about everything from the poms and use the release  
>>>> profile instead
>>> +1, we're about to provide a vote on an updated portals-pom-1.1  
>>> which will use apache 6 pom
>>>
>>>> 7. make the portals-pom specify use of m-r-r-plugin always.
>>> You mean maven-remote-resources-plugin, right?
>>> Probably +1, haven't reviewed in detail what possible side-effects  
>>> that could have though.
>>>
>>>> 8 update portals-pom to use apache 6 pom as soon as it's available.
>>> See above, and FYI: apache 6 pom is already released and available
>>>
>>>> 9. (maybe) maybe I'm biased :-) but I prefer to use geronimo  
>>>> servlet specs because I know a bit about their quality.  I'd  
>>>> rather build against the geronimo servlet 2.5 spec even though  
>>>> it's uplevel for what's needed than the 2.3 and 2.4 servlet specs  
>>>> that I don't know much about.
>>> -1
>>> Not all end users are using a servlet 2.5 container yet, and  
>>> adding a dependency on that could cause problems if they  
>>> inadvertently then would use features from that not supported in  
>>> their runtime environment.
>>>
>>>> If everyone agrees these are good changes I think I could find  
>>>> the time to do them soon.  I'd also be happy if someone else does  
>>>> them :-)
>>> Whoever gets there first :)
>>> You're very welcome to help out further with this, much appreciated.
>>>
>>>> thanks
>>>> david jencks
>>>> On May 6, 2009, at 1:00 PM, Ate Douma wrote:
>>>>> David Jencks wrote:
>>>>>> My manager thinks it's OK for me, as an IBM employee, to update  
>>>>>> the sources to conform with apache standards, I will try to get  
>>>>>> to it today or tomorrow.
>>>>> Cool!
>>>>>
>>>>> Thanks for helping out with this David.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Ate
>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>> On May 4, 2009, at 4:35 PM, David Jencks wrote:
>>>>>>> Hi Ate,
>>>>>>>
>>>>>>> I haven't heard back from my manager yet, I pinged him again.  
>>>>>>> I think it's ok to add the apache license header for now, but  
>>>>>>> it would definitely be better to get it fixed, especially as  
>>>>>>> the existing license.txt file does not contain a license at all.
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>> On May 4, 2009, at 3:26 AM, Ate Douma wrote:
>>>>>>>
>>>>>>>> David Jencks wrote:
>>>>>>>>> On Apr 18, 2009, at 1:37 PM, Ate Douma wrote:
>>>>>>>>
>>>>>>>> <snip/>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In addition, there is this license.txt within the source  
>>>>>>>>>> tree containing the following:
>>>>>>>>>>
>>>>>>>>>> � Copyright IBM Corp. 2006, 2007
>>>>>>>>>> All rights reserved.
>>>>>>>>>>
>>>>>>>>>> Should that file remain or maybe should we move that  
>>>>>>>>>> statement to our NOTICE.txt instead?
>>>>>>>>>>
>>>>>>>>>> Furthermore, every portlet-api-2.0 source file also  
>>>>>>>>>> contains the "Copyright 2006 IBM Corporation." in the header.
>>>>>>>>> IIUC the recommended route is to move these copyright  
>>>>>>>>> notices to the NOTICE file.  However someone from IBM has to  
>>>>>>>>> do it.  I'm from IBM but right now I wouldn't be comfortable  
>>>>>>>>> removing them without input from at least one author or IBM  
>>>>>>>>> legal.  I'll ask my boss and see what happens.
>>>>>>>>
>>>>>>>> David Jencks, do you have any feedback on this issue?
>>>>>>>> I'd like to move forward with this proposal ASAP but its a  
>>>>>>>> little unclear to me how we can and/or are allowed to proceed  
>>>>>>>> now.
>>>>>>>>
>>>>>>>> I would think at least we are allowed to *add* the ASF  
>>>>>>>> licence header to the sources while (for now) retaining the  
>>>>>>>> the IBM copyright notices therein.
>>>>>>>> And the license.txt file I would think should be fine to be  
>>>>>>>> removed when we move the content to our own NOTICE file.
>>>>>>>> The remaining question for me is, should we only provide the  
>>>>>>>> standard ASF LICENSE file, or should that in addition *also*  
>>>>>>>> contain the content of the original IBM license.txt?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Ate
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Note that none of such copyright statements are found in  
>>>>>>>>>> the portlet-api-1.0 source, not even from SUN.
>>>>>>>>>> On the other hand, the portlet-api-1.0 sources do have the  
>>>>>>>>>> ASF 1.1 license header, not the 2.0 license header.
>>>>>>>>>> I'm not too familiar with what is required when a new  
>>>>>>>>>> release is put out, but I think if we would do this, those  
>>>>>>>>>> need to be replaced with ASF 2.0 license headers now, right?
>>>>>>>>> yes, and I think we can do that without any legal arguments  
>>>>>>>>> from anyone.
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Ate
>>>>>>>>>>
>>>>>>>>>>> Carsten
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>

[djencks]

On May 10, 2009, at 3:21 PM, Ate Douma wrote:

> David Jencks wrote:
>> Also, does apache have an appropriately licensed copy of one or  
>> both portlet xsds?
> Not that I'm aware of.
> However, why would we need them as we're not distributing them either?

why not :-) ?
>
>
>> In geronimo IIRC we ended up typing up the schemas without any  
>> comments. This was unpleasant.... if there's a real copy we can  
>> have in svn that would be great.
> It might be useful I guess, but the porlet specs (pdf) already  
> contains them verbatim too.
> Why would we need to "type up" these schema's?

At best sun probably provides cddl schemas.  There has been some  
argument about what license would apply to the result of running  
xmlbeans or jaxb code generation on a cddl schema; Craig Russell  
thinks it ought to be cddl.  In order to avoid any discussion of this  
having an apache licensed copy of the parts of the schema that don't  
affect code generation is valuable for anyone who wants to generate  
such code.  As far as we've been able to figure out, if we type up the  
schema without any of the sun documentation annotations the result  
can  be apache licensed.

thanks
david jencks

>
>
> Regards,
>
> Ate
>
>> thanks
>> david jencks
>> On May 8, 2009, at 4:38 PM, David Jencks wrote:
>>> I've been working on this, see PORTALS-14.
>>>
>>> I updated to use the portals 1.1 pom now under vote.  I have some  
>>> comments in that thread.
>>>
>>> It may or may not be a good idea, but I updated the names to  
>>> portlet-api_x.0_spec with version 1.0-SNAPSHOT for both specs.  If  
>>> we don't like it we can change it back.
>>>
>>> I added use of the felix bundle plugin for osgi metadata.  It is  
>>> generating different info than the hand-supplied info previously  
>>> in the 2.0 spec.  Here's what the bundle plugin comes up with:
>>>
>>> Manifest-Version: 1.0
>>> Export-Package:  
>>> javax.portlet.filter;uses:="javax.portlet,org.w3c.dom,
>>> javax
>>> .servlet.http,javax.xml.namespace";version="1.0.0.SNAPSHOT",java
>>> x
>>> .portlet;uses:="org.w3c.dom,javax.servlet.http,javax.xml.namespace";
>>> version="1.0.0.SNAPSHOT"
>>> Implementation-Title: Java Portlet Specification V2.0
>>> Implementation-Version: 1.0-SNAPSHOT
>>> Tool: Bnd-0.0.227
>>> Bundle-Name: portlet-api_2.0_spec
>>> Created-By: 1.6.0_07 (Apple Inc.)
>>> Bundle-Vendor: Apache Software Foundation
>>> Bundle-Version: 1.0.0.SNAPSHOT
>>> Bnd-LastModified: 1241824729053
>>> Bundle-ManifestVersion: 2
>>> Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.html
>>> Bundle-Description: The Java Portlet API version 2.0 developed by  
>>> the
>>> Java Community Process JSR-286 Expert Group.
>>> Import-Package:  
>>> javax.portlet;version="1.0.0.SNAPSHOT",javax.portlet.f
>>> ilter
>>> ;version="1.0.0.SNAPSHOT",javax.servlet.http,javax.xml.namespace
>>> ,org.w3c.dom
>>> Bundle-SymbolicName: javax.portlet.portlet-api_2.0_spec
>>> Bundle-DocURL: http://portals.apache.org/
>>>
>>> Here's the manually constructed manifest:
>>>
>>> Manifest-Version: 1.0
>>> Archiver-Version: Plexus Archiver
>>> Created-By: Apache Maven
>>> Built-By: david
>>> Build-Jdk: 1.6.0_07
>>> Specification-Title: Java Portlet Specification V2.0
>>> Specification-Version: 1.0-SNAPSHOT
>>> Specification-Vendor: Apache Software Foundation
>>> Implementation-Title: Java Portlet Specification V2.0
>>> Implementation-Version: 1.0-SNAPSHOT
>>> Implementation-Vendor-Id: javax.portlet
>>> Implementation-Vendor: Apache Software Foundation
>>> Bundle-DocURL: http://www.jcp.org/en/jsr/detail?id=286
>>> Bundle-ManifestVersion: 2
>>> Bundle-Name: JSR 286
>>> Bundle-SymbolicName: javax.portlet
>>> Bundle-Version: 2.0
>>> Export-Package: javax.portlet;version="2.0.0",
>>>                  javax.portlet.filter;version="2.0.0"
>>> Import-Package: org.w3c.dom,
>>>                  javax.xml.namespace,
>>>                  javax.servlet.http; version="2.4.0"
>>>
>>>
>>> I'm not enough of an osgi expert to completely understand these  
>>> but..... there are some obvious problems with the felix-generated  
>>> entries in the version of import/exports.  However at this point  
>>> I'd like to investigate what's going on with this a bit more  
>>> before recommending one or the other approach.
>>>
>>> thanks
>>> david jencks
>>>
>>> On May 8, 2009, at 12:55 AM, Ate Douma wrote:
>>>
>>>> Hi David,
>>>>
>>>> First of all, thanks again for helping out on this!
>>>>
>>>> I have some inline comments below.
>>>>
>>>> Regards,
>>>>
>>>> Ate
>>>>
>>>> David Jencks wrote:
>>>>> See https://issues.apache.org/jira/browse/PORTALS-12 and https://issues.apache.org/jira/browse/PORTALS-13
>>>>> portlet 2.0:
>>>>> I removed the ibm copyrights from the source files and the  
>>>>> license.txt file and added the copyright notice to the NOTICE  
>>>>> file. I added the portals-pom as parent and used the maven-
>>>>> remote-resources plugin to generate the LICENSE and NOTICE  
>>>>> files.  I also added the LICENSE and NOTICE files to the root of  
>>>>> the svn source.
>>>>> portlet 1.0:
>>>>> I changed the license header from apache 1.1 to the current  
>>>>> header, allowing its release post- march-2004 :-).  I also added  
>>>>> the portals-pom as parent and used the maven-remote-resources  
>>>>> plugin to generate the requred LICENSE and NOTICE files, and  
>>>>> added these at the root of svn source.
>>>>> Other stuff I think needs to happen:
>>>>> 1. remove the portlet.xml.txt files unless they serve some  
>>>>> actual purpose.
>>>> +1, I don't see any purpose at all.
>>>> It is just an example portlet.xml which I think accidentally  
>>>> landed in the source tree.
>>>>
>>>>> 2. in 2.0, remove the statement that the spec is provisional  
>>>>> found in every file
>>>> +1
>>>>
>>>>> 3. remove the portal-site src and pom completely, use the maven  
>>>>> generated site instead for each spec level.
>>>> We have some other plans about site management for all of portals  
>>>> by moving that out of the main release cycle svn trees for each  
>>>> project and instead maintain it separately (without trunk/tags  
>>>> folders) based off /portals/site, with a master portals-site pom  
>>>> and sub projects inherit from it (but not necessarily as parent  
>>>> pom modules as maven-site plugin is too broken to deal with that  
>>>> correctly).
>>>> This does pose a problem for code based generated docs like  
>>>> reports and javadoc, but I think we can and should simply check  
>>>> those in and integrate them manually in the corresponding (sub)  
>>>> project site xdocs.
>>>> Anyway, I'll write a formal proposal/vote email for doing this  
>>>> for all Portals projects shortly, and then in more detail.
>>>>
>>>>> 4. make the svn tree look like:
>>>>> https://svn.apache.org/repos/asf/portals/portlet-spec
>>>>> +tags
>>>>> \trunk
>>>>>  +portlet-api-1.0
>>>>>  \portlet-api-2.0
>>>> +1
>>>>
>>>>> Somewhat to my surprise we've found this structure to work fine  
>>>>> with the geronimo specs and the release plugin.
>>>>> 5. use the felix bundle plugin to insert osgi metadata
>>>> +0, we already do this for portlet-api-2.0 within the pom itself,  
>>>> not sure if more is needed here.
>>>> I guess Carsten might have some additional ideas about this.
>>>>
>>>>> 6. remove just about everything from the poms and use the  
>>>>> release profile instead
>>>> +1, we're about to provide a vote on an updated portals-pom-1.1  
>>>> which will use apache 6 pom
>>>>
>>>>> 7. make the portals-pom specify use of m-r-r-plugin always.
>>>> You mean maven-remote-resources-plugin, right?
>>>> Probably +1, haven't reviewed in detail what possible side-
>>>> effects that could have though.
>>>>
>>>>> 8 update portals-pom to use apache 6 pom as soon as it's  
>>>>> available.
>>>> See above, and FYI: apache 6 pom is already released and available
>>>>
>>>>> 9. (maybe) maybe I'm biased :-) but I prefer to use geronimo  
>>>>> servlet specs because I know a bit about their quality.  I'd  
>>>>> rather build against the geronimo servlet 2.5 spec even though  
>>>>> it's uplevel for what's needed than the 2.3 and 2.4 servlet  
>>>>> specs that I don't know much about.
>>>> -1
>>>> Not all end users are using a servlet 2.5 container yet, and  
>>>> adding a dependency on that could cause problems if they  
>>>> inadvertently then would use features from that not supported in  
>>>> their runtime environment.
>>>>
>>>>> If everyone agrees these are good changes I think I could find  
>>>>> the time to do them soon.  I'd also be happy if someone else  
>>>>> does them :-)
>>>> Whoever gets there first :)
>>>> You're very welcome to help out further with this, much  
>>>> appreciated.
>>>>
>>>>> thanks
>>>>> david jencks
>>>>> On May 6, 2009, at 1:00 PM, Ate Douma wrote:
>>>>>> David Jencks wrote:
>>>>>>> My manager thinks it's OK for me, as an IBM employee, to  
>>>>>>> update the sources to conform with apache standards, I will  
>>>>>>> try to get to it today or tomorrow.
>>>>>> Cool!
>>>>>>
>>>>>> Thanks for helping out with this David.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Ate
>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>> On May 4, 2009, at 4:35 PM, David Jencks wrote:
>>>>>>>> Hi Ate,
>>>>>>>>
>>>>>>>> I haven't heard back from my manager yet, I pinged him  
>>>>>>>> again.  I think it's ok to add the apache license header for  
>>>>>>>> now, but it would definitely be better to get it fixed,  
>>>>>>>> especially as the existing license.txt file does not contain  
>>>>>>>> a license at all.
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>> On May 4, 2009, at 3:26 AM, Ate Douma wrote:
>>>>>>>>
>>>>>>>>> David Jencks wrote:
>>>>>>>>>> On Apr 18, 2009, at 1:37 PM, Ate Douma wrote:
>>>>>>>>>
>>>>>>>>> <snip/>
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> In addition, there is this license.txt within the source  
>>>>>>>>>>> tree containing the following:
>>>>>>>>>>>
>>>>>>>>>>> � Copyright IBM Corp. 2006, 2007
>>>>>>>>>>> All rights reserved.
>>>>>>>>>>>
>>>>>>>>>>> Should that file remain or maybe should we move that  
>>>>>>>>>>> statement to our NOTICE.txt instead?
>>>>>>>>>>>
>>>>>>>>>>> Furthermore, every portlet-api-2.0 source file also  
>>>>>>>>>>> contains the "Copyright 2006 IBM Corporation." in the  
>>>>>>>>>>> header.
>>>>>>>>>> IIUC the recommended route is to move these copyright  
>>>>>>>>>> notices to the NOTICE file.  However someone from IBM has  
>>>>>>>>>> to do it.  I'm from IBM but right now I wouldn't be  
>>>>>>>>>> comfortable removing them without input from at least one  
>>>>>>>>>> author or IBM legal.  I'll ask my boss and see what happens.
>>>>>>>>>
>>>>>>>>> David Jencks, do you have any feedback on this issue?
>>>>>>>>> I'd like to move forward with this proposal ASAP but its a  
>>>>>>>>> little unclear to me how we can and/or are allowed to  
>>>>>>>>> proceed now.
>>>>>>>>>
>>>>>>>>> I would think at least we are allowed to *add* the ASF  
>>>>>>>>> licence header to the sources while (for now) retaining the  
>>>>>>>>> the IBM copyright notices therein.
>>>>>>>>> And the license.txt file I would think should be fine to be  
>>>>>>>>> removed when we move the content to our own NOTICE file.
>>>>>>>>> The remaining question for me is, should we only provide the  
>>>>>>>>> standard ASF LICENSE file, or should that in addition *also*  
>>>>>>>>> contain the content of the original IBM license.txt?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Ate
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Note that none of such copyright statements are found in  
>>>>>>>>>>> the portlet-api-1.0 source, not even from SUN.
>>>>>>>>>>> On the other hand, the portlet-api-1.0 sources do have the  
>>>>>>>>>>> ASF 1.1 license header, not the 2.0 license header.
>>>>>>>>>>> I'm not too familiar with what is required when a new  
>>>>>>>>>>> release is put out, but I think if we would do this, those  
>>>>>>>>>>> need to be replaced with ASF 2.0 license headers now, right?
>>>>>>>>>> yes, and I think we can do that without any legal arguments  
>>>>>>>>>> from anyone.
>>>>>>>>>> thanks
>>>>>>>>>> david jencks
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Ate
>>>>>>>>>>>
>>>>>>>>>>>> Carsten
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>
>

[Ate Douma]

David Jencks wrote:

>
> On May 10, 2009, at 3:04 PM, Ate Douma wrote:
>
>> Hi David,
>>
>> Thanks for the work on this, and especially for cleaning up the
>> license headers mess :)
>> We're now much closer to what is needed I think, but there are still a
>> few things to sort out before we can start releasing these.
>>
>> First of all, I think the current groupId which is still
>> javax.portlet, need to be changed to org.apache.portals.
>> Once that's done, we can start updating Pluto, Jetspeed and APA
>> (trunks) to use our own portlet-api artifacts.
> done.

Thanks!
>>
>>
>> Secondly, the /portals/portlet-spec/site folder should be moved to
>> /portals/site/portlet-spec, where it can be cleaned up restructured as
>> much as we like. But at least, by moving it from here it won't be in
>> the way anymore for the planned release.
>
> It's at portlet-specs/trunk/site now so it won't interfere with the
> release.  Moving it is probably a good idea anyway.
Ah yes, you're right.
Anyway, we'd like to bring all Portals sites together under /portals/site to provide a clear and release independent maintenance tree, so
moving it from /portals/portlet-specs/trunk/site to /portals/site/portlet-specs is best, but there is indeed no need to rush that.

>>
>>
>> And thirdly, I think we need to decide about the OSGi bundle generation.
>> To be honest, I'm not very much in favor *right now* to use the Felix
>> plugin for this.
>> As you're already detected, the result is not quite similar to what
>> was produced manually (for portlet-api-2.0).
>> AFAIK, the manually produced OSGi meta-data *is* correct and how it
>> should be.
>> For instance, I think the two most important OSGi tags,
>> Bundle-SymbolicName and Bundle-Version, should be (and remain)
>> java.portlet and 2.0 respectively, independent of our our
>> groupId/artifactId/version, as this jar (OSGi bundle) is expected to
>> be a "drop in" for specifically this *spec* version.
>
> I learned more about osgi the last couple of days :-)

Much more than I'm aware of for sure: I'm no OSGi expert by far :)

> bundle-symbolic-name needs to identify these bundles as different from
> the ones sun may or may not supply.  It doesn't have anything to do with
> what's inside :-)  So I think we should continue with the default from
> the maven-bundle-plugin of <groupId>.<artifactId>, here
> org.apache.portals.portlet-api_1.0_spec etc.
>
> bundle version identities the version of the bundle, not the package
> version of anything inslde.  So I think the standard procedure is to
> start at 1.0.0.
>
> We do need to make sure that the packages inside have version either 2.0
> or 2.0.0.  After a lot of headaches I discovered that the bundle-version
> and the versions for each exported package have nothing to do with one
> another.

OK, I trust your opinion on that.

>
>>
>> To me, the Felix plugin doesn't seem to provide much added value but
>> instead a higher degree of complexity and unsureness how to use it
>> properly and correctly.
>
> If we can get it to produce slightly more reasonable output by the end
> of tomorrow I think we should use it.  For instance it has pointed out
> that the packages in Export-Packages should have uses clauses, at least
> for the servlet package needed.  If no answer from feiix arrives by
> tomorrow then I agree we should use the manual manifest setup..... but
> informed by the bundle plugin output.

Sounds good to me.
I hope Carsten can chime in on this tomorrow too as he's the one bringing in the OSGi configuration in the first place ;)

Regards,

Ate

>
> thanks
> david jencks
>
>>
>>
>> With the rather critical amount of release steps coming up
>> (portals-pom-1.1 -> these portlet-specs -> Pluto 2.0 -> multiple
>> APA-1.0 projects -> Jetspeed 2.2) which are all depending on the
>> previous release step, I strongly urge everyone involved to keep the
>> amount of remaining tasks to the minimum and most practical. Switching
>> back to the manual OSGi bundle generation should be good enough for
>> now IMO.
>>
>> Once the whole of these planned releases are done and over, I have no
>> objections to further investigate how to do this "right" (if needed)
>> and release an update of the spec jars later on. Which is the whole
>> point of now maintaining these ourselves. But lets start out with the
>> minimum required to get rolling.
>>
>> If nobody objects, I think we can do the above 3 steps by tomorrow and
>> create a release 1.0 proposal right after portals-pom-1.1 has been
>> released itself.
>>
>> Regards,
>>
>> Ate
>>
>> David Jencks wrote:
>>> I've been working on this, see PORTALS-14.
>>> I updated to use the portals 1.1 pom now under vote.  I have some
>>> comments in that thread.
>>> It may or may not be a good idea, but I updated the names to
>>> portlet-api_x.0_spec with version 1.0-SNAPSHOT for both specs.  If we
>>> don't like it we can change it back.
>>> I added use of the felix bundle plugin for osgi metadata.  It is
>>> generating different info than the hand-supplied info previously in
>>> the 2.0 spec.  Here's what the bundle plugin comes up with:
>>> Manifest-Version: 1.0
>>> Export-Package: javax.portlet.filter;uses:="javax.portlet,org.w3c.dom,
>>> javax.servlet.http,javax.xml.namespace";version="1.0.0.SNAPSHOT",java
>>> x.portlet;uses:="org.w3c.dom,javax.servlet.http,javax.xml.namespace";
>>> version="1.0.0.SNAPSHOT"
>>> Implementation-Title: Java Portlet Specification V2.0
>>> Implementation-Version: 1.0-SNAPSHOT
>>> Tool: Bnd-0.0.227
>>> Bundle-Name: portlet-api_2.0_spec
>>> Created-By: 1.6.0_07 (Apple Inc.)
>>> Bundle-Vendor: Apache Software Foundation
>>> Bundle-Version: 1.0.0.SNAPSHOT
>>> Bnd-LastModified: 1241824729053
>>> Bundle-ManifestVersion: 2
>>> Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.html
>>> Bundle-Description: The Java Portlet API version 2.0 developed by the
>>> Java Community Process JSR-286 Expert Group.
>>> Import-Package: javax.portlet;version="1.0.0.SNAPSHOT",javax.portlet.f
>>> ilter;version="1.0.0.SNAPSHOT",javax.servlet.http,javax.xml.namespace
>>> ,org.w3c.dom
>>> Bundle-SymbolicName: javax.portlet.portlet-api_2.0_spec
>>> Bundle-DocURL: http://portals.apache.org/
>>> Here's the manually constructed manifest:
>>> Manifest-Version: 1.0
>>> Archiver-Version: Plexus Archiver
>>> Created-By: Apache Maven
>>> Built-By: david
>>> Build-Jdk: 1.6.0_07
>>> Specification-Title: Java Portlet Specification V2.0
>>> Specification-Version: 1.0-SNAPSHOT
>>> Specification-Vendor: Apache Software Foundation
>>> Implementation-Title: Java Portlet Specification V2.0
>>> Implementation-Version: 1.0-SNAPSHOT
>>> Implementation-Vendor-Id: javax.portlet
>>> Implementation-Vendor: Apache Software Foundation
>>> Bundle-DocURL: http://www.jcp.org/en/jsr/detail?id=286
>>> Bundle-ManifestVersion: 2
>>> Bundle-Name: JSR 286
>>> Bundle-SymbolicName: javax.portlet
>>> Bundle-Version: 2.0
>>> Export-Package: javax.portlet;version="2.0.0",
>>>                   javax.portlet.filter;version="2.0.0"
>>> Import-Package: org.w3c.dom,
>>>                   javax.xml.namespace,
>>>                   javax.servlet.http; version="2.4.0"
>>> I'm not enough of an osgi expert to completely understand these
>>> but..... there are some obvious problems with the felix-generated
>>> entries in the version of import/exports.  However at this point I'd
>>> like to investigate what's going on with this a bit more before
>>> recommending one or the other approach.
>>> thanks
>>> david jencks
>>> On May 8, 2009, at 12:55 AM, Ate Douma wrote:
>>>> Hi David,
>>>>
>>>> First of all, thanks again for helping out on this!
>>>>
>>>> I have some inline comments below.
>>>>
>>>> Regards,
>>>>
>>>> Ate
>>>>
>>>> David Jencks wrote:
>>>>> See https://issues.apache.org/jira/browse/PORTALS-12 and
>>>>> https://issues.apache.org/jira/browse/PORTALS-13
>>>>> portlet 2.0:
>>>>> I removed the ibm copyrights from the source files and the
>>>>> license.txt file and added the copyright notice to the NOTICE file.
>>>>> I added the portals-pom as parent and used the
>>>>> maven-remote-resources plugin to generate the LICENSE and NOTICE
>>>>> files.  I also added the LICENSE and NOTICE files to the root of
>>>>> the svn source.
>>>>> portlet 1.0:
>>>>> I changed the license header from apache 1.1 to the current header,
>>>>> allowing its release post- march-2004 :-).  I also added the
>>>>> portals-pom as parent and used the maven-remote-resources plugin to
>>>>> generate the requred LICENSE and NOTICE files, and added these at
>>>>> the root of svn source.
>>>>> Other stuff I think needs to happen:
>>>>> 1. remove the portlet.xml.txt files unless they serve some actual
>>>>> purpose.
>>>> +1, I don't see any purpose at all.
>>>> It is just an example portlet.xml which I think accidentally landed
>>>> in the source tree.
>>>>
>>>>> 2. in 2.0, remove the statement that the spec is provisional found
>>>>> in every file
>>>> +1
>>>>
>>>>> 3. remove the portal-site src and pom completely, use the maven
>>>>> generated site instead for each spec level.
>>>> We have some other plans about site management for all of portals by
>>>> moving that out of the main release cycle svn trees for each project
>>>> and instead maintain it separately (without trunk/tags folders)
>>>> based off /portals/site, with a master portals-site pom and sub
>>>> projects inherit from it (but not necessarily as parent pom modules
>>>> as maven-site plugin is too broken to deal with that correctly).
>>>> This does pose a problem for code based generated docs like reports
>>>> and javadoc, but I think we can and should simply check those in and
>>>> integrate them manually in the corresponding (sub) project site xdocs.
>>>> Anyway, I'll write a formal proposal/vote email for doing this for
>>>> all Portals projects shortly, and then in more detail.
>>>>
>>>>> 4. make the svn tree look like:
>>>>> https://svn.apache.org/repos/asf/portals/portlet-spec
>>>>> +tags
>>>>> \trunk
>>>>>   +portlet-api-1.0
>>>>>   \portlet-api-2.0
>>>> +1
>>>>
>>>>> Somewhat to my surprise we've found this structure to work fine
>>>>> with the geronimo specs and the release plugin.
>>>>> 5. use the felix bundle plugin to insert osgi metadata
>>>> +0, we already do this for portlet-api-2.0 within the pom itself,
>>>> not sure if more is needed here.
>>>> I guess Carsten might have some additional ideas about this.
>>>>
>>>>> 6. remove just about everything from the poms and use the release
>>>>> profile instead
>>>> +1, we're about to provide a vote on an updated portals-pom-1.1
>>>> which will use apache 6 pom
>>>>
>>>>> 7. make the portals-pom specify use of m-r-r-plugin always.
>>>> You mean maven-remote-resources-plugin, right?
>>>> Probably +1, haven't reviewed in detail what possible side-effects
>>>> that could have though.
>>>>
>>>>> 8 update portals-pom to use apache 6 pom as soon as it's available.
>>>> See above, and FYI: apache 6 pom is already released and available
>>>>
>>>>> 9. (maybe) maybe I'm biased :-) but I prefer to use geronimo
>>>>> servlet specs because I know a bit about their quality.  I'd rather
>>>>> build against the geronimo servlet 2.5 spec even though it's
>>>>> uplevel for what's needed than the 2.3 and 2.4 servlet specs that I
>>>>> don't know much about.
>>>> -1
>>>> Not all end users are using a servlet 2.5 container yet, and adding
>>>> a dependency on that could cause problems if they inadvertently then
>>>> would use features from that not supported in their runtime
>>>> environment.
>>>>
>>>>> If everyone agrees these are good changes I think I could find the
>>>>> time to do them soon.  I'd also be happy if someone else does them :-)
>>>> Whoever gets there first :)
>>>> You're very welcome to help out further with this, much appreciated.
>>>>
>>>>> thanks
>>>>> david jencks
>>>>> On May 6, 2009, at 1:00 PM, Ate Douma wrote:
>>>>>> David Jencks wrote:
>>>>>>> My manager thinks it's OK for me, as an IBM employee, to update
>>>>>>> the sources to conform with apache standards, I will try to get
>>>>>>> to it today or tomorrow.
>>>>>> Cool!
>>>>>>
>>>>>> Thanks for helping out with this David.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Ate
>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>> On May 4, 2009, at 4:35 PM, David Jencks wrote:
>>>>>>>> Hi Ate,
>>>>>>>>
>>>>>>>> I haven't heard back from my manager yet, I pinged him again.  I
>>>>>>>> think it's ok to add the apache license header for now, but it
>>>>>>>> would definitely be better to get it fixed, especially as the
>>>>>>>> existing license.txt file does not contain a license at all.
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>> On May 4, 2009, at 3:26 AM, Ate Douma wrote:
>>>>>>>>
>>>>>>>>> David Jencks wrote:
>>>>>>>>>> On Apr 18, 2009, at 1:37 PM, Ate Douma wrote:
>>>>>>>>>
>>>>>>>>> <snip/>
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> In addition, there is this license.txt within the source tree
>>>>>>>>>>> containing the following:
>>>>>>>>>>>
>>>>>>>>>>> � Copyright IBM Corp. 2006, 2007
>>>>>>>>>>> All rights reserved.
>>>>>>>>>>>
>>>>>>>>>>> Should that file remain or maybe should we move that
>>>>>>>>>>> statement to our NOTICE.txt instead?
>>>>>>>>>>>
>>>>>>>>>>> Furthermore, every portlet-api-2.0 source file also contains
>>>>>>>>>>> the "Copyright 2006 IBM Corporation." in the header.
>>>>>>>>>> IIUC the recommended route is to move these copyright notices
>>>>>>>>>> to the NOTICE file.  However someone from IBM has to do it.  
>>>>>>>>>> I'm from IBM but right now I wouldn't be comfortable removing
>>>>>>>>>> them without input from at least one author or IBM legal.  
>>>>>>>>>> I'll ask my boss and see what happens.
>>>>>>>>>
>>>>>>>>> David Jencks, do you have any feedback on this issue?
>>>>>>>>> I'd like to move forward with this proposal ASAP but its a
>>>>>>>>> little unclear to me how we can and/or are allowed to proceed now.
>>>>>>>>>
>>>>>>>>> I would think at least we are allowed to *add* the ASF licence
>>>>>>>>> header to the sources while (for now) retaining the the IBM
>>>>>>>>> copyright notices therein.
>>>>>>>>> And the license.txt file I would think should be fine to be
>>>>>>>>> removed when we move the content to our own NOTICE file.
>>>>>>>>> The remaining question for me is, should we only provide the
>>>>>>>>> standard ASF LICENSE file, or should that in addition *also*
>>>>>>>>> contain the content of the original IBM license.txt?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Ate
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Note that none of such copyright statements are found in the
>>>>>>>>>>> portlet-api-1.0 source, not even from SUN.
>>>>>>>>>>> On the other hand, the portlet-api-1.0 sources do have the
>>>>>>>>>>> ASF 1.1 license header, not the 2.0 license header.
>>>>>>>>>>> I'm not too familiar with what is required when a new release
>>>>>>>>>>> is put out, but I think if we would do this, those need to be
>>>>>>>>>>> replaced with ASF 2.0 license headers now, right?
>>>>>>>>>> yes, and I think we can do that without any legal arguments
>>>>>>>>>> from anyone.
>>>>>>>>>> thanks
>>>>>>>>>> david jencks
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Ate
>>>>>>>>>>>
>>>>>>>>>>>> Carsten
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>
>