On Thu, May 4, 2017 at 9:22 AM, Craig Russell <apache....@gmail.com> wrote: > clr% find . -name "*.jar" > ./android/playground/gradle/wrapper/gradle-wrapper.jar > ./android/sdk/gradle/wrapper/gradle-wrapper.jar > ./android/sdk/license/license-gradle-plugin-0.12.1.jar > ./android/sdk/license/maven-license-plugin-1.10.b1.jar > ./android/sdk/license/plexus-utils-3.0.24.jar > ./android/weex_debug/gradle/wrapper/gradle-wrapper.jar > ./android/weex_debug/libs/classes.jar > ./scripts/apache-rat-0.12.jar
> 1. These jar files are not source and must not appear in the source release. These are convenience for building the system. Those who are overly concerned and don't trust Apache project members, are free to build using tools downloaded by themselves. I have argued that this will be changed to a "only source code" approach in the future, but should not hinder a release now. > 2. I appreciate the effort involved in compiling the POSSIBLE-NOTICES-FOR-BIN-DIST. But looking into these dependencies I am troubled by the difficulty actually finding the licenses of the projects. > > For example, the "possible notice" for animaitonjs (possible typo here) refers to https://www.npmjs.com/package/animationjs from which it is impossible (ok, perhaps possible but I could not find a link) to find the actual project. > > References to npmjs in this entire file should be removed and replaced by references to the home of the project. (Not relevant for this release because the files are not actually being distributed.) And YET, the argument is that this file SHOULD NOT BE INCLUDED AT ALL, so that downstream packagers have to not only worry about what you are listing above, BUT ALSO figuring out what to start looking for. For fak sake, man.... Get a grip on reality! > 3. The java source files in android/commons/src are still in the com.alibaba name space. Assuming that these are actually weex source files, they must be repackaged to org.apache. YES, that is on purpose to avoid breaking compatibility with hundreds of people using Weex in their projects right now. org.apache.weex namespace is slated for a later release when compatibility is sacrificed. > 4. The javascript source files in playground/app/src are missing the license header. They have a style that I do not recognize. Are these generated files? The first several lines of storage-demo.js: > > /******/ (function(modules) { // webpackBootstrap > /******/ // The module cache > /******/ var installedModules = {}; > > /******/ // The require function > /******/ function __webpack_require__(moduleId) { > > /******/ // Check if module is in cache > /******/ if(installedModules[moduleId]) > /******/ return installedModules[moduleId].exports; I don't know about this one. > 5. The java files in playground/app/src/main/java_zxing are in the com.google name space. They have a google license header. I have missed that one. But it is bundled source code from elsewhere, and should be mentioned in top-level NOTICE, not only the localized one. Before you complain about the NOTICE and LICENSE in playground, that is due to the intent that the playground/ is expected to be copied elsewhere as a sample project that uses the Weex SDK. Hence its location there. > 6. The packages/weex-html5 contains LICENSE and NOTICE files. These should be in the top level directory of the release. This one is less than clear cut. The content in packages/ will be uploaded to npm registry, and the files in the directory will be moved there. There is relatively little information (compared to Maven Central uploads) how that is to be handled, since the content that is uploaded need to be part of a source release. > 7. The scripts/rh contains LICENSE and NOTICE files. These should be in the top level directory of the release. The scripts/ directory is mistakenly included in the dist. > 8. There is an executable file that doesn't belong: > > clr% ls -l start > -rwxr-xr-x@ 1 clr staff 161 Apr 27 20:34 start What's the problem with "executable file"? It is a shell script, and since when are we not allowed to ship that? Granted; lacking license header, but that is not your complaint. > 9. There is an executable gradlew in sdk/gradle that doesn't belong in a source release. Port of your point 1, and gradlew is another shell script. ARE YOU SAYING that shell scripts are not allowed in source distros? > 10. There are shared objects in sdk/libs that don't belong in a source release. Alright, this is a issue that I am not convinced either way. I agree that "doesn't belong", but on the other hand, the steps to set up (and get working) the Android Native Development Kit (not talking about the Android SDK) is substantial. By allowing these built binaries, we can avoid that for most users, who normally never touch the NDK. By demanding that these binaries are taken out, then you just condemned this project to produce a Binary Release as well, which was not planned for this release. > 11. There are NOTICE and LICENSE files in ios/sdk that seem to be unix executable files. > clr% ls -l ios/sdk > total 40 > -rwxr-xr-x@ 1 clr staff 11343 Apr 27 20:34 LICENSE > -rwxr-xr-x@ 1 clr staff 575 Apr 27 20:34 NOTICE An honest mistake, and shouldn't stop a release. > 12. The README.md doesn't tell me how to build/use org.apache.weex. The first several lines refer to third-party projects from Alibaba and cocoapods. How do I use the Apache project? Well, you just introduced more complexity in "using the project" with your insistence on no binaries, and more so if your "no execute flag" is also now not allowed. AFAIK, there is no obligation that the source distribution must contain all details needed to build the project, only that it can be built. But for you convenience; 1. Install Gradle and learn how to use it. 2. Install Maven and learn how to use it. 3. Install Android NDK and learn how to use it. 4. Install Android SDK and learn how to use it. 5. Install Xcode and learn how to use it. 6. Install IOS SDK and learn how to use it. 7. Build each part with the tool needed. Cheers -- Niclas Hedhman, Software Developer http://polygene.apache.org - New Energy for Java
