Saturday, April 22, 2017, 12:41:23 PM, Niclas Hedhman wrote: > Note on gradle-wrapper.jar, > For source releases, we expect the project to be buildable by the user. The > Gradle wrapper is the easiest way to make that happen. It (together with > the gradlew and gradlew.bat scripts) ensures that that the build will be > the same, and not suffer from different Gradle versions being used, > potentially incompatible. Now, you could write a document on how to achieve > this in other ways, and deal with the fall-out. But just like the > gradle-wrapper.jar is committed to the source repository, I stand by that > the gradle-wrapper belongs in the source distro, as a defacto standard for > projects using Gradle to build. You will find similar 'bundling' of build > systems in other languages as well, are they also banned? Or it just > because they are in human-readable format that it is considered ok?
I'm also interested in the answer for this. Committing gradle-wrapper.jar into the VCN is a quite common practice (and is also the subject of some "religious" disputes, because some just can't bear the idea of committing jar-s). We have run into yet another problem with gradle-wrapper.jar; there's no license information for it, or at least we couldn't find it. I guess that will be the real blocker when it comes to including it. (Or perhaps ASF could make an exception with gradle-wrapper.jar, as it's commonly known what it is and where it comes from.) > Note on LICENSE; > IIUIC, the source distribution doesn't ship any dependencies (except Gradle > above), and there is only Apache License to be considered. > > As for NOTICE, the ASF documentation you point to, basically says that a) > don't put in anything that is not bundled (i.e. just about nothing in the > source release), b) no burden on downstream users. HOWEVER, by excluding > the list of dependencies that will be in the resulting product, we would > actually increase the burden of downstream users as they would need to > figure out what licensing requirements will come out of it all, if they > choose to distribute. > Therefor, I would argue that documentation is in this case arguing against > itself in a single sentence, and think that the approach taken by Weex is > appropriate. We do have a different NOTICE and LICENSE for the source distribution and for the binary distribution, plus one more variation that's included in the jar artifact (which is distributed in itself via the Maven Central Repository). That's because each form of distributor carries different files. I'm not saying that's the correct way (I don't know... but I hope so), but such releases have passed voting here for 3 times so far. > (all subject to that my understanding of that there is no third-party in > the source distribution) > > > Package name; yeah, I completely forgot that, as I saw it in the directory > name. > > > On Sat, Apr 22, 2017 at 6:10 PM, John D. Ament <johndam...@apache.org> > wrote: > >> Sorry but -1 due to misnamed package and binary content. >> >> - No "incubating" / "incubator" in package name >> - JAR files are present in the source release (gradle-wrapper.jar) >> - Ideally the expanded package would include "apache" in the folder, not a >> big deal. >> - DISCLAIMER present >> >> Your NOTICE seems way too big. Do you actually bundle all of these >> dependencies? I can't find them if you do. Most of what's being called out >> in NOTICE should actually be in LICENSE. For instance, only Apache >> licensed code would normally call out NOTICE entries, and those entries are >> meant to be copied verbatim from the source package. In this case, fastjson >> is referenced (though I don't see it anywhere), but it has no NOTICE so >> nothing to declare. >> >> Meanwhile, your LICENSE is too short. Each project that you do bundle, if >> its not Apache licensed, you must copy its license text or provide a >> pointer to the license. We have a full guide on how to assemble these - >> http://www.apache.org/dev/licensing-howto.html - please reach out if you >> need help. >> >> The critical piece to fix is your package name. If you're re-rolling to >> fix that, I would recommend going through your NOTICE/LICENSE and see what >> does and doesn't belong. The second piece to fix is the JAR files. You >> must not include them (I've tried fighting the fight, and can't get >> anywhere on it - source releases are for source code only). >> >> John >> >> On Thu, Apr 20, 2017 at 4:11 AM sospartan <sospar...@apache.org> wrote: >> >> > Hi all, >> > I'll calling a vote for Weex-incubating 0.12.0-RC2 release. >> > >> > The PPMC vote for this release has passed: >> > >> > https://lists.apache.org/thread.html/d544a60a4038f9d053f7ea1eca0d16 >> 2b9aef392551a02a0401041e8f@%3Cdev.weex.apache.org%3E >> > >> > The tag to be voted upon: >> > https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git >> > ;a=shortlog;h=refs/tags/0.12.0-rc1 >> > >> > The commit hash: >> > https://git-wip-us.apache.org/repos/asf?p=incubator-weex.git;a=commit;h= >> > 9ac0c82443e65b1c9d8a2714fea6b9a5b8af9907 >> > <https://git-wip-us.apache.org/repos/asf?p=incubator- >> weex.git;a=commit;h=9ac0c82443e65b1c9d8a2714fea6b9a5b8af9907> >> > >> > The source tarball can be found at: >> > >> > https://dist.apache.org/repos/dist/dev/incubator/weex/0.12. >> 0-incubating/RC1/ >> > >> > The fingerprint of key to sign release artifacts: >> > 97B9 6598 A6A3 B63C 53BD 77E9 44C5 2286 22B9 7784 >> > >> > Release artifacts are signed with the following key: >> > https://dist.apache.org/repos/dist/dev/incubator/weex/KEYS >> > >> > Release note about this version: >> > https://issues.apache.org/jira/browse/WEEX-26 >> > >> > This vote will remain open for at least 72 hours. >> > Please vote on releasing this RC. >> > >> > [ ] +1 approve >> > [ ] +0 no opinion >> > [ ] -1 disapprove (and reason why) >> > >> > -- >> > Best Regards! >> > ------------------------------ >> > >> > sospartan >> > https://weex-project.io >> > >> > > > -- Thanks, Daniel Dekany --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
