Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3

[Niclas Hedhman]

Thanks Anthony,
so that's where the notion "gradlew doesn't work on Windows" comes from.
Makes more sense now. But I don't think that is just as practical for Weex
as it is for BigTop.

On Sat, May 6, 2017 at 3:10 AM, Anthony Baker  wrote:

>
> > On May 5, 2017, at 4:27 AM, sospartan  wrote:
> >
> > I'll remove whole playground sample app from artifacts innext release. So
> > #7 would be a problem anymore.
> > As the gradle wrapper will be removed too. I'll suggest use installed
> > gradle to create that. These will be put in new "how to build from
> source"
> > doc in root folder.
> > Pierre Smits 于2017年5月5日 周五下午6:32写道：
> >
>
> You might want to consider using the Bigtop approach for gradlew [1] to
> avoid shipping a binary in the source release.  The Geode project has been
> using this successfully (thanks to Roman for pointing us in this
> direction!).
>
> Anthony
>
> [1] https://github.com/apache/bigtop/blob/master/gradlew <
> https://github.com/apache/bigtop/blob/master/gradlew>
>
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

[DISCUSSION] Apache SystemML podling graduation

[Luciano Resende]

Apache SystemML has been under incubation since November 2015 and so far
the project has accomplished 5 official Apache Releases, voted 4 new
committers/PPMC members and has welcomed a new mentor. The community also
continues to evangelize the project at universities, blog posts, public
webcasts as well as in multiple conferences.

It's time to discuss the graduation of SystemML

The SystemML PPMC graduation discussion can be found here:
https://www.mail-archive.com/dev@systemml.incubator.apache.org/msg01457.html

If SyatemML were to graduate, the proposed board resolution is being
discussed/drafted at:
https://www.mail-archive.com/dev@systemml.incubator.apache.org/msg01728.html

The optional maturity model is available at:
http://systemml.apache.org/maturit 


Any thoughts, comments, questions?

Thanks !

Regards


-- 
Luciano Resende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Re: [VOTE] Release Apache Airflow 1.8.1 (incubating)

[Chris Riccomini]

Sigh, that was meant to be signed:

Cheers,
Chris

On Fri, May 5, 2017 at 1:44 PM, Chris Riccomini 
wrote:

