Hi All, To understand part of the problem correctly, in currently proposed release there are many compiled components (jar files)that aren't allowed to be included.... > clr% find . -name "*.jar"
1. > ./android/playground/gradle/wrapper/gradle-wrapper.jar 2. > ./android/sdk/gradle/wrapper/gradle-wrapper.jar 3. > ./android/sdk/license/license-gradle-plugin-0.12.1.jar 4. > ./android/sdk/license/maven-license-plugin-1.10.b1.jar 5. > ./android/sdk/license/plexus-utils-3.0.24.jar 6. > ./android/weex_debug/gradle/wrapper/gradle-wrapper.jar 7. > ./android/weex_debug/libs/classes.jar 8. > ./scripts/apache-rat-0.12.jar So lets break this down: Re 1 & 2 and 6 : gradle-wrapper.jar This is an 3rd party solution provided by the Gradle community/organisation build through the 'gradle wrapper' task. Licensed under AL2.0. This can be included in the source repo, however it can NOT (per current conventions) be included in source releases. But it can be included in convenience downloads based on source releases; Re 3: license-gradle-plugin-0.12.1.jar This is apparently a 3rd party solution available through e.g. mvnrepository.com. Licensed under AL2.0. This can be included in the source repo, however it can NOT (per current conventions) be included in source releases. But it can be included in convenience downloads based on source releases; Re 4. maven-license-plugin-1.10.b1.jar This is apparently a 3rd party solution available through e.g. mvnrepository.com. Licensed under AL2.0. This can be included in the source repo, however it can NOT (per current conventions) be included in source releases. But it can be included in convenience downloads based on source releases; Re 5: plexus-utils-3.0.24.jar This is apparently a 3rd party solution available through e.g. mvnrepository.com. Licensed under AL2.0. This can be included in the source repo, however it can NOT (per current conventions) be included in source releases. But it can be included in convenience downloads based on source releases; Re 7: classes.jar Cursory analysis of the jar shows that it stemming from com.taobao java code, used in [1] and referenced in the Weex proposal (see [2]). Re 8: apache-rat-0.12.jar This is an artefact produced by Apache Creadur project (see [3]). This can be included in the source repo, and CAN be included in source releases (as it is ASF own).And it can be included in convenience downloads based on source releases; [1] https://github.com/apache/incubator-weex/tree/master/android/weex_debug/src/main/java/com/taobao/weex [2] https://wiki.apache.org/incubator/WeexProposal~) [3] http://creadur.apache.org/rat/ Conclusion(s): 1. Many of the 3rd party solutions (jar files) used in the Apache Weex product are available in artefact repos like mvnrepository.com, and need not be included in the code base, source releases and convenience downloads as they can be retrieved through the dependency mgt solution used by the project (gradle in this case); 2. Convenience downloads (jar files) of ASF projects can be included when downloaded from ASF sources. However, if these are not available through ASF or 3rd party artefact repos ( e.g. mvnrepository.com) it is advised that the project contacts the (appropriate) ASF project that delivers such solutions and have them included in these artefact repos. The project can then have such retrieved through the depency mgt solution used by the project; 3. gradle-wrapper.jar is generated by executing a gradle task (./gradle wrapper), and is based on 1. the gradle version used (by the person having downloaded the source) 2. potential gradle configuration elements included in the project's source code (build.gradle, etc). No gradle-wrapper.jar artefact was found via mvnrepository.com. The ideal situation (to resolve the major issue discussed in this thread) would be if such convenience download would be made available through the various jar repos (e.g. mvnrepository). This should (preferably) be done by the Gradle community/organisation. However, in the short term, the project could adjust the gradlew scripts in the codebase to have that invoke the download from the project's repo ((in ./gradlew for linux initiate e.g. wget), and in ./gradlew.bat initiate an equivalent)) I trust the above helps to clear the air. Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Fri, May 5, 2017 at 3:57 AM, sospartan <sospar...@gmail.com> wrote: > Taylor, > Can you point out which objections you are agreed exactly? > > > > On Fri, May 5, 2017 at 9:31 AM, P. Taylor Goetz <ptgo...@gmail.com> wrote: > > > Apologies for the auto correct. > > > > Please sub "Niclas" for "Nicolas". > > > > -Taylor > > > > > On May 4, 2017, at 8:43 PM, P. Taylor Goetz <ptgo...@gmail.com> wrote: > > > > > > Nicolas, > > > > > > I understand and appreciate your passion, but would respectfully ask > > that you step down your tone a little bit. Craig and John have both taken > > time to review the release candidate (which you should be appreciative of > > -- getting IPMC members to review a release can be difficult). In my > > opinion their reviews bring up some valid points that need to be > considered. > > > > > > Weex, by its nature, has a complicated codebase with respect to > > licensing and building from source. It is a far cry from a java project > > with a Pom and a a "src" directory. It pulls in a lot of different code > > that needs to be considered and evaluated. Going forward the (P)PMC will > > need to understand that and as a TLP will need to be able to address > issues > > accordingly. > > > > > > What may seem like "Incubator hazing" right now, I would argue, is an > > exercise in making sure the podling has what it takes to operate as a > fully > > functional TLP. No two podlings are the same, and some face certain > burdens > > that others do not. > > > > > > For now can we try to turn the thread toward a more constructive path > > that benefits both the podling and the Incubator? > > > > > > For what it's worth, I agree with some (not all) of the objections that > > have been raised. So I would be a -1 as well. > > > > > > -Taylor > > > > > > > > > > > >> On May 4, 2017, at 3:02 AM, Niclas Hedhman <nic...@hedhman.org> > wrote: > > >> > > >> Sorry, but if you don't know the background on that file, then perhaps > > you > > >> think I am "not civil"... The fact is that NOTICE file doesn't require > > any > > >> inclusion of what the project depends on, since they are not bundled, > > but > > >> will be downloaded during build. In a previous round, we were told to > > take > > >> it out of NOTICE for that reason (not bundled) and I argued that we > > should > > >> keep it in to make it more reasonable for downstreams to get an idea > of > > >> what a binary distro will actually contain. This file was the > > compromise of > > >> providing such details to downstream. > > >> > > >> Now you say, "Uhhh, it is unclear..." when in reality it would be even > > more > > >> unclear if we left it out, as some people on this very list pushed for > > on a > > >> previous RC. > > >> > > >> So, yes, I get pissed off as well. The incubator over time is getting > > more > > >> and more intolerant at podling's first release, and I think it is the > > wrong > > >> way to go. It is disheartening... truly... > > >> > > >> > > >> Niclas > > >> > > >>> On Thu, May 4, 2017 at 1:57 PM, Craig Russell <apache....@gmail.com> > > wrote: > > >>> > > >>> I'm going to call foul on this one. > > >>> > > >>> If you cannot be civil, then leave the discussion to others. > > >>> > > >>> Craig > > >>> > > >>>> On May 3, 2017, at 7:24 PM, Niclas Hedhman <nic...@hedhman.org> > > wrote: > > >>>> > > >>>> BUT ALSO figuring out what to start looking for. For fak sake, > > >>>> man.... Get a grip on reality! > > >>> > > >>> Craig L Russell > > >>> Secretary, Apache Software Foundation > > >>> c...@apache.org http://db.apache.org/jdo > > >>> > > >>> > > >>> ------------------------------------------------------------ > --------- > > >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > >>> For additional commands, e-mail: general-h...@incubator.apache.org > > >>> > > >>> > > >> > > >> > > >> -- > > >> Niclas Hedhman, Software Developer > > >> http://polygene.apache.org - New Energy for Java > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > -- > sospartan > Phone:13588488290 > HangZhou >
