Re: Need to Revisit RAT Excludes and Wildcards
On Mon, Aug 20, 2012 at 3:05 PM, 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 staff340 Nov 1 2011 .. > -rw-r--r--@ 1 dave staff 6553 Nov 7 2011 FrameGrabber.java > drwxr-xr-x@ 3 dave staff102 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 staff102 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 staff476 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
On Mon, Aug 20, 2012 at 6:05 PM, Dave Fisher 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 staff340 Nov 1 2011 .. > -rw-r--r--@ 1 dave staff 6553 Nov 7 2011 FrameGrabber.java > drwxr-xr-x@ 3 dave staff102 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 staff102 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 staff476 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
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
On Mon, Aug 20, 2012 at 9:09 PM, Pedro Giffuni 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
- 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
On Mon, Aug 20, 2012 at 9: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. > 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
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
- 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
On Mon, Aug 20, 2012 at 10:51 PM, Pedro Giffuni 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
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
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 staff340 Nov 1 2011 .. -rw-r--r--@ 1 dave staff 6553 Nov 7 2011 FrameGrabber.java drwxr-xr-x@ 3 dave staff102 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 staff102 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 staff476 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
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 staff340 Nov 1 2011 .. > -rw-r--r--@ 1 dave staff 6553 Nov 7 2011 FrameGrabber.java > drwxr-xr-x@ 3 dave staff102 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 staff102 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 staff476 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
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 staff340 Nov 1 2011 .. -rw-r--r--@ 1 dave staff 6553 Nov 7 2011 FrameGrabber.java drwxr-xr-x@ 3 dave staff102 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 staff102 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 staff476 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
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
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 staff340 Nov 1 2011 .. -rw-r--r--@ 1 dave staff 6553 Nov 7 2011 FrameGrabber.java drwxr-xr-x@ 3 dave staff102 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 staff102 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 staff476 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
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
On Wed, Aug 22, 2012 at 6:10 AM, Oliver-Rainer Wittmann < orwittm...@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
On Mon, Aug 20, 2012 at 6:05 PM, 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 > 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 staff340 Nov 1 2011 .. > -rw-r--r--@ 1 dave staff 6553 Nov 7 2011 FrameGrabber.java > drwxr-xr-x@ 3 dave staff102 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 staff102 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 staff476 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
On 8/23/12 2:43 AM, Rob Weir wrote: > On Mon, Aug 20, 2012 at 6:05 PM, 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 >> > > 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 staff340 Nov 1 2011 .. >> -rw-r--r--@ 1 dave staff 6553 Nov 7 2011 FrameGrabber.java >> drwxr-xr-x@ 3 dave staff102 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 staff102 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 staff476 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
On 23.08.2012 02:43, Rob Weir wrote: On Mon, Aug 20, 2012 at 6:05 PM, 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 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 staff340 Nov 1 2011 .. -rw-r--r--@ 1 dave staff 6553 Nov 7 2011 FrameGrabber.java drwxr-xr-x@ 3 dave staff102 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 staff102 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 staff476 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
On 8/22/2012 5:43 PM, Rob Weir wrote: On Mon, Aug 20, 2012 at 6:05 PM, 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 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