> Hello Incubator PMC’ers,
>
> The Apache Airflow community has voted and approved the proposal to
> release Apache Airflow 1.8.1 (incubating) based on 1.8.1 Release Candidate
> 2. We now kindly request the Incubator PMC members to review and vote on
> this incubator release. If the vote is successful we will rename release
> candidate 2 to final.
>
> Airflow is a platform to programmatically author, schedule and monitor
> workflows. Use airflow to author workflows as directed acyclic graphs
> (DAGs) of tasks. The airflow scheduler executes your tasks on an array of
> workers while following the specified dependencies. Rich command line
> utilities make performing complex surgeries on DAGs a snap. The rich user
> interface makes it easy to visualize pipelines running in production,
> monitor progress, and troubleshoot issues when needed. When workflows are
> defined as code, they become more maintainable, versionable, testable, and
> collaborative.
>
> The Apache Airflow-1.8.1-incubating release candidate is now available
> with the following artifacts for a project vote:
>
> * [VOTE] Thread:*
> https://mail-archives.apache.org/mod_mbox/incubator-
> airflow-dev/201705.mbox/%3CCABYbY7eZk2SYHs3ni31h94uwwRd
> cn4dkJwumYtUMsfFLq-gwjg%40mail.gmail.com%3E
>
> *[RESULT] [VOTE] Thread:*
> https://mail-archives.apache.org/mod_mbox/incubator-
> airflow-dev/201705.mbox/%3CCABYbY7dBAnjcvb-w_
> 4Hdy3ZUM3CGn6Y3eUvZctuFCfdAfPGAXQ%40mail.gmail.com%3E
>
> *The release candidate(s) to be voted on is available at:*
> https://dist.apache.org/repos/dist/dev/incubator/airflow/ or
> https://dist.apache.org/repos/dist/dev/incubator/airflow/
> apache-airflow-1.8.1rc2+incubating.tar.gz
>
> *Git branch*
> https://github.com/apache/incubator-airflow/tree/v1-8-test or
> https://git-wip-us.apache.org/repos/asf?p=incubator-airflow.
> git;a=tree;h=refs/heads/v1-8-stable;hb=refs/heads/v1-8-test
>
> *Git tag*
> https://git-wip-us.apache.org/repos/asf?p=incubator-airflow.
> git;a=shortlog;h=af2d0b4b5cb1ef30a065b1af66f90a01a953e2be
>
> *PGP signature*
> https://dist.apache.org/repos/dist/dev/incubator/airflow/
> apache-airflow-1.8.1rc2+incubating.tar.gz.asc
>
> *MD5/SHA Hashes*
> https://dist.apache.org/repos/dist/dev/incubator/airflow/
> apache-airflow-1.8.1rc2+incubating.tar.gz.md5
> https://dist.apache.org/repos/dist/dev/incubator/airflow/
> apache-airflow-1.8.1rc2+incubating.tar.gz.sha
>
> *Keys to verify the signature of the release artifacts are available at:*
> https://dist.apache.org/repos/dist/release/incubator/airflow/
>
> * RAT License checks*
>
> RAT is executed as part of the CI process (e.g.
> https://travis-ci.org/apache/incubator-airflow/builds/226568140) but can
> also be run manually by issuing “sh scripts/ci/check-license.sh” from the
> top level.
>
> Source code is always included, i.e. there is no binary release.
> Compilation and installation will happen by standard Python practices, e.g.
> pip install <> or python setup.py install.
>
> The vote will be open for at least 72 hours or until necessary number of
> votes are reached.
>
> Members please be sure to indicate "(Binding)" with your vote which will
> help in tallying the vote(s).
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> *Here is my +1 (non-binding)*
>
> Cheers,
> Bolke
>
>

[VOTE] Release Apache Airflow 1.8.1 (incubating)

[Chris Riccomini]

Hello Incubator PMC’ers,

The Apache Airflow community has voted and approved the proposal to release
Apache Airflow 1.8.1 (incubating) based on 1.8.1 Release Candidate 2. We
now kindly request the Incubator PMC members to review and vote on this
incubator release. If the vote is successful we will rename release
candidate 2 to final.

Airflow is a platform to programmatically author, schedule and monitor
workflows. Use airflow to author workflows as directed acyclic graphs
(DAGs) of tasks. The airflow scheduler executes your tasks on an array of
workers while following the specified dependencies. Rich command line
utilities make performing complex surgeries on DAGs a snap. The rich user
interface makes it easy to visualize pipelines running in production,
monitor progress, and troubleshoot issues when needed. When workflows are
defined as code, they become more maintainable, versionable, testable, and
collaborative.

The Apache Airflow-1.8.1-incubating release candidate is now available with
the following artifacts for a project vote:

* [VOTE] Thread:*
https://mail-archives.apache.org/mod_mbox/incubator-airflow-dev/201705.mbox/%3CCABYbY7eZk2SYHs3ni31h94uwwRdcn4dkJwumYtUMsfFLq-gwjg%40mail.gmail.com%3E

*[RESULT] [VOTE] Thread:*
https://mail-archives.apache.org/mod_mbox/incubator-airflow-dev/201705.mbox/%3CCABYbY7dBAnjcvb-w_4Hdy3ZUM3CGn6Y3eUvZctuFCfdAfPGAXQ%40mail.gmail.com%3E

*The release candidate(s) to be voted on is available at:*
https://dist.apache.org/repos/dist/dev/incubator/airflow/ or
https://dist.apache.org/repos/dist/dev/incubator/airflow/apache-airflow-1.8.1rc2+incubating.tar.gz

*Git branch*
https://github.com/apache/incubator-airflow/tree/v1-8-test or
https://git-wip-us.apache.org/repos/asf?p=incubator-airflow.git;a=tree;h=refs/heads/v1-8-stable;hb=refs/heads/v1-8-test

*Git tag*
https://git-wip-us.apache.org/repos/asf?p=incubator-airflow.git;a=shortlog;h=af2d0b4b5cb1ef30a065b1af66f90a01a953e2be

*PGP signature*
https://dist.apache.org/repos/dist/dev/incubator/airflow/apache-airflow-1.8.1rc2+incubating.tar.gz.asc

*MD5/SHA Hashes*
https://dist.apache.org/repos/dist/dev/incubator/airflow/apache-airflow-1.8.1rc2+incubating.tar.gz.md5
https://dist.apache.org/repos/dist/dev/incubator/airflow/apache-airflow-1.8.1rc2+incubating.tar.gz.sha

*Keys to verify the signature of the release artifacts are available at:*
https://dist.apache.org/repos/dist/release/incubator/airflow/

* RAT License checks*

RAT is executed as part of the CI process (e.g.
https://travis-ci.org/apache/incubator-airflow/builds/226568140) but can
also be run manually by issuing “sh scripts/ci/check-license.sh” from the
top level.

Source code is always included, i.e. there is no binary release.
Compilation and installation will happen by standard Python practices, e.g.
pip install <> or python setup.py install.

The vote will be open for at least 72 hours or until necessary number of
votes are reached.

Members please be sure to indicate "(Binding)" with your vote which will
help in tallying the vote(s).

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

*Here is my +1 (non-binding)*

Cheers,
Bolke

Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3

[Anthony Baker]

> On May 5, 2017, at 4:27 AM, sospartan  wrote:
> 
> I'll remove whole playground sample app from artifacts innext release. So
> #7 would be a problem anymore.
> As the gradle wrapper will be removed too. I'll suggest use installed
> gradle to create that. These will be put in new "how to build from source"
> doc in root folder.
> Pierre Smits 于2017年5月5日 周五下午6:32写道：
> 

You might want to consider using the Bigtop approach for gradlew [1] to avoid 
shipping a binary in the source release.  The Geode project has been using this 
successfully (thanks to Roman for pointing us in this direction!).

Anthony

[1] https://github.com/apache/bigtop/blob/master/gradlew 

Re: [VOTE] Apache SystemML 0.14.0-incubating (RC4)

[Arvind Surve]

Hi John,
Can you please look at my response and advise?

-Arvind--- Arvind Surve | Spark Technology Center  | 
http://www.spark.tc/

  From: Arvind Surve 
 To: "general@incubator.apache.org" ; John D. 
Ament  
 Sent: Wednesday, May 3, 2017 8:48 PM
 Subject: Re: [VOTE] Apache SystemML 0.14.0-incubating (RC4)
   
Thanks John for response. Let me try to answer your third question.
>
> In the samples/images directory you have a bunch of files named "bluemix"
> which implies IBM Bluemix.  How are these images licensed?
> Arvind: These are screen shots, we can remove these images.
>
>
>
This doesn't answer my question.  My only question is how are they
licensed, I'm not necessarily asking you to remove them unless you don't
have rights to use them in which case they need to go.  Where did your team
get them from?

One of the SystemML member created notebook example using through Bluemix which 
is FREE trial version.While in the process, person took snapshots so that other 
users can same procedure.In short, person took screen shots from Bluemix site 
and added those images.Hope this answers your question.
-Arvind
 Arvind Surve | Spark Technology Center  | http://www.spark.tc/

      From: John D. Ament 
 To: Arvind Surve ; "general@incubator.apache.org" 
 
 Sent: Wednesday, May 3, 2017 5:13 PM
 Subject: Re: [VOTE] Apache SystemML 0.14.0-incubating (RC4)
  
Arvind,

On Wed, May 3, 2017 at 4:12 PM Arvind Surve  wrote:

> Hi John,
>
> Please see my response below and advise.
>
> For the first section, it doesn't seem to reference any files.  Why is it
> present?
> Arvind: It was part of sizzle.js license, got splitted when license for
> Pygments got added.
> We wil fix it.
>
>
> For the second, I can't find a "node_modules" directory.
> Arvind: This will be removed.
>
>
Ok to both of the above.

>
> In the samples/images directory you have a bunch of files named "bluemix"
> which implies IBM Bluemix.  How are these images licensed?
> Arvind: These are screen shots, we can remove these images.
>
>
>
This doesn't answer my question.  My only question is how are they
licensed, I'm not necessarily asking you to remove them unless you don't
have rights to use them in which case they need to go.  Where did your team
get them from?


> Please let me know if its ok to address all above changes in next release.
>
> Thanks
> Arvind
>
>
>
> Arvind Surve | Spark Technology Center  | http://www.spark.tc/
>
>
> --
> *From:* John D. Ament 
> *To:* general@incubator.apache.org; Arvind Surve 
> *Sent:* Tuesday, May 2, 2017 5:32 PM
> *Subject:* Re: [VOTE] Apache SystemML 0.14.0-incubating (RC4)
>
> Some questions about your release:
>
> The following appears in your license:
>
> Permission is hereby granted, free of charge, to any person obtaining
> a copy of this software and associated documentation files (the
> "Software"), to deal in the Software without restriction, including
> without limitation the rights to use, copy, modify, merge, publish,
> distribute, sublicense, and/or sell copies of the Software, and to
> permit persons to whom the Software is furnished to do so, subject to
> the following conditions:
>
> The above copyright notice and this permission notice shall be
> included in all copies or substantial portions of the Software.
>
> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
> LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
> OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
> WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
>
> 
>
> All files located in the node_modules and external directories are
> externally maintained libraries used by this software which have their
> own licenses; we recommend you read them, as their terms may differ from
> the terms above.
>
> For the first section, it doesn't seem to reference any files.  Why is it
> present?
>
> For the second, I can't find a "node_modules" directory.
>
> In the samples/images directory you have a bunch of files named "bluemix"
> which implies IBM Bluemix.  How are these images licensed?
>
> John
>
> On Mon, May 1, 2017 at 12:42 PM Arvind Surve 
> wrote:
>
> > Please vote on releasing the following candidate as Apache SystemML
> > version 0.14.0-incubating !
> >
> >
> >
> > The vote is open for at least 72 hours and passes if a majority of at
> > least 3 +1 PMC votes are cast.
> > [ ] +1 Release this package as Apache SystemML 0.14.0-incubating[ ] -1 Do
> > not release this package because ...
> > To learn more 

Re: [PROPOSAL] Pulsar - proposal for Apache Incubation

[Dave Fisher]

Hi -

Anyone else interested in mentoring?

Regards,
Dave

Sent from my iPhone

> On May 1, 2017, at 4:55 PM, Dave Fisher  wrote:
> 
> Hi -
> 
> I had a discussion with Joe and another gentleman involved in Pulsar.
> 
> They asked how long incubation takes. I answered that it depends. We reviewed 
> some of the steps needed in Incubation particularly:
> 
> - Release process with correct LICENSE and NOTICE
> - Community building requirement - especially accepting and promoting someone 
> new from outside the initial committers.
> - Everything on the ML meaning decisions which might be made in conversation 
> need to be there for a review over a few rotations of the planet. I mentioned 
> BFDLs not being what is wanted and told the 10 year old story of POI’s OOXML 
> flame.
> - Build infrastructure questions regarding unit tests some of which will be 
> preferred on clusters. Some are currently proprietary. I’m not sure what 
> Apache Infra currently supports so negotiation is required.
> 
> I think that there is a good chance for a diverse community that will not be 
> wholly dependent on Yahoo.
> 
> End result - I am willing to sign up as a Mentor for Pulsar.
> 
> Regards,
> Dave
> 
>> On Apr 28, 2017, at 7:56 AM, Dave Fisher  wrote:
>> 
>> Hi John,
>> 
>> I am trying to decide if I personally wish to mentor Pulsar and will be 
>> asking technical questions. IMO this is not appropriate to an Incubator 
>> discussion. Anything that surfaces that is appropriate can be brought back 
>> to this discussion.
>> 
>> There is no intension to subvert Incubator process.
>> 
>> I certainly understand asynchronous global teams. I've spent many years 
>> working with development teams in Moscow and India.
>> 
>> We can have a separate discussion about how misunderstandings can cause 
>> email threads to totally blow up.
>> 
>> Regards,
>> Dave
>> 
>> Sent from my iPhone
>> 
>>> On Apr 28, 2017, at 4:20 AM, John D. Ament  wrote:
>>> 
>>> I'm sorry but I'm a bit dumb founded by this part of the thread.  I'll
>>> apologize up front for my bluntness.
>>> 
>>> In the incubator, we're trying to teach projects to deal with asynchronous
>>> communication.  The last thing we should be doing is encouraging phone
>>> calls/real time meetings.  If there are technical questions, and you feel
>>> they need to be answered prior to starting incubation that's perfectly fine
>>> - but try to get the answers in ways we would expect, via public mailing
>>> lists.
>>> 
>>> John
>>> 
 On Thu, Apr 27, 2017 at 10:17 PM Dave Fisher  wrote:
 
 Hi -
 
 I am in California and could do a webex this Monday.
 
 Regards,
 Dave
 
 Sent from my iPhone
 
> On Apr 27, 2017, at 1:41 AM, Jochen Theodorou  wrote:
> 
> 
> 
>> On 26.04.2017 23:19, Joe Francis wrote:
>> 
>> Dear Apache Incubator Community,
>> 
>> 
>> We would like to submit the Pulsar proposal to the incubator.  Our
 draft is
>> available at:
>> https://wiki.apache.org/incubator/PulsarProposal
>> 
>> A quick overview of Pulsar:
>> 
>> Pulsar is a highly scalable, low latency messaging platform running on
>> commodity hardware. It provides simple pub-sub semantics over topics,
>> guaranteed at-least-once delivery of messages, automatic cursor
 management for
>> subscribers, and cross-datacenter replication.
> 
> Without really knowing the details of a messaging platform and even with
 the danger of comparing apples and oranges... how would you compare for
 example hazelcast based messaging to pulsar?
> 
> bye Jochen
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
>> 
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3

[sospartan]

I'll remove whole playground sample app from artifacts innext release. So
#7 would be a problem anymore.
As the gradle wrapper will be removed too. I'll suggest use installed
gradle to create that. These will be put in new "how to build from source"
doc in root folder.
Pierre Smits 于2017年5月5日 周五下午6:32写道：

> 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 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Fri, May 5, 2017 at 12:25 PM, Pierre Smits 
> 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 

Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3

[Pierre Smits]

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 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Fri, May 5, 2017 at 12:25 PM, Pierre Smits 
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 

Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC3

[Pierre Smits]

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 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Fri, May 5, 2017 at 3:57 AM, sospartan  wrote:

> Taylor,
> Can you point out which objections you are agreed exactly?
>
>
>
> On Fri, May 5, 2017 at 9:31 AM, P. Taylor Goetz  wrote:
>
> > Apologies for the auto correct.
> >
> > Please sub "Niclas" for "Nicolas".
> >
> > -Taylor
> >
> > > On May 4, 2017, at 8:43 PM, P. Taylor Goetz  wrote:
> > >
> > > Nicolas,
> > >
> > > I 

Re: Generating contents for LICENSE, NOTICE for hawq incubating binary release

[Ruilong Huo]

Thanks John for the feedback!

It is reasonable that the LICENSE and NOTICE files for src and binary
tarball should be in separate locations.

Yes, our release with rpm package has the same contents as binary tarball.​