You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Dave Fisher <da...@comcast.net> on 2012/08/21 00:05:42 UTC
Need to Revisit RAT Excludes and Wildcards
Hi Folks,
We are really getting ahead of ourselves.
We have a legitimate -1 IPMC vote on our release, it might get changed - Marvin asked for confirmation that the IPMC votes are based only on the official SOURCE release.
I looked again at the rat-excludes and we should look into a small handful of binary files that slip through. Most are "test" files and should be OK, but there are a small number that are not. If we have a plan to remove them and/or show that they are unused and harmless it may be that Marvin will be convinced to change his vote.
Someone should inspect these wildcards in the source tree
**/*.dbf
**/*.dbt
**/*.jar
**/*.zip
**/*.class
**/*.dll
**/*.exe
**/*.mdb
E.G.
$ find . -name "*.jar"
./avmedia/source/java/avmedia.jar
./qadevOOo/testdocs/qadevlibs/JobExecutor.jar
./qadevOOo/testdocs/qadevlibs/MyPersistObjectImpl.jar
./stax/download/README_stax-1.2.0.jar
./testautomation/global/input/xslt_stylesheets/docbook.jar
./testautomation/global/input/xslt_stylesheets/excel.jar
./testautomation/global/input/xslt_stylesheets/word.jar
./testautomation/global/input/xslt_stylesheets/xhtml.jar
./testgraphical/ui/java/ConvwatchGUIProject/dist/ConvwatchGUIProject.jar
./xmlsecurity/test_docs/tools/httpserv/dist/httpserv.jar
$ ls -lart ./avmedia/source/java
total 208
-rw-r--r--@ 1 dave staff 48 Nov 1 2011 manifest
-rw-r--r--@ 1 dave staff 15776 Nov 1 2011 avmedia.jar
drwxr-xr-x@ 10 dave staff 340 Nov 1 2011 ..
-rw-r--r--@ 1 dave staff 6553 Nov 7 2011 FrameGrabber.java
drwxr-xr-x@ 3 dave staff 102 Nov 7 2011 x11
-rw-r--r--@ 1 dave staff 21629 Nov 7 2011 WindowAdapter.java
-rw-r--r--@ 1 dave staff 20064 Nov 7 2011 PlayerWindow.java
-rw-r--r--@ 1 dave staff 2120 Nov 7 2011 MediaUno.java
drwxr-xr-x@ 3 dave staff 102 Nov 7 2011 win
-rw-r--r--@ 1 dave staff 9906 Nov 7 2011 Player.java
-rw-r--r--@ 1 dave staff 4367 Nov 7 2011 Manager.java
-rw-r--r--@ 1 dave staff 2132 Jan 19 2012 makefile.mk
-rw-r--r--@ 1 dave staff 1230 Jan 19 2012 avmedia.jar.component
drwxr-xr-x@ 14 dave staff 476 Jan 19 2012 .
$ jar tvf ./avmedia/source/java/avmedia.jar
104 Thu Jun 10 20:27:16 PDT 2010 META-INF/MANIFEST.MF
1277 Thu Jun 10 20:27:16 PDT 2010 MediaUno.class
4872 Thu Jun 10 20:27:16 PDT 2010 Player.class
8279 Thu Jun 10 20:27:16 PDT 2010 PlayerWindow.class
7738 Thu Jun 10 20:27:16 PDT 2010 WindowAdapter.class
0 Thu Jun 10 19:46:36 PDT 2010 avmedia/
0 Thu Jun 10 20:27:16 PDT 2010 avmedia/META-INF/
104 Thu Jun 10 20:27:16 PDT 2010 avmedia/META-INF/MANIFEST.MF
1418 Thu Jun 10 20:27:16 PDT 2010 SystemWindowAdapter.class
3883 Thu Jun 10 20:27:16 PDT 2010 FrameGrabber.class
2066 Thu Jun 10 20:27:16 PDT 2010 Manager.class
It looks like the jar file is unnecessary, but it may be in use.
Regards,
Dave
PS. Sure glad that we did as suggested by Pedro ;-)
Re: Need to Revisit RAT Excludes and Wildcards
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 21.08.2012 14:34, Oliver-Rainer Wittmann wrote:
> Hi,
>
> On 21.08.2012 00:05, Dave Fisher wrote:
>> Hi Folks,
>>
>> We are really getting ahead of ourselves.
>>
>> We have a legitimate -1 IPMC vote on our release, it might get changed -
>> Marvin asked for confirmation that the IPMC votes are based only on the
>> official SOURCE release.
>>
>> I looked again at the rat-excludes and we should look into a small handful of
>> binary files that slip through. Most are "test" files and should be OK, but
>> there are a small number that are not. If we have a plan to remove them and/or
>> show that they are unused and harmless it may be that Marvin will be convinced
>> to change his vote.
>>
>> Someone should inspect these wildcards in the source tree
>> **/*.dbf
>> **/*.dbt
>> **/*.jar
>> **/*.zip
>> **/*.class
>> **/*.dll
>> **/*.exe
>> **/*.mdb
>>
>
> I will have a look at the specific *.dll files which can be found in our source.
>
I have found the following *.dll files:
- group 1:
./main/external/dbghelp/README_dbghelp.dll
./main/external/gdiplus/README_gdiplus.dll
./main/external/mingwm10/README_mingwm10.dll
./main/external/msvcp70/README_msvcp70.dll
./main/external/msvcp71/README_msvcX71.dll
./main/external/msvcp80/README_msvcX80.dll
./main/external/msvcp90/README_msvcX90.dll
These are all text files with a "bad" file extension.
The content of these files more or less explain which DLL needs to be copied in
the given folder as a prerequisite for building AOO under Windows.
Proposed solution: rename these files
- group 2:
./main/testautomation/writer/optional/input/filter/lib/old/hwpreadermi.dll
./main/testautomation/writer/optional/input/filter/lib/old/jsreadermi.dll
./main/testautomation/writer/optional/input/filter/lib/wps2star.dll
These DLLs are part of the former testing framework. Investigation reveals that
these DLLs were checked into the repository together with some sample text
document files (*.sxw, OpenOffice.org XML file format). I did not find any
reference to these DLLs.
Proposed solution: remove these DLLs
- group 3:
./main/testtools/source/cliversioning/old_version_libs_v2/version_2_0_0.dll
./main/testtools/source/cliversioning/old_version_libs_v2/version_2_0_1.dll
./main/testtools/source/cliversioning/old_version_libs_v2/version_2_0_2.dll
./main/testtools/source/cliversioning/old_version_libs_v2/version_2_0_3.dll
./main/testtools/source/cliversioning/old_version_libs_v2/version_2_0_3r3.dll
./main/testtools/source/cliversioning/old_version_libs_v2/version_2_0_4.dll
./main/testtools/source/cliversioning/old_version_libs_v2/version_2_1.dll
./main/testtools/source/cliversioning/old_version_libs_v2/version_2_2.dll
./main/testtools/source/cliversioning/old_version_libs_v2/version_2_2_1.dll
./main/testtools/source/cliversioning/old_version_libs_v2/version_2_3.dll
./main/testtools/source/cliversioning/old_version_libs_v2/version_2_3_1.dll
./main/testtools/source/cliversioning/old_version_libs_v2/version_2_4.dll
./main/testtools/source/cliversioning/old_version_libs_v2/version_2_4_1.dll
./main/testtools/source/cliversioning/version_libs/version_3_0_0.dll
./main/testtools/source/cliversioning/version_libs/version_3_0_1.dll
./main/testtools/source/cliversioning/version_libs/version_3_1.dll
./main/testtools/source/cliversioning/version_libs/version_3_1_1.dll
./main/testtools/source/cliversioning/version_libs/version_3_2.dll
./main/testtools/source/cliversioning/version_libs/version_3_2_1.dll
./main/testtools/source/cliversioning/version_libs/version_3_3.dll
All these DLLs are build artefacts. The _X_X_X_ in the file name correspond to
the OOo version for which the DLL has been created. See readme file
./main/testtools/source/cliversioning/readme.txt.
I assume these former versions were kept in order to have the possibility to run
the corresponding test also on former OOo versions.
Proposed solution: remove these DLLs
- group 4:
./main/xmerge/source/activesync/BIN/xmergesync.dll
This is a build artefact which had been checked into the repository.
It looks like - I have searched the SVN log from OOo project [1] - that someone
was not able to get this DLL build in OOo's environment.
It looks like that this DLL is needed for tool regutil.exe which can be build in
./main/xmerge/source/regutil/. But as this is not part of our build.
Proposed solution: Remove completely the folders
./main/xmerge/source/activesync/ and ./main/xmerge/source/regutil/
I will go ahead and apply the proposed solution on trunk.
Please raise your objections - svn commits can be easily reverted.
Best regards, Oliver.
[1] http://svn.services.openoffice.org/ooo/
Re: Need to Revisit RAT Excludes and Wildcards
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 21.08.2012 00:05, Dave Fisher wrote:
> Hi Folks,
>
> We are really getting ahead of ourselves.
>
> We have a legitimate -1 IPMC vote on our release, it might get changed - Marvin asked for confirmation that the IPMC votes are based only on the official SOURCE release.
>
> I looked again at the rat-excludes and we should look into a small handful of binary files that slip through. Most are "test" files and should be OK, but there are a small number that are not. If we have a plan to remove them and/or show that they are unused and harmless it may be that Marvin will be convinced to change his vote.
>
> Someone should inspect these wildcards in the source tree
> **/*.dbf
> **/*.dbt
> **/*.jar
> **/*.zip
> **/*.class
> **/*.dll
> **/*.exe
> **/*.mdb
>
I will have a look at the specific *.dll files which can be found in our source.
Best regards, Oliver.
> E.G.
>
> $ find . -name "*.jar"
> ./avmedia/source/java/avmedia.jar
> ./qadevOOo/testdocs/qadevlibs/JobExecutor.jar
> ./qadevOOo/testdocs/qadevlibs/MyPersistObjectImpl.jar
> ./stax/download/README_stax-1.2.0.jar
> ./testautomation/global/input/xslt_stylesheets/docbook.jar
> ./testautomation/global/input/xslt_stylesheets/excel.jar
> ./testautomation/global/input/xslt_stylesheets/word.jar
> ./testautomation/global/input/xslt_stylesheets/xhtml.jar
> ./testgraphical/ui/java/ConvwatchGUIProject/dist/ConvwatchGUIProject.jar
> ./xmlsecurity/test_docs/tools/httpserv/dist/httpserv.jar
>
> $ ls -lart ./avmedia/source/java
> total 208
> -rw-r--r--@ 1 dave staff 48 Nov 1 2011 manifest
> -rw-r--r--@ 1 dave staff 15776 Nov 1 2011 avmedia.jar
> drwxr-xr-x@ 10 dave staff 340 Nov 1 2011 ..
> -rw-r--r--@ 1 dave staff 6553 Nov 7 2011 FrameGrabber.java
> drwxr-xr-x@ 3 dave staff 102 Nov 7 2011 x11
> -rw-r--r--@ 1 dave staff 21629 Nov 7 2011 WindowAdapter.java
> -rw-r--r--@ 1 dave staff 20064 Nov 7 2011 PlayerWindow.java
> -rw-r--r--@ 1 dave staff 2120 Nov 7 2011 MediaUno.java
> drwxr-xr-x@ 3 dave staff 102 Nov 7 2011 win
> -rw-r--r--@ 1 dave staff 9906 Nov 7 2011 Player.java
> -rw-r--r--@ 1 dave staff 4367 Nov 7 2011 Manager.java
> -rw-r--r--@ 1 dave staff 2132 Jan 19 2012 makefile.mk
> -rw-r--r--@ 1 dave staff 1230 Jan 19 2012 avmedia.jar.component
> drwxr-xr-x@ 14 dave staff 476 Jan 19 2012 .
>
> $ jar tvf ./avmedia/source/java/avmedia.jar
> 104 Thu Jun 10 20:27:16 PDT 2010 META-INF/MANIFEST.MF
> 1277 Thu Jun 10 20:27:16 PDT 2010 MediaUno.class
> 4872 Thu Jun 10 20:27:16 PDT 2010 Player.class
> 8279 Thu Jun 10 20:27:16 PDT 2010 PlayerWindow.class
> 7738 Thu Jun 10 20:27:16 PDT 2010 WindowAdapter.class
> 0 Thu Jun 10 19:46:36 PDT 2010 avmedia/
> 0 Thu Jun 10 20:27:16 PDT 2010 avmedia/META-INF/
> 104 Thu Jun 10 20:27:16 PDT 2010 avmedia/META-INF/MANIFEST.MF
> 1418 Thu Jun 10 20:27:16 PDT 2010 SystemWindowAdapter.class
> 3883 Thu Jun 10 20:27:16 PDT 2010 FrameGrabber.class
> 2066 Thu Jun 10 20:27:16 PDT 2010 Manager.class
>
> It looks like the jar file is unnecessary, but it may be in use.
>
> Regards,
> Dave
>
> PS. Sure glad that we did as suggested by Pedro ;-)
>
Re: Need to Revisit RAT Excludes and Wildcards
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 8/21/12 12:05 AM, Dave Fisher wrote:
> Hi Folks,
>
> We are really getting ahead of ourselves.
>
> We have a legitimate -1 IPMC vote on our release, it might get changed - Marvin asked for confirmation that the IPMC votes are based only on the official SOURCE release.
>
> I looked again at the rat-excludes and we should look into a small handful of binary files that slip through. Most are "test" files and should be OK, but there are a small number that are not. If we have a plan to remove them and/or show that they are unused and harmless it may be that Marvin will be convinced to change his vote.
>
> Someone should inspect these wildcards in the source tree
> **/*.dbf
> **/*.dbt
> **/*.jar
> **/*.zip
> **/*.class
> **/*.dll
> **/*.exe
> **/*.mdb
>
> E.G.
>
> $ find . -name "*.jar"
> ./avmedia/source/java/avmedia.jar
> ./qadevOOo/testdocs/qadevlibs/JobExecutor.jar
> ./qadevOOo/testdocs/qadevlibs/MyPersistObjectImpl.jar
> ./stax/download/README_stax-1.2.0.jar
> ./testautomation/global/input/xslt_stylesheets/docbook.jar
> ./testautomation/global/input/xslt_stylesheets/excel.jar
> ./testautomation/global/input/xslt_stylesheets/word.jar
> ./testautomation/global/input/xslt_stylesheets/xhtml.jar
> ./testgraphical/ui/java/ConvwatchGUIProject/dist/ConvwatchGUIProject.jar
> ./xmlsecurity/test_docs/tools/httpserv/dist/httpserv.jar
>
> $ ls -lart ./avmedia/source/java
> total 208
> -rw-r--r--@ 1 dave staff 48 Nov 1 2011 manifest
> -rw-r--r--@ 1 dave staff 15776 Nov 1 2011 avmedia.jar
> drwxr-xr-x@ 10 dave staff 340 Nov 1 2011 ..
> -rw-r--r--@ 1 dave staff 6553 Nov 7 2011 FrameGrabber.java
> drwxr-xr-x@ 3 dave staff 102 Nov 7 2011 x11
> -rw-r--r--@ 1 dave staff 21629 Nov 7 2011 WindowAdapter.java
> -rw-r--r--@ 1 dave staff 20064 Nov 7 2011 PlayerWindow.java
> -rw-r--r--@ 1 dave staff 2120 Nov 7 2011 MediaUno.java
> drwxr-xr-x@ 3 dave staff 102 Nov 7 2011 win
> -rw-r--r--@ 1 dave staff 9906 Nov 7 2011 Player.java
> -rw-r--r--@ 1 dave staff 4367 Nov 7 2011 Manager.java
> -rw-r--r--@ 1 dave staff 2132 Jan 19 2012 makefile.mk
> -rw-r--r--@ 1 dave staff 1230 Jan 19 2012 avmedia.jar.component
> drwxr-xr-x@ 14 dave staff 476 Jan 19 2012 .
>
> $ jar tvf ./avmedia/source/java/avmedia.jar
> 104 Thu Jun 10 20:27:16 PDT 2010 META-INF/MANIFEST.MF
> 1277 Thu Jun 10 20:27:16 PDT 2010 MediaUno.class
> 4872 Thu Jun 10 20:27:16 PDT 2010 Player.class
> 8279 Thu Jun 10 20:27:16 PDT 2010 PlayerWindow.class
> 7738 Thu Jun 10 20:27:16 PDT 2010 WindowAdapter.class
> 0 Thu Jun 10 19:46:36 PDT 2010 avmedia/
> 0 Thu Jun 10 20:27:16 PDT 2010 avmedia/META-INF/
> 104 Thu Jun 10 20:27:16 PDT 2010 avmedia/META-INF/MANIFEST.MF
> 1418 Thu Jun 10 20:27:16 PDT 2010 SystemWindowAdapter.class
> 3883 Thu Jun 10 20:27:16 PDT 2010 FrameGrabber.class
> 2066 Thu Jun 10 20:27:16 PDT 2010 Manager.class
>
> It looks like the jar file is unnecessary, but it may be in use.
I have already respond on general incubator to address
./xmlsecurity/test_docs/tools/httpserv/dist/httpserv.jar
./testgraphical/ui/java/ConvwatchGUIProject/dist/ConvwatchGUIProject.jar
both are the result of the checke din NetBeans projects and "dist"
folder was probably check in by mistake. And the second mistake is that
the "dist" folder is not moved in the global output directory on the module.
the same is probably true for avmedia but here it is no NetBeans project
I have proposed to address and fix it on trunk and don't prevent the
release for now.
>
> Regards,
> Dave
>
> PS. Sure glad that we did as suggested by Pedro ;-)
>
what exactly do you mean here, what has Pedro suggested? I don't see a
direct connection here. I only see a lot of controversial information
and different opinions flowing around that needs probably some general
and written down definition that makes it 100% clear for everybody.
And of course the currently found issues could have been addressed by
anybody if they were found earlier.
Juergen
Re: Need to Revisit RAT Excludes and Wildcards
Posted by Pedro Giffuni <pf...@apache.org>.
Hi Dave;
----- Original Message -----
...
>>
>> The particular concern of how the "official" packages are
>> generated and distributed is also interesting. At this time
>> I would say the FreeBSD port is as legitimate and
>> worthy of being tagged "Apache OpenOffice" as the Windows
>> packages in sourceforge.
>
> I have been thinking the same.
>
> I think that we need to carefully define what is an official Apache Release -
> SOURCE - and what is a project "sanctioned" binary artifact that can
> be called Apache OpenOffice in a way that Users will be able to trust what they
> receive.
>
> The build options and source code changes for each "sanctioned" binary
> artifact will need to be disclosed. At what point does a build of Apache
> OpenOffice require the name Foo Bar powered by Apache OpenOffice?
>
The concept of no binary release gives strength to the notion I have sustained
that a release is "what is tagged in SVN", and anything that comes out from it,
including LibreOffice, is an ApacheOO derivative.
Concerning binary branding:
If we compare the code generated by gcc42 or gcc46 or clang we will
find accidental differences that I don't think are worthy of forcing a branding
change. I would think that changes to the build system that don't affect the
source code are perfectly acceptable from a branding point of view.
If we take apart, for a moment, the compilation options and the specific compiler
used, we could say there is a one to one relationship between the source code
and the executable for a given platform and I would think it can be called
Apache OpenOffice.
What would define the need, or not, of the "powered by" prefix would be added
value: extra icons, more filters, etc. Of course other projects may choose not to
use the Apache name at all, and so far there have been no requests to use
Apache branding on such releases. For the time being I think we can leave
for later the definition of those hypothetical branding schemes.
>>>
>>> PS. Sure glad that we did as suggested by Pedro ;-)
>>>
>>
>> Yes, thanks for mentioning! I took a lot of heat for it at the time but
> finally it should
>> be clear it had to be done :).
>
> I was with you at the time. It can be easy to forget that some of the initial
> compromises are interim solutions that are contingent on further action. There
> is an important reason for the DISCLAIMER, and this is one.
>
Yes, Ross and you and some few others with more insight into the ASF
processes have been immensely helpful
Thanks!
Pedro.
Re: Need to Revisit RAT Excludes and Wildcards
Posted by Dave Fisher <da...@comcast.net>.
On Aug 20, 2012, at 6:42 PM, Pedro Giffuni wrote:
>
> ----- Original Message -----
> ...
>>
>> Hi Folks,
>>
>> We are really getting ahead of ourselves.
>>
>
> I think so too :(.
>
>> We have a legitimate -1 IPMC vote on our release, it might get changed - Marvin
>> asked for confirmation that the IPMC votes are based only on the official SOURCE
>> release.
>>
>
> Marvin's intervention is very far reaching indeed. It pretty much supports the position
> that there is no such thing as a binary release, and it involves some issues that have
> to be solved before graduation.
>
> For the podling, up till now, the source was only of secondary importance because
> end users (and QA) can't really evaluate the source code and instead are interested
> in the behaviour of the program (therefore the executables). As I see it, the issue of
> considering the source code alone is very valid for the IPMC. I think it is perfectly
> reasonable that this issue has come up at this time.
>
> The particular concern of how the "official" packages are generated and distributed
> is also interesting. At this time I would say the FreeBSD port is as legitimate and
> worthy of being tagged "Apache OpenOffice" as the Windows packages in
> sourceforge.
I have been thinking the same.
I think that we need to carefully define what is an official Apache Release - SOURCE - and what is a project "sanctioned" binary artifact that can be called Apache OpenOffice in a way that Users will be able to trust what they receive.
The build options and source code changes for each "sanctioned" binary artifact will need to be disclosed. At what point does a build of Apache OpenOffice require the name Foo Bar powered by Apache OpenOffice?
>>
>> PS. Sure glad that we did as suggested by Pedro ;-)
>>
>
> Yes, thanks for mentioning! I took a lot of heat for it at the time but finally it should
> be clear it had to be done :).
I was with you at the time. It can be easy to forget that some of the initial compromises are interim solutions that are contingent on further action. There is an important reason for the DISCLAIMER, and this is one.
Regards,
Dave
>
> Pedro.
Re: Need to Revisit RAT Excludes and Wildcards
Posted by Rob Weir <ro...@apache.org>.
On Mon, Aug 20, 2012 at 10:51 PM, Pedro Giffuni <pf...@apache.org> wrote:
>
> ----- Original Message -----
>
>>>
>>> Marvin's intervention is very far reaching indeed. It pretty much
>> supports the position
>>> that there is no such thing as a binary release, and it involves some
>> issues that have
>>> to be solved before graduation.
>>>
>>
>> Now I think you are getting ahead of yourself. I've shown that the
>> IPMC has repeatedly voted on releases that included binaries, and has
>> done this recently and without dissent. Three of the most recent 7
>> podlings to have graduated included binaries in their releases.
>>
>
> I am aware of your position that you know better than the IPMC what they
> voted for and I will let you discuss your issues with the IPMC members. Do
> let us know who wins :).
>
I'm not assuming that the IPMC has a consensus view on the topic.
We're clearly bringing into focus a long-standing, unresolved issue
that transcends AOO. It should probably be escalated to the ASF
Board, since there should probably not be a fundamental disconnect
between the policy for what TLP's may release versus what Podlings may
release. Presumably common sense will arrive at this conclusion
before too many more electrons are wasted.
> Please note that I don't mean we should stop the graduation process:
> a process involves steps and this has to be defined as part of such
> process.
>
I think they are linked, at least in the mind of some IPMC members.
Of course, we can still prepare our graduation resolution, etc., and
get it ready. Nothing is holding us back on that.
-Rob
> Pedro.
Re: Need to Revisit RAT Excludes and Wildcards
Posted by Pedro Giffuni <pf...@apache.org>.
----- Original Message -----
>>
>> Marvin's intervention is very far reaching indeed. It pretty much
> supports the position
>> that there is no such thing as a binary release, and it involves some
> issues that have
>> to be solved before graduation.
>>
>
> Now I think you are getting ahead of yourself. I've shown that the
> IPMC has repeatedly voted on releases that included binaries, and has
> done this recently and without dissent. Three of the most recent 7
> podlings to have graduated included binaries in their releases.
>
I am aware of your position that you know better than the IPMC what they
voted for and I will let you discuss your issues with the IPMC members. Do
let us know who wins :).
Please note that I don't mean we should stop the graduation process:
a process involves steps and this has to be defined as part of such
process.
Pedro.
Re: Need to Revisit RAT Excludes and Wildcards
Posted by Rob Weir <ro...@apache.org>.
On Mon, Aug 20, 2012 at 9:42 PM, Pedro Giffuni <pf...@apache.org> wrote:
>
> ----- Original Message -----
> ...
>>
>> Hi Folks,
>>
>> We are really getting ahead of ourselves.
>>
>
> I think so too :(.
>
>> We have a legitimate -1 IPMC vote on our release, it might get changed - Marvin
>> asked for confirmation that the IPMC votes are based only on the official SOURCE
>> release.
>>
>
> Marvin's intervention is very far reaching indeed. It pretty much supports the position
> that there is no such thing as a binary release, and it involves some issues that have
> to be solved before graduation.
>
Now I think you are getting ahead of yourself. I've shown that the
IPMC has repeatedly voted on releases that included binaries, and has
done this recently and without dissent. Three of the most recent 7
podlings to have graduated included binaries in their releases.
> For the podling, up till now, the source was only of secondary importance because
> end users (and QA) can't really evaluate the source code and instead are interested
> in the behaviour of the program (therefore the executables). As I see it, the issue of
> considering the source code alone is very valid for the IPMC. I think it is perfectly
> reasonable that this issue has come up at this time.
>
It would have been even more fine if the concern came up in the
previous podling releases, from this project, or from any of the many
other that included bbinaries ;-)
> The particular concern of how the "official" packages are generated and distributed
> is also interesting. At this time I would say the FreeBSD port is as legitimate and
> worthy of being tagged "Apache OpenOffice" as the Windows packages in
> sourceforge.
>
That doesn't logically follow.
Regards,
-Rob
>>
>> PS. Sure glad that we did as suggested by Pedro ;-)
>>
>
> Yes, thanks for mentioning! I took a lot of heat for it at the time but finally it should
> be clear it had to be done :).
>
> Pedro.
Re: Need to Revisit RAT Excludes and Wildcards
Posted by Pedro Giffuni <pf...@apache.org>.
----- Original Message -----
...
>
> Hi Folks,
>
> We are really getting ahead of ourselves.
>
I think so too :(.
> We have a legitimate -1 IPMC vote on our release, it might get changed - Marvin
> asked for confirmation that the IPMC votes are based only on the official SOURCE
> release.
>
Marvin's intervention is very far reaching indeed. It pretty much supports the position
that there is no such thing as a binary release, and it involves some issues that have
to be solved before graduation.
For the podling, up till now, the source was only of secondary importance because
end users (and QA) can't really evaluate the source code and instead are interested
in the behaviour of the program (therefore the executables). As I see it, the issue of
considering the source code alone is very valid for the IPMC. I think it is perfectly
reasonable that this issue has come up at this time.
The particular concern of how the "official" packages are generated and distributed
is also interesting. At this time I would say the FreeBSD port is as legitimate and
worthy of being tagged "Apache OpenOffice" as the Windows packages in
sourceforge.
>
> PS. Sure glad that we did as suggested by Pedro ;-)
>
Yes, thanks for mentioning! I took a lot of heat for it at the time but finally it should
be clear it had to be done :).
Pedro.
Re: Need to Revisit RAT Excludes and Wildcards
Posted by Andre Fischer <aw...@gmail.com>.
On 21.08.2012 00:05, Dave Fisher wrote:
> Hi Folks,
>
> We are really getting ahead of ourselves.
>
> We have a legitimate -1 IPMC vote on our release, it might get changed - Marvin asked for confirmation that the IPMC votes are based only on the official SOURCE release.
>
> I looked again at the rat-excludes and we should look into a small handful of binary files that slip through. Most are "test" files and should be OK, but there are a small number that are not. If we have a plan to remove them and/or show that they are unused and harmless it may be that Marvin will be convinced to change his vote.
>
> Someone should inspect these wildcards in the source tree
> **/*.dbf
> **/*.dbt
> **/*.jar
> **/*.zip
> **/*.class
> **/*.dll
> **/*.exe
> **/*.mdb
>
> E.G.
>
> $ find . -name "*.jar"
> ./avmedia/source/java/avmedia.jar
> ./qadevOOo/testdocs/qadevlibs/JobExecutor.jar
> ./qadevOOo/testdocs/qadevlibs/MyPersistObjectImpl.jar
> ./stax/download/README_stax-1.2.0.jar
> ./testautomation/global/input/xslt_stylesheets/docbook.jar
> ./testautomation/global/input/xslt_stylesheets/excel.jar
> ./testautomation/global/input/xslt_stylesheets/word.jar
> ./testautomation/global/input/xslt_stylesheets/xhtml.jar
> ./testgraphical/ui/java/ConvwatchGUIProject/dist/ConvwatchGUIProject.jar
> ./xmlsecurity/test_docs/tools/httpserv/dist/httpserv.jar
FYI: I have created issues 120634 [1] and 120635 [2] to address the jar
files in testgraphical/ and xmlsecurity/ respectively. Are there
volunteers for the other jars?
I created issue 120637 [3] for including the rat scan into the build
process. With that we (a) don't have to rely on the build bots to run
the rat scans and (b) can easily run rat scans for any branch,
especially that of the release.
-Andre
[1] https://issues.apache.org/ooo/show_bug.cgi?id=120634
[2] https://issues.apache.org/ooo/show_bug.cgi?id=120635
[3] https://issues.apache.org/ooo/show_bug.cgi?id=120637
>
> $ ls -lart ./avmedia/source/java
> total 208
> -rw-r--r--@ 1 dave staff 48 Nov 1 2011 manifest
> -rw-r--r--@ 1 dave staff 15776 Nov 1 2011 avmedia.jar
> drwxr-xr-x@ 10 dave staff 340 Nov 1 2011 ..
> -rw-r--r--@ 1 dave staff 6553 Nov 7 2011 FrameGrabber.java
> drwxr-xr-x@ 3 dave staff 102 Nov 7 2011 x11
> -rw-r--r--@ 1 dave staff 21629 Nov 7 2011 WindowAdapter.java
> -rw-r--r--@ 1 dave staff 20064 Nov 7 2011 PlayerWindow.java
> -rw-r--r--@ 1 dave staff 2120 Nov 7 2011 MediaUno.java
> drwxr-xr-x@ 3 dave staff 102 Nov 7 2011 win
> -rw-r--r--@ 1 dave staff 9906 Nov 7 2011 Player.java
> -rw-r--r--@ 1 dave staff 4367 Nov 7 2011 Manager.java
> -rw-r--r--@ 1 dave staff 2132 Jan 19 2012 makefile.mk
> -rw-r--r--@ 1 dave staff 1230 Jan 19 2012 avmedia.jar.component
> drwxr-xr-x@ 14 dave staff 476 Jan 19 2012 .
>
> $ jar tvf ./avmedia/source/java/avmedia.jar
> 104 Thu Jun 10 20:27:16 PDT 2010 META-INF/MANIFEST.MF
> 1277 Thu Jun 10 20:27:16 PDT 2010 MediaUno.class
> 4872 Thu Jun 10 20:27:16 PDT 2010 Player.class
> 8279 Thu Jun 10 20:27:16 PDT 2010 PlayerWindow.class
> 7738 Thu Jun 10 20:27:16 PDT 2010 WindowAdapter.class
> 0 Thu Jun 10 19:46:36 PDT 2010 avmedia/
> 0 Thu Jun 10 20:27:16 PDT 2010 avmedia/META-INF/
> 104 Thu Jun 10 20:27:16 PDT 2010 avmedia/META-INF/MANIFEST.MF
> 1418 Thu Jun 10 20:27:16 PDT 2010 SystemWindowAdapter.class
> 3883 Thu Jun 10 20:27:16 PDT 2010 FrameGrabber.class
> 2066 Thu Jun 10 20:27:16 PDT 2010 Manager.class
>
> It looks like the jar file is unnecessary, but it may be in use.
>
> Regards,
> Dave
>
> PS. Sure glad that we did as suggested by Pedro ;-)
>
Re: Need to Revisit RAT Excludes and Wildcards
Posted by Rob Weir <ro...@apache.org>.
On Mon, Aug 20, 2012 at 9:09 PM, Pedro Giffuni <pf...@apache.org> wrote:
> Hi;
>
>
> ----- Original Message -----
> ...
>>
>> Ditto. This is our code, the source is there, with Apache headers.
>> The pre-built JAR at worst is redundant. I don't see a policy issue
>> here.
>>
>>> ./stax/download/README_stax-1.2.0.jar
>>
>> Need to ask Pedro about that one:
>> http://svnsearch.org/svnsearch/repos/ASF/search?revision=1243337&showPaths=all&
>>
>
> This is actually a text file. We can just rename it to a .txt extension to
> avoid confusions.
>
Of course. Why not give text files a .jar extension? It keeps prying
eyes away, Thanks for the smile. I needed that.
-Rob
> Pedro.
Re: Need to Revisit RAT Excludes and Wildcards
Posted by Pedro Giffuni <pf...@apache.org>.
Hi;
----- Original Message -----
...
>
> Ditto. This is our code, the source is there, with Apache headers.
> The pre-built JAR at worst is redundant. I don't see a policy issue
> here.
>
>> ./stax/download/README_stax-1.2.0.jar
>
> Need to ask Pedro about that one:
> http://svnsearch.org/svnsearch/repos/ASF/search?revision=1243337&showPaths=all&
>
This is actually a text file. We can just rename it to a .txt extension to
avoid confusions.
Pedro.
Re: Need to Revisit RAT Excludes and Wildcards
Posted by Rob Weir <ro...@apache.org>.
On Mon, Aug 20, 2012 at 6:05 PM, Dave Fisher <da...@comcast.net> wrote:
> Hi Folks,
>
> We are really getting ahead of ourselves.
>
Not really. It is not like issues like this are going to be found by
sitting here and not pushing the code our further. Every new class of
testers will find a new class of bugs. This was true with AOO 3.4.0,
where things that were missed by us and the IPMC were found after we
released. For example, that we were missing a notice for the CoinMP
libraries. So getting there release in front of the IPMC is a great
next step. Getting further and having even more eyeballs on it is
even better .
> We have a legitimate -1 IPMC vote on our release, it might get changed - Marvin asked for confirmation that the IPMC votes are based only on the official SOURCE release.
>
> I looked again at the rat-excludes and we should look into a small handful of binary files that slip through. Most are "test" files and should be OK, but there are a small number that are not. If we have a plan to remove them and/or show that they are unused and harmless it may be that Marvin will be convinced to change his vote.
>
> Someone should inspect these wildcards in the source tree
I don't see how this related to the concerns Marvin raised. It sounds
like he is concerned with releasing binaries in general, not with
anything specific in the source tree. I didn't see any technical
detail in his -1, or proposed changes that would satisfy his concerns.
In any case, let's look at what you found
> **/*.dbf
> **/*.dbt
> **/*.jar
> **/*.zip
> **/*.class
> **/*.dll
> **/*.exe
> **/*.mdb
>
> E.G.
>
> $ find . -name "*.jar"
> ./avmedia/source/java/avmedia.jar
This is our code, the source is there, with Apache headers. The
pre-built JAR at worst is redundant. I don't see a policy issue here.
> ./qadevOOo/testdocs/qadevlibs/JobExecutor.jar
> ./qadevOOo/testdocs/qadevlibs/MyPersistObjectImpl.jar
Ditto. This is our code, the source is there, with Apache headers.
The pre-built JAR at worst is redundant. I don't see a policy issue
here.
> ./stax/download/README_stax-1.2.0.jar
Need to ask Pedro about that one:
http://svnsearch.org/svnsearch/repos/ASF/search?revision=1243337&showPaths=all&
> ./testautomation/global/input/xslt_stylesheets/docbook.jar
> ./testautomation/global/input/xslt_stylesheets/excel.jar
> ./testautomation/global/input/xslt_stylesheets/word.jar
> ./testautomation/global/input/xslt_stylesheets/xhtml.jar
Appears to be JAR'ed prebuilt versions of XSLT scripts that are mainly
stored in /main/filter/source/xslt/export/worldml, and related
directories.
Again, redundant, but I don't see a policy issue here.
> ./testgraphical/ui/java/ConvwatchGUIProject/dist/ConvwatchGUIProject.jar
No idea. But it is test code, not needed for building.
> ./xmlsecurity/test_docs/tools/httpserv/dist/httpserv.jar
Not needed for building. It is part of a test setup for testing
Certification Revocation Lists.
So for the last two we should verify license. If the license allows
redistribution, then I think we're fine. If not, then we need to
build a new src ZIP without them.
-Rob
>
> $ ls -lart ./avmedia/source/java
> total 208
> -rw-r--r--@ 1 dave staff 48 Nov 1 2011 manifest
> -rw-r--r--@ 1 dave staff 15776 Nov 1 2011 avmedia.jar
> drwxr-xr-x@ 10 dave staff 340 Nov 1 2011 ..
> -rw-r--r--@ 1 dave staff 6553 Nov 7 2011 FrameGrabber.java
> drwxr-xr-x@ 3 dave staff 102 Nov 7 2011 x11
> -rw-r--r--@ 1 dave staff 21629 Nov 7 2011 WindowAdapter.java
> -rw-r--r--@ 1 dave staff 20064 Nov 7 2011 PlayerWindow.java
> -rw-r--r--@ 1 dave staff 2120 Nov 7 2011 MediaUno.java
> drwxr-xr-x@ 3 dave staff 102 Nov 7 2011 win
> -rw-r--r--@ 1 dave staff 9906 Nov 7 2011 Player.java
> -rw-r--r--@ 1 dave staff 4367 Nov 7 2011 Manager.java
> -rw-r--r--@ 1 dave staff 2132 Jan 19 2012 makefile.mk
> -rw-r--r--@ 1 dave staff 1230 Jan 19 2012 avmedia.jar.component
> drwxr-xr-x@ 14 dave staff 476 Jan 19 2012 .
>
> $ jar tvf ./avmedia/source/java/avmedia.jar
> 104 Thu Jun 10 20:27:16 PDT 2010 META-INF/MANIFEST.MF
> 1277 Thu Jun 10 20:27:16 PDT 2010 MediaUno.class
> 4872 Thu Jun 10 20:27:16 PDT 2010 Player.class
> 8279 Thu Jun 10 20:27:16 PDT 2010 PlayerWindow.class
> 7738 Thu Jun 10 20:27:16 PDT 2010 WindowAdapter.class
> 0 Thu Jun 10 19:46:36 PDT 2010 avmedia/
> 0 Thu Jun 10 20:27:16 PDT 2010 avmedia/META-INF/
> 104 Thu Jun 10 20:27:16 PDT 2010 avmedia/META-INF/MANIFEST.MF
> 1418 Thu Jun 10 20:27:16 PDT 2010 SystemWindowAdapter.class
> 3883 Thu Jun 10 20:27:16 PDT 2010 FrameGrabber.class
> 2066 Thu Jun 10 20:27:16 PDT 2010 Manager.class
>
> It looks like the jar file is unnecessary, but it may be in use.
>
> Regards,
> Dave
>
> PS. Sure glad that we did as suggested by Pedro ;-)
>
Re: Need to Revisit RAT Excludes and Wildcards
Posted by Kay Schenk <ka...@gmail.com>.
On Mon, Aug 20, 2012 at 3:05 PM, Dave Fisher <da...@comcast.net> wrote:
> Hi Folks,
>
> We are really getting ahead of ourselves.
>
> We have a legitimate -1 IPMC vote on our release, it might get changed -
> Marvin asked for confirmation that the IPMC votes are based only on the
> official SOURCE release.
>
> I looked again at the rat-excludes and we should look into a small handful
> of binary files that slip through. Most are "test" files and should be OK,
> but there are a small number that are not. If we have a plan to remove them
> and/or show that they are unused and harmless it may be that Marvin will be
> convinced to change his vote.
>
> Someone should inspect these wildcards in the source tree
> **/*.dbf
> **/*.dbt
> **/*.jar
> **/*.zip
> **/*.class
> **/*.dll
> **/*.exe
> **/*.mdb
>
> E.G.
>
> $ find . -name "*.jar"
> ./avmedia/source/java/avmedia.jar
> ./qadevOOo/testdocs/qadevlibs/JobExecutor.jar
> ./qadevOOo/testdocs/qadevlibs/MyPersistObjectImpl.jar
> ./stax/download/README_stax-1.2.0.jar
> ./testautomation/global/input/xslt_stylesheets/docbook.jar
> ./testautomation/global/input/xslt_stylesheets/excel.jar
> ./testautomation/global/input/xslt_stylesheets/word.jar
> ./testautomation/global/input/xslt_stylesheets/xhtml.jar
> ./testgraphical/ui/java/ConvwatchGUIProject/dist/ConvwatchGUIProject.jar
> ./xmlsecurity/test_docs/tools/httpserv/dist/httpserv.jar
>
> $ ls -lart ./avmedia/source/java
> total 208
> -rw-r--r--@ 1 dave staff 48 Nov 1 2011 manifest
> -rw-r--r--@ 1 dave staff 15776 Nov 1 2011 avmedia.jar
> drwxr-xr-x@ 10 dave staff 340 Nov 1 2011 ..
> -rw-r--r--@ 1 dave staff 6553 Nov 7 2011 FrameGrabber.java
> drwxr-xr-x@ 3 dave staff 102 Nov 7 2011 x11
> -rw-r--r--@ 1 dave staff 21629 Nov 7 2011 WindowAdapter.java
> -rw-r--r--@ 1 dave staff 20064 Nov 7 2011 PlayerWindow.java
> -rw-r--r--@ 1 dave staff 2120 Nov 7 2011 MediaUno.java
> drwxr-xr-x@ 3 dave staff 102 Nov 7 2011 win
> -rw-r--r--@ 1 dave staff 9906 Nov 7 2011 Player.java
> -rw-r--r--@ 1 dave staff 4367 Nov 7 2011 Manager.java
> -rw-r--r--@ 1 dave staff 2132 Jan 19 2012 makefile.mk
> -rw-r--r--@ 1 dave staff 1230 Jan 19 2012 avmedia.jar.component
> drwxr-xr-x@ 14 dave staff 476 Jan 19 2012 .
>
> $ jar tvf ./avmedia/source/java/avmedia.jar
> 104 Thu Jun 10 20:27:16 PDT 2010 META-INF/MANIFEST.MF
> 1277 Thu Jun 10 20:27:16 PDT 2010 MediaUno.class
> 4872 Thu Jun 10 20:27:16 PDT 2010 Player.class
> 8279 Thu Jun 10 20:27:16 PDT 2010 PlayerWindow.class
> 7738 Thu Jun 10 20:27:16 PDT 2010 WindowAdapter.class
> 0 Thu Jun 10 19:46:36 PDT 2010 avmedia/
> 0 Thu Jun 10 20:27:16 PDT 2010 avmedia/META-INF/
> 104 Thu Jun 10 20:27:16 PDT 2010 avmedia/META-INF/MANIFEST.MF
> 1418 Thu Jun 10 20:27:16 PDT 2010 SystemWindowAdapter.class
> 3883 Thu Jun 10 20:27:16 PDT 2010 FrameGrabber.class
> 2066 Thu Jun 10 20:27:16 PDT 2010 Manager.class
>
> It looks like the jar file is unnecessary, but it may be in use.
>
> Regards,
> Dave
>
> PS. Sure glad that we did as suggested by Pedro ;-)
>
>
yes...I was looking at the vote process and did some investigating also,
and was just about to ask about this.
For example, I'm not sure why the "test..." area is included in the main
trunk. It seems some of these cases/files should be handled by build
options (off trunk) specifically for testing only. Some of he others ????
--
----------------------------------------------------------------------------------------
MzK
"Never express yourself more clearly than you are able to think."
--
Niels Bohr
Re: Need to Revisit RAT Excludes and Wildcards
Posted by Kay Schenk <ka...@gmail.com>.
On Wed, Aug 22, 2012 at 6:10 AM, Oliver-Rainer Wittmann <
orwittmann@googlemail.com> wrote:
> Hi,
>
>
> On 22.08.2012 11:29, Oliver-Rainer Wittmann wrote:
>
>> Hi,
>>
>> On 21.08.2012 00:05, Dave Fisher wrote:
>>
>>> Hi Folks,
>>>
>>> We are really getting ahead of ourselves.
>>>
>>> We have a legitimate -1 IPMC vote on our release, it might get changed -
>>> Marvin asked for confirmation that the IPMC votes are based only on the
>>> official SOURCE release.
>>>
>>> I looked again at the rat-excludes and we should look into a small
>>> handful of
>>> binary files that slip through. Most are "test" files and should be OK,
>>> but
>>> there are a small number that are not. If we have a plan to remove them
>>> and/or
>>> show that they are unused and harmless it may be that Marvin will be
>>> convinced
>>> to change his vote.
>>>
>>> Someone should inspect these wildcards in the source tree
>>> **/*.dbf
>>> **/*.dbt
>>> **/*.jar
>>> **/*.zip
>>> **/*.class
>>> **/*.dll
>>> **/*.exe
>>> **/*.mdb
>>>
>>>
>> Now, I will have a look at the specific *.zip files which can be found in
>> our
>> source.
>>
>>
> I have found the following ZIP files:
> - group 1:
> ./main/icc/makefiles.zip
> This ZIP file contains certain makefiles for the purpose to build the
> source code of ICC with our build system. These makefiles were part of
> Oracle's SGA and their license header had been already adapted accordingly
> by Andrew Rist.
> Proposed solution: exclude this ZIP explicitly from the RAT scan (full
> path named in the rat-excludes file) together with the above documentation
> of the IP review.
>
> - group 2:
> ./main/scripting/workben/data/**share_scripts.zip
> ./main/scripting/workben/data/**user_scripts.zip
> These ZIP files contain some more or less empty .java, .class, .xml and
> .class files. I did not find any references to these files. The ZIP files
> were checked into the repository with the comment "Add some jsuite tests
> for the Scripting Framework". Thus, I assume that they are only for testing
> purposes.
> ./main/scripting/workben/ is also not part of our build. I tried to build
> it, but the build failed.
> Proposed solution: remove these ZIP files. (May be the complete folder
> ./main/scripting/workben/ can be removed.)
>
> - group 3:
> ./main/sd/res/buttons/glas-**blue.zip
> ./main/sd/res/buttons/glas-**green.zip
> ./main/sd/res/buttons/glas-**red.zip
> ./main/sd/res/buttons/round-**gorilla.zip
> ./main/sd/res/buttons/round-**white.zip
> ./main/sd/res/buttons/simple.**zip
> ./main/sd/res/buttons/square-**blue.zip
> ./main/sd/res/buttons/square-**gray.zip
> ./main/sd/res/buttons/square-**green.zip
> ./main/sd/res/buttons/square-**red.zip
> ./main/sd/res/buttons/square-**yellow.zip
> Each of these ZIP files contain a set of 12 PNG images. The differences
> between the images of one ZIP file to another ZIP file are in color and/or
> shape - as the names of the ZIP files indicate. These images are used when
> exporting a presentation document to HTML as navigation buttons in the
> created HTML. The user can choose one of the sets. These ZIP files are part
> of Oracle's SGA.
> Proposed solution: exclude these ZIP files explicitly from the RAT scan
> (full paths named in the rat-excludes file) and put a license file into
> ./main/sd/res/buttons/ to provide corresponding license information for the
> PNG images inside the ZIP files.
>
>
> Best regards, Oliver.
>
Great work Oliver! Really! Since I'm not a direct coder for the project, I
was really wondering about these files used by "test", and if they couldn't
be moved somewhere and brought in as needed, build flags or some other
way. Anyway, good job and I think this will serve us very well in the
future.
--
----------------------------------------------------------------------------------------
MzK
"As a child my family's menu consisted of two choices:
take it or leave it. "
-- Buddy Hackett
Re: Need to Revisit RAT Excludes and Wildcards
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 22.08.2012 11:29, Oliver-Rainer Wittmann wrote:
> Hi,
>
> On 21.08.2012 00:05, Dave Fisher wrote:
>> Hi Folks,
>>
>> We are really getting ahead of ourselves.
>>
>> We have a legitimate -1 IPMC vote on our release, it might get changed -
>> Marvin asked for confirmation that the IPMC votes are based only on the
>> official SOURCE release.
>>
>> I looked again at the rat-excludes and we should look into a small handful of
>> binary files that slip through. Most are "test" files and should be OK, but
>> there are a small number that are not. If we have a plan to remove them and/or
>> show that they are unused and harmless it may be that Marvin will be convinced
>> to change his vote.
>>
>> Someone should inspect these wildcards in the source tree
>> **/*.dbf
>> **/*.dbt
>> **/*.jar
>> **/*.zip
>> **/*.class
>> **/*.dll
>> **/*.exe
>> **/*.mdb
>>
>
> Now, I will have a look at the specific *.zip files which can be found in our
> source.
>
I have found the following ZIP files:
- group 1:
./main/icc/makefiles.zip
This ZIP file contains certain makefiles for the purpose to build the source
code of ICC with our build system. These makefiles were part of Oracle's SGA and
their license header had been already adapted accordingly by Andrew Rist.
Proposed solution: exclude this ZIP explicitly from the RAT scan (full path
named in the rat-excludes file) together with the above documentation of the IP
review.
- group 2:
./main/scripting/workben/data/share_scripts.zip
./main/scripting/workben/data/user_scripts.zip
These ZIP files contain some more or less empty .java, .class, .xml and .class
files. I did not find any references to these files. The ZIP files were checked
into the repository with the comment "Add some jsuite tests for the Scripting
Framework". Thus, I assume that they are only for testing purposes.
./main/scripting/workben/ is also not part of our build. I tried to build it,
but the build failed.
Proposed solution: remove these ZIP files. (May be the complete folder
./main/scripting/workben/ can be removed.)
- group 3:
./main/sd/res/buttons/glas-blue.zip
./main/sd/res/buttons/glas-green.zip
./main/sd/res/buttons/glas-red.zip
./main/sd/res/buttons/round-gorilla.zip
./main/sd/res/buttons/round-white.zip
./main/sd/res/buttons/simple.zip
./main/sd/res/buttons/square-blue.zip
./main/sd/res/buttons/square-gray.zip
./main/sd/res/buttons/square-green.zip
./main/sd/res/buttons/square-red.zip
./main/sd/res/buttons/square-yellow.zip
Each of these ZIP files contain a set of 12 PNG images. The differences between
the images of one ZIP file to another ZIP file are in color and/or shape - as
the names of the ZIP files indicate. These images are used when exporting a
presentation document to HTML as navigation buttons in the created HTML. The
user can choose one of the sets. These ZIP files are part of Oracle's SGA.
Proposed solution: exclude these ZIP files explicitly from the RAT scan (full
paths named in the rat-excludes file) and put a license file into
./main/sd/res/buttons/ to provide corresponding license information for the PNG
images inside the ZIP files.
Best regards, Oliver.
Re: Need to Revisit RAT Excludes and Wildcards
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 21.08.2012 00:05, Dave Fisher wrote:
> Hi Folks,
>
> We are really getting ahead of ourselves.
>
> We have a legitimate -1 IPMC vote on our release, it might get changed - Marvin asked for confirmation that the IPMC votes are based only on the official SOURCE release.
>
> I looked again at the rat-excludes and we should look into a small handful of binary files that slip through. Most are "test" files and should be OK, but there are a small number that are not. If we have a plan to remove them and/or show that they are unused and harmless it may be that Marvin will be convinced to change his vote.
>
> Someone should inspect these wildcards in the source tree
> **/*.dbf
> **/*.dbt
> **/*.jar
> **/*.zip
> **/*.class
> **/*.dll
> **/*.exe
> **/*.mdb
>
Now, I will have a look at the specific *.zip files which can be found in our
source.
Best regards, Oliver.
> E.G.
>
> $ find . -name "*.jar"
> ./avmedia/source/java/avmedia.jar
> ./qadevOOo/testdocs/qadevlibs/JobExecutor.jar
> ./qadevOOo/testdocs/qadevlibs/MyPersistObjectImpl.jar
> ./stax/download/README_stax-1.2.0.jar
> ./testautomation/global/input/xslt_stylesheets/docbook.jar
> ./testautomation/global/input/xslt_stylesheets/excel.jar
> ./testautomation/global/input/xslt_stylesheets/word.jar
> ./testautomation/global/input/xslt_stylesheets/xhtml.jar
> ./testgraphical/ui/java/ConvwatchGUIProject/dist/ConvwatchGUIProject.jar
> ./xmlsecurity/test_docs/tools/httpserv/dist/httpserv.jar
>
> $ ls -lart ./avmedia/source/java
> total 208
> -rw-r--r--@ 1 dave staff 48 Nov 1 2011 manifest
> -rw-r--r--@ 1 dave staff 15776 Nov 1 2011 avmedia.jar
> drwxr-xr-x@ 10 dave staff 340 Nov 1 2011 ..
> -rw-r--r--@ 1 dave staff 6553 Nov 7 2011 FrameGrabber.java
> drwxr-xr-x@ 3 dave staff 102 Nov 7 2011 x11
> -rw-r--r--@ 1 dave staff 21629 Nov 7 2011 WindowAdapter.java
> -rw-r--r--@ 1 dave staff 20064 Nov 7 2011 PlayerWindow.java
> -rw-r--r--@ 1 dave staff 2120 Nov 7 2011 MediaUno.java
> drwxr-xr-x@ 3 dave staff 102 Nov 7 2011 win
> -rw-r--r--@ 1 dave staff 9906 Nov 7 2011 Player.java
> -rw-r--r--@ 1 dave staff 4367 Nov 7 2011 Manager.java
> -rw-r--r--@ 1 dave staff 2132 Jan 19 2012 makefile.mk
> -rw-r--r--@ 1 dave staff 1230 Jan 19 2012 avmedia.jar.component
> drwxr-xr-x@ 14 dave staff 476 Jan 19 2012 .
>
> $ jar tvf ./avmedia/source/java/avmedia.jar
> 104 Thu Jun 10 20:27:16 PDT 2010 META-INF/MANIFEST.MF
> 1277 Thu Jun 10 20:27:16 PDT 2010 MediaUno.class
> 4872 Thu Jun 10 20:27:16 PDT 2010 Player.class
> 8279 Thu Jun 10 20:27:16 PDT 2010 PlayerWindow.class
> 7738 Thu Jun 10 20:27:16 PDT 2010 WindowAdapter.class
> 0 Thu Jun 10 19:46:36 PDT 2010 avmedia/
> 0 Thu Jun 10 20:27:16 PDT 2010 avmedia/META-INF/
> 104 Thu Jun 10 20:27:16 PDT 2010 avmedia/META-INF/MANIFEST.MF
> 1418 Thu Jun 10 20:27:16 PDT 2010 SystemWindowAdapter.class
> 3883 Thu Jun 10 20:27:16 PDT 2010 FrameGrabber.class
> 2066 Thu Jun 10 20:27:16 PDT 2010 Manager.class
>
> It looks like the jar file is unnecessary, but it may be in use.
>
> Regards,
> Dave
>
> PS. Sure glad that we did as suggested by Pedro ;-)
>
Re: Need to Revisit RAT Excludes and Wildcards
Posted by Andrew Rist <an...@oracle.com>.
On 8/22/2012 5:43 PM, Rob Weir wrote:
> On Mon, Aug 20, 2012 at 6:05 PM, Dave Fisher <da...@comcast.net> wrote:
>> Hi Folks,
>>
>> We are really getting ahead of ourselves.
>>
>> We have a legitimate -1 IPMC vote on our release, it might get changed - Marvin asked for confirmation that the IPMC votes are based only on the official SOURCE release.
>>
>> I looked again at the rat-excludes and we should look into a small handful of binary files that slip through. Most are "test" files and should be OK, but there are a small number that are not. If we have a plan to remove them and/or show that they are unused and harmless it may be that Marvin will be convinced to change his vote.
>>
>> Someone should inspect these wildcards in the source tree
>> **/*.dbf
>> **/*.dbt
>> **/*.jar
>> **/*.zip
>> **/*.class
>> **/*.dll
>> **/*.exe
>> **/*.mdb
>>
> A quick general observation:
>
> Wildcard exclusions are dangerous. They may be useful but they are
> dangerous. Does RAT have a mode where we can dump a list of all
> excluded files? Not just the patterns, but the files?
Well, you can remove the wild cards. Then all the files are listed in
the report.
Not making any judgements or decisions, I'll describe how the RAT
exclusions were generated.
I started out with excludes for almost every type of file, except for
*.c *.h *.cpp *.hpp *.java
Then as the relicensing of the files went ahead, this list of excludes
was slowly whittled down.
RAT doesn't handle binary files, so those excludes were kept to quiet
down the scan.
This clean-up is looking really good, and arriving at a point where
there are no wild cards and
explanations for each excluded file would be the best outcome. One way
to do that would be
to remove the remaining wildcards, and then work through cleaning up the
report.
A.
>
> If so, that might be a good thing to enable, just so we're aware when
> reviewing the report, to make sure that more is not excluded than we
> intended.
>
> If this isn't an option in RAT, maybe this is a patch we can send them?
>
> -Rob
<snip>
Re: Need to Revisit RAT Excludes and Wildcards
Posted by Andre Fischer <aw...@gmail.com>.
On 23.08.2012 02:43, Rob Weir wrote:
> On Mon, Aug 20, 2012 at 6:05 PM, Dave Fisher <da...@comcast.net> wrote:
>> Hi Folks,
>>
>> We are really getting ahead of ourselves.
>>
>> We have a legitimate -1 IPMC vote on our release, it might get changed - Marvin asked for confirmation that the IPMC votes are based only on the official SOURCE release.
>>
>> I looked again at the rat-excludes and we should look into a small handful of binary files that slip through. Most are "test" files and should be OK, but there are a small number that are not. If we have a plan to remove them and/or show that they are unused and harmless it may be that Marvin will be convinced to change his vote.
>>
>> Someone should inspect these wildcards in the source tree
>> **/*.dbf
>> **/*.dbt
>> **/*.jar
>> **/*.zip
>> **/*.class
>> **/*.dll
>> **/*.exe
>> **/*.mdb
>>
>
> A quick general observation:
>
> Wildcard exclusions are dangerous. They may be useful but they are
> dangerous. Does RAT have a mode where we can dump a list of all
> excluded files? Not just the patterns, but the files?
While Rat has functionality for excluding files, we are using Ant to
exclude the files. main/rat-excludes is fed directly to Ant to do that.
I am currently integrating the rat scan into our build. Adding a target
to produce the negative list of files that are excluded should be simple.
>
> If so, that might be a good thing to enable, just so we're aware when
> reviewing the report, to make sure that more is not excluded than we
> intended.
>
> If this isn't an option in RAT, maybe this is a patch we can send them?
I have already contacted the Rat team (no pun intended) for another
matter: marking binary files as binary, not for excluding them from the
scan, but for excluding their content to be included in the report.
With that we can identify binary files that where accidentally checked
in much easier. Excluding binary files from the scan with wildcards
just to keep the report readable will then not be necessary anymore.
-Andre
>
> -Rob
>
>> E.G.
>>
>> $ find . -name "*.jar"
>> ./avmedia/source/java/avmedia.jar
>> ./qadevOOo/testdocs/qadevlibs/JobExecutor.jar
>> ./qadevOOo/testdocs/qadevlibs/MyPersistObjectImpl.jar
>> ./stax/download/README_stax-1.2.0.jar
>> ./testautomation/global/input/xslt_stylesheets/docbook.jar
>> ./testautomation/global/input/xslt_stylesheets/excel.jar
>> ./testautomation/global/input/xslt_stylesheets/word.jar
>> ./testautomation/global/input/xslt_stylesheets/xhtml.jar
>> ./testgraphical/ui/java/ConvwatchGUIProject/dist/ConvwatchGUIProject.jar
>> ./xmlsecurity/test_docs/tools/httpserv/dist/httpserv.jar
>>
>> $ ls -lart ./avmedia/source/java
>> total 208
>> -rw-r--r--@ 1 dave staff 48 Nov 1 2011 manifest
>> -rw-r--r--@ 1 dave staff 15776 Nov 1 2011 avmedia.jar
>> drwxr-xr-x@ 10 dave staff 340 Nov 1 2011 ..
>> -rw-r--r--@ 1 dave staff 6553 Nov 7 2011 FrameGrabber.java
>> drwxr-xr-x@ 3 dave staff 102 Nov 7 2011 x11
>> -rw-r--r--@ 1 dave staff 21629 Nov 7 2011 WindowAdapter.java
>> -rw-r--r--@ 1 dave staff 20064 Nov 7 2011 PlayerWindow.java
>> -rw-r--r--@ 1 dave staff 2120 Nov 7 2011 MediaUno.java
>> drwxr-xr-x@ 3 dave staff 102 Nov 7 2011 win
>> -rw-r--r--@ 1 dave staff 9906 Nov 7 2011 Player.java
>> -rw-r--r--@ 1 dave staff 4367 Nov 7 2011 Manager.java
>> -rw-r--r--@ 1 dave staff 2132 Jan 19 2012 makefile.mk
>> -rw-r--r--@ 1 dave staff 1230 Jan 19 2012 avmedia.jar.component
>> drwxr-xr-x@ 14 dave staff 476 Jan 19 2012 .
>>
>> $ jar tvf ./avmedia/source/java/avmedia.jar
>> 104 Thu Jun 10 20:27:16 PDT 2010 META-INF/MANIFEST.MF
>> 1277 Thu Jun 10 20:27:16 PDT 2010 MediaUno.class
>> 4872 Thu Jun 10 20:27:16 PDT 2010 Player.class
>> 8279 Thu Jun 10 20:27:16 PDT 2010 PlayerWindow.class
>> 7738 Thu Jun 10 20:27:16 PDT 2010 WindowAdapter.class
>> 0 Thu Jun 10 19:46:36 PDT 2010 avmedia/
>> 0 Thu Jun 10 20:27:16 PDT 2010 avmedia/META-INF/
>> 104 Thu Jun 10 20:27:16 PDT 2010 avmedia/META-INF/MANIFEST.MF
>> 1418 Thu Jun 10 20:27:16 PDT 2010 SystemWindowAdapter.class
>> 3883 Thu Jun 10 20:27:16 PDT 2010 FrameGrabber.class
>> 2066 Thu Jun 10 20:27:16 PDT 2010 Manager.class
>>
>> It looks like the jar file is unnecessary, but it may be in use.
>>
>> Regards,
>> Dave
>>
>> PS. Sure glad that we did as suggested by Pedro ;-)
>>
Re: Need to Revisit RAT Excludes and Wildcards
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 8/23/12 2:43 AM, Rob Weir wrote:
> On Mon, Aug 20, 2012 at 6:05 PM, Dave Fisher <da...@comcast.net> wrote:
>> Hi Folks,
>>
>> We are really getting ahead of ourselves.
>>
>> We have a legitimate -1 IPMC vote on our release, it might get changed - Marvin asked for confirmation that the IPMC votes are based only on the official SOURCE release.
>>
>> I looked again at the rat-excludes and we should look into a small handful of binary files that slip through. Most are "test" files and should be OK, but there are a small number that are not. If we have a plan to remove them and/or show that they are unused and harmless it may be that Marvin will be convinced to change his vote.
>>
>> Someone should inspect these wildcards in the source tree
>> **/*.dbf
>> **/*.dbt
>> **/*.jar
>> **/*.zip
>> **/*.class
>> **/*.dll
>> **/*.exe
>> **/*.mdb
>>
>
> A quick general observation:
>
> Wildcard exclusions are dangerous. They may be useful but they are
> dangerous. Does RAT have a mode where we can dump a list of all
> excluded files? Not just the patterns, but the files?
>
> If so, that might be a good thing to enable, just so we're aware when
> reviewing the report, to make sure that more is not excluded than we
> intended.
>
> If this isn't an option in RAT, maybe this is a patch we can send them?
it should be easy because the exclude list is used in a fileset target
in an ant script. WE can easy create a revert file list and can dump it.
Andre prepared a new configure switch to enable a RAT scan in the build
process. We can enhance the ant script that is triggering the RAT scan.
Juergen
>
> -Rob
>
>> E.G.
>>
>> $ find . -name "*.jar"
>> ./avmedia/source/java/avmedia.jar
>> ./qadevOOo/testdocs/qadevlibs/JobExecutor.jar
>> ./qadevOOo/testdocs/qadevlibs/MyPersistObjectImpl.jar
>> ./stax/download/README_stax-1.2.0.jar
>> ./testautomation/global/input/xslt_stylesheets/docbook.jar
>> ./testautomation/global/input/xslt_stylesheets/excel.jar
>> ./testautomation/global/input/xslt_stylesheets/word.jar
>> ./testautomation/global/input/xslt_stylesheets/xhtml.jar
>> ./testgraphical/ui/java/ConvwatchGUIProject/dist/ConvwatchGUIProject.jar
>> ./xmlsecurity/test_docs/tools/httpserv/dist/httpserv.jar
>>
>> $ ls -lart ./avmedia/source/java
>> total 208
>> -rw-r--r--@ 1 dave staff 48 Nov 1 2011 manifest
>> -rw-r--r--@ 1 dave staff 15776 Nov 1 2011 avmedia.jar
>> drwxr-xr-x@ 10 dave staff 340 Nov 1 2011 ..
>> -rw-r--r--@ 1 dave staff 6553 Nov 7 2011 FrameGrabber.java
>> drwxr-xr-x@ 3 dave staff 102 Nov 7 2011 x11
>> -rw-r--r--@ 1 dave staff 21629 Nov 7 2011 WindowAdapter.java
>> -rw-r--r--@ 1 dave staff 20064 Nov 7 2011 PlayerWindow.java
>> -rw-r--r--@ 1 dave staff 2120 Nov 7 2011 MediaUno.java
>> drwxr-xr-x@ 3 dave staff 102 Nov 7 2011 win
>> -rw-r--r--@ 1 dave staff 9906 Nov 7 2011 Player.java
>> -rw-r--r--@ 1 dave staff 4367 Nov 7 2011 Manager.java
>> -rw-r--r--@ 1 dave staff 2132 Jan 19 2012 makefile.mk
>> -rw-r--r--@ 1 dave staff 1230 Jan 19 2012 avmedia.jar.component
>> drwxr-xr-x@ 14 dave staff 476 Jan 19 2012 .
>>
>> $ jar tvf ./avmedia/source/java/avmedia.jar
>> 104 Thu Jun 10 20:27:16 PDT 2010 META-INF/MANIFEST.MF
>> 1277 Thu Jun 10 20:27:16 PDT 2010 MediaUno.class
>> 4872 Thu Jun 10 20:27:16 PDT 2010 Player.class
>> 8279 Thu Jun 10 20:27:16 PDT 2010 PlayerWindow.class
>> 7738 Thu Jun 10 20:27:16 PDT 2010 WindowAdapter.class
>> 0 Thu Jun 10 19:46:36 PDT 2010 avmedia/
>> 0 Thu Jun 10 20:27:16 PDT 2010 avmedia/META-INF/
>> 104 Thu Jun 10 20:27:16 PDT 2010 avmedia/META-INF/MANIFEST.MF
>> 1418 Thu Jun 10 20:27:16 PDT 2010 SystemWindowAdapter.class
>> 3883 Thu Jun 10 20:27:16 PDT 2010 FrameGrabber.class
>> 2066 Thu Jun 10 20:27:16 PDT 2010 Manager.class
>>
>> It looks like the jar file is unnecessary, but it may be in use.
>>
>> Regards,
>> Dave
>>
>> PS. Sure glad that we did as suggested by Pedro ;-)
>>
Re: Need to Revisit RAT Excludes and Wildcards
Posted by Rob Weir <ro...@apache.org>.
On Mon, Aug 20, 2012 at 6:05 PM, Dave Fisher <da...@comcast.net> wrote:
> Hi Folks,
>
> We are really getting ahead of ourselves.
>
> We have a legitimate -1 IPMC vote on our release, it might get changed - Marvin asked for confirmation that the IPMC votes are based only on the official SOURCE release.
>
> I looked again at the rat-excludes and we should look into a small handful of binary files that slip through. Most are "test" files and should be OK, but there are a small number that are not. If we have a plan to remove them and/or show that they are unused and harmless it may be that Marvin will be convinced to change his vote.
>
> Someone should inspect these wildcards in the source tree
> **/*.dbf
> **/*.dbt
> **/*.jar
> **/*.zip
> **/*.class
> **/*.dll
> **/*.exe
> **/*.mdb
>
A quick general observation:
Wildcard exclusions are dangerous. They may be useful but they are
dangerous. Does RAT have a mode where we can dump a list of all
excluded files? Not just the patterns, but the files?
If so, that might be a good thing to enable, just so we're aware when
reviewing the report, to make sure that more is not excluded than we
intended.
If this isn't an option in RAT, maybe this is a patch we can send them?
-Rob
> E.G.
>
> $ find . -name "*.jar"
> ./avmedia/source/java/avmedia.jar
> ./qadevOOo/testdocs/qadevlibs/JobExecutor.jar
> ./qadevOOo/testdocs/qadevlibs/MyPersistObjectImpl.jar
> ./stax/download/README_stax-1.2.0.jar
> ./testautomation/global/input/xslt_stylesheets/docbook.jar
> ./testautomation/global/input/xslt_stylesheets/excel.jar
> ./testautomation/global/input/xslt_stylesheets/word.jar
> ./testautomation/global/input/xslt_stylesheets/xhtml.jar
> ./testgraphical/ui/java/ConvwatchGUIProject/dist/ConvwatchGUIProject.jar
> ./xmlsecurity/test_docs/tools/httpserv/dist/httpserv.jar
>
> $ ls -lart ./avmedia/source/java
> total 208
> -rw-r--r--@ 1 dave staff 48 Nov 1 2011 manifest
> -rw-r--r--@ 1 dave staff 15776 Nov 1 2011 avmedia.jar
> drwxr-xr-x@ 10 dave staff 340 Nov 1 2011 ..
> -rw-r--r--@ 1 dave staff 6553 Nov 7 2011 FrameGrabber.java
> drwxr-xr-x@ 3 dave staff 102 Nov 7 2011 x11
> -rw-r--r--@ 1 dave staff 21629 Nov 7 2011 WindowAdapter.java
> -rw-r--r--@ 1 dave staff 20064 Nov 7 2011 PlayerWindow.java
> -rw-r--r--@ 1 dave staff 2120 Nov 7 2011 MediaUno.java
> drwxr-xr-x@ 3 dave staff 102 Nov 7 2011 win
> -rw-r--r--@ 1 dave staff 9906 Nov 7 2011 Player.java
> -rw-r--r--@ 1 dave staff 4367 Nov 7 2011 Manager.java
> -rw-r--r--@ 1 dave staff 2132 Jan 19 2012 makefile.mk
> -rw-r--r--@ 1 dave staff 1230 Jan 19 2012 avmedia.jar.component
> drwxr-xr-x@ 14 dave staff 476 Jan 19 2012 .
>
> $ jar tvf ./avmedia/source/java/avmedia.jar
> 104 Thu Jun 10 20:27:16 PDT 2010 META-INF/MANIFEST.MF
> 1277 Thu Jun 10 20:27:16 PDT 2010 MediaUno.class
> 4872 Thu Jun 10 20:27:16 PDT 2010 Player.class
> 8279 Thu Jun 10 20:27:16 PDT 2010 PlayerWindow.class
> 7738 Thu Jun 10 20:27:16 PDT 2010 WindowAdapter.class
> 0 Thu Jun 10 19:46:36 PDT 2010 avmedia/
> 0 Thu Jun 10 20:27:16 PDT 2010 avmedia/META-INF/
> 104 Thu Jun 10 20:27:16 PDT 2010 avmedia/META-INF/MANIFEST.MF
> 1418 Thu Jun 10 20:27:16 PDT 2010 SystemWindowAdapter.class
> 3883 Thu Jun 10 20:27:16 PDT 2010 FrameGrabber.class
> 2066 Thu Jun 10 20:27:16 PDT 2010 Manager.class
>
> It looks like the jar file is unnecessary, but it may be in use.
>
> Regards,
> Dave
>
> PS. Sure glad that we did as suggested by Pedro ;-)
>