Luc Maisonobe a écrit : > Siegfried Goeschl a écrit : >> Hi folks, >> >> the following changes were made regarding the feedback from the previous >> vote >> >> 1) using "org.apache.commons"/"commons-exec" as groupId/artifactId >> 2) using SVN tag "EXEC_1_0_0" instead of "EXEC_1_0_0_RC3" (Rahul Alkolkar) >> 3) fixed folder name in the source distribution (Oliver Heger, Jörg >> Schaible) >> 4) fixed STATUS regarding deprecation of System.getEnv (Jörg Schaible) >> 5) added a section to FAQ regarding setting the executable bits for the >> test scripts (Jörg Schaible) >> 6) removed the "*.asc.md5" and "*.asc.sha1" from the uploaded files >> (Sebastian Bazley) >> 7) removed JUnit XML output formatter to pass the regression tests on >> JDK 1.3 (Sebastian Bazley) >> 8) added my PGP keys to SVN and http://www.apache.org/dist/commons/KEYS >> (Sebastian Bazley) >> >> So it is time to call a vote on commons-exec-1.0.0 again ... > > I've run findbugs, it shows the following issues: > > DefaultExecutor (line 203) > setExitValues(int[]) may expose internal representation by storing an > externally mutable object into DefaultExecutor.exitValues > > DefaultProcessingEnvironment (lines 169 and 171) > Hard coded reference to an absolute pathname > > DefaultProcessingEnvironment (line 108) and > OpenVmsProcessingEnvironment (line 89) > concatenates strings using + in a loop > > OpenVmsProcessingEnvironment (line 114) and > MapUtils (line 72) > inefficient use of keySet iterator instead of entrySet iterator > > The first issue should probably be fixed by cloning the array, but does > not appear to be an important problem. The second issue is a false > positive (if findbugs were activated by default in the pom, this could > be prevented by a configured exclusion file). The remaining issues are > harmless.
I've created a Jira issue (https://issues.apache.org/jira/browse/EXEC-35) and provided patches for these. > > The Javadoc for the OS class still refers to ant, this should be > replaced by a more generic name like "the application". The javadoc is > missing for many methods in the Executor interface, even some non > obvious ones like setExitValues (who should call it ? what do the > various entries of the array mean ?). This interface seems to be a > central point of the component and will be the first one read by users, > so it should be thoroughly documented. Looking at the source in order to provide another patch for this one, I noticed the documentation for methods was there but does start like regular comment-block not javadoc, there is only one '*' missing on all methods. The global interface documentation is still missing though. So fixing this should be easy. I did not check if other classes have the same ill-formed javadoc. Luc > > In summary, to me the findbugs issues are not blocking elements, but the > javadoc for the Executor interface bothers me. I'm -0 on this release. > > Luc > >> Tag: >> >> https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0_0 >> >> Site: >> >> http://people.apache.org/builds/commons/exec/1.0.0/RC3/site/index.html >> >> Binaries: >> >> http://people.apache.org/builds/commons/exec/1.0.0/RC3/staged/org/apache/commons/commons-exec/ >> >> [ ] +1 release it >> [ ] +0 go ahead I don't care >> [ ] -1 no, do not release it because >> >> >> Let the fun begin ... >> >> Siegfried Goeschl >> >> PS: The test distribution is not part of the release but handy for >> platform testing - http://people.apache.org/~sgoeschl/download/commons-exec/ >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
