You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@portals.apache.org by Ate Douma <at...@douma.nu> on 2009/05/04 12:26:36 UTC
Re: Should or must Apache Portals create and maintain its own Portlet
API (JSR-168/286) spec implementation?
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
>>
>>
>
>
Re: Should or must Apache Portals create and maintain its own Portlet
API (JSR-168/286) spec implementation?
Posted by Ate Douma <at...@douma.nu>.
Ate Douma wrote:
> David Jencks wrote:
<snip/>
>>>>> Anything I could be missing in the above plan?
>>>> - checking that pluto and jetspeed work with our spec jars
>>> Sure, we can (and should) do that, but I have no doubt it will as we
>>> didn't change a single bit within the code base itself.
>>> Its just a change of dependency IMO, nothing more.
>>
>> I'd still like to see it working before voting :-)
> I'm already working on it :)
> I'm in the process of updating Pluto trunk to use the new dependencies
> and will test both manually and run the JSR-286 TCK against it.
> If that works well, I'll repeat it for Jetspeed-2.
> And if all passes, I'll commit the updates for these dependencies.
I performed all the needed updates for the dependency changes in Pluto, APAs and Jetspeed-2 locally.
Then I did some visual/manual interaction testing of Pluto Portal and Jetspeed-2 + APAs and finally ran the JSR-286 TCK against both Pluto
and Jetspeed-2.
I've encountered no issues at all (as expected), so I'm ready to commit the changes now.
I'll create JIRA issues in Pluto, APA and Jetspeed-2 for this update first though.
Regards,
Ate
Re: Should or must Apache Portals create and maintain its own Portlet
API (JSR-168/286) spec implementation?
Posted by Ate Douma <at...@douma.nu>.
David Jencks wrote:
>
> On May 12, 2009, at 7:27 AM, Ate Douma wrote:
>
<snip/>
>> After several fruitless attempts to force the assembly plugin to do
>> what we need, I concluded there is no way to "fix" this without
>> resorting to custom assemblies, *per project* :(
>>
>> And so I did. I modified the portals-pom and removed the configuration
>> element and added a custom project assembly descriptor to both the 1.0
>> and 2.0 spec projects. Now this works fine AFAICT.
>
> I should have mentioned something about this.
>
> I think we can keep using the built-in "project" descriptor because we
> use this only during release. The release plugin does an svn export of
> the project before building the release. This won't have any or the
> .eclipse files, and if we get the assembly to run early enough in the
> build, the velocity.log file won't be there either.
I'm not sure how that can work and produce the expected/required resulting NOTICE file, besides how to ensure the assembly is run first
before the m-r-r-plugin which I haven't figured out yete how to do.
The "odd" thing about such a release distro project assembly build is that it should contain the actual project source tree but also a
complete and valid NOTICE file. As we only have a partial NOTICE file in svn, augmented by the m-r-r-plugin at build time, which one should
be provided in the assembled distro? Either way this seems like conflicting requirements to me.
And, if we choose (or are required) to include the augmented NOTICE file, we're back to square one, as this will result in the velocity.log
to be included as well.
Maybe there is a way to suppress the creation of the velocity.log or have it put somewhere else, using a -D system property overriding the
logdir?
Any thoughts?
> I'd rather stick with the built-in descriptor.
>
> thanks
> david jencks
Re: Should or must Apache Portals create and maintain its own Portlet
API (JSR-168/286) spec implementation?
Posted by Ate Douma <at...@douma.nu>.
David Jencks wrote:
>
> On May 12, 2009, at 7:27 AM, Ate Douma wrote:
>
>> David Jencks wrote:
>>> On May 11, 2009, at 4:29 PM, Ate Douma wrote:
>>>> David Jencks wrote:
>>>>> On May 11, 2009, at 3:42 PM, Ate Douma wrote:
>>>> <snip/>
>> <more-snip/>
>>>>>>
>>>>>>> I think we should add the assembly plugin to each top level pom
>>>>>>> to build the source distro, and continue using the release plugin
>>>>>>> for the entire release process. IIUC this approach will get into
>>>>>>> the next apache pom with some additional automation. I'll see if
>>>>>>> I can come up with appropriate assembly plugin configuration.
>>>>>> Sure, if you find a way to further automate this, I'm all for it,
>>>>>> as long as it works :)
>>>>>> What is unclear to me however, how/where this source distro is
>>>>>> going to be "published" to the maven repository.
>>>>>> I assume that requires an additional artifact (e.g. pom.xml)
>>>>>> definition, right?
>>>>> I set this up. IIUC the new project distro artifacts will be
>>>>> deployed along with all the other artifacts when we run mvn deploy
>>>>> -Papache-release, for instance when the release:perform goal does
>>>>> this.
>>>> Cool, thanks David, I will try this out right away (locally of course).
>>> My original commit might not work, there seems to be a problem in the
>>> assembly plugin 2.2-beta-3. I switched to 2.2-beta-2 which does seem
>>> to work.
>> I discovered an issue with the predefined project assembly descriptor
>> in that you cannot customize it with additional includes/excludes.
>> That makes these predefined assemblies pretty useless imo, as we
>> clearly need to add a few excludes of our own:
>> velocity.log (produced by the remote-resources-plugin)
>> .project
>> .classpath
>> .settings/*
>>
>> After several fruitless attempts to force the assembly plugin to do
>> what we need, I concluded there is no way to "fix" this without
>> resorting to custom assemblies, *per project* :(
>>
>> And so I did. I modified the portals-pom and removed the configuration
>> element and added a custom project assembly descriptor to both the 1.0
>> and 2.0 spec projects. Now this works fine AFAICT.
>
> I should have mentioned something about this.
>
> I think we can keep using the built-in "project" descriptor because we
> use this only during release. The release plugin does an svn export of
> the project before building the release. This won't have any or the
> .eclipse files, and if we get the assembly to run early enough in the
> build, the velocity.log file won't be there either. I'd rather stick
> with the built-in descriptor.
Oh, well.
I already started the release:prepare and release:perform but am hitting several problems doing that.
Somehow I seem not have enough rights at the Nexus repo, even while I have a login account.
Based upon your comments above and on another thread, I've decided to rollback my commits and figure out how to do this correct.
Welcome your further comments and help about this.
Regards,
Ate
>
> thanks
> david jencks
>>
>>
>> With the additional cleanup Vivek performed earlier, it seems to me
>> we're finally ready now to start the release of the portals-pom-1.2
>> and the spec projects together.
>>
>> I'll start working on that now.
>>
>> Regards,
>>
>> Ate
>>
>>>>
>>>>
>>>>> As noted in another thread I think the changes we'd like in
>>>>> portals-pom are piling up and we should get them all in and release
>>>>> portals-pom 1.2 and the specs in one vote (or simultaneous votes).
>>>>> I'd move the pluginManagement assembly plugin configuration to the
>>>>> parent.
>>>> OK, +1
>>>> Just as David Taylor just asked on another thread, can you explain
>>>> how you want the ianal plugin to be run on all builds?
>>> just include it in the <build><plugins> element in the portals-pom.
>>> To re-answer David's question, it checks that the required legal
>>> files are included in every artifact.
>>>>
>>>>
>>>> If I may ask, would you be willing to do the required changed for
>>>> the portals-pom-1.2-SNAPSHOT so we can all assess what these changes
>>>> will amount to?
>>> I did this and also updated the spec poms to use the snapshot
>>> parent. rev 773745 in case you want to revert it.
>>> Only part not discussed previously is that I renamed prepare-release
>>> profile to rat. I don't know what problems occurred when running it
>>> as apache-release, but I don't think people usually include rat in
>>> the release profile. I'm not sure why or why not.... I'm fine with
>>> asking RMs to run -Prat before release:prepare.
>>> thanks
>>> david jencks
>>>>
>>>>
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Anything I could be missing in the above plan?
>>>>>>> - checking that pluto and jetspeed work with our spec jars
>>>>>> Sure, we can (and should) do that, but I have no doubt it will as
>>>>>> we didn't change a single bit within the code base itself.
>>>>>> Its just a change of dependency IMO, nothing more.
>>>>> I'd still like to see it working before voting :-)
>>>> I'm already working on it :)
>>>> I'm in the process of updating Pluto trunk to use the new
>>>> dependencies and will test both manually and run the JSR-286 TCK
>>>> against it.
>>>> If that works well, I'll repeat it for Jetspeed-2.
>>>> And if all passes, I'll commit the updates for these dependencies.
>>>>
>>>>>>
>>>>>> The area where we did make changes, the OSGi bundle configuration,
>>>>>> won't affect Pluto or Jetspeed-2 as they don't use that information.
>>>>>>
>>>>>>> - checking that our osgi metadata is accurate enough to work.
>>>>>> That I have to leave up to you and especially Carsten to validate.
>>>>>> I know Carsten is using OSGi a lot, so I presume he should be able
>>>>>> to quickly test this out.
>>>>>> For the the usage of these spec jars within the Apache Portals
>>>>>> projects, the dependency replacement is what matters to me the
>>>>>> most for this initial release. If the OSGi bundle configuration
>>>>>> turns out to need more tweaking in the future, a follow up release
>>>>>> is easily done.
>>>>> agreed.
>>>>> thanks
>>>>> david jencks
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Ate
>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Ate
>>>>>>>>
>>>>>>>> David Jencks wrote:
>>>>>>>>> On May 11, 2009, at 11:20 AM, Carsten Ziegeler wrote:
>>>>>>>>>> Ate Douma wrote:
>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> 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 ;)
>>>>>>>>>>>
>>>>>>>>>> I'm slowly recovering from switching to my new laptop :)
>>>>>>>>>>
>>>>>>>>>> Ok I think we don't need to use the maven bundle plugin as the
>>>>>>>>>> manifest
>>>>>>>>>> headers are constant in our case; but there is nothing wrong
>>>>>>>>>> with using
>>>>>>>>>> the plugin, so we can leave it as is. But in this case, I
>>>>>>>>>> suggest to
>>>>>>>>>> remove the import package statement and change the export
>>>>>>>>>> statement to just:
>>>>>>>>>> <Export-Package>javax.portlet.filter;version=2.0.0,
>>>>>>>>>> javax.portlet;version=2.0.0
>>>>>>>>>> </Export-Package>
>>>>>>>>>> The plugin is doing the rest (adding the uses, creating the
>>>>>>>>>> correct
>>>>>>>>>> import etc.)
>>>>>>>>>>
>>>>>>>>> OK.... I had to include some info on imports in order to get
>>>>>>>>> the servlet version to be 2.4, the sun api jar isn't a bundle
>>>>>>>>> with package versions. I simplified the poms as much as I
>>>>>>>>> could...
>>>>>>>>> many thanks
>>>>>>>>> david jencks
>>>>>>>>>>
>>>>>>>>>> Carsten
>>>>>>>>>> --
>>>>>>>>>> Carsten Ziegeler
>>>>>>>>>> cziegeler@apache.org
>>>>>>>>
>>>>>>
>>>>
>>
>
>
Re: Should or must Apache Portals create and maintain its own Portlet API (JSR-168/286) spec implementation?
Posted by David Jencks <da...@yahoo.com>.
On May 12, 2009, at 7:27 AM, Ate Douma wrote:
> David Jencks wrote:
>> On May 11, 2009, at 4:29 PM, Ate Douma wrote:
>>> David Jencks wrote:
>>>> On May 11, 2009, at 3:42 PM, Ate Douma wrote:
>>> <snip/>
> <more-snip/>
>>>>>
>>>>>> I think we should add the assembly plugin to each top level pom
>>>>>> to build the source distro, and continue using the release
>>>>>> plugin for the entire release process. IIUC this approach will
>>>>>> get into the next apache pom with some additional automation.
>>>>>> I'll see if I can come up with appropriate assembly plugin
>>>>>> configuration.
>>>>> Sure, if you find a way to further automate this, I'm all for
>>>>> it, as long as it works :)
>>>>> What is unclear to me however, how/where this source distro is
>>>>> going to be "published" to the maven repository.
>>>>> I assume that requires an additional artifact (e.g. pom.xml)
>>>>> definition, right?
>>>> I set this up. IIUC the new project distro artifacts will be
>>>> deployed along with all the other artifacts when we run mvn
>>>> deploy -Papache-release, for instance when the release:perform
>>>> goal does this.
>>> Cool, thanks David, I will try this out right away (locally of
>>> course).
>> My original commit might not work, there seems to be a problem in
>> the assembly plugin 2.2-beta-3. I switched to 2.2-beta-2 which
>> does seem to work.
> I discovered an issue with the predefined project assembly
> descriptor in that you cannot customize it with additional includes/
> excludes.
> That makes these predefined assemblies pretty useless imo, as we
> clearly need to add a few excludes of our own:
> velocity.log (produced by the remote-resources-plugin)
> .project
> .classpath
> .settings/*
>
> After several fruitless attempts to force the assembly plugin to do
> what we need, I concluded there is no way to "fix" this without
> resorting to custom assemblies, *per project* :(
>
> And so I did. I modified the portals-pom and removed the
> configuration element and added a custom project assembly descriptor
> to both the 1.0 and 2.0 spec projects. Now this works fine AFAICT.
I should have mentioned something about this.
I think we can keep using the built-in "project" descriptor because
we use this only during release. The release plugin does an svn
export of the project before building the release. This won't have
any or the .eclipse files, and if we get the assembly to run early
enough in the build, the velocity.log file won't be there either. I'd
rather stick with the built-in descriptor.
thanks
david jencks
>
>
> With the additional cleanup Vivek performed earlier, it seems to me
> we're finally ready now to start the release of the portals-pom-1.2
> and the spec projects together.
>
> I'll start working on that now.
>
> Regards,
>
> Ate
>
>>>
>>>
>>>> As noted in another thread I think the changes we'd like in
>>>> portals-pom are piling up and we should get them all in and
>>>> release portals-pom 1.2 and the specs in one vote (or
>>>> simultaneous votes). I'd move the pluginManagement assembly
>>>> plugin configuration to the parent.
>>> OK, +1
>>> Just as David Taylor just asked on another thread, can you explain
>>> how you want the ianal plugin to be run on all builds?
>> just include it in the <build><plugins> element in the portals-
>> pom. To re-answer David's question, it checks that the required
>> legal files are included in every artifact.
>>>
>>>
>>> If I may ask, would you be willing to do the required changed for
>>> the portals-pom-1.2-SNAPSHOT so we can all assess what these
>>> changes will amount to?
>> I did this and also updated the spec poms to use the snapshot
>> parent. rev 773745 in case you want to revert it.
>> Only part not discussed previously is that I renamed prepare-
>> release profile to rat. I don't know what problems occurred when
>> running it as apache-release, but I don't think people usually
>> include rat in the release profile. I'm not sure why or why
>> not.... I'm fine with asking RMs to run -Prat before release:prepare.
>> thanks
>> david jencks
>>>
>>>
>>>>>
>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Anything I could be missing in the above plan?
>>>>>> - checking that pluto and jetspeed work with our spec jars
>>>>> Sure, we can (and should) do that, but I have no doubt it will
>>>>> as we didn't change a single bit within the code base itself.
>>>>> Its just a change of dependency IMO, nothing more.
>>>> I'd still like to see it working before voting :-)
>>> I'm already working on it :)
>>> I'm in the process of updating Pluto trunk to use the new
>>> dependencies and will test both manually and run the JSR-286 TCK
>>> against it.
>>> If that works well, I'll repeat it for Jetspeed-2.
>>> And if all passes, I'll commit the updates for these dependencies.
>>>
>>>>>
>>>>> The area where we did make changes, the OSGi bundle
>>>>> configuration, won't affect Pluto or Jetspeed-2 as they don't
>>>>> use that information.
>>>>>
>>>>>> - checking that our osgi metadata is accurate enough to work.
>>>>> That I have to leave up to you and especially Carsten to
>>>>> validate. I know Carsten is using OSGi a lot, so I presume he
>>>>> should be able to quickly test this out.
>>>>> For the the usage of these spec jars within the Apache Portals
>>>>> projects, the dependency replacement is what matters to me the
>>>>> most for this initial release. If the OSGi bundle configuration
>>>>> turns out to need more tweaking in the future, a follow up
>>>>> release is easily done.
>>>> agreed.
>>>> thanks
>>>> david jencks
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Ate
>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Ate
>>>>>>>
>>>>>>> David Jencks wrote:
>>>>>>>> On May 11, 2009, at 11:20 AM, Carsten Ziegeler wrote:
>>>>>>>>> Ate Douma wrote:
>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>
>>>>>>>>>>> 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 ;)
>>>>>>>>>>
>>>>>>>>> I'm slowly recovering from switching to my new laptop :)
>>>>>>>>>
>>>>>>>>> Ok I think we don't need to use the maven bundle plugin as
>>>>>>>>> the manifest
>>>>>>>>> headers are constant in our case; but there is nothing wrong
>>>>>>>>> with using
>>>>>>>>> the plugin, so we can leave it as is. But in this case, I
>>>>>>>>> suggest to
>>>>>>>>> remove the import package statement and change the export
>>>>>>>>> statement to just:
>>>>>>>>> <Export-Package>javax.portlet.filter;version=2.0.0,
>>>>>>>>> javax.portlet;version=2.0.0
>>>>>>>>> </Export-Package>
>>>>>>>>> The plugin is doing the rest (adding the uses, creating the
>>>>>>>>> correct
>>>>>>>>> import etc.)
>>>>>>>>>
>>>>>>>> OK.... I had to include some info on imports in order to get
>>>>>>>> the servlet version to be 2.4, the sun api jar isn't a bundle
>>>>>>>> with package versions. I simplified the poms as much as I
>>>>>>>> could...
>>>>>>>> many thanks
>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>> Carsten
>>>>>>>>> --
>>>>>>>>> Carsten Ziegeler
>>>>>>>>> cziegeler@apache.org
>>>>>>>
>>>>>
>>>
>
Re: Should or must Apache Portals create and maintain its own Portlet
API (JSR-168/286) spec implementation?
Posted by Ate Douma <at...@douma.nu>.
David Jencks wrote:
>
> On May 11, 2009, at 4:29 PM, Ate Douma wrote:
>
>> David Jencks wrote:
>>> On May 11, 2009, at 3:42 PM, Ate Douma wrote:
>> <snip/>
<more-snip/>
>>>>
>>>>> I think we should add the assembly plugin to each top level pom to
>>>>> build the source distro, and continue using the release plugin for
>>>>> the entire release process. IIUC this approach will get into the
>>>>> next apache pom with some additional automation. I'll see if I can
>>>>> come up with appropriate assembly plugin configuration.
>>>> Sure, if you find a way to further automate this, I'm all for it, as
>>>> long as it works :)
>>>> What is unclear to me however, how/where this source distro is going
>>>> to be "published" to the maven repository.
>>>> I assume that requires an additional artifact (e.g. pom.xml)
>>>> definition, right?
>>> I set this up. IIUC the new project distro artifacts will be
>>> deployed along with all the other artifacts when we run mvn deploy
>>> -Papache-release, for instance when the release:perform goal does this.
>> Cool, thanks David, I will try this out right away (locally of course).
>
> My original commit might not work, there seems to be a problem in the
> assembly plugin 2.2-beta-3. I switched to 2.2-beta-2 which does seem to
> work.
I discovered an issue with the predefined project assembly descriptor in that you cannot customize it with additional includes/excludes.
That makes these predefined assemblies pretty useless imo, as we clearly need to add a few excludes of our own:
velocity.log (produced by the remote-resources-plugin)
.project
.classpath
.settings/*
After several fruitless attempts to force the assembly plugin to do what we need, I concluded there is no way to "fix" this without
resorting to custom assemblies, *per project* :(
And so I did. I modified the portals-pom and removed the configuration element and added a custom project assembly descriptor to both the
1.0 and 2.0 spec projects. Now this works fine AFAICT.
With the additional cleanup Vivek performed earlier, it seems to me we're finally ready now to start the release of the portals-pom-1.2 and
the spec projects together.
I'll start working on that now.
Regards,
Ate
>>
>>
>>> As noted in another thread I think the changes we'd like in
>>> portals-pom are piling up and we should get them all in and release
>>> portals-pom 1.2 and the specs in one vote (or simultaneous votes).
>>> I'd move the pluginManagement assembly plugin configuration to the
>>> parent.
>> OK, +1
>> Just as David Taylor just asked on another thread, can you explain how
>> you want the ianal plugin to be run on all builds?
>
> just include it in the <build><plugins> element in the portals-pom. To
> re-answer David's question, it checks that the required legal files are
> included in every artifact.
>>
>>
>> If I may ask, would you be willing to do the required changed for the
>> portals-pom-1.2-SNAPSHOT so we can all assess what these changes will
>> amount to?
>
> I did this and also updated the spec poms to use the snapshot parent.
> rev 773745 in case you want to revert it.
>
> Only part not discussed previously is that I renamed prepare-release
> profile to rat. I don't know what problems occurred when running it as
> apache-release, but I don't think people usually include rat in the
> release profile. I'm not sure why or why not.... I'm fine with asking
> RMs to run -Prat before release:prepare.
>
>
> thanks
> david jencks
>
>>
>>
>>>>
>>>>
>>>>>>
>>>>>>
>>>>>> Anything I could be missing in the above plan?
>>>>> - checking that pluto and jetspeed work with our spec jars
>>>> Sure, we can (and should) do that, but I have no doubt it will as we
>>>> didn't change a single bit within the code base itself.
>>>> Its just a change of dependency IMO, nothing more.
>>> I'd still like to see it working before voting :-)
>> I'm already working on it :)
>> I'm in the process of updating Pluto trunk to use the new dependencies
>> and will test both manually and run the JSR-286 TCK against it.
>> If that works well, I'll repeat it for Jetspeed-2.
>> And if all passes, I'll commit the updates for these dependencies.
>>
>>>>
>>>> The area where we did make changes, the OSGi bundle configuration,
>>>> won't affect Pluto or Jetspeed-2 as they don't use that information.
>>>>
>>>>> - checking that our osgi metadata is accurate enough to work.
>>>> That I have to leave up to you and especially Carsten to validate. I
>>>> know Carsten is using OSGi a lot, so I presume he should be able to
>>>> quickly test this out.
>>>> For the the usage of these spec jars within the Apache Portals
>>>> projects, the dependency replacement is what matters to me the most
>>>> for this initial release. If the OSGi bundle configuration turns out
>>>> to need more tweaking in the future, a follow up release is easily
>>>> done.
>>> agreed.
>>> thanks
>>> david jencks
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Ate
>>>>
>>>>> thanks
>>>>> david jencks
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Ate
>>>>>>
>>>>>> David Jencks wrote:
>>>>>>> On May 11, 2009, at 11:20 AM, Carsten Ziegeler wrote:
>>>>>>>> Ate Douma wrote:
>>>>>>>>> David Jencks wrote:
>>>>>>>>>>
>>>>>>>>>> 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 ;)
>>>>>>>>>
>>>>>>>> I'm slowly recovering from switching to my new laptop :)
>>>>>>>>
>>>>>>>> Ok I think we don't need to use the maven bundle plugin as the
>>>>>>>> manifest
>>>>>>>> headers are constant in our case; but there is nothing wrong
>>>>>>>> with using
>>>>>>>> the plugin, so we can leave it as is. But in this case, I
>>>>>>>> suggest to
>>>>>>>> remove the import package statement and change the export
>>>>>>>> statement to just:
>>>>>>>> <Export-Package>javax.portlet.filter;version=2.0.0,
>>>>>>>> javax.portlet;version=2.0.0
>>>>>>>> </Export-Package>
>>>>>>>> The plugin is doing the rest (adding the uses, creating the correct
>>>>>>>> import etc.)
>>>>>>>>
>>>>>>> OK.... I had to include some info on imports in order to get the
>>>>>>> servlet version to be 2.4, the sun api jar isn't a bundle with
>>>>>>> package versions. I simplified the poms as much as I could...
>>>>>>> many thanks
>>>>>>> david jencks
>>>>>>>>
>>>>>>>> Carsten
>>>>>>>> --
>>>>>>>> Carsten Ziegeler
>>>>>>>> cziegeler@apache.org
>>>>>>
>>>>
>>
>
Re: Should or must Apache Portals create and maintain its own Portlet API (JSR-168/286) spec implementation?
Posted by David Jencks <da...@yahoo.com>.
On May 11, 2009, at 4:29 PM, Ate Douma wrote:
> David Jencks wrote:
>> On May 11, 2009, at 3:42 PM, Ate Douma wrote:
> <snip/>
>
>>>>> The release plan I have come up to be in alignment with the
>>>>> (refreshed) ASF release requirements is the following:
>>>>> 1) first do a Nexus release to a staged repository (this will
>>>>> create the release tags for both projects)
>>>>>
>>>>> 2) do a manual checkout of the release tag src and build src
>>>>> dist archives myself, sign them and upload to a public folder at
>>>>> people.apache.org, like people.apache.org/~ate/portlet_spec/ [...]
>>>>> or
>>>>> for instance use the maven assembly plugin doing (all) the above
>>>>> automatically???
>>>>> I actually have never needed to use the assembly plugin yet so
>>>>> I'm not sure what/how much it can do...
>>>>> Maybe David or Carsten know more about it, but if I have to find
>>>>> out myself, I might just resort back to doing it manual this time
>>>>>
>>>>> 3) send out a VOTE email concerning *both* the Nexus provided
>>>>> artifacts from the temporary staged repository *and* the
>>>>> uploaded src dist archives
>>>>>
>>>>> 4) .... process the VOTE results and (hopefully) have the
>>>>> release completed.
>>>> IMO this is too complicated to be workable.
>>> Well, at least it should work as we already know now Nexus works
>>> fine, and the manual bit is just the same as how we've done it in
>>> the past.
>>>
>>>> I think we should add the assembly plugin to each top level pom
>>>> to build the source distro, and continue using the release plugin
>>>> for the entire release process. IIUC this approach will get into
>>>> the next apache pom with some additional automation. I'll see if
>>>> I can come up with appropriate assembly plugin configuration.
>>> Sure, if you find a way to further automate this, I'm all for it,
>>> as long as it works :)
>>> What is unclear to me however, how/where this source distro is
>>> going to be "published" to the maven repository.
>>> I assume that requires an additional artifact (e.g. pom.xml)
>>> definition, right?
>> I set this up. IIUC the new project distro artifacts will be
>> deployed along with all the other artifacts when we run mvn deploy -
>> Papache-release, for instance when the release:perform goal does
>> this.
> Cool, thanks David, I will try this out right away (locally of
> course).
My original commit might not work, there seems to be a problem in the
assembly plugin 2.2-beta-3. I switched to 2.2-beta-2 which does seem
to work.
>
>
>> As noted in another thread I think the changes we'd like in portals-
>> pom are piling up and we should get them all in and release portals-
>> pom 1.2 and the specs in one vote (or simultaneous votes). I'd
>> move the pluginManagement assembly plugin configuration to the
>> parent.
> OK, +1
> Just as David Taylor just asked on another thread, can you explain
> how you want the ianal plugin to be run on all builds?
just include it in the <build><plugins> element in the portals-pom.
To re-answer David's question, it checks that the required legal files
are included in every artifact.
>
>
> If I may ask, would you be willing to do the required changed for
> the portals-pom-1.2-SNAPSHOT so we can all assess what these changes
> will amount to?
I did this and also updated the spec poms to use the snapshot parent.
rev 773745 in case you want to revert it.
Only part not discussed previously is that I renamed prepare-release
profile to rat. I don't know what problems occurred when running it
as apache-release, but I don't think people usually include rat in the
release profile. I'm not sure why or why not.... I'm fine with asking
RMs to run -Prat before release:prepare.
thanks
david jencks
>
>
>>>
>>>
>>>>>
>>>>>
>>>>> Anything I could be missing in the above plan?
>>>> - checking that pluto and jetspeed work with our spec jars
>>> Sure, we can (and should) do that, but I have no doubt it will as
>>> we didn't change a single bit within the code base itself.
>>> Its just a change of dependency IMO, nothing more.
>> I'd still like to see it working before voting :-)
> I'm already working on it :)
> I'm in the process of updating Pluto trunk to use the new
> dependencies and will test both manually and run the JSR-286 TCK
> against it.
> If that works well, I'll repeat it for Jetspeed-2.
> And if all passes, I'll commit the updates for these dependencies.
>
>>>
>>> The area where we did make changes, the OSGi bundle configuration,
>>> won't affect Pluto or Jetspeed-2 as they don't use that information.
>>>
>>>> - checking that our osgi metadata is accurate enough to work.
>>> That I have to leave up to you and especially Carsten to validate.
>>> I know Carsten is using OSGi a lot, so I presume he should be able
>>> to quickly test this out.
>>> For the the usage of these spec jars within the Apache Portals
>>> projects, the dependency replacement is what matters to me the
>>> most for this initial release. If the OSGi bundle configuration
>>> turns out to need more tweaking in the future, a follow up release
>>> is easily done.
>> agreed.
>> thanks
>> david jencks
>>>
>>>
>>> Regards,
>>>
>>> Ate
>>>
>>>> thanks
>>>> david jencks
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Ate
>>>>>
>>>>> David Jencks wrote:
>>>>>> On May 11, 2009, at 11:20 AM, Carsten Ziegeler wrote:
>>>>>>> Ate Douma wrote:
>>>>>>>> David Jencks wrote:
>>>>>>>>>
>>>>>>>>> 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 ;)
>>>>>>>>
>>>>>>> I'm slowly recovering from switching to my new laptop :)
>>>>>>>
>>>>>>> Ok I think we don't need to use the maven bundle plugin as the
>>>>>>> manifest
>>>>>>> headers are constant in our case; but there is nothing wrong
>>>>>>> with using
>>>>>>> the plugin, so we can leave it as is. But in this case, I
>>>>>>> suggest to
>>>>>>> remove the import package statement and change the export
>>>>>>> statement to just:
>>>>>>> <Export-Package>javax.portlet.filter;version=2.0.0,
>>>>>>> javax.portlet;version=2.0.0
>>>>>>> </Export-Package>
>>>>>>> The plugin is doing the rest (adding the uses, creating the
>>>>>>> correct
>>>>>>> import etc.)
>>>>>>>
>>>>>> OK.... I had to include some info on imports in order to get
>>>>>> the servlet version to be 2.4, the sun api jar isn't a bundle
>>>>>> with package versions. I simplified the poms as much as I
>>>>>> could...
>>>>>> many thanks
>>>>>> david jencks
>>>>>>>
>>>>>>> Carsten
>>>>>>> --
>>>>>>> Carsten Ziegeler
>>>>>>> cziegeler@apache.org
>>>>>
>>>
>
Re: Should or must Apache Portals create and maintain its own Portlet
API (JSR-168/286) spec implementation?
Posted by Ate Douma <at...@douma.nu>.
David Jencks wrote:
>
> On May 11, 2009, at 3:42 PM, Ate Douma wrote:
>
<snip/>
>>>> The release plan I have come up to be in alignment with the
>>>> (refreshed) ASF release requirements is the following:
>>>> 1) first do a Nexus release to a staged repository (this will create
>>>> the release tags for both projects)
>>>>
>>>> 2) do a manual checkout of the release tag src and build src dist
>>>> archives myself, sign them and upload to a public folder at
>>>> people.apache.org, like people.apache.org/~ate/portlet_spec/ [...]
>>>> or
>>>> for instance use the maven assembly plugin doing (all) the above
>>>> automatically???
>>>> I actually have never needed to use the assembly plugin yet so I'm
>>>> not sure what/how much it can do...
>>>> Maybe David or Carsten know more about it, but if I have to find
>>>> out myself, I might just resort back to doing it manual this time
>>>>
>>>> 3) send out a VOTE email concerning *both* the Nexus provided
>>>> artifacts from the temporary staged repository *and* the uploaded
>>>> src dist archives
>>>>
>>>> 4) .... process the VOTE results and (hopefully) have the release
>>>> completed.
>>> IMO this is too complicated to be workable.
>> Well, at least it should work as we already know now Nexus works fine,
>> and the manual bit is just the same as how we've done it in the past.
>>
>>> I think we should add the assembly plugin to each top level pom to
>>> build the source distro, and continue using the release plugin for
>>> the entire release process. IIUC this approach will get into the
>>> next apache pom with some additional automation. I'll see if I can
>>> come up with appropriate assembly plugin configuration.
>> Sure, if you find a way to further automate this, I'm all for it, as
>> long as it works :)
>> What is unclear to me however, how/where this source distro is going
>> to be "published" to the maven repository.
>> I assume that requires an additional artifact (e.g. pom.xml)
>> definition, right?
>
> I set this up. IIUC the new project distro artifacts will be deployed
> along with all the other artifacts when we run mvn deploy
> -Papache-release, for instance when the release:perform goal does this.
Cool, thanks David, I will try this out right away (locally of course).
>
> As noted in another thread I think the changes we'd like in portals-pom
> are piling up and we should get them all in and release portals-pom 1.2
> and the specs in one vote (or simultaneous votes). I'd move the
> pluginManagement assembly plugin configuration to the parent.
OK, +1
Just as David Taylor just asked on another thread, can you explain how you want the ianal plugin to be run on all builds?
If I may ask, would you be willing to do the required changed for the portals-pom-1.2-SNAPSHOT so we can all assess what these changes will
amount to?
>>
>>
>>>>
>>>>
>>>> Anything I could be missing in the above plan?
>>> - checking that pluto and jetspeed work with our spec jars
>> Sure, we can (and should) do that, but I have no doubt it will as we
>> didn't change a single bit within the code base itself.
>> Its just a change of dependency IMO, nothing more.
>
> I'd still like to see it working before voting :-)
I'm already working on it :)
I'm in the process of updating Pluto trunk to use the new dependencies and will test both manually and run the JSR-286 TCK against it.
If that works well, I'll repeat it for Jetspeed-2.
And if all passes, I'll commit the updates for these dependencies.
>
>>
>> The area where we did make changes, the OSGi bundle configuration,
>> won't affect Pluto or Jetspeed-2 as they don't use that information.
>>
>>> - checking that our osgi metadata is accurate enough to work.
>> That I have to leave up to you and especially Carsten to validate. I
>> know Carsten is using OSGi a lot, so I presume he should be able to
>> quickly test this out.
>> For the the usage of these spec jars within the Apache Portals
>> projects, the dependency replacement is what matters to me the most
>> for this initial release. If the OSGi bundle configuration turns out
>> to need more tweaking in the future, a follow up release is easily done.
>
> agreed.
> thanks
> david jencks
>
>>
>>
>> Regards,
>>
>> Ate
>>
>>> thanks
>>> david jencks
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Ate
>>>>
>>>> David Jencks wrote:
>>>>> On May 11, 2009, at 11:20 AM, Carsten Ziegeler wrote:
>>>>>> Ate Douma wrote:
>>>>>>> David Jencks wrote:
>>>>>>>>
>>>>>>>> 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 ;)
>>>>>>>
>>>>>> I'm slowly recovering from switching to my new laptop :)
>>>>>>
>>>>>> Ok I think we don't need to use the maven bundle plugin as the
>>>>>> manifest
>>>>>> headers are constant in our case; but there is nothing wrong with
>>>>>> using
>>>>>> the plugin, so we can leave it as is. But in this case, I suggest to
>>>>>> remove the import package statement and change the export
>>>>>> statement to just:
>>>>>> <Export-Package>javax.portlet.filter;version=2.0.0,
>>>>>> javax.portlet;version=2.0.0
>>>>>> </Export-Package>
>>>>>> The plugin is doing the rest (adding the uses, creating the correct
>>>>>> import etc.)
>>>>>>
>>>>> OK.... I had to include some info on imports in order to get the
>>>>> servlet version to be 2.4, the sun api jar isn't a bundle with
>>>>> package versions. I simplified the poms as much as I could...
>>>>> many thanks
>>>>> david jencks
>>>>>>
>>>>>> Carsten
>>>>>> --
>>>>>> Carsten Ziegeler
>>>>>> cziegeler@apache.org
>>>>
>>
>
>
Re: Should or must Apache Portals create and maintain its own Portlet API (JSR-168/286) spec implementation?
Posted by David Jencks <da...@yahoo.com>.
On May 11, 2009, at 3:42 PM, Ate Douma wrote:
> David Jencks wrote:
>> On May 11, 2009, at 1:31 PM, Ate Douma wrote:
>>> Hi,
>>>
>>> I cleaned up a few last minor things in the portlet_spec poms:
>>> - some svn:ignore properties as needed for Eclipse IDE
>>> - added provided servlet 2.3 dependency for portlet_spec 1.0
>> It builds for me without this dependency so I don't think we should
>> include it. Do you have some reason to think it's needed?
> No, my mistake and I removed it again.
> I also already responded on your earlier reply on the commit message.
>
>>>
>>> - fixed changed scm locations
>>>
>>> Then, I ran rat using the new portals-pom-1.1 prepare-release
>>> profile (mvn install -P prepare-release) and hit two files without
>>> proper AL header in the portlet_spec 2.0 project, used for and
>>> produced by the maven-remote-resources-plugin:
>>>
>>> - src/main/appended-resources/META-INF/NOTICE.vm
>>> - velocity.log
>>>
>>> As someone not familiar with the rat plugin, what is the best
>>> solution to get these false positives ignored or resolved?
>>>
>> looks like you fixed this.
> Yes, a little searching showed howto.
>>>
>>> Other than this last issue, and assuming the OSGi bundle info now
>>> is generated correctly (relying on the assessment of both David
>>> and Carsten for this), I think we're ready to go to release these
>>> portlet_spec projects through Nexus by tomorrow morning.
>>>
>>> The release plan I have come up to be in alignment with the
>>> (refreshed) ASF release requirements is the following:
>>> 1) first do a Nexus release to a staged repository (this will
>>> create the release tags for both projects)
>>>
>>> 2) do a manual checkout of the release tag src and build src dist
>>> archives myself, sign them and upload to a public folder at
>>> people.apache.org, like people.apache.org/~ate/portlet_spec/ [...]
>>> or
>>> for instance use the maven assembly plugin doing (all) the above
>>> automatically???
>>> I actually have never needed to use the assembly plugin yet so
>>> I'm not sure what/how much it can do...
>>> Maybe David or Carsten know more about it, but if I have to find
>>> out myself, I might just resort back to doing it manual this time
>>>
>>> 3) send out a VOTE email concerning *both* the Nexus provided
>>> artifacts from the temporary staged repository *and* the uploaded
>>> src dist archives
>>>
>>> 4) .... process the VOTE results and (hopefully) have the release
>>> completed.
>> IMO this is too complicated to be workable.
> Well, at least it should work as we already know now Nexus works
> fine, and the manual bit is just the same as how we've done it in
> the past.
>
>> I think we should add the assembly plugin to each top level pom to
>> build the source distro, and continue using the release plugin for
>> the entire release process. IIUC this approach will get into the
>> next apache pom with some additional automation. I'll see if I can
>> come up with appropriate assembly plugin configuration.
> Sure, if you find a way to further automate this, I'm all for it, as
> long as it works :)
> What is unclear to me however, how/where this source distro is going
> to be "published" to the maven repository.
> I assume that requires an additional artifact (e.g. pom.xml)
> definition, right?
I set this up. IIUC the new project distro artifacts will be deployed
along with all the other artifacts when we run mvn deploy -Papache-
release, for instance when the release:perform goal does this.
As noted in another thread I think the changes we'd like in portals-
pom are piling up and we should get them all in and release portals-
pom 1.2 and the specs in one vote (or simultaneous votes). I'd move
the pluginManagement assembly plugin configuration to the parent.
>
>
>>>
>>>
>>> Anything I could be missing in the above plan?
>> - checking that pluto and jetspeed work with our spec jars
> Sure, we can (and should) do that, but I have no doubt it will as we
> didn't change a single bit within the code base itself.
> Its just a change of dependency IMO, nothing more.
I'd still like to see it working before voting :-)
>
> The area where we did make changes, the OSGi bundle configuration,
> won't affect Pluto or Jetspeed-2 as they don't use that information.
>
>> - checking that our osgi metadata is accurate enough to work.
> That I have to leave up to you and especially Carsten to validate. I
> know Carsten is using OSGi a lot, so I presume he should be able to
> quickly test this out.
> For the the usage of these spec jars within the Apache Portals
> projects, the dependency replacement is what matters to me the most
> for this initial release. If the OSGi bundle configuration turns out
> to need more tweaking in the future, a follow up release is easily
> done.
agreed.
thanks
david jencks
>
>
> Regards,
>
> Ate
>
>> thanks
>> david jencks
>>>
>>>
>>> Regards,
>>>
>>> Ate
>>>
>>> David Jencks wrote:
>>>> On May 11, 2009, at 11:20 AM, Carsten Ziegeler wrote:
>>>>> Ate Douma wrote:
>>>>>> David Jencks wrote:
>>>>>>>
>>>>>>> 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 ;)
>>>>>>
>>>>> I'm slowly recovering from switching to my new laptop :)
>>>>>
>>>>> Ok I think we don't need to use the maven bundle plugin as the
>>>>> manifest
>>>>> headers are constant in our case; but there is nothing wrong
>>>>> with using
>>>>> the plugin, so we can leave it as is. But in this case, I
>>>>> suggest to
>>>>> remove the import package statement and change the export
>>>>> statement to just:
>>>>> <Export-Package>javax.portlet.filter;version=2.0.0,
>>>>> javax.portlet;version=2.0.0
>>>>> </Export-Package>
>>>>> The plugin is doing the rest (adding the uses, creating the
>>>>> correct
>>>>> import etc.)
>>>>>
>>>> OK.... I had to include some info on imports in order to get the
>>>> servlet version to be 2.4, the sun api jar isn't a bundle with
>>>> package versions. I simplified the poms as much as I could...
>>>> many thanks
>>>> david jencks
>>>>>
>>>>> Carsten
>>>>> --
>>>>> Carsten Ziegeler
>>>>> cziegeler@apache.org
>>>
>
Re: Should or must Apache Portals create and maintain its own Portlet
API (JSR-168/286) spec implementation?
Posted by Ate Douma <at...@douma.nu>.
David Jencks wrote:
>
> On May 11, 2009, at 1:31 PM, Ate Douma wrote:
>
>> Hi,
>>
>> I cleaned up a few last minor things in the portlet_spec poms:
>> - some svn:ignore properties as needed for Eclipse IDE
>> - added provided servlet 2.3 dependency for portlet_spec 1.0
>
> It builds for me without this dependency so I don't think we should
> include it. Do you have some reason to think it's needed?
No, my mistake and I removed it again.
I also already responded on your earlier reply on the commit message.
>
>>
>> - fixed changed scm locations
>>
>> Then, I ran rat using the new portals-pom-1.1 prepare-release profile
>> (mvn install -P prepare-release) and hit two files without proper AL
>> header in the portlet_spec 2.0 project, used for and produced by the
>> maven-remote-resources-plugin:
>>
>> - src/main/appended-resources/META-INF/NOTICE.vm
>> - velocity.log
>>
>> As someone not familiar with the rat plugin, what is the best solution
>> to get these false positives ignored or resolved?
>>
>
> looks like you fixed this.
Yes, a little searching showed howto.
>>
>> Other than this last issue, and assuming the OSGi bundle info now is
>> generated correctly (relying on the assessment of both David and
>> Carsten for this), I think we're ready to go to release these
>> portlet_spec projects through Nexus by tomorrow morning.
>>
>> The release plan I have come up to be in alignment with the
>> (refreshed) ASF release requirements is the following:
>> 1) first do a Nexus release to a staged repository (this will create
>> the release tags for both projects)
>>
>> 2) do a manual checkout of the release tag src and build src dist
>> archives myself, sign them and upload to a public folder at
>> people.apache.org, like people.apache.org/~ate/portlet_spec/ [...]
>> or
>> for instance use the maven assembly plugin doing (all) the above
>> automatically???
>> I actually have never needed to use the assembly plugin yet so I'm
>> not sure what/how much it can do...
>> Maybe David or Carsten know more about it, but if I have to find out
>> myself, I might just resort back to doing it manual this time
>>
>> 3) send out a VOTE email concerning *both* the Nexus provided
>> artifacts from the temporary staged repository *and* the uploaded src
>> dist archives
>>
>> 4) .... process the VOTE results and (hopefully) have the release
>> completed.
>
> IMO this is too complicated to be workable.
Well, at least it should work as we already know now Nexus works fine, and the manual bit is just the same as how we've done it in the past.
> I think we should add the
> assembly plugin to each top level pom to build the source distro, and
> continue using the release plugin for the entire release process. IIUC
> this approach will get into the next apache pom with some additional
> automation. I'll see if I can come up with appropriate assembly plugin
> configuration.
Sure, if you find a way to further automate this, I'm all for it, as long as it works :)
What is unclear to me however, how/where this source distro is going to be "published" to the maven repository.
I assume that requires an additional artifact (e.g. pom.xml) definition, right?
>>
>>
>> Anything I could be missing in the above plan?
>
> - checking that pluto and jetspeed work with our spec jars
Sure, we can (and should) do that, but I have no doubt it will as we didn't change a single bit within the code base itself.
Its just a change of dependency IMO, nothing more.
The area where we did make changes, the OSGi bundle configuration, won't affect Pluto or Jetspeed-2 as they don't use that information.
> - checking that our osgi metadata is accurate enough to work.
That I have to leave up to you and especially Carsten to validate. I know Carsten is using OSGi a lot, so I presume he should be able to
quickly test this out.
For the the usage of these spec jars within the Apache Portals projects, the dependency replacement is what matters to me the most for this
initial release. If the OSGi bundle configuration turns out to need more tweaking in the future, a follow up release is easily done.
Regards,
Ate
>
> thanks
> david jencks
>
>>
>>
>> Regards,
>>
>> Ate
>>
>> David Jencks wrote:
>>> On May 11, 2009, at 11:20 AM, Carsten Ziegeler wrote:
>>>> Ate Douma wrote:
>>>>> David Jencks wrote:
>>>>>>
>>>>>> 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 ;)
>>>>>
>>>> I'm slowly recovering from switching to my new laptop :)
>>>>
>>>> Ok I think we don't need to use the maven bundle plugin as the manifest
>>>> headers are constant in our case; but there is nothing wrong with using
>>>> the plugin, so we can leave it as is. But in this case, I suggest to
>>>> remove the import package statement and change the export statement
>>>> to just:
>>>> <Export-Package>javax.portlet.filter;version=2.0.0,
>>>> javax.portlet;version=2.0.0
>>>> </Export-Package>
>>>> The plugin is doing the rest (adding the uses, creating the correct
>>>> import etc.)
>>>>
>>> OK.... I had to include some info on imports in order to get the
>>> servlet version to be 2.4, the sun api jar isn't a bundle with
>>> package versions. I simplified the poms as much as I could...
>>> many thanks
>>> david jencks
>>>>
>>>> Carsten
>>>> --
>>>> Carsten Ziegeler
>>>> cziegeler@apache.org
>>
>
Re: Should or must Apache Portals create and maintain its own Portlet API (JSR-168/286) spec implementation?
Posted by David Jencks <da...@yahoo.com>.
On May 11, 2009, at 1:31 PM, Ate Douma wrote:
> Hi,
>
> I cleaned up a few last minor things in the portlet_spec poms:
> - some svn:ignore properties as needed for Eclipse IDE
> - added provided servlet 2.3 dependency for portlet_spec 1.0
It builds for me without this dependency so I don't think we should
include it. Do you have some reason to think it's needed?
>
> - fixed changed scm locations
>
> Then, I ran rat using the new portals-pom-1.1 prepare-release
> profile (mvn install -P prepare-release) and hit two files without
> proper AL header in the portlet_spec 2.0 project, used for and
> produced by the maven-remote-resources-plugin:
>
> - src/main/appended-resources/META-INF/NOTICE.vm
> - velocity.log
>
> As someone not familiar with the rat plugin, what is the best
> solution to get these false positives ignored or resolved?
>
looks like you fixed this.
>
> Other than this last issue, and assuming the OSGi bundle info now is
> generated correctly (relying on the assessment of both David and
> Carsten for this), I think we're ready to go to release these
> portlet_spec projects through Nexus by tomorrow morning.
>
> The release plan I have come up to be in alignment with the
> (refreshed) ASF release requirements is the following:
> 1) first do a Nexus release to a staged repository (this will create
> the release tags for both projects)
>
> 2) do a manual checkout of the release tag src and build src dist
> archives myself, sign them and upload to a public folder at
> people.apache.org, like people.apache.org/~ate/portlet_spec/ [...]
> or
> for instance use the maven assembly plugin doing (all) the above
> automatically???
> I actually have never needed to use the assembly plugin yet so I'm
> not sure what/how much it can do...
> Maybe David or Carsten know more about it, but if I have to find
> out myself, I might just resort back to doing it manual this time
>
> 3) send out a VOTE email concerning *both* the Nexus provided
> artifacts from the temporary staged repository *and* the uploaded
> src dist archives
>
> 4) .... process the VOTE results and (hopefully) have the release
> completed.
IMO this is too complicated to be workable. I think we should add the
assembly plugin to each top level pom to build the source distro, and
continue using the release plugin for the entire release process.
IIUC this approach will get into the next apache pom with some
additional automation. I'll see if I can come up with appropriate
assembly plugin configuration.
>
>
> Anything I could be missing in the above plan?
- checking that pluto and jetspeed work with our spec jars
- checking that our osgi metadata is accurate enough to work.
thanks
david jencks
>
>
> Regards,
>
> Ate
>
> David Jencks wrote:
>> On May 11, 2009, at 11:20 AM, Carsten Ziegeler wrote:
>>> Ate Douma wrote:
>>>> David Jencks wrote:
>>>>>
>>>>> 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 ;)
>>>>
>>> I'm slowly recovering from switching to my new laptop :)
>>>
>>> Ok I think we don't need to use the maven bundle plugin as the
>>> manifest
>>> headers are constant in our case; but there is nothing wrong with
>>> using
>>> the plugin, so we can leave it as is. But in this case, I suggest to
>>> remove the import package statement and change the export
>>> statement to just:
>>> <Export-Package>javax.portlet.filter;version=2.0.0,
>>> javax.portlet;version=2.0.0
>>> </Export-Package>
>>> The plugin is doing the rest (adding the uses, creating the correct
>>> import etc.)
>>>
>> OK.... I had to include some info on imports in order to get the
>> servlet version to be 2.4, the sun api jar isn't a bundle with
>> package versions. I simplified the poms as much as I could...
>> many thanks
>> david jencks
>>>
>>> Carsten
>>> --
>>> Carsten Ziegeler
>>> cziegeler@apache.org
>
Re: Should or must Apache Portals create and maintain its own Portlet
API (JSR-168/286) spec implementation?
Posted by Ate Douma <at...@douma.nu>.
Hi,
I cleaned up a few last minor things in the portlet_spec poms:
- some svn:ignore properties as needed for Eclipse IDE
- added provided servlet 2.3 dependency for portlet_spec 1.0
- fixed changed scm locations
Then, I ran rat using the new portals-pom-1.1 prepare-release profile (mvn install -P prepare-release) and hit two files without proper AL
header in the portlet_spec 2.0 project, used for and produced by the maven-remote-resources-plugin:
- src/main/appended-resources/META-INF/NOTICE.vm
- velocity.log
As someone not familiar with the rat plugin, what is the best solution to get these false positives ignored or resolved?
Other than this last issue, and assuming the OSGi bundle info now is generated correctly (relying on the assessment of both David and
Carsten for this), I think we're ready to go to release these portlet_spec projects through Nexus by tomorrow morning.
The release plan I have come up to be in alignment with the (refreshed) ASF release requirements is the following:
1) first do a Nexus release to a staged repository (this will create the release tags for both projects)
2) do a manual checkout of the release tag src and build src dist archives myself, sign them and upload to a public folder at
people.apache.org, like people.apache.org/~ate/portlet_spec/ [...]
or
for instance use the maven assembly plugin doing (all) the above automatically???
I actually have never needed to use the assembly plugin yet so I'm not sure what/how much it can do...
Maybe David or Carsten know more about it, but if I have to find out myself, I might just resort back to doing it manual this time
3) send out a VOTE email concerning *both* the Nexus provided artifacts from the temporary staged repository *and* the uploaded src dist
archives
4) .... process the VOTE results and (hopefully) have the release completed.
Anything I could be missing in the above plan?
Regards,
Ate
David Jencks wrote:
>
> On May 11, 2009, at 11:20 AM, Carsten Ziegeler wrote:
>
>> Ate Douma wrote:
>>> David Jencks wrote:
>>>>
>>>> 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 ;)
>>>
>> I'm slowly recovering from switching to my new laptop :)
>>
>> Ok I think we don't need to use the maven bundle plugin as the manifest
>> headers are constant in our case; but there is nothing wrong with using
>> the plugin, so we can leave it as is. But in this case, I suggest to
>> remove the import package statement and change the export statement to
>> just:
>> <Export-Package>javax.portlet.filter;version=2.0.0,
>> javax.portlet;version=2.0.0
>> </Export-Package>
>> The plugin is doing the rest (adding the uses, creating the correct
>> import etc.)
>>
>
> OK.... I had to include some info on imports in order to get the servlet
> version to be 2.4, the sun api jar isn't a bundle with package
> versions. I simplified the poms as much as I could...
>
> many thanks
> david jencks
>
>>
>> Carsten
>> --
>> Carsten Ziegeler
>> cziegeler@apache.org
>
>
Re: Should or must Apache Portals create and maintain its own Portlet API (JSR-168/286) spec implementation?
Posted by David Jencks <da...@yahoo.com>.
On May 11, 2009, at 11:20 AM, Carsten Ziegeler wrote:
> Ate Douma wrote:
>> David Jencks wrote:
>>>
>>> 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 ;)
>>
> I'm slowly recovering from switching to my new laptop :)
>
> Ok I think we don't need to use the maven bundle plugin as the
> manifest
> headers are constant in our case; but there is nothing wrong with
> using
> the plugin, so we can leave it as is. But in this case, I suggest to
> remove the import package statement and change the export statement
> to just:
> <Export-Package>javax.portlet.filter;version=2.0.0,
> javax.portlet;version=2.0.0
> </Export-Package>
> The plugin is doing the rest (adding the uses, creating the correct
> import etc.)
>
OK.... I had to include some info on imports in order to get the
servlet version to be 2.4, the sun api jar isn't a bundle with package
versions. I simplified the poms as much as I could...
many thanks
david jencks
>
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: Should or must Apache Portals create and maintain its own Portlet
API (JSR-168/286) spec implementation?
Posted by Carsten Ziegeler <cz...@apache.org>.
Ate Douma wrote:
> David Jencks wrote:
>>
>> 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 ;)
>
I'm slowly recovering from switching to my new laptop :)
Ok I think we don't need to use the maven bundle plugin as the manifest
headers are constant in our case; but there is nothing wrong with using
the plugin, so we can leave it as is. But in this case, I suggest to
remove the import package statement and change the export statement to just:
<Export-Package>javax.portlet.filter;version=2.0.0,
javax.portlet;version=2.0.0
</Export-Package>
The plugin is doing the rest (adding the uses, creating the correct
import etc.)
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Should or must Apache Portals create and maintain its own Portlet API (JSR-168/286) spec implementation?
Posted by David Jencks <da...@yahoo.com>.
I'm not sure we'll hear back from felix soon so I went ahead and
configured the maven-bundle-plugin to produce what I think I want
directly. I also converted the package.html files to package-
info.java files and specified the java level at 1.4 in the portlet 1.0
pom.
Here are the manifests I'm seeing now:
portlet 1.0:
Manifest-Version: 1.0
Export-Package: javax.portlet;version="1.0.0"
Implementation-Title: Java Portlet Specification V1.0
Implementation-Version: 1.0.0-SNAPSHOT
Built-By: david
Tool: Bnd-0.0.311
Bundle-Name: Java Portlet Specification V1.0
Created-By: Apache Maven Bundle Plugin
Bundle-Vendor: Apache Software Foundation
Build-Jdk: 1.6.0_07
Bundle-Version: 1.0.0.SNAPSHOT
Bnd-LastModified: 1242059699283
Bundle-ManifestVersion: 2
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.html
Bundle-Description: The Java Portlet API version 1.0 developed by the
Java Community Process JSR-168 Expert Group.
Import-Package: javax.portlet;version="1.0.0"
Bundle-SymbolicName: org.apache.portals.portlet-api_1.0_spec
Bundle-DocURL: http://portals.apache.org/
portlet 2.0:
Manifest-Version: 1.0
Export-Package: javax.portlet.filter;uses:="javax.portlet,javax.xml.na
mespace,javax.servlet.http,org.w3c.dom";version="2.0.0",javax.portlet
;uses:="javax.xml.namespace,javax.servlet.http,org.w3c.dom";version="
2.0.0"
Implementation-Title: Java Portlet Specification V2.0
Implementation-Version: 1.0-SNAPSHOT
Built-By: david
Tool: Bnd-0.0.311
Bundle-Name: Java Portlet Specification V2.0
Created-By: Apache Maven Bundle Plugin
Bundle-Vendor: Apache Software Foundation
Build-Jdk: 1.6.0_07
Bundle-Version: 1.0.0.SNAPSHOT
Bnd-LastModified: 1242059353261
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="2.0.0",javax.portlet.filter;ver
sion="2.0.0",javax.servlet.http;version="2.4",javax.xml.namespace,org
.w3c.dom
Bundle-SymbolicName: org.apache.portals.portlet-api_2.0_spec
Bundle-DocURL: http://portals.apache.org/
I don't see anything wrong with these. I left the original manifest
insertion code in the 2.0 pom, commented out. If we agree to use the
maven-bundle-plugin it should be removed before release.
Does anyone have an osgi-enabled use of these spec jars to find out if
they actually work in osgi? I'd also prefer to see that pluto and
jetspeed actually build and work with these jars before releasing
them. Other than that I'm ok with their current state. If we hear
back from felix soon enough we can try changing the bundle plugin
configuration again.
thanks
david jencks
On May 10, 2009, at 3:59 PM, Ate Douma wrote:
> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
Re: Should or must Apache Portals create and maintain its own Portlet
API (JSR-168/286) spec implementation?
Posted by Ate Douma <at...@douma.nu>.
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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>
>
Re: Should or must Apache Portals create and maintain its own Portlet API (JSR-168/286) spec implementation?
Posted by David Jencks <da...@yahoo.com>.
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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
Re: Should or must Apache Portals create and maintain its own Portlet
API (JSR-168/286) spec implementation?
Posted by Ate Douma <at...@douma.nu>.
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
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>
>
Re: Should or must Apache Portals create and maintain its own Portlet API (JSR-168/286) spec implementation?
Posted by David Jencks <da...@yahoo.com>.
On May 10, 2009, at 4:15 PM, Ate Douma wrote:
> David Jencks wrote:
>> 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.
> Ugh, you're kidding me, right?
I don't recall anyone agreeing with him.
>
> Are you saying the code generated by jaxb from the xsd "inherit" the
> license from the xsd(s) itself?
> I used the jaxb compiler initially to generated skeleton code based
> on the xsd, but it turned out so crappy I rewrote at least 90% of it
> by hand... Only real "left-over" bits I kept are the generated
> javadoc headers in the sources as documentation.
> See for example:
> https://svn.eu.apache.org/repos/asf/portals/pluto/trunk/pluto-container/src/main/java/org/apache/pluto/container/om/portlet/impl/PortletAppType.java
>
>> 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.
> Jeez, how far does can this licensing madness go?
I have no idea :-)
>
>
> Does that mean if I simply delete the generated javadoc (based on
> those documentation annotations) from the code, we're fine just as
> well? If so, I'm happy to do so right up... although I think its
> kind of nuts.
I might be overreacting to my unreliable memories. Thinking back.....
I believe that when we typed up the ee schemas sun had not yet made
them available under cddl. I believe that the final consensus on
legal-discuss is that a few cddl schemas that are not expected to be
modified can be checked into apache svn and then we can generate code
from them that is apache licensed. So, your hand-modified jaxb code
would certainly be fine.
If we can find copies of the schemas that are clearly cddl licensed I
think it would be a good idea to get them into svn in an appropriate
location. At least for ee stuff it can be very handy for users to
include the schemas for reference.
thanks
david jencks
>
>
> Regards,
> Ate
>
>> thanks
>> david jencks
Re: Should or must Apache Portals create and maintain its own Portlet
API (JSR-168/286) spec implementation?
Posted by Ate Douma <at...@douma.nu>.
David Jencks wrote:
>
> 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.
Ugh, you're kidding me, right?
Are you saying the code generated by jaxb from the xsd "inherit" the license from the xsd(s) itself?
I used the jaxb compiler initially to generated skeleton code based on the xsd, but it turned out so crappy I rewrote at least 90% of it by
hand... Only real "left-over" bits I kept are the generated javadoc headers in the sources as documentation.
See for example:
https://svn.eu.apache.org/repos/asf/portals/pluto/trunk/pluto-container/src/main/java/org/apache/pluto/container/om/portlet/impl/PortletAppType.java
> 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.
Jeez, how far does can this licensing madness go?
Does that mean if I simply delete the generated javadoc (based on those documentation annotations) from the code, we're fine just as well?
If so, I'm happy to do so right up... although I think its kind of nuts.
Regards,
Ate
>
> thanks
> david jencks
>
Re: Should or must Apache Portals create and maintain its own Portlet API (JSR-168/286) spec implementation?
Posted by David Jencks <da...@yahoo.com>.
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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>
>
Re: Should or must Apache Portals create and maintain its own Portlet
API (JSR-168/286) spec implementation?
Posted by Ate Douma <at...@douma.nu>.
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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
>
Re: Should or must Apache Portals create and maintain its own Portlet API (JSR-168/286) spec implementation?
Posted by David Jencks <da...@yahoo.com>.
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
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>
Re: Should or must Apache Portals create and maintain its own Portlet API (JSR-168/286) spec implementation?
Posted by David Jencks <da...@yahoo.com>.
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
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>
>
Re: Should or must Apache Portals create and maintain its own Portlet
API (JSR-168/286) spec implementation?
Posted by Ate Douma <at...@douma.nu>.
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
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>
>
Re: Should or must Apache Portals create and maintain its own Portlet API (JSR-168/286) spec implementation?
Posted by David Jencks <da...@yahoo.com>.
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
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>
>
Re: Should or must Apache Portals create and maintain its own Portlet
API (JSR-168/286) spec implementation?
Posted by Ate Douma <at...@douma.nu>.
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
>>>>>
>>>>>
>>>
>>>
>>
>
>
Re: Should or must Apache Portals create and maintain its own Portlet API (JSR-168/286) spec implementation?
Posted by David Jencks <da...@yahoo.com>.
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
>>>>
>>>>
>>
>>
>
Re: Should or must Apache Portals create and maintain its own Portlet API (JSR-168/286) spec implementation?
Posted by David Jencks <da...@yahoo.com>.
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
>>>
>>>
>
>