incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre Smits <pierre.sm...@gmail.com>
Subject Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3
Date Fri, 05 May 2017 10:32:30 GMT
I forgot to address in my conclusion aspect #7 (classes.jar).

This seems to be quite the issue, as I could not find a license associated
with it when I did the cursory review. Nor could I find in the proposal
anything more than a single reference. My question(s):

   - where does this originate from, and what is the license?
   - was this intended to be part of the Weex solution? And If so, does the
   ASF have an SGA for this?

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 12:25 PM, Pierre Smits <pierre.smits@gmail.com>
wrote:

> 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 <sospartan@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 <ptgoetz@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 <ptgoetz@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 <niclas@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.clr@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 <niclas@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
>> > >>> clr@apache.org http://db.apache.org/jdo
>> > >>>
>> > >>>
>> > >>> ------------------------------------------------------------
>> ---------
>> > >>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> > >>> For additional commands, e-mail: general-help@incubator.apache.org
>> > >>>
>> > >>>
>> > >>
>> > >>
>> > >> --
>> > >> Niclas Hedhman, Software Developer
>> > >> http://polygene.apache.org - New Energy for Java
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: general-help@incubator.apache.org
>> >
>> >
>>
>>
>> --
>> sospartan
>> Phone:13588488290
>> HangZhou
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message