Good morning Simo,
2013/3/25 Simone Tripodi <simonetrip...@apache.org> > Hallo! > > > > > build works fine with my environment, which is: > > > > Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) > > Maven home: D:\Entwicklung\maven\3.0.3 > > Java version: 1.7.0_13, vendor: Oracle Corporation > > Java home: D:\Entwicklung\Java\jdk1.7.0_13-x64\jre > > Default locale: de_DE, platform encoding: Cp1252 > > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" > > > > Site looks good, signatures are okay. > > > > gut! > > > One thing that caught my attention (but probably is related to how RMs > > create RCs): commons-fileupload-1.3-bin.tar.gz and > > commons-fileupload-1.3-bin.zip not only contain the binaries but also > > contain sources jars, as well as test classes. As far as I can remember > > this is different from the other two releases I have voted for > > Please note that what Apache really releases are the *sources* and not > binary archives - an interesting reading is "What is a release?"[1] > where it is specified: > > <quote> > "The Apache Software Foundation produces open source software. All > releases are in the form of the source materials needed to make > changes to the software being released. In some cases, binary/bytecode > packages are also produced as a convenience to users that might not > have the appropriate tools to build a compiled version of the source. > In all such cases, the binary/bytecode package must have the same > version number as the source release and may only add binary/bytecode > files that are the result of compiling that version of the source code > release." > </quote> > > Here we are speaking about binary release and each component has the > freedom to include, along the main jar archive, whatever aux file is > required to properly use the main distribution package. There's no > guideline anyway on how -bin archives have to be composed - this is > something I tried to unify some time ago, describing an approach which > shares a single assembly descriptor[2] across all modules, but the > proposal was rejected. > Thanks for this explanation! > > > and it is > > definitely different from fileupload 1.2.2. Also the site directory in > > those archives only contains the JavaDoc page, where as the site > directory > > from commons-fileupload-1.2.2-bin.zip contains the hole site. > > yup that depends on which goals order the previous RM executed - > invoking the `site` first, it includes all pages, not just javadoc, > which are generated before deploying artifacts anyway. > Okay, so here is my (non-binding) +1 :-) Benedikt > > Thanks for reviewing, > -Simo > > [1] http://www.apache.org/dev/release.html#releases > [2] http://markmail.org/message/tvxh4kflhdm3zq4k > > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
