You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@asterixdb.apache.org by Ahmed Eldawy <el...@cs.ucr.edu> on 2017/07/11 16:39:54 UTC
Re: License issue when using esri geometry api
There's a good news. Riyafa has opened an issue on ESRI Geometry API
project on Github about the license problem and they made the necessary
changes to remove the bad dependency.
https://github.com/Esri/geometry-api-java/issues/135
The changes are on their github repository but they are not released yet. I
think we can just continue what we're doing and wait for the new release to
hit Maven repository.
Thanks
Ahmed
On Mon, Jun 26, 2017 at 7:55 AM, Mike Carey <dt...@gmail.com> wrote:
> It sounds like the best option is 4 minus parsing, then, if we can do
> that. (Which would also address Wail's comments, which could be a killer
> for big data eventually.) If not, we could go with 2 for the summer as a
> first step, I guess? (But figuring out the feasibility of 4 would be
> great...)
>
> Cheers,
>
> Mike
>
>
>
> On 6/26/17 2:59 AM, Ahmed Eldawy wrote:
>
>> It seems that (3) would require modifying the open source Esri API library
>> which I don't like. Not only for the overhead of understanding and
>> modifying the code, but also for deviating from the standard library which
>> means we will miss future updates. One of the reasons we chose to use Esri
>> API is the hope that it will be well-maintained in the future.
>> This leaves us with (4). I don't know if it is technically possible to
>> depend on the standard Esri API without using the non-compliant library or
>> not. If this is possible, then we can just use the computational geometry
>> (CG) functionality from the library, and provide our own GeoJSON parser.
>> If
>> this is not possible, then I would rather consider the use of another
>> library, e.g., JTS.
>>
>>
>> Thanks
>> Ahmed
>>
>> On Sun, Jun 25, 2017 at 11:47 AM, Wail Alkowaileet <wa...@gmail.com>
>> wrote:
>>
>> I can see from the code that there is a serder steps as such: Asterix
>>> Object (binary) --> JSON (String) --> Esri geometry (Java object) -->
>>> Esri
>>> geometry (binary).
>>> I think it would be nice if there is a binary-to-binary conversion
>>> without
>>> any deserialization (4th option).
>>>
>>> On Sun, Jun 25, 2017 at 6:36 PM, Mike Carey <dt...@gmail.com> wrote:
>>>
>>> Agreed that 3 or 4 are what we'll need to do....! (Sigh.)
>>>>
>>>>
>>>>
>>>> On 6/25/17 5:57 AM, Till Westmann wrote:
>>>>
>>>> Hi Riyafa,
>>>>>
>>>>> I think that the problem is bigger than the failing test. The JSON
>>>>> license itself is not acceptable for inclusion in an Apache artifact
>>>>> [4]. So we cannot use the ESRI API as-is, if we want the GeoJSON
>>>>> functionality be a non-optional part of AsterixDB.
>>>>>
>>>>> Here are a few options I see:
>>>>> 1) Make GeoJSON an optional part of AsterixDB (separate download from a
>>>>> non-Apache location).
>>>>> 2) Make JSON.org a dependency that is not shipped (i.e. each user would
>>>>> have to download and install those jars separately - and get error
>>>>> messages if the jars are not available).
>>>>> 3) Create a clone/copy of the ESRI API that uses another JSON library.
>>>>> 4) Do all of the parsing independently from the ESRI API.
>>>>>
>>>>> I’m not sure if 1) is a good option as the extensibility in this part
>>>>> of the code might not be sufficient to support this option easily.
>>>>> 2) is technically easier, but it involves an unpleasant user
>>>>> experience.
>>>>> Also, I think that both 1) and 2) are not desirable, as GeoJSON should
>>>>> be supported by vanilla AsterixDB.
>>>>> For 3) and 4) we would need to look into the details to see how much
>>>>> work is required for each of those options and if there are other legal
>>>>> hurdles.
>>>>>
>>>>> Are there other options?
>>>>> Other thoughts/concerns?
>>>>>
>>>>> Cheers,
>>>>> Till
>>>>>
>>>>> [4] https://www.apache.org/legal/resolved.html#category-x
>>>>>
>>>>> On 25 Jun 2017, at 13:57, Riyafa Abdul Hameed wrote:
>>>>>
>>>>> Dear all,
>>>>>
>>>>>> I implemented parse_geojon() function[1] using esri-geometry api[2]
>>>>>>
>>>>> which
>>>
>>>> is apache-2.0 licensed. But this api uses org.json as a dependency.
>>>>>> org.json is licensed under JSON which causes a license issue in the
>>>>>>
>>>>> code
>>>
>>>> I
>>>>>> have written[3]. What can I do about this issue?
>>>>>>
>>>>>> [1] https://asterix-gerrit.ics.uci.edu/1838
>>>>>> [2]https://github.com/Esri/geometry-api-java
>>>>>> [3]
>>>>>> https://asterix-jenkins.ics.uci.edu/job/asterix-gerrit-integ
>>>>>> ration-tests/3290/
>>>>>>
>>>>>> Thank you.
>>>>>> Yours sincerely,
>>>>>> Riyafa
>>>>>>
>>>>>>
>>> --
>>>
>>> *Regards,*
>>> Wail Alkowaileet
>>>
>>>
>
--
Ahmed Eldawy
Assistant Professor
Computer Science and Engineering
http://www.cs.ucr.edu/~eldawy
Tel: +1 (951) 827-5654
Re: License issue when using esri geometry api
Posted by Till Westmann <ti...@apache.org>.
Indeed, that’s very good news.
Cheers,
Till
On 4 Sep 2017, at 8:37, Mike Carey wrote:
> Nice!
>
>
> On 9/3/17 11:44 PM, Riyafa Abdul Hameed wrote:
>> Hi,
>>
>> Esri geometry-api version 2.0.0 have been released in maven
>> central[1]. Now
>> I am able to use it without any license issues[2].
>>
>> [1] https://github.com/Esri/geometry-api-java/issues/140
>> [2] https://asterix-gerrit.ics.uci.edu/#/c/1838
>>
>> Thank you.
>> Sincerely,
>> Riyafa
>>
>> On 30 July 2017 at 07:58, Riyafa Abdul Hameed
>> <ri...@cse.mrt.ac.lk>
>> wrote:
>>
>>> Hi Till,
>>>
>>> Thank you. You seem to have followed the option 2). I didn't
>>> understand
>>> how to get along with option 1). I wanted to ask with Ahmed about it
>>> and
>>> get back.
>>> I have no idea when they will release so I asked a question[1]
>>> though I
>>> didn't get an answer for that.
>>>
>>> Thank you.
>>> Sincerely,
>>> Riyafa
>>>
>>> [1] https://github.com/Esri/geometry-api-java/issues/140
>>>
>>> On 29 July 2017 at 10:58, Till Westmann <ti...@apache.org> wrote:
>>>
>>>> Hi Riyafa,
>>>>
>>>> I’ve uploaded another commit to your change [4] that shows what
>>>> option 2)
>>>> would look like.
>>>> Please take a look and see what you think.
>>>> I think that this could only be a temporary solution.
>>>> Do you have an idea, when Esri might publish a new version of the
>>>> API?
>>>>
>>>> Cheers,
>>>> Till
>>>>
>>>> [4] https://asterix-gerrit.ics.uci.edu/#/c/1895
>>>>
>>>>
>>>> On 27 Jul 2017, at 10:13, Mike Carey wrote:
>>>>
>>>> +1 on option 1 for now, I would say (from afar :-)), until ESRI
>>>> finishes
>>>>> resolving stuff on their end.
>>>>>
>>>>> Aloha,
>>>>>
>>>>> Mike
>>>>>
>>>>>
>>>>> On 7/27/17 6:23 AM, Till Westmann wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I’m sorry for the late reply on the subject.
>>>>>>
>>>>>> Generally, Apache-releases are source releases [3] and so adding
>>>>>> a
>>>>>> precompiled jar without sources would prevent us from being able
>>>>>> to
>>>>>> release AsterixDB. So we will have to find another solution.
>>>>>>
>>>>>> A few options that I can think of right now would be to
>>>>>> 1) make it an optional dependency and require the user to
>>>>>> require/obtain the jar external and to provide it to the platform
>>>>>> that
>>>>>> they build on or to
>>>>>> 2) include the source files in the AsterixDB source repository or
>>>>>> to
>>>>>> 3) download and build the source as part of the build process.
>>>>>>
>>>>>> Of these 3 options, I think that 1) is the cleanest option from a
>>>>>> licensing perspective, 2) can be managed if we understand the
>>>>>> provenance of the source files and 3) seems problematic as we
>>>>>> would put
>>>>>> a load on a system that provide the source for every build and as
>>>>>> we
>>>>>> could retrieve use unvetted source code.
>>>>>>
>>>>>> Thoughts/concerns about these options?
>>>>>> Does anybody see other options?
>>>>>>
>>>>>> Cheers,
>>>>>> Till
>>>>>>
>>>>>> [3] http://www.apache.org/legal/release-policy.html#artifacts
>>>>>>
>>>>>> On 27 Jul 2017, at 7:21, Riyafa Abdul Hameed wrote:
>>>>>>
>>>>>> Dear all,
>>>>>>> Is there a way to ship a jar file as a dependency for AsterixDB
>>>>>>> apart
>>>>>>> from
>>>>>>> the method I have used here[1]. This is because the build of
>>>>>>> asterix-app
>>>>>>> seems to fail[2] when I use the external jar file like this.
>>>>>>> Though I am unable to find a connection between the failure and
>>>>>>> the
>>>>>>> dependency it seems I need to assume that it is the cause,
>>>>>>> because
>>>>>>> otherwise if I use the Maven-released version the build passes
>>>>>>> without
>>>>>>> issue.
>>>>>>>
>>>>>>> Any help would be highly appreciated.
>>>>>>> [1]
>>>>>>> https://asterix-gerrit.ics.uci.edu/#/c/1895/3/asterixdb/aste
>>>>>>> rix-om/pom.xml
>>>>>>> [2] https://asterix-gerrit.ics.uci.edu/#/c/1895
>>>>>>>
>>>>>>> On 22 July 2017 at 01:59, Ahmed Eldawy <el...@cs.ucr.edu>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Although Esri resolved the issue, their Maven-released version
>>>>>>> still
>>>>>>>> relies
>>>>>>>> on the incompatible library. We can wait until they release a
>>>>>>>> new
>>>>>>>> version
>>>>>>>> on Maven but this might take a while. To be able to merge the
>>>>>>>> current
>>>>>>>> code,
>>>>>>>> we might need to compile our own JAR file and ship it with the
>>>>>>>> source
>>>>>>>> code.
>>>>>>>> Do you know if this is possible/allowed/recommended in
>>>>>>>> AsterixDB? Is
>>>>>>>> there
>>>>>>>> another preferred way to handle this issue? Keep in mind that,
>>>>>>>> most
>>>>>>>> likely,
>>>>>>>> the summer project will conclude before Esri releases the new
>>>>>>>> version.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Ahmed
>>>>>>>>
>>>>>>>> On Tue, Jul 11, 2017 at 11:04 AM, Mike Carey
>>>>>>>> <dt...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> NICE!!!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 7/11/17 9:39 AM, Ahmed Eldawy wrote:
>>>>>>>>>
>>>>>>>>> There's a good news. Riyafa has opened an issue on ESRI
>>>>>>>>> Geometry API
>>>>>>>>>> project on Github about the license problem and they made the
>>>>>>>>>> necessary
>>>>>>>>>> changes to remove the bad dependency.
>>>>>>>>>> https://github.com/Esri/geometry-api-java/issues/135
>>>>>>>>>> The changes are on their github repository but they are not
>>>>>>>>>> released
>>>>>>>>>>
>>>>>>>>> yet.
>>>>>>>>> I
>>>>>>>>>> think we can just continue what we're doing and wait for the
>>>>>>>>>> new
>>>>>>>>>> release
>>>>>>>>>> to
>>>>>>>>>> hit Maven repository.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Ahmed
>>>>>>>>>>
>>>>>>>>>> On Mon, Jun 26, 2017 at 7:55 AM, Mike Carey
>>>>>>>>>> <dt...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> It sounds like the best option is 4 minus parsing, then, if
>>>>>>>>>> we can
>>>>>>>>>> do
>>>>>>>>>>
>>>>>>>>>>> that. (Which would also address Wail's comments, which
>>>>>>>>>>> could be a
>>>>>>>>>>>
>>>>>>>>>> killer
>>>>>>>>> for big data eventually.) If not, we could go with 2 for the
>>>>>>>>> summer
>>>>>>>>>> as a
>>>>>>>>> first step, I guess? (But figuring out the feasibility of 4
>>>>>>>>> would be
>>>>>>>>>>> great...)
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>>
>>>>>>>>>>> Mike
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 6/26/17 2:59 AM, Ahmed Eldawy wrote:
>>>>>>>>>>>
>>>>>>>>>>> It seems that (3) would require modifying the open source
>>>>>>>>>>> Esri API
>>>>>>>>>>>
>>>>>>>>>>>> library
>>>>>>>>>>>> which I don't like. Not only for the overhead of
>>>>>>>>>>>> understanding and
>>>>>>>>>>>> modifying the code, but also for deviating from the
>>>>>>>>>>>> standard
>>>>>>>>>>>> library
>>>>>>>>>>>> which
>>>>>>>>>>>> means we will miss future updates. One of the reasons we
>>>>>>>>>>>> chose to
>>>>>>>>>>>> use
>>>>>>>>>>>> Esri
>>>>>>>>>>>> API is the hope that it will be well-maintained in the
>>>>>>>>>>>> future.
>>>>>>>>>>>> This leaves us with (4). I don't know if it is technically
>>>>>>>>>>>> possible to
>>>>>>>>>>>> depend on the standard Esri API without using the
>>>>>>>>>>>> non-compliant
>>>>>>>>>>>>
>>>>>>>>>>> library
>>>>>>>>> or
>>>>>>>>>>>> not. If this is possible, then we can just use the
>>>>>>>>>>>> computational
>>>>>>>>>>>> geometry
>>>>>>>>>>>> (CG) functionality from the library, and provide our own
>>>>>>>>>>>> GeoJSON
>>>>>>>>>>>>
>>>>>>>>>>> parser.
>>>>>>>>> If
>>>>>>>>>>>> this is not possible, then I would rather consider the use
>>>>>>>>>>>> of
>>>>>>>>>>>> another
>>>>>>>>>>>> library, e.g., JTS.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Ahmed
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Jun 25, 2017 at 11:47 AM, Wail Alkowaileet <
>>>>>>>>>>>>
>>>>>>>>>>> wael.y.k@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>>> I can see from the code that there is a serder steps as
>>>>>>>>>>>> such:
>>>>>>>>>>>> Asterix
>>>>>>>>>>>>
>>>>>>>>>>>> Object (binary) --> JSON (String) --> Esri geometry (Java
>>>>>>>>>>>> object)
>>>>>>>>>>>>> -->
>>>>>>>>>>>>> Esri
>>>>>>>>>>>>> geometry (binary).
>>>>>>>>>>>>> I think it would be nice if there is a binary-to-binary
>>>>>>>>>>>>> conversion
>>>>>>>>>>>>> without
>>>>>>>>>>>>> any deserialization (4th option).
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Jun 25, 2017 at 6:36 PM, Mike Carey
>>>>>>>>>>>>> <dt...@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> Agreed that 3 or 4 are what we'll need to do....! (Sigh.)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 6/25/17 5:57 AM, Till Westmann wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Riyafa,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think that the problem is bigger than the failing test.
>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>> JSON
>>>>>>>>>>>>>>> license itself is not acceptable for inclusion in an
>>>>>>>>>>>>>>> Apache
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> artifact
>>>>>>>>> [4]. So we cannot use the ESRI API as-is, if we want the
>>>>>>>>> GeoJSON
>>>>>>>>>>>>>>> functionality be a non-optional part of AsterixDB.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Here are a few options I see:
>>>>>>>>>>>>>>> 1) Make GeoJSON an optional part of AsterixDB (separate
>>>>>>>>>>>>>>> download
>>>>>>>>>>>>>>> from a
>>>>>>>>>>>>>>> non-Apache location).
>>>>>>>>>>>>>>> 2) Make JSON.org a dependency that is not shipped (i.e.
>>>>>>>>>>>>>>> each
>>>>>>>>>>>>>>> user
>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>> have to download and install those jars separately
>>>>>>>>>>>>>>> - and
>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>> error
>>>>>>>>>>>>>>> messages if the jars are not available).
>>>>>>>>>>>>>>> 3) Create a clone/copy of the ESRI API that uses another
>>>>>>>>>>>>>>> JSON
>>>>>>>>>>>>>>> library.
>>>>>>>>>>>>>>> 4) Do all of the parsing independently from the ESRI
>>>>>>>>>>>>>>> API.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I’m not sure if 1) is a good option as the
>>>>>>>>>>>>>>> extensibility in
>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> part
>>>>>>>>> of the code might not be sufficient to support this option
>>>>>>>>> easily.
>>>>>>>>>>>>>>> 2) is technically easier, but it involves an unpleasant
>>>>>>>>>>>>>>> user
>>>>>>>>>>>>>>> experience.
>>>>>>>>>>>>>>> Also, I think that both 1) and 2) are not desirable, as
>>>>>>>>>>>>>>> GeoJSON
>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>> be supported by vanilla AsterixDB.
>>>>>>>>>>>>>>> For 3) and 4) we would need to look into the details to
>>>>>>>>>>>>>>> see how
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> much
>>>>>>>>> work is required for each of those options and if there are
>>>>>>>>> other
>>>>>>>>>>>>>>> legal
>>>>>>>>>>>>>>> hurdles.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Are there other options?
>>>>>>>>>>>>>>> Other thoughts/concerns?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>> Till
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [4]
>>>>>>>>>>>>>>> https://www.apache.org/legal/resolved.html#category-x
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 25 Jun 2017, at 13:57, Riyafa Abdul Hameed wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Dear all,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I implemented parse_geojon() function[1] using
>>>>>>>>>>>>>>> esri-geometry
>>>>>>>>>>>>>>> api[2]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> is apache-2.0 licensed. But this api uses org.json as a
>>>>>>>>>>>>>> dependency.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> org.json is licensed under JSON which causes a license
>>>>>>>>>>>>>> issue in
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>> have written[3]. What can I do about this issue?
>>>>>>>>>>>>>>>> [1] https://asterix-gerrit.ics.uci.edu/1838
>>>>>>>>>>>>>>>> [2]https://github.com/Esri/geometry-api-java
>>>>>>>>>>>>>>>> [3]
>>>>>>>>>>>>>>>> https://asterix-jenkins.ics.uci.edu/job/asterix-gerrit-integ
>>>>>>>>>>>>>>>> ration-tests/3290/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thank you.
>>>>>>>>>>>>>>>> Yours sincerely,
>>>>>>>>>>>>>>>> Riyafa
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> *Regards,*
>>>>>>>>>>>>> Wail Alkowaileet
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Ahmed Eldawy
>>>>>>>> Assistant Professor
>>>>>>>> http://www.cs.ucr.edu/~eldawy
>>>>>>>> Tel: +1 (951) 827-5654
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Riyafa Abdul Hameed
>>>>>>> Undergraduate, University of Moratuwa
>>>>>>>
>>>>>>> Email: riyafa.12@cse.mrt.ac.lk
>>>>>>> Website: https://riyafa.wordpress.com/
>>>>>>> <http://riyafa.wordpress.com/>
>>>>>>> <http://facebook.com/riyafa.ahf>
>>>>>>> <http://lk.linkedin.com/in/riyafa>
>>>>>>> <http://twitter.com/Riyafa1>
>>>>>>>
>>>
>>> --
>>> Riyafa Abdul Hameed
>>> Undergraduate, University of Moratuwa
>>>
>>> Email: riyafa.12@cse.mrt.ac.lk
>>> Website: https://riyafa.wordpress.com/
>>> <http://riyafa.wordpress.com/>
>>> <http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa>
>>> <http://twitter.com/Riyafa1>
>>>
>>
>>
Re: License issue when using esri geometry api
Posted by Mike Carey <dt...@gmail.com>.
Nice!
On 9/3/17 11:44 PM, Riyafa Abdul Hameed wrote:
> Hi,
>
> Esri geometry-api version 2.0.0 have been released in maven central[1]. Now
> I am able to use it without any license issues[2].
>
> [1] https://github.com/Esri/geometry-api-java/issues/140
> [2] https://asterix-gerrit.ics.uci.edu/#/c/1838
>
> Thank you.
> Sincerely,
> Riyafa
>
> On 30 July 2017 at 07:58, Riyafa Abdul Hameed <ri...@cse.mrt.ac.lk>
> wrote:
>
>> Hi Till,
>>
>> Thank you. You seem to have followed the option 2). I didn't understand
>> how to get along with option 1). I wanted to ask with Ahmed about it and
>> get back.
>> I have no idea when they will release so I asked a question[1] though I
>> didn't get an answer for that.
>>
>> Thank you.
>> Sincerely,
>> Riyafa
>>
>> [1] https://github.com/Esri/geometry-api-java/issues/140
>>
>> On 29 July 2017 at 10:58, Till Westmann <ti...@apache.org> wrote:
>>
>>> Hi Riyafa,
>>>
>>> I’ve uploaded another commit to your change [4] that shows what option 2)
>>> would look like.
>>> Please take a look and see what you think.
>>> I think that this could only be a temporary solution.
>>> Do you have an idea, when Esri might publish a new version of the API?
>>>
>>> Cheers,
>>> Till
>>>
>>> [4] https://asterix-gerrit.ics.uci.edu/#/c/1895
>>>
>>>
>>> On 27 Jul 2017, at 10:13, Mike Carey wrote:
>>>
>>> +1 on option 1 for now, I would say (from afar :-)), until ESRI finishes
>>>> resolving stuff on their end.
>>>>
>>>> Aloha,
>>>>
>>>> Mike
>>>>
>>>>
>>>> On 7/27/17 6:23 AM, Till Westmann wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I’m sorry for the late reply on the subject.
>>>>>
>>>>> Generally, Apache-releases are source releases [3] and so adding a
>>>>> precompiled jar without sources would prevent us from being able to
>>>>> release AsterixDB. So we will have to find another solution.
>>>>>
>>>>> A few options that I can think of right now would be to
>>>>> 1) make it an optional dependency and require the user to
>>>>> require/obtain the jar external and to provide it to the platform that
>>>>> they build on or to
>>>>> 2) include the source files in the AsterixDB source repository or to
>>>>> 3) download and build the source as part of the build process.
>>>>>
>>>>> Of these 3 options, I think that 1) is the cleanest option from a
>>>>> licensing perspective, 2) can be managed if we understand the
>>>>> provenance of the source files and 3) seems problematic as we would put
>>>>> a load on a system that provide the source for every build and as we
>>>>> could retrieve use unvetted source code.
>>>>>
>>>>> Thoughts/concerns about these options?
>>>>> Does anybody see other options?
>>>>>
>>>>> Cheers,
>>>>> Till
>>>>>
>>>>> [3] http://www.apache.org/legal/release-policy.html#artifacts
>>>>>
>>>>> On 27 Jul 2017, at 7:21, Riyafa Abdul Hameed wrote:
>>>>>
>>>>> Dear all,
>>>>>> Is there a way to ship a jar file as a dependency for AsterixDB apart
>>>>>> from
>>>>>> the method I have used here[1]. This is because the build of
>>>>>> asterix-app
>>>>>> seems to fail[2] when I use the external jar file like this.
>>>>>> Though I am unable to find a connection between the failure and the
>>>>>> dependency it seems I need to assume that it is the cause, because
>>>>>> otherwise if I use the Maven-released version the build passes without
>>>>>> issue.
>>>>>>
>>>>>> Any help would be highly appreciated.
>>>>>> [1]
>>>>>> https://asterix-gerrit.ics.uci.edu/#/c/1895/3/asterixdb/aste
>>>>>> rix-om/pom.xml
>>>>>> [2] https://asterix-gerrit.ics.uci.edu/#/c/1895
>>>>>>
>>>>>> On 22 July 2017 at 01:59, Ahmed Eldawy <el...@cs.ucr.edu> wrote:
>>>>>>
>>>>>> Although Esri resolved the issue, their Maven-released version still
>>>>>>> relies
>>>>>>> on the incompatible library. We can wait until they release a new
>>>>>>> version
>>>>>>> on Maven but this might take a while. To be able to merge the current
>>>>>>> code,
>>>>>>> we might need to compile our own JAR file and ship it with the source
>>>>>>> code.
>>>>>>> Do you know if this is possible/allowed/recommended in AsterixDB? Is
>>>>>>> there
>>>>>>> another preferred way to handle this issue? Keep in mind that, most
>>>>>>> likely,
>>>>>>> the summer project will conclude before Esri releases the new version.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Ahmed
>>>>>>>
>>>>>>> On Tue, Jul 11, 2017 at 11:04 AM, Mike Carey <dt...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> NICE!!!
>>>>>>>>
>>>>>>>>
>>>>>>>> On 7/11/17 9:39 AM, Ahmed Eldawy wrote:
>>>>>>>>
>>>>>>>> There's a good news. Riyafa has opened an issue on ESRI Geometry API
>>>>>>>>> project on Github about the license problem and they made the
>>>>>>>>> necessary
>>>>>>>>> changes to remove the bad dependency.
>>>>>>>>> https://github.com/Esri/geometry-api-java/issues/135
>>>>>>>>> The changes are on their github repository but they are not released
>>>>>>>>>
>>>>>>>> yet.
>>>>>>>> I
>>>>>>>>> think we can just continue what we're doing and wait for the new
>>>>>>>>> release
>>>>>>>>> to
>>>>>>>>> hit Maven repository.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Ahmed
>>>>>>>>>
>>>>>>>>> On Mon, Jun 26, 2017 at 7:55 AM, Mike Carey <dt...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> It sounds like the best option is 4 minus parsing, then, if we can
>>>>>>>>> do
>>>>>>>>>
>>>>>>>>>> that. (Which would also address Wail's comments, which could be a
>>>>>>>>>>
>>>>>>>>> killer
>>>>>>>> for big data eventually.) If not, we could go with 2 for the summer
>>>>>>>>> as a
>>>>>>>> first step, I guess? (But figuring out the feasibility of 4 would be
>>>>>>>>>> great...)
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>>
>>>>>>>>>> Mike
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 6/26/17 2:59 AM, Ahmed Eldawy wrote:
>>>>>>>>>>
>>>>>>>>>> It seems that (3) would require modifying the open source Esri API
>>>>>>>>>>
>>>>>>>>>>> library
>>>>>>>>>>> which I don't like. Not only for the overhead of understanding and
>>>>>>>>>>> modifying the code, but also for deviating from the standard
>>>>>>>>>>> library
>>>>>>>>>>> which
>>>>>>>>>>> means we will miss future updates. One of the reasons we chose to
>>>>>>>>>>> use
>>>>>>>>>>> Esri
>>>>>>>>>>> API is the hope that it will be well-maintained in the future.
>>>>>>>>>>> This leaves us with (4). I don't know if it is technically
>>>>>>>>>>> possible to
>>>>>>>>>>> depend on the standard Esri API without using the non-compliant
>>>>>>>>>>>
>>>>>>>>>> library
>>>>>>>> or
>>>>>>>>>>> not. If this is possible, then we can just use the computational
>>>>>>>>>>> geometry
>>>>>>>>>>> (CG) functionality from the library, and provide our own GeoJSON
>>>>>>>>>>>
>>>>>>>>>> parser.
>>>>>>>> If
>>>>>>>>>>> this is not possible, then I would rather consider the use of
>>>>>>>>>>> another
>>>>>>>>>>> library, e.g., JTS.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Ahmed
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Jun 25, 2017 at 11:47 AM, Wail Alkowaileet <
>>>>>>>>>>>
>>>>>>>>>> wael.y.k@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>>> I can see from the code that there is a serder steps as such:
>>>>>>>>>>> Asterix
>>>>>>>>>>>
>>>>>>>>>>> Object (binary) --> JSON (String) --> Esri geometry (Java object)
>>>>>>>>>>>> -->
>>>>>>>>>>>> Esri
>>>>>>>>>>>> geometry (binary).
>>>>>>>>>>>> I think it would be nice if there is a binary-to-binary
>>>>>>>>>>>> conversion
>>>>>>>>>>>> without
>>>>>>>>>>>> any deserialization (4th option).
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Jun 25, 2017 at 6:36 PM, Mike Carey <dt...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> Agreed that 3 or 4 are what we'll need to do....! (Sigh.)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On 6/25/17 5:57 AM, Till Westmann wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Riyafa,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think that the problem is bigger than the failing test. The
>>>>>>>>>>>>>> JSON
>>>>>>>>>>>>>> license itself is not acceptable for inclusion in an Apache
>>>>>>>>>>>>>>
>>>>>>>>>>>>> artifact
>>>>>>>> [4]. So we cannot use the ESRI API as-is, if we want the GeoJSON
>>>>>>>>>>>>>> functionality be a non-optional part of AsterixDB.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Here are a few options I see:
>>>>>>>>>>>>>> 1) Make GeoJSON an optional part of AsterixDB (separate
>>>>>>>>>>>>>> download
>>>>>>>>>>>>>> from a
>>>>>>>>>>>>>> non-Apache location).
>>>>>>>>>>>>>> 2) Make JSON.org a dependency that is not shipped (i.e. each
>>>>>>>>>>>>>> user
>>>>>>>>>>>>>> would
>>>>>>>>>>>>>> have to download and install those jars separately - and
>>>>>>>>>>>>>> get
>>>>>>>>>>>>>> error
>>>>>>>>>>>>>> messages if the jars are not available).
>>>>>>>>>>>>>> 3) Create a clone/copy of the ESRI API that uses another JSON
>>>>>>>>>>>>>> library.
>>>>>>>>>>>>>> 4) Do all of the parsing independently from the ESRI API.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I’m not sure if 1) is a good option as the extensibility in
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>
>>>>>>>>>>>>> part
>>>>>>>> of the code might not be sufficient to support this option easily.
>>>>>>>>>>>>>> 2) is technically easier, but it involves an unpleasant user
>>>>>>>>>>>>>> experience.
>>>>>>>>>>>>>> Also, I think that both 1) and 2) are not desirable, as GeoJSON
>>>>>>>>>>>>>> should
>>>>>>>>>>>>>> be supported by vanilla AsterixDB.
>>>>>>>>>>>>>> For 3) and 4) we would need to look into the details to see how
>>>>>>>>>>>>>>
>>>>>>>>>>>>> much
>>>>>>>> work is required for each of those options and if there are other
>>>>>>>>>>>>>> legal
>>>>>>>>>>>>>> hurdles.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Are there other options?
>>>>>>>>>>>>>> Other thoughts/concerns?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>> Till
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [4] https://www.apache.org/legal/resolved.html#category-x
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 25 Jun 2017, at 13:57, Riyafa Abdul Hameed wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Dear all,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I implemented parse_geojon() function[1] using esri-geometry
>>>>>>>>>>>>>> api[2]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> is apache-2.0 licensed. But this api uses org.json as a
>>>>>>>>>>>>> dependency.
>>>>>>>>>>>>>
>>>>>>>>>>>>> org.json is licensed under JSON which causes a license issue in
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I
>>>>>>>>>>>>> have written[3]. What can I do about this issue?
>>>>>>>>>>>>>>> [1] https://asterix-gerrit.ics.uci.edu/1838
>>>>>>>>>>>>>>> [2]https://github.com/Esri/geometry-api-java
>>>>>>>>>>>>>>> [3]
>>>>>>>>>>>>>>> https://asterix-jenkins.ics.uci.edu/job/asterix-gerrit-integ
>>>>>>>>>>>>>>> ration-tests/3290/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank you.
>>>>>>>>>>>>>>> Yours sincerely,
>>>>>>>>>>>>>>> Riyafa
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>
>>>>>>>>>>>> *Regards,*
>>>>>>>>>>>> Wail Alkowaileet
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Ahmed Eldawy
>>>>>>> Assistant Professor
>>>>>>> http://www.cs.ucr.edu/~eldawy
>>>>>>> Tel: +1 (951) 827-5654
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Riyafa Abdul Hameed
>>>>>> Undergraduate, University of Moratuwa
>>>>>>
>>>>>> Email: riyafa.12@cse.mrt.ac.lk
>>>>>> Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/>
>>>>>> <http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa>
>>>>>> <http://twitter.com/Riyafa1>
>>>>>>
>>
>> --
>> Riyafa Abdul Hameed
>> Undergraduate, University of Moratuwa
>>
>> Email: riyafa.12@cse.mrt.ac.lk
>> Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/>
>> <http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa>
>> <http://twitter.com/Riyafa1>
>>
>
>
Re: License issue when using esri geometry api
Posted by Riyafa Abdul Hameed <ri...@cse.mrt.ac.lk>.
Hi,
Esri geometry-api version 2.0.0 have been released in maven central[1]. Now
I am able to use it without any license issues[2].
[1] https://github.com/Esri/geometry-api-java/issues/140
[2] https://asterix-gerrit.ics.uci.edu/#/c/1838
Thank you.
Sincerely,
Riyafa
On 30 July 2017 at 07:58, Riyafa Abdul Hameed <ri...@cse.mrt.ac.lk>
wrote:
> Hi Till,
>
> Thank you. You seem to have followed the option 2). I didn't understand
> how to get along with option 1). I wanted to ask with Ahmed about it and
> get back.
> I have no idea when they will release so I asked a question[1] though I
> didn't get an answer for that.
>
> Thank you.
> Sincerely,
> Riyafa
>
> [1] https://github.com/Esri/geometry-api-java/issues/140
>
> On 29 July 2017 at 10:58, Till Westmann <ti...@apache.org> wrote:
>
>> Hi Riyafa,
>>
>> I’ve uploaded another commit to your change [4] that shows what option 2)
>> would look like.
>> Please take a look and see what you think.
>> I think that this could only be a temporary solution.
>> Do you have an idea, when Esri might publish a new version of the API?
>>
>> Cheers,
>> Till
>>
>> [4] https://asterix-gerrit.ics.uci.edu/#/c/1895
>>
>>
>> On 27 Jul 2017, at 10:13, Mike Carey wrote:
>>
>> +1 on option 1 for now, I would say (from afar :-)), until ESRI finishes
>>> resolving stuff on their end.
>>>
>>> Aloha,
>>>
>>> Mike
>>>
>>>
>>> On 7/27/17 6:23 AM, Till Westmann wrote:
>>>
>>>> Hi,
>>>>
>>>> I’m sorry for the late reply on the subject.
>>>>
>>>> Generally, Apache-releases are source releases [3] and so adding a
>>>> precompiled jar without sources would prevent us from being able to
>>>> release AsterixDB. So we will have to find another solution.
>>>>
>>>> A few options that I can think of right now would be to
>>>> 1) make it an optional dependency and require the user to
>>>> require/obtain the jar external and to provide it to the platform that
>>>> they build on or to
>>>> 2) include the source files in the AsterixDB source repository or to
>>>> 3) download and build the source as part of the build process.
>>>>
>>>> Of these 3 options, I think that 1) is the cleanest option from a
>>>> licensing perspective, 2) can be managed if we understand the
>>>> provenance of the source files and 3) seems problematic as we would put
>>>> a load on a system that provide the source for every build and as we
>>>> could retrieve use unvetted source code.
>>>>
>>>> Thoughts/concerns about these options?
>>>> Does anybody see other options?
>>>>
>>>> Cheers,
>>>> Till
>>>>
>>>> [3] http://www.apache.org/legal/release-policy.html#artifacts
>>>>
>>>> On 27 Jul 2017, at 7:21, Riyafa Abdul Hameed wrote:
>>>>
>>>> Dear all,
>>>>>
>>>>> Is there a way to ship a jar file as a dependency for AsterixDB apart
>>>>> from
>>>>> the method I have used here[1]. This is because the build of
>>>>> asterix-app
>>>>> seems to fail[2] when I use the external jar file like this.
>>>>> Though I am unable to find a connection between the failure and the
>>>>> dependency it seems I need to assume that it is the cause, because
>>>>> otherwise if I use the Maven-released version the build passes without
>>>>> issue.
>>>>>
>>>>> Any help would be highly appreciated.
>>>>> [1]
>>>>> https://asterix-gerrit.ics.uci.edu/#/c/1895/3/asterixdb/aste
>>>>> rix-om/pom.xml
>>>>> [2] https://asterix-gerrit.ics.uci.edu/#/c/1895
>>>>>
>>>>> On 22 July 2017 at 01:59, Ahmed Eldawy <el...@cs.ucr.edu> wrote:
>>>>>
>>>>> Although Esri resolved the issue, their Maven-released version still
>>>>>> relies
>>>>>> on the incompatible library. We can wait until they release a new
>>>>>> version
>>>>>> on Maven but this might take a while. To be able to merge the current
>>>>>> code,
>>>>>> we might need to compile our own JAR file and ship it with the source
>>>>>> code.
>>>>>> Do you know if this is possible/allowed/recommended in AsterixDB? Is
>>>>>> there
>>>>>> another preferred way to handle this issue? Keep in mind that, most
>>>>>> likely,
>>>>>> the summer project will conclude before Esri releases the new version.
>>>>>>
>>>>>> Thanks
>>>>>> Ahmed
>>>>>>
>>>>>> On Tue, Jul 11, 2017 at 11:04 AM, Mike Carey <dt...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> NICE!!!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 7/11/17 9:39 AM, Ahmed Eldawy wrote:
>>>>>>>
>>>>>>> There's a good news. Riyafa has opened an issue on ESRI Geometry API
>>>>>>>> project on Github about the license problem and they made the
>>>>>>>> necessary
>>>>>>>> changes to remove the bad dependency.
>>>>>>>> https://github.com/Esri/geometry-api-java/issues/135
>>>>>>>> The changes are on their github repository but they are not released
>>>>>>>>
>>>>>>> yet.
>>>>>>
>>>>>>> I
>>>>>>>> think we can just continue what we're doing and wait for the new
>>>>>>>> release
>>>>>>>> to
>>>>>>>> hit Maven repository.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Ahmed
>>>>>>>>
>>>>>>>> On Mon, Jun 26, 2017 at 7:55 AM, Mike Carey <dt...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> It sounds like the best option is 4 minus parsing, then, if we can
>>>>>>>> do
>>>>>>>>
>>>>>>>>> that. (Which would also address Wail's comments, which could be a
>>>>>>>>>
>>>>>>>> killer
>>>>>>
>>>>>>> for big data eventually.) If not, we could go with 2 for the summer
>>>>>>>>>
>>>>>>>> as a
>>>>>>
>>>>>>> first step, I guess? (But figuring out the feasibility of 4 would be
>>>>>>>>> great...)
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>> Mike
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 6/26/17 2:59 AM, Ahmed Eldawy wrote:
>>>>>>>>>
>>>>>>>>> It seems that (3) would require modifying the open source Esri API
>>>>>>>>>
>>>>>>>>>> library
>>>>>>>>>> which I don't like. Not only for the overhead of understanding and
>>>>>>>>>> modifying the code, but also for deviating from the standard
>>>>>>>>>> library
>>>>>>>>>> which
>>>>>>>>>> means we will miss future updates. One of the reasons we chose to
>>>>>>>>>> use
>>>>>>>>>> Esri
>>>>>>>>>> API is the hope that it will be well-maintained in the future.
>>>>>>>>>> This leaves us with (4). I don't know if it is technically
>>>>>>>>>> possible to
>>>>>>>>>> depend on the standard Esri API without using the non-compliant
>>>>>>>>>>
>>>>>>>>> library
>>>>>>
>>>>>>> or
>>>>>>>>>> not. If this is possible, then we can just use the computational
>>>>>>>>>> geometry
>>>>>>>>>> (CG) functionality from the library, and provide our own GeoJSON
>>>>>>>>>>
>>>>>>>>> parser.
>>>>>>
>>>>>>> If
>>>>>>>>>> this is not possible, then I would rather consider the use of
>>>>>>>>>> another
>>>>>>>>>> library, e.g., JTS.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Ahmed
>>>>>>>>>>
>>>>>>>>>> On Sun, Jun 25, 2017 at 11:47 AM, Wail Alkowaileet <
>>>>>>>>>>
>>>>>>>>> wael.y.k@gmail.com>
>>>>>>
>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> I can see from the code that there is a serder steps as such:
>>>>>>>>>> Asterix
>>>>>>>>>>
>>>>>>>>>> Object (binary) --> JSON (String) --> Esri geometry (Java object)
>>>>>>>>>>> -->
>>>>>>>>>>> Esri
>>>>>>>>>>> geometry (binary).
>>>>>>>>>>> I think it would be nice if there is a binary-to-binary
>>>>>>>>>>> conversion
>>>>>>>>>>> without
>>>>>>>>>>> any deserialization (4th option).
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Jun 25, 2017 at 6:36 PM, Mike Carey <dt...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>>>>> Agreed that 3 or 4 are what we'll need to do....! (Sigh.)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 6/25/17 5:57 AM, Till Westmann wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Riyafa,
>>>>>>>>>>>>
>>>>>>>>>>>> I think that the problem is bigger than the failing test. The
>>>>>>>>>>>>> JSON
>>>>>>>>>>>>> license itself is not acceptable for inclusion in an Apache
>>>>>>>>>>>>>
>>>>>>>>>>>> artifact
>>>>>>
>>>>>>> [4]. So we cannot use the ESRI API as-is, if we want the GeoJSON
>>>>>>>>>>>>> functionality be a non-optional part of AsterixDB.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here are a few options I see:
>>>>>>>>>>>>> 1) Make GeoJSON an optional part of AsterixDB (separate
>>>>>>>>>>>>> download
>>>>>>>>>>>>> from a
>>>>>>>>>>>>> non-Apache location).
>>>>>>>>>>>>> 2) Make JSON.org a dependency that is not shipped (i.e. each
>>>>>>>>>>>>> user
>>>>>>>>>>>>> would
>>>>>>>>>>>>> have to download and install those jars separately - and
>>>>>>>>>>>>> get
>>>>>>>>>>>>> error
>>>>>>>>>>>>> messages if the jars are not available).
>>>>>>>>>>>>> 3) Create a clone/copy of the ESRI API that uses another JSON
>>>>>>>>>>>>> library.
>>>>>>>>>>>>> 4) Do all of the parsing independently from the ESRI API.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I’m not sure if 1) is a good option as the extensibility in
>>>>>>>>>>>>> this
>>>>>>>>>>>>>
>>>>>>>>>>>> part
>>>>>>
>>>>>>> of the code might not be sufficient to support this option easily.
>>>>>>>>>>>>> 2) is technically easier, but it involves an unpleasant user
>>>>>>>>>>>>> experience.
>>>>>>>>>>>>> Also, I think that both 1) and 2) are not desirable, as GeoJSON
>>>>>>>>>>>>> should
>>>>>>>>>>>>> be supported by vanilla AsterixDB.
>>>>>>>>>>>>> For 3) and 4) we would need to look into the details to see how
>>>>>>>>>>>>>
>>>>>>>>>>>> much
>>>>>>
>>>>>>> work is required for each of those options and if there are other
>>>>>>>>>>>>> legal
>>>>>>>>>>>>> hurdles.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Are there other options?
>>>>>>>>>>>>> Other thoughts/concerns?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Till
>>>>>>>>>>>>>
>>>>>>>>>>>>> [4] https://www.apache.org/legal/resolved.html#category-x
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 25 Jun 2017, at 13:57, Riyafa Abdul Hameed wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Dear all,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I implemented parse_geojon() function[1] using esri-geometry
>>>>>>>>>>>>> api[2]
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> is apache-2.0 licensed. But this api uses org.json as a
>>>>>>>>>>>> dependency.
>>>>>>>>>>>>
>>>>>>>>>>>> org.json is licensed under JSON which causes a license issue in
>>>>>>>>>>>>> the
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I
>>>>>>>>>>>>
>>>>>>>>>>>> have written[3]. What can I do about this issue?
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [1] https://asterix-gerrit.ics.uci.edu/1838
>>>>>>>>>>>>>> [2]https://github.com/Esri/geometry-api-java
>>>>>>>>>>>>>> [3]
>>>>>>>>>>>>>> https://asterix-jenkins.ics.uci.edu/job/asterix-gerrit-integ
>>>>>>>>>>>>>> ration-tests/3290/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you.
>>>>>>>>>>>>>> Yours sincerely,
>>>>>>>>>>>>>> Riyafa
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>> *Regards,*
>>>>>>>>>>> Wail Alkowaileet
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Ahmed Eldawy
>>>>>> Assistant Professor
>>>>>> http://www.cs.ucr.edu/~eldawy
>>>>>> Tel: +1 (951) 827-5654
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Riyafa Abdul Hameed
>>>>> Undergraduate, University of Moratuwa
>>>>>
>>>>> Email: riyafa.12@cse.mrt.ac.lk
>>>>> Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/>
>>>>> <http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa>
>>>>> <http://twitter.com/Riyafa1>
>>>>>
>>>>
>
>
> --
> Riyafa Abdul Hameed
> Undergraduate, University of Moratuwa
>
> Email: riyafa.12@cse.mrt.ac.lk
> Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/>
> <http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa>
> <http://twitter.com/Riyafa1>
>
--
Riyafa Abdul Hameed
Undergraduate, University of Moratuwa
Email: riyafa.12@cse.mrt.ac.lk
Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/>
<http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa>
<http://twitter.com/Riyafa1>
Re: License issue when using esri geometry api
Posted by Riyafa Abdul Hameed <ri...@cse.mrt.ac.lk>.
Hi Till,
Thank you. You seem to have followed the option 2). I didn't understand how
to get along with option 1). I wanted to ask with Ahmed about it and get
back.
I have no idea when they will release so I asked a question[1] though I
didn't get an answer for that.
Thank you.
Sincerely,
Riyafa
[1] https://github.com/Esri/geometry-api-java/issues/140
On 29 July 2017 at 10:58, Till Westmann <ti...@apache.org> wrote:
> Hi Riyafa,
>
> I’ve uploaded another commit to your change [4] that shows what option 2)
> would look like.
> Please take a look and see what you think.
> I think that this could only be a temporary solution.
> Do you have an idea, when Esri might publish a new version of the API?
>
> Cheers,
> Till
>
> [4] https://asterix-gerrit.ics.uci.edu/#/c/1895
>
>
> On 27 Jul 2017, at 10:13, Mike Carey wrote:
>
> +1 on option 1 for now, I would say (from afar :-)), until ESRI finishes
>> resolving stuff on their end.
>>
>> Aloha,
>>
>> Mike
>>
>>
>> On 7/27/17 6:23 AM, Till Westmann wrote:
>>
>>> Hi,
>>>
>>> I’m sorry for the late reply on the subject.
>>>
>>> Generally, Apache-releases are source releases [3] and so adding a
>>> precompiled jar without sources would prevent us from being able to
>>> release AsterixDB. So we will have to find another solution.
>>>
>>> A few options that I can think of right now would be to
>>> 1) make it an optional dependency and require the user to
>>> require/obtain the jar external and to provide it to the platform that
>>> they build on or to
>>> 2) include the source files in the AsterixDB source repository or to
>>> 3) download and build the source as part of the build process.
>>>
>>> Of these 3 options, I think that 1) is the cleanest option from a
>>> licensing perspective, 2) can be managed if we understand the
>>> provenance of the source files and 3) seems problematic as we would put
>>> a load on a system that provide the source for every build and as we
>>> could retrieve use unvetted source code.
>>>
>>> Thoughts/concerns about these options?
>>> Does anybody see other options?
>>>
>>> Cheers,
>>> Till
>>>
>>> [3] http://www.apache.org/legal/release-policy.html#artifacts
>>>
>>> On 27 Jul 2017, at 7:21, Riyafa Abdul Hameed wrote:
>>>
>>> Dear all,
>>>>
>>>> Is there a way to ship a jar file as a dependency for AsterixDB apart
>>>> from
>>>> the method I have used here[1]. This is because the build of asterix-app
>>>> seems to fail[2] when I use the external jar file like this.
>>>> Though I am unable to find a connection between the failure and the
>>>> dependency it seems I need to assume that it is the cause, because
>>>> otherwise if I use the Maven-released version the build passes without
>>>> issue.
>>>>
>>>> Any help would be highly appreciated.
>>>> [1]
>>>> https://asterix-gerrit.ics.uci.edu/#/c/1895/3/asterixdb/aste
>>>> rix-om/pom.xml
>>>> [2] https://asterix-gerrit.ics.uci.edu/#/c/1895
>>>>
>>>> On 22 July 2017 at 01:59, Ahmed Eldawy <el...@cs.ucr.edu> wrote:
>>>>
>>>> Although Esri resolved the issue, their Maven-released version still
>>>>> relies
>>>>> on the incompatible library. We can wait until they release a new
>>>>> version
>>>>> on Maven but this might take a while. To be able to merge the current
>>>>> code,
>>>>> we might need to compile our own JAR file and ship it with the source
>>>>> code.
>>>>> Do you know if this is possible/allowed/recommended in AsterixDB? Is
>>>>> there
>>>>> another preferred way to handle this issue? Keep in mind that, most
>>>>> likely,
>>>>> the summer project will conclude before Esri releases the new version.
>>>>>
>>>>> Thanks
>>>>> Ahmed
>>>>>
>>>>> On Tue, Jul 11, 2017 at 11:04 AM, Mike Carey <dt...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> NICE!!!
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 7/11/17 9:39 AM, Ahmed Eldawy wrote:
>>>>>>
>>>>>> There's a good news. Riyafa has opened an issue on ESRI Geometry API
>>>>>>> project on Github about the license problem and they made the
>>>>>>> necessary
>>>>>>> changes to remove the bad dependency.
>>>>>>> https://github.com/Esri/geometry-api-java/issues/135
>>>>>>> The changes are on their github repository but they are not released
>>>>>>>
>>>>>> yet.
>>>>>
>>>>>> I
>>>>>>> think we can just continue what we're doing and wait for the new
>>>>>>> release
>>>>>>> to
>>>>>>> hit Maven repository.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Ahmed
>>>>>>>
>>>>>>> On Mon, Jun 26, 2017 at 7:55 AM, Mike Carey <dt...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> It sounds like the best option is 4 minus parsing, then, if we can do
>>>>>>>
>>>>>>>> that. (Which would also address Wail's comments, which could be a
>>>>>>>>
>>>>>>> killer
>>>>>
>>>>>> for big data eventually.) If not, we could go with 2 for the summer
>>>>>>>>
>>>>>>> as a
>>>>>
>>>>>> first step, I guess? (But figuring out the feasibility of 4 would be
>>>>>>>> great...)
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Mike
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 6/26/17 2:59 AM, Ahmed Eldawy wrote:
>>>>>>>>
>>>>>>>> It seems that (3) would require modifying the open source Esri API
>>>>>>>>
>>>>>>>>> library
>>>>>>>>> which I don't like. Not only for the overhead of understanding and
>>>>>>>>> modifying the code, but also for deviating from the standard
>>>>>>>>> library
>>>>>>>>> which
>>>>>>>>> means we will miss future updates. One of the reasons we chose to
>>>>>>>>> use
>>>>>>>>> Esri
>>>>>>>>> API is the hope that it will be well-maintained in the future.
>>>>>>>>> This leaves us with (4). I don't know if it is technically
>>>>>>>>> possible to
>>>>>>>>> depend on the standard Esri API without using the non-compliant
>>>>>>>>>
>>>>>>>> library
>>>>>
>>>>>> or
>>>>>>>>> not. If this is possible, then we can just use the computational
>>>>>>>>> geometry
>>>>>>>>> (CG) functionality from the library, and provide our own GeoJSON
>>>>>>>>>
>>>>>>>> parser.
>>>>>
>>>>>> If
>>>>>>>>> this is not possible, then I would rather consider the use of
>>>>>>>>> another
>>>>>>>>> library, e.g., JTS.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Ahmed
>>>>>>>>>
>>>>>>>>> On Sun, Jun 25, 2017 at 11:47 AM, Wail Alkowaileet <
>>>>>>>>>
>>>>>>>> wael.y.k@gmail.com>
>>>>>
>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I can see from the code that there is a serder steps as such:
>>>>>>>>> Asterix
>>>>>>>>>
>>>>>>>>> Object (binary) --> JSON (String) --> Esri geometry (Java object)
>>>>>>>>>> -->
>>>>>>>>>> Esri
>>>>>>>>>> geometry (binary).
>>>>>>>>>> I think it would be nice if there is a binary-to-binary conversion
>>>>>>>>>> without
>>>>>>>>>> any deserialization (4th option).
>>>>>>>>>>
>>>>>>>>>> On Sun, Jun 25, 2017 at 6:36 PM, Mike Carey <dt...@gmail.com>
>>>>>>>>>>
>>>>>>>>> wrote:
>>>>>
>>>>>>
>>>>>>>>>> Agreed that 3 or 4 are what we'll need to do....! (Sigh.)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 6/25/17 5:57 AM, Till Westmann wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Riyafa,
>>>>>>>>>>>
>>>>>>>>>>> I think that the problem is bigger than the failing test. The
>>>>>>>>>>>> JSON
>>>>>>>>>>>> license itself is not acceptable for inclusion in an Apache
>>>>>>>>>>>>
>>>>>>>>>>> artifact
>>>>>
>>>>>> [4]. So we cannot use the ESRI API as-is, if we want the GeoJSON
>>>>>>>>>>>> functionality be a non-optional part of AsterixDB.
>>>>>>>>>>>>
>>>>>>>>>>>> Here are a few options I see:
>>>>>>>>>>>> 1) Make GeoJSON an optional part of AsterixDB (separate download
>>>>>>>>>>>> from a
>>>>>>>>>>>> non-Apache location).
>>>>>>>>>>>> 2) Make JSON.org a dependency that is not shipped (i.e. each
>>>>>>>>>>>> user
>>>>>>>>>>>> would
>>>>>>>>>>>> have to download and install those jars separately - and
>>>>>>>>>>>> get
>>>>>>>>>>>> error
>>>>>>>>>>>> messages if the jars are not available).
>>>>>>>>>>>> 3) Create a clone/copy of the ESRI API that uses another JSON
>>>>>>>>>>>> library.
>>>>>>>>>>>> 4) Do all of the parsing independently from the ESRI API.
>>>>>>>>>>>>
>>>>>>>>>>>> I’m not sure if 1) is a good option as the extensibility in this
>>>>>>>>>>>>
>>>>>>>>>>> part
>>>>>
>>>>>> of the code might not be sufficient to support this option easily.
>>>>>>>>>>>> 2) is technically easier, but it involves an unpleasant user
>>>>>>>>>>>> experience.
>>>>>>>>>>>> Also, I think that both 1) and 2) are not desirable, as GeoJSON
>>>>>>>>>>>> should
>>>>>>>>>>>> be supported by vanilla AsterixDB.
>>>>>>>>>>>> For 3) and 4) we would need to look into the details to see how
>>>>>>>>>>>>
>>>>>>>>>>> much
>>>>>
>>>>>> work is required for each of those options and if there are other
>>>>>>>>>>>> legal
>>>>>>>>>>>> hurdles.
>>>>>>>>>>>>
>>>>>>>>>>>> Are there other options?
>>>>>>>>>>>> Other thoughts/concerns?
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Till
>>>>>>>>>>>>
>>>>>>>>>>>> [4] https://www.apache.org/legal/resolved.html#category-x
>>>>>>>>>>>>
>>>>>>>>>>>> On 25 Jun 2017, at 13:57, Riyafa Abdul Hameed wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Dear all,
>>>>>>>>>>>>
>>>>>>>>>>>> I implemented parse_geojon() function[1] using esri-geometry
>>>>>>>>>>>> api[2]
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> which
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> is apache-2.0 licensed. But this api uses org.json as a
>>>>>>>>>>> dependency.
>>>>>>>>>>>
>>>>>>>>>>> org.json is licensed under JSON which causes a license issue in
>>>>>>>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> code
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I
>>>>>>>>>>>
>>>>>>>>>>> have written[3]. What can I do about this issue?
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1] https://asterix-gerrit.ics.uci.edu/1838
>>>>>>>>>>>>> [2]https://github.com/Esri/geometry-api-java
>>>>>>>>>>>>> [3]
>>>>>>>>>>>>> https://asterix-jenkins.ics.uci.edu/job/asterix-gerrit-integ
>>>>>>>>>>>>> ration-tests/3290/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you.
>>>>>>>>>>>>> Yours sincerely,
>>>>>>>>>>>>> Riyafa
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>> *Regards,*
>>>>>>>>>> Wail Alkowaileet
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Ahmed Eldawy
>>>>> Assistant Professor
>>>>> http://www.cs.ucr.edu/~eldawy
>>>>> Tel: +1 (951) 827-5654
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Riyafa Abdul Hameed
>>>> Undergraduate, University of Moratuwa
>>>>
>>>> Email: riyafa.12@cse.mrt.ac.lk
>>>> Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/>
>>>> <http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa>
>>>> <http://twitter.com/Riyafa1>
>>>>
>>>
--
Riyafa Abdul Hameed
Undergraduate, University of Moratuwa
Email: riyafa.12@cse.mrt.ac.lk
Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/>
<http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa>
<http://twitter.com/Riyafa1>
Re: License issue when using esri geometry api
Posted by Till Westmann <ti...@apache.org>.
Hi Riyafa,
I’ve uploaded another commit to your change [4] that shows what option
2) would look like.
Please take a look and see what you think.
I think that this could only be a temporary solution.
Do you have an idea, when Esri might publish a new version of the API?
Cheers,
Till
[4] https://asterix-gerrit.ics.uci.edu/#/c/1895
On 27 Jul 2017, at 10:13, Mike Carey wrote:
> +1 on option 1 for now, I would say (from afar :-)), until ESRI
> finishes resolving stuff on their end.
>
> Aloha,
>
> Mike
>
>
> On 7/27/17 6:23 AM, Till Westmann wrote:
>> Hi,
>>
>> I’m sorry for the late reply on the subject.
>>
>> Generally, Apache-releases are source releases [3] and so adding a
>> precompiled jar without sources would prevent us from being able to
>> release AsterixDB. So we will have to find another solution.
>>
>> A few options that I can think of right now would be to
>> 1) make it an optional dependency and require the user to
>> require/obtain the jar external and to provide it to the platform
>> that
>> they build on or to
>> 2) include the source files in the AsterixDB source repository or to
>> 3) download and build the source as part of the build process.
>>
>> Of these 3 options, I think that 1) is the cleanest option from a
>> licensing perspective, 2) can be managed if we understand the
>> provenance of the source files and 3) seems problematic as we would
>> put
>> a load on a system that provide the source for every build and as we
>> could retrieve use unvetted source code.
>>
>> Thoughts/concerns about these options?
>> Does anybody see other options?
>>
>> Cheers,
>> Till
>>
>> [3] http://www.apache.org/legal/release-policy.html#artifacts
>>
>> On 27 Jul 2017, at 7:21, Riyafa Abdul Hameed wrote:
>>
>>> Dear all,
>>>
>>> Is there a way to ship a jar file as a dependency for AsterixDB
>>> apart from
>>> the method I have used here[1]. This is because the build of
>>> asterix-app
>>> seems to fail[2] when I use the external jar file like this.
>>> Though I am unable to find a connection between the failure and the
>>> dependency it seems I need to assume that it is the cause, because
>>> otherwise if I use the Maven-released version the build passes
>>> without
>>> issue.
>>>
>>> Any help would be highly appreciated.
>>> [1]
>>> https://asterix-gerrit.ics.uci.edu/#/c/1895/3/asterixdb/asterix-om/pom.xml
>>> [2] https://asterix-gerrit.ics.uci.edu/#/c/1895
>>>
>>> On 22 July 2017 at 01:59, Ahmed Eldawy <el...@cs.ucr.edu> wrote:
>>>
>>>> Although Esri resolved the issue, their Maven-released version
>>>> still relies
>>>> on the incompatible library. We can wait until they release a new
>>>> version
>>>> on Maven but this might take a while. To be able to merge the
>>>> current code,
>>>> we might need to compile our own JAR file and ship it with the
>>>> source code.
>>>> Do you know if this is possible/allowed/recommended in AsterixDB?
>>>> Is there
>>>> another preferred way to handle this issue? Keep in mind that, most
>>>> likely,
>>>> the summer project will conclude before Esri releases the new
>>>> version.
>>>>
>>>> Thanks
>>>> Ahmed
>>>>
>>>> On Tue, Jul 11, 2017 at 11:04 AM, Mike Carey <dt...@gmail.com>
>>>> wrote:
>>>>
>>>>> NICE!!!
>>>>>
>>>>>
>>>>>
>>>>> On 7/11/17 9:39 AM, Ahmed Eldawy wrote:
>>>>>
>>>>>> There's a good news. Riyafa has opened an issue on ESRI Geometry
>>>>>> API
>>>>>> project on Github about the license problem and they made the
>>>>>> necessary
>>>>>> changes to remove the bad dependency.
>>>>>> https://github.com/Esri/geometry-api-java/issues/135
>>>>>> The changes are on their github repository but they are not
>>>>>> released
>>>> yet.
>>>>>> I
>>>>>> think we can just continue what we're doing and wait for the new
>>>>>> release
>>>>>> to
>>>>>> hit Maven repository.
>>>>>>
>>>>>> Thanks
>>>>>> Ahmed
>>>>>>
>>>>>> On Mon, Jun 26, 2017 at 7:55 AM, Mike Carey <dt...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> It sounds like the best option is 4 minus parsing, then, if we
>>>>>> can do
>>>>>>> that. (Which would also address Wail's comments, which could be
>>>>>>> a
>>>> killer
>>>>>>> for big data eventually.) If not, we could go with 2 for the
>>>>>>> summer
>>>> as a
>>>>>>> first step, I guess? (But figuring out the feasibility of 4
>>>>>>> would be
>>>>>>> great...)
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 6/26/17 2:59 AM, Ahmed Eldawy wrote:
>>>>>>>
>>>>>>> It seems that (3) would require modifying the open source Esri
>>>>>>> API
>>>>>>>> library
>>>>>>>> which I don't like. Not only for the overhead of understanding
>>>>>>>> and
>>>>>>>> modifying the code, but also for deviating from the standard
>>>>>>>> library
>>>>>>>> which
>>>>>>>> means we will miss future updates. One of the reasons we chose
>>>>>>>> to use
>>>>>>>> Esri
>>>>>>>> API is the hope that it will be well-maintained in the future.
>>>>>>>> This leaves us with (4). I don't know if it is technically
>>>>>>>> possible to
>>>>>>>> depend on the standard Esri API without using the non-compliant
>>>> library
>>>>>>>> or
>>>>>>>> not. If this is possible, then we can just use the
>>>>>>>> computational
>>>>>>>> geometry
>>>>>>>> (CG) functionality from the library, and provide our own
>>>>>>>> GeoJSON
>>>> parser.
>>>>>>>> If
>>>>>>>> this is not possible, then I would rather consider the use of
>>>>>>>> another
>>>>>>>> library, e.g., JTS.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Ahmed
>>>>>>>>
>>>>>>>> On Sun, Jun 25, 2017 at 11:47 AM, Wail Alkowaileet <
>>>> wael.y.k@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I can see from the code that there is a serder steps as such:
>>>>>>>> Asterix
>>>>>>>>
>>>>>>>>> Object (binary) --> JSON (String) --> Esri geometry (Java
>>>>>>>>> object) -->
>>>>>>>>> Esri
>>>>>>>>> geometry (binary).
>>>>>>>>> I think it would be nice if there is a binary-to-binary
>>>>>>>>> conversion
>>>>>>>>> without
>>>>>>>>> any deserialization (4th option).
>>>>>>>>>
>>>>>>>>> On Sun, Jun 25, 2017 at 6:36 PM, Mike Carey
>>>>>>>>> <dt...@gmail.com>
>>>> wrote:
>>>>>>>>>
>>>>>>>>> Agreed that 3 or 4 are what we'll need to do....! (Sigh.)
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 6/25/17 5:57 AM, Till Westmann wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Riyafa,
>>>>>>>>>>
>>>>>>>>>>> I think that the problem is bigger than the failing test.
>>>>>>>>>>> The JSON
>>>>>>>>>>> license itself is not acceptable for inclusion in an Apache
>>>> artifact
>>>>>>>>>>> [4]. So we cannot use the ESRI API as-is, if we want the
>>>>>>>>>>> GeoJSON
>>>>>>>>>>> functionality be a non-optional part of AsterixDB.
>>>>>>>>>>>
>>>>>>>>>>> Here are a few options I see:
>>>>>>>>>>> 1) Make GeoJSON an optional part of AsterixDB (separate
>>>>>>>>>>> download
>>>>>>>>>>> from a
>>>>>>>>>>> non-Apache location).
>>>>>>>>>>> 2) Make JSON.org a dependency that is not shipped (i.e. each
>>>>>>>>>>> user
>>>>>>>>>>> would
>>>>>>>>>>> have to download and install those jars separately -
>>>>>>>>>>> and get
>>>>>>>>>>> error
>>>>>>>>>>> messages if the jars are not available).
>>>>>>>>>>> 3) Create a clone/copy of the ESRI API that uses another
>>>>>>>>>>> JSON
>>>>>>>>>>> library.
>>>>>>>>>>> 4) Do all of the parsing independently from the ESRI API.
>>>>>>>>>>>
>>>>>>>>>>> I’m not sure if 1) is a good option as the extensibility
>>>>>>>>>>> in this
>>>> part
>>>>>>>>>>> of the code might not be sufficient to support this option
>>>>>>>>>>> easily.
>>>>>>>>>>> 2) is technically easier, but it involves an unpleasant user
>>>>>>>>>>> experience.
>>>>>>>>>>> Also, I think that both 1) and 2) are not desirable, as
>>>>>>>>>>> GeoJSON
>>>>>>>>>>> should
>>>>>>>>>>> be supported by vanilla AsterixDB.
>>>>>>>>>>> For 3) and 4) we would need to look into the details to see
>>>>>>>>>>> how
>>>> much
>>>>>>>>>>> work is required for each of those options and if there are
>>>>>>>>>>> other
>>>>>>>>>>> legal
>>>>>>>>>>> hurdles.
>>>>>>>>>>>
>>>>>>>>>>> Are there other options?
>>>>>>>>>>> Other thoughts/concerns?
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Till
>>>>>>>>>>>
>>>>>>>>>>> [4] https://www.apache.org/legal/resolved.html#category-x
>>>>>>>>>>>
>>>>>>>>>>> On 25 Jun 2017, at 13:57, Riyafa Abdul Hameed wrote:
>>>>>>>>>>>
>>>>>>>>>>> Dear all,
>>>>>>>>>>>
>>>>>>>>>>> I implemented parse_geojon() function[1] using esri-geometry
>>>>>>>>>>> api[2]
>>>>>>>>>>>>
>>>>>>>>>>>> which
>>>>>>>>>>>
>>>>>>>>>> is apache-2.0 licensed. But this api uses org.json as a
>>>>>>>>>> dependency.
>>>>>>>>>>
>>>>>>>>>>> org.json is licensed under JSON which causes a license issue
>>>>>>>>>>> in the
>>>>>>>>>>>>
>>>>>>>>>>>> code
>>>>>>>>>>>
>>>>>>>>>> I
>>>>>>>>>>
>>>>>>>>>>> have written[3]. What can I do about this issue?
>>>>>>>>>>>>
>>>>>>>>>>>> [1] https://asterix-gerrit.ics.uci.edu/1838
>>>>>>>>>>>> [2]https://github.com/Esri/geometry-api-java
>>>>>>>>>>>> [3]
>>>>>>>>>>>> https://asterix-jenkins.ics.uci.edu/job/asterix-gerrit-integ
>>>>>>>>>>>> ration-tests/3290/
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you.
>>>>>>>>>>>> Yours sincerely,
>>>>>>>>>>>> Riyafa
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> *Regards,*
>>>>>>>>> Wail Alkowaileet
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Ahmed Eldawy
>>>> Assistant Professor
>>>> http://www.cs.ucr.edu/~eldawy
>>>> Tel: +1 (951) 827-5654
>>>>
>>>
>>>
>>>
>>> --
>>> Riyafa Abdul Hameed
>>> Undergraduate, University of Moratuwa
>>>
>>> Email: riyafa.12@cse.mrt.ac.lk
>>> Website: https://riyafa.wordpress.com/
>>> <http://riyafa.wordpress.com/>
>>> <http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa>
>>> <http://twitter.com/Riyafa1>
Re: License issue when using esri geometry api
Posted by Mike Carey <dt...@gmail.com>.
+1 on option 1 for now, I would say (from afar :-)), until ESRI finishes
resolving stuff on their end.
Aloha,
Mike
On 7/27/17 6:23 AM, Till Westmann wrote:
> Hi,
>
> I’m sorry for the late reply on the subject.
>
> Generally, Apache-releases are source releases [3] and so adding a
> precompiled jar without sources would prevent us from being able to
> release AsterixDB. So we will have to find another solution.
>
> A few options that I can think of right now would be to
> 1) make it an optional dependency and require the user to
> require/obtain the jar external and to provide it to the platform that
> they build on or to
> 2) include the source files in the AsterixDB source repository or to
> 3) download and build the source as part of the build process.
>
> Of these 3 options, I think that 1) is the cleanest option from a
> licensing perspective, 2) can be managed if we understand the
> provenance of the source files and 3) seems problematic as we would put
> a load on a system that provide the source for every build and as we
> could retrieve use unvetted source code.
>
> Thoughts/concerns about these options?
> Does anybody see other options?
>
> Cheers,
> Till
>
> [3] http://www.apache.org/legal/release-policy.html#artifacts
>
> On 27 Jul 2017, at 7:21, Riyafa Abdul Hameed wrote:
>
>> Dear all,
>>
>> Is there a way to ship a jar file as a dependency for AsterixDB apart
>> from
>> the method I have used here[1]. This is because the build of asterix-app
>> seems to fail[2] when I use the external jar file like this.
>> Though I am unable to find a connection between the failure and the
>> dependency it seems I need to assume that it is the cause, because
>> otherwise if I use the Maven-released version the build passes without
>> issue.
>>
>> Any help would be highly appreciated.
>> [1]
>> https://asterix-gerrit.ics.uci.edu/#/c/1895/3/asterixdb/asterix-om/pom.xml
>>
>> [2] https://asterix-gerrit.ics.uci.edu/#/c/1895
>>
>> On 22 July 2017 at 01:59, Ahmed Eldawy <el...@cs.ucr.edu> wrote:
>>
>>> Although Esri resolved the issue, their Maven-released version still
>>> relies
>>> on the incompatible library. We can wait until they release a new
>>> version
>>> on Maven but this might take a while. To be able to merge the
>>> current code,
>>> we might need to compile our own JAR file and ship it with the
>>> source code.
>>> Do you know if this is possible/allowed/recommended in AsterixDB? Is
>>> there
>>> another preferred way to handle this issue? Keep in mind that, most
>>> likely,
>>> the summer project will conclude before Esri releases the new version.
>>>
>>> Thanks
>>> Ahmed
>>>
>>> On Tue, Jul 11, 2017 at 11:04 AM, Mike Carey <dt...@gmail.com> wrote:
>>>
>>>> NICE!!!
>>>>
>>>>
>>>>
>>>> On 7/11/17 9:39 AM, Ahmed Eldawy wrote:
>>>>
>>>>> There's a good news. Riyafa has opened an issue on ESRI Geometry API
>>>>> project on Github about the license problem and they made the
>>>>> necessary
>>>>> changes to remove the bad dependency.
>>>>> https://github.com/Esri/geometry-api-java/issues/135
>>>>> The changes are on their github repository but they are not released
>>> yet.
>>>>> I
>>>>> think we can just continue what we're doing and wait for the new
>>>>> release
>>>>> to
>>>>> hit Maven repository.
>>>>>
>>>>> Thanks
>>>>> Ahmed
>>>>>
>>>>> On Mon, Jun 26, 2017 at 7:55 AM, Mike Carey <dt...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> It sounds like the best option is 4 minus parsing, then, if we can do
>>>>>> that. (Which would also address Wail's comments, which could be a
>>> killer
>>>>>> for big data eventually.) If not, we could go with 2 for the summer
>>> as a
>>>>>> first step, I guess? (But figuring out the feasibility of 4
>>>>>> would be
>>>>>> great...)
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 6/26/17 2:59 AM, Ahmed Eldawy wrote:
>>>>>>
>>>>>> It seems that (3) would require modifying the open source Esri API
>>>>>>> library
>>>>>>> which I don't like. Not only for the overhead of understanding and
>>>>>>> modifying the code, but also for deviating from the standard
>>>>>>> library
>>>>>>> which
>>>>>>> means we will miss future updates. One of the reasons we chose
>>>>>>> to use
>>>>>>> Esri
>>>>>>> API is the hope that it will be well-maintained in the future.
>>>>>>> This leaves us with (4). I don't know if it is technically
>>>>>>> possible to
>>>>>>> depend on the standard Esri API without using the non-compliant
>>> library
>>>>>>> or
>>>>>>> not. If this is possible, then we can just use the computational
>>>>>>> geometry
>>>>>>> (CG) functionality from the library, and provide our own GeoJSON
>>> parser.
>>>>>>> If
>>>>>>> this is not possible, then I would rather consider the use of
>>>>>>> another
>>>>>>> library, e.g., JTS.
>>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>> Ahmed
>>>>>>>
>>>>>>> On Sun, Jun 25, 2017 at 11:47 AM, Wail Alkowaileet <
>>> wael.y.k@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I can see from the code that there is a serder steps as such:
>>>>>>> Asterix
>>>>>>>
>>>>>>>> Object (binary) --> JSON (String) --> Esri geometry (Java
>>>>>>>> object) -->
>>>>>>>> Esri
>>>>>>>> geometry (binary).
>>>>>>>> I think it would be nice if there is a binary-to-binary conversion
>>>>>>>> without
>>>>>>>> any deserialization (4th option).
>>>>>>>>
>>>>>>>> On Sun, Jun 25, 2017 at 6:36 PM, Mike Carey <dt...@gmail.com>
>>> wrote:
>>>>>>>>
>>>>>>>> Agreed that 3 or 4 are what we'll need to do....! (Sigh.)
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 6/25/17 5:57 AM, Till Westmann wrote:
>>>>>>>>>
>>>>>>>>> Hi Riyafa,
>>>>>>>>>
>>>>>>>>>> I think that the problem is bigger than the failing test. The
>>>>>>>>>> JSON
>>>>>>>>>> license itself is not acceptable for inclusion in an Apache
>>> artifact
>>>>>>>>>> [4]. So we cannot use the ESRI API as-is, if we want the GeoJSON
>>>>>>>>>> functionality be a non-optional part of AsterixDB.
>>>>>>>>>>
>>>>>>>>>> Here are a few options I see:
>>>>>>>>>> 1) Make GeoJSON an optional part of AsterixDB (separate download
>>>>>>>>>> from a
>>>>>>>>>> non-Apache location).
>>>>>>>>>> 2) Make JSON.org a dependency that is not shipped (i.e. each
>>>>>>>>>> user
>>>>>>>>>> would
>>>>>>>>>> have to download and install those jars separately - and
>>>>>>>>>> get
>>>>>>>>>> error
>>>>>>>>>> messages if the jars are not available).
>>>>>>>>>> 3) Create a clone/copy of the ESRI API that uses another JSON
>>>>>>>>>> library.
>>>>>>>>>> 4) Do all of the parsing independently from the ESRI API.
>>>>>>>>>>
>>>>>>>>>> I’m not sure if 1) is a good option as the extensibility in this
>>> part
>>>>>>>>>> of the code might not be sufficient to support this option
>>>>>>>>>> easily.
>>>>>>>>>> 2) is technically easier, but it involves an unpleasant user
>>>>>>>>>> experience.
>>>>>>>>>> Also, I think that both 1) and 2) are not desirable, as GeoJSON
>>>>>>>>>> should
>>>>>>>>>> be supported by vanilla AsterixDB.
>>>>>>>>>> For 3) and 4) we would need to look into the details to see how
>>> much
>>>>>>>>>> work is required for each of those options and if there are
>>>>>>>>>> other
>>>>>>>>>> legal
>>>>>>>>>> hurdles.
>>>>>>>>>>
>>>>>>>>>> Are there other options?
>>>>>>>>>> Other thoughts/concerns?
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Till
>>>>>>>>>>
>>>>>>>>>> [4] https://www.apache.org/legal/resolved.html#category-x
>>>>>>>>>>
>>>>>>>>>> On 25 Jun 2017, at 13:57, Riyafa Abdul Hameed wrote:
>>>>>>>>>>
>>>>>>>>>> Dear all,
>>>>>>>>>>
>>>>>>>>>> I implemented parse_geojon() function[1] using esri-geometry
>>>>>>>>>> api[2]
>>>>>>>>>>>
>>>>>>>>>>> which
>>>>>>>>>>
>>>>>>>>> is apache-2.0 licensed. But this api uses org.json as a
>>>>>>>>> dependency.
>>>>>>>>>
>>>>>>>>>> org.json is licensed under JSON which causes a license issue
>>>>>>>>>> in the
>>>>>>>>>>>
>>>>>>>>>>> code
>>>>>>>>>>
>>>>>>>>> I
>>>>>>>>>
>>>>>>>>>> have written[3]. What can I do about this issue?
>>>>>>>>>>>
>>>>>>>>>>> [1] https://asterix-gerrit.ics.uci.edu/1838
>>>>>>>>>>> [2]https://github.com/Esri/geometry-api-java
>>>>>>>>>>> [3]
>>>>>>>>>>> https://asterix-jenkins.ics.uci.edu/job/asterix-gerrit-integ
>>>>>>>>>>> ration-tests/3290/
>>>>>>>>>>>
>>>>>>>>>>> Thank you.
>>>>>>>>>>> Yours sincerely,
>>>>>>>>>>> Riyafa
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>
>>>>>>>> *Regards,*
>>>>>>>> Wail Alkowaileet
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Ahmed Eldawy
>>> Assistant Professor
>>> http://www.cs.ucr.edu/~eldawy
>>> Tel: +1 (951) 827-5654
>>>
>>
>>
>>
>> --
>> Riyafa Abdul Hameed
>> Undergraduate, University of Moratuwa
>>
>> Email: riyafa.12@cse.mrt.ac.lk
>> Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/>
>> <http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa>
>> <http://twitter.com/Riyafa1>
Re: License issue when using esri geometry api
Posted by Till Westmann <ti...@apache.org>.
Hi,
I’m sorry for the late reply on the subject.
Generally, Apache-releases are source releases [3] and so adding a
precompiled jar without sources would prevent us from being able to
release AsterixDB. So we will have to find another solution.
A few options that I can think of right now would be to
1) make it an optional dependency and require the user to
require/obtain the jar external and to provide it to the platform that
they build on or to
2) include the source files in the AsterixDB source repository or to
3) download and build the source as part of the build process.
Of these 3 options, I think that 1) is the cleanest option from a
licensing perspective, 2) can be managed if we understand the
provenance of the source files and 3) seems problematic as we would put
a load on a system that provide the source for every build and as we
could retrieve use unvetted source code.
Thoughts/concerns about these options?
Does anybody see other options?
Cheers,
Till
[3] http://www.apache.org/legal/release-policy.html#artifacts
On 27 Jul 2017, at 7:21, Riyafa Abdul Hameed wrote:
> Dear all,
>
> Is there a way to ship a jar file as a dependency for AsterixDB apart
> from
> the method I have used here[1]. This is because the build of
> asterix-app
> seems to fail[2] when I use the external jar file like this.
> Though I am unable to find a connection between the failure and the
> dependency it seems I need to assume that it is the cause, because
> otherwise if I use the Maven-released version the build passes without
> issue.
>
> Any help would be highly appreciated.
> [1]
> https://asterix-gerrit.ics.uci.edu/#/c/1895/3/asterixdb/asterix-om/pom.xml
> [2] https://asterix-gerrit.ics.uci.edu/#/c/1895
>
> On 22 July 2017 at 01:59, Ahmed Eldawy <el...@cs.ucr.edu> wrote:
>
>> Although Esri resolved the issue, their Maven-released version still
>> relies
>> on the incompatible library. We can wait until they release a new
>> version
>> on Maven but this might take a while. To be able to merge the current
>> code,
>> we might need to compile our own JAR file and ship it with the source
>> code.
>> Do you know if this is possible/allowed/recommended in AsterixDB? Is
>> there
>> another preferred way to handle this issue? Keep in mind that, most
>> likely,
>> the summer project will conclude before Esri releases the new
>> version.
>>
>> Thanks
>> Ahmed
>>
>> On Tue, Jul 11, 2017 at 11:04 AM, Mike Carey <dt...@gmail.com>
>> wrote:
>>
>>> NICE!!!
>>>
>>>
>>>
>>> On 7/11/17 9:39 AM, Ahmed Eldawy wrote:
>>>
>>>> There's a good news. Riyafa has opened an issue on ESRI Geometry
>>>> API
>>>> project on Github about the license problem and they made the
>>>> necessary
>>>> changes to remove the bad dependency.
>>>> https://github.com/Esri/geometry-api-java/issues/135
>>>> The changes are on their github repository but they are not
>>>> released
>> yet.
>>>> I
>>>> think we can just continue what we're doing and wait for the new
>>>> release
>>>> to
>>>> hit Maven repository.
>>>>
>>>> Thanks
>>>> Ahmed
>>>>
>>>> On Mon, Jun 26, 2017 at 7:55 AM, Mike Carey <dt...@gmail.com>
>>>> wrote:
>>>>
>>>> It sounds like the best option is 4 minus parsing, then, if we can
>>>> do
>>>>> that. (Which would also address Wail's comments, which could be a
>> killer
>>>>> for big data eventually.) If not, we could go with 2 for the
>>>>> summer
>> as a
>>>>> first step, I guess? (But figuring out the feasibility of 4 would
>>>>> be
>>>>> great...)
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>> On 6/26/17 2:59 AM, Ahmed Eldawy wrote:
>>>>>
>>>>> It seems that (3) would require modifying the open source Esri API
>>>>>> library
>>>>>> which I don't like. Not only for the overhead of understanding
>>>>>> and
>>>>>> modifying the code, but also for deviating from the standard
>>>>>> library
>>>>>> which
>>>>>> means we will miss future updates. One of the reasons we chose to
>>>>>> use
>>>>>> Esri
>>>>>> API is the hope that it will be well-maintained in the future.
>>>>>> This leaves us with (4). I don't know if it is technically
>>>>>> possible to
>>>>>> depend on the standard Esri API without using the non-compliant
>> library
>>>>>> or
>>>>>> not. If this is possible, then we can just use the computational
>>>>>> geometry
>>>>>> (CG) functionality from the library, and provide our own GeoJSON
>> parser.
>>>>>> If
>>>>>> this is not possible, then I would rather consider the use of
>>>>>> another
>>>>>> library, e.g., JTS.
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Ahmed
>>>>>>
>>>>>> On Sun, Jun 25, 2017 at 11:47 AM, Wail Alkowaileet <
>> wael.y.k@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> I can see from the code that there is a serder steps as such:
>>>>>> Asterix
>>>>>>
>>>>>>> Object (binary) --> JSON (String) --> Esri geometry (Java
>>>>>>> object) -->
>>>>>>> Esri
>>>>>>> geometry (binary).
>>>>>>> I think it would be nice if there is a binary-to-binary
>>>>>>> conversion
>>>>>>> without
>>>>>>> any deserialization (4th option).
>>>>>>>
>>>>>>> On Sun, Jun 25, 2017 at 6:36 PM, Mike Carey <dt...@gmail.com>
>> wrote:
>>>>>>>
>>>>>>> Agreed that 3 or 4 are what we'll need to do....! (Sigh.)
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 6/25/17 5:57 AM, Till Westmann wrote:
>>>>>>>>
>>>>>>>> Hi Riyafa,
>>>>>>>>
>>>>>>>>> I think that the problem is bigger than the failing test. The
>>>>>>>>> JSON
>>>>>>>>> license itself is not acceptable for inclusion in an Apache
>> artifact
>>>>>>>>> [4]. So we cannot use the ESRI API as-is, if we want the
>>>>>>>>> GeoJSON
>>>>>>>>> functionality be a non-optional part of AsterixDB.
>>>>>>>>>
>>>>>>>>> Here are a few options I see:
>>>>>>>>> 1) Make GeoJSON an optional part of AsterixDB (separate
>>>>>>>>> download
>>>>>>>>> from a
>>>>>>>>> non-Apache location).
>>>>>>>>> 2) Make JSON.org a dependency that is not shipped (i.e. each
>>>>>>>>> user
>>>>>>>>> would
>>>>>>>>> have to download and install those jars separately - and
>>>>>>>>> get
>>>>>>>>> error
>>>>>>>>> messages if the jars are not available).
>>>>>>>>> 3) Create a clone/copy of the ESRI API that uses another JSON
>>>>>>>>> library.
>>>>>>>>> 4) Do all of the parsing independently from the ESRI API.
>>>>>>>>>
>>>>>>>>> I’m not sure if 1) is a good option as the extensibility in
>>>>>>>>> this
>> part
>>>>>>>>> of the code might not be sufficient to support this option
>>>>>>>>> easily.
>>>>>>>>> 2) is technically easier, but it involves an unpleasant user
>>>>>>>>> experience.
>>>>>>>>> Also, I think that both 1) and 2) are not desirable, as
>>>>>>>>> GeoJSON
>>>>>>>>> should
>>>>>>>>> be supported by vanilla AsterixDB.
>>>>>>>>> For 3) and 4) we would need to look into the details to see
>>>>>>>>> how
>> much
>>>>>>>>> work is required for each of those options and if there are
>>>>>>>>> other
>>>>>>>>> legal
>>>>>>>>> hurdles.
>>>>>>>>>
>>>>>>>>> Are there other options?
>>>>>>>>> Other thoughts/concerns?
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Till
>>>>>>>>>
>>>>>>>>> [4] https://www.apache.org/legal/resolved.html#category-x
>>>>>>>>>
>>>>>>>>> On 25 Jun 2017, at 13:57, Riyafa Abdul Hameed wrote:
>>>>>>>>>
>>>>>>>>> Dear all,
>>>>>>>>>
>>>>>>>>> I implemented parse_geojon() function[1] using esri-geometry
>>>>>>>>> api[2]
>>>>>>>>>>
>>>>>>>>>> which
>>>>>>>>>
>>>>>>>> is apache-2.0 licensed. But this api uses org.json as a
>>>>>>>> dependency.
>>>>>>>>
>>>>>>>>> org.json is licensed under JSON which causes a license issue
>>>>>>>>> in the
>>>>>>>>>>
>>>>>>>>>> code
>>>>>>>>>
>>>>>>>> I
>>>>>>>>
>>>>>>>>> have written[3]. What can I do about this issue?
>>>>>>>>>>
>>>>>>>>>> [1] https://asterix-gerrit.ics.uci.edu/1838
>>>>>>>>>> [2]https://github.com/Esri/geometry-api-java
>>>>>>>>>> [3]
>>>>>>>>>> https://asterix-jenkins.ics.uci.edu/job/asterix-gerrit-integ
>>>>>>>>>> ration-tests/3290/
>>>>>>>>>>
>>>>>>>>>> Thank you.
>>>>>>>>>> Yours sincerely,
>>>>>>>>>> Riyafa
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>
>>>>>>> *Regards,*
>>>>>>> Wail Alkowaileet
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>
>>
>>
>> --
>>
>> Ahmed Eldawy
>> Assistant Professor
>> http://www.cs.ucr.edu/~eldawy
>> Tel: +1 (951) 827-5654
>>
>
>
>
> --
> Riyafa Abdul Hameed
> Undergraduate, University of Moratuwa
>
> Email: riyafa.12@cse.mrt.ac.lk
> Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/>
> <http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa>
> <http://twitter.com/Riyafa1>
Re: License issue when using esri geometry api
Posted by Riyafa Abdul Hameed <ri...@cse.mrt.ac.lk>.
Dear all,
Is there a way to ship a jar file as a dependency for AsterixDB apart from
the method I have used here[1]. This is because the build of asterix-app
seems to fail[2] when I use the external jar file like this.
Though I am unable to find a connection between the failure and the
dependency it seems I need to assume that it is the cause, because
otherwise if I use the Maven-released version the build passes without
issue.
Any help would be highly appreciated.
[1]
https://asterix-gerrit.ics.uci.edu/#/c/1895/3/asterixdb/asterix-om/pom.xml
[2] https://asterix-gerrit.ics.uci.edu/#/c/1895
On 22 July 2017 at 01:59, Ahmed Eldawy <el...@cs.ucr.edu> wrote:
> Although Esri resolved the issue, their Maven-released version still relies
> on the incompatible library. We can wait until they release a new version
> on Maven but this might take a while. To be able to merge the current code,
> we might need to compile our own JAR file and ship it with the source code.
> Do you know if this is possible/allowed/recommended in AsterixDB? Is there
> another preferred way to handle this issue? Keep in mind that, most likely,
> the summer project will conclude before Esri releases the new version.
>
> Thanks
> Ahmed
>
> On Tue, Jul 11, 2017 at 11:04 AM, Mike Carey <dt...@gmail.com> wrote:
>
> > NICE!!!
> >
> >
> >
> > On 7/11/17 9:39 AM, Ahmed Eldawy wrote:
> >
> >> There's a good news. Riyafa has opened an issue on ESRI Geometry API
> >> project on Github about the license problem and they made the necessary
> >> changes to remove the bad dependency.
> >> https://github.com/Esri/geometry-api-java/issues/135
> >> The changes are on their github repository but they are not released
> yet.
> >> I
> >> think we can just continue what we're doing and wait for the new release
> >> to
> >> hit Maven repository.
> >>
> >> Thanks
> >> Ahmed
> >>
> >> On Mon, Jun 26, 2017 at 7:55 AM, Mike Carey <dt...@gmail.com> wrote:
> >>
> >> It sounds like the best option is 4 minus parsing, then, if we can do
> >>> that. (Which would also address Wail's comments, which could be a
> killer
> >>> for big data eventually.) If not, we could go with 2 for the summer
> as a
> >>> first step, I guess? (But figuring out the feasibility of 4 would be
> >>> great...)
> >>>
> >>> Cheers,
> >>>
> >>> Mike
> >>>
> >>>
> >>>
> >>> On 6/26/17 2:59 AM, Ahmed Eldawy wrote:
> >>>
> >>> It seems that (3) would require modifying the open source Esri API
> >>>> library
> >>>> which I don't like. Not only for the overhead of understanding and
> >>>> modifying the code, but also for deviating from the standard library
> >>>> which
> >>>> means we will miss future updates. One of the reasons we chose to use
> >>>> Esri
> >>>> API is the hope that it will be well-maintained in the future.
> >>>> This leaves us with (4). I don't know if it is technically possible to
> >>>> depend on the standard Esri API without using the non-compliant
> library
> >>>> or
> >>>> not. If this is possible, then we can just use the computational
> >>>> geometry
> >>>> (CG) functionality from the library, and provide our own GeoJSON
> parser.
> >>>> If
> >>>> this is not possible, then I would rather consider the use of another
> >>>> library, e.g., JTS.
> >>>>
> >>>>
> >>>> Thanks
> >>>> Ahmed
> >>>>
> >>>> On Sun, Jun 25, 2017 at 11:47 AM, Wail Alkowaileet <
> wael.y.k@gmail.com>
> >>>> wrote:
> >>>>
> >>>> I can see from the code that there is a serder steps as such: Asterix
> >>>>
> >>>>> Object (binary) --> JSON (String) --> Esri geometry (Java object) -->
> >>>>> Esri
> >>>>> geometry (binary).
> >>>>> I think it would be nice if there is a binary-to-binary conversion
> >>>>> without
> >>>>> any deserialization (4th option).
> >>>>>
> >>>>> On Sun, Jun 25, 2017 at 6:36 PM, Mike Carey <dt...@gmail.com>
> wrote:
> >>>>>
> >>>>> Agreed that 3 or 4 are what we'll need to do....! (Sigh.)
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 6/25/17 5:57 AM, Till Westmann wrote:
> >>>>>>
> >>>>>> Hi Riyafa,
> >>>>>>
> >>>>>>> I think that the problem is bigger than the failing test. The JSON
> >>>>>>> license itself is not acceptable for inclusion in an Apache
> artifact
> >>>>>>> [4]. So we cannot use the ESRI API as-is, if we want the GeoJSON
> >>>>>>> functionality be a non-optional part of AsterixDB.
> >>>>>>>
> >>>>>>> Here are a few options I see:
> >>>>>>> 1) Make GeoJSON an optional part of AsterixDB (separate download
> >>>>>>> from a
> >>>>>>> non-Apache location).
> >>>>>>> 2) Make JSON.org a dependency that is not shipped (i.e. each user
> >>>>>>> would
> >>>>>>> have to download and install those jars separately - and get
> >>>>>>> error
> >>>>>>> messages if the jars are not available).
> >>>>>>> 3) Create a clone/copy of the ESRI API that uses another JSON
> >>>>>>> library.
> >>>>>>> 4) Do all of the parsing independently from the ESRI API.
> >>>>>>>
> >>>>>>> I’m not sure if 1) is a good option as the extensibility in this
> part
> >>>>>>> of the code might not be sufficient to support this option easily.
> >>>>>>> 2) is technically easier, but it involves an unpleasant user
> >>>>>>> experience.
> >>>>>>> Also, I think that both 1) and 2) are not desirable, as GeoJSON
> >>>>>>> should
> >>>>>>> be supported by vanilla AsterixDB.
> >>>>>>> For 3) and 4) we would need to look into the details to see how
> much
> >>>>>>> work is required for each of those options and if there are other
> >>>>>>> legal
> >>>>>>> hurdles.
> >>>>>>>
> >>>>>>> Are there other options?
> >>>>>>> Other thoughts/concerns?
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>> Till
> >>>>>>>
> >>>>>>> [4] https://www.apache.org/legal/resolved.html#category-x
> >>>>>>>
> >>>>>>> On 25 Jun 2017, at 13:57, Riyafa Abdul Hameed wrote:
> >>>>>>>
> >>>>>>> Dear all,
> >>>>>>>
> >>>>>>> I implemented parse_geojon() function[1] using esri-geometry api[2]
> >>>>>>>>
> >>>>>>>> which
> >>>>>>>
> >>>>>> is apache-2.0 licensed. But this api uses org.json as a dependency.
> >>>>>>
> >>>>>>> org.json is licensed under JSON which causes a license issue in the
> >>>>>>>>
> >>>>>>>> code
> >>>>>>>
> >>>>>> I
> >>>>>>
> >>>>>>> have written[3]. What can I do about this issue?
> >>>>>>>>
> >>>>>>>> [1] https://asterix-gerrit.ics.uci.edu/1838
> >>>>>>>> [2]https://github.com/Esri/geometry-api-java
> >>>>>>>> [3]
> >>>>>>>> https://asterix-jenkins.ics.uci.edu/job/asterix-gerrit-integ
> >>>>>>>> ration-tests/3290/
> >>>>>>>>
> >>>>>>>> Thank you.
> >>>>>>>> Yours sincerely,
> >>>>>>>> Riyafa
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>
> >>>>> *Regards,*
> >>>>> Wail Alkowaileet
> >>>>>
> >>>>>
> >>>>>
> >>
> >
>
>
> --
>
> Ahmed Eldawy
> Assistant Professor
> http://www.cs.ucr.edu/~eldawy
> Tel: +1 (951) 827-5654
>
--
Riyafa Abdul Hameed
Undergraduate, University of Moratuwa
Email: riyafa.12@cse.mrt.ac.lk
Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/>
<http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa>
<http://twitter.com/Riyafa1>
Re: License issue when using esri geometry api
Posted by Ahmed Eldawy <el...@cs.ucr.edu>.
Although Esri resolved the issue, their Maven-released version still relies
on the incompatible library. We can wait until they release a new version
on Maven but this might take a while. To be able to merge the current code,
we might need to compile our own JAR file and ship it with the source code.
Do you know if this is possible/allowed/recommended in AsterixDB? Is there
another preferred way to handle this issue? Keep in mind that, most likely,
the summer project will conclude before Esri releases the new version.
Thanks
Ahmed
On Tue, Jul 11, 2017 at 11:04 AM, Mike Carey <dt...@gmail.com> wrote:
> NICE!!!
>
>
>
> On 7/11/17 9:39 AM, Ahmed Eldawy wrote:
>
>> There's a good news. Riyafa has opened an issue on ESRI Geometry API
>> project on Github about the license problem and they made the necessary
>> changes to remove the bad dependency.
>> https://github.com/Esri/geometry-api-java/issues/135
>> The changes are on their github repository but they are not released yet.
>> I
>> think we can just continue what we're doing and wait for the new release
>> to
>> hit Maven repository.
>>
>> Thanks
>> Ahmed
>>
>> On Mon, Jun 26, 2017 at 7:55 AM, Mike Carey <dt...@gmail.com> wrote:
>>
>> It sounds like the best option is 4 minus parsing, then, if we can do
>>> that. (Which would also address Wail's comments, which could be a killer
>>> for big data eventually.) If not, we could go with 2 for the summer as a
>>> first step, I guess? (But figuring out the feasibility of 4 would be
>>> great...)
>>>
>>> Cheers,
>>>
>>> Mike
>>>
>>>
>>>
>>> On 6/26/17 2:59 AM, Ahmed Eldawy wrote:
>>>
>>> It seems that (3) would require modifying the open source Esri API
>>>> library
>>>> which I don't like. Not only for the overhead of understanding and
>>>> modifying the code, but also for deviating from the standard library
>>>> which
>>>> means we will miss future updates. One of the reasons we chose to use
>>>> Esri
>>>> API is the hope that it will be well-maintained in the future.
>>>> This leaves us with (4). I don't know if it is technically possible to
>>>> depend on the standard Esri API without using the non-compliant library
>>>> or
>>>> not. If this is possible, then we can just use the computational
>>>> geometry
>>>> (CG) functionality from the library, and provide our own GeoJSON parser.
>>>> If
>>>> this is not possible, then I would rather consider the use of another
>>>> library, e.g., JTS.
>>>>
>>>>
>>>> Thanks
>>>> Ahmed
>>>>
>>>> On Sun, Jun 25, 2017 at 11:47 AM, Wail Alkowaileet <wa...@gmail.com>
>>>> wrote:
>>>>
>>>> I can see from the code that there is a serder steps as such: Asterix
>>>>
>>>>> Object (binary) --> JSON (String) --> Esri geometry (Java object) -->
>>>>> Esri
>>>>> geometry (binary).
>>>>> I think it would be nice if there is a binary-to-binary conversion
>>>>> without
>>>>> any deserialization (4th option).
>>>>>
>>>>> On Sun, Jun 25, 2017 at 6:36 PM, Mike Carey <dt...@gmail.com> wrote:
>>>>>
>>>>> Agreed that 3 or 4 are what we'll need to do....! (Sigh.)
>>>>>
>>>>>>
>>>>>>
>>>>>> On 6/25/17 5:57 AM, Till Westmann wrote:
>>>>>>
>>>>>> Hi Riyafa,
>>>>>>
>>>>>>> I think that the problem is bigger than the failing test. The JSON
>>>>>>> license itself is not acceptable for inclusion in an Apache artifact
>>>>>>> [4]. So we cannot use the ESRI API as-is, if we want the GeoJSON
>>>>>>> functionality be a non-optional part of AsterixDB.
>>>>>>>
>>>>>>> Here are a few options I see:
>>>>>>> 1) Make GeoJSON an optional part of AsterixDB (separate download
>>>>>>> from a
>>>>>>> non-Apache location).
>>>>>>> 2) Make JSON.org a dependency that is not shipped (i.e. each user
>>>>>>> would
>>>>>>> have to download and install those jars separately - and get
>>>>>>> error
>>>>>>> messages if the jars are not available).
>>>>>>> 3) Create a clone/copy of the ESRI API that uses another JSON
>>>>>>> library.
>>>>>>> 4) Do all of the parsing independently from the ESRI API.
>>>>>>>
>>>>>>> I’m not sure if 1) is a good option as the extensibility in this part
>>>>>>> of the code might not be sufficient to support this option easily.
>>>>>>> 2) is technically easier, but it involves an unpleasant user
>>>>>>> experience.
>>>>>>> Also, I think that both 1) and 2) are not desirable, as GeoJSON
>>>>>>> should
>>>>>>> be supported by vanilla AsterixDB.
>>>>>>> For 3) and 4) we would need to look into the details to see how much
>>>>>>> work is required for each of those options and if there are other
>>>>>>> legal
>>>>>>> hurdles.
>>>>>>>
>>>>>>> Are there other options?
>>>>>>> Other thoughts/concerns?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Till
>>>>>>>
>>>>>>> [4] https://www.apache.org/legal/resolved.html#category-x
>>>>>>>
>>>>>>> On 25 Jun 2017, at 13:57, Riyafa Abdul Hameed wrote:
>>>>>>>
>>>>>>> Dear all,
>>>>>>>
>>>>>>> I implemented parse_geojon() function[1] using esri-geometry api[2]
>>>>>>>>
>>>>>>>> which
>>>>>>>
>>>>>> is apache-2.0 licensed. But this api uses org.json as a dependency.
>>>>>>
>>>>>>> org.json is licensed under JSON which causes a license issue in the
>>>>>>>>
>>>>>>>> code
>>>>>>>
>>>>>> I
>>>>>>
>>>>>>> have written[3]. What can I do about this issue?
>>>>>>>>
>>>>>>>> [1] https://asterix-gerrit.ics.uci.edu/1838
>>>>>>>> [2]https://github.com/Esri/geometry-api-java
>>>>>>>> [3]
>>>>>>>> https://asterix-jenkins.ics.uci.edu/job/asterix-gerrit-integ
>>>>>>>> ration-tests/3290/
>>>>>>>>
>>>>>>>> Thank you.
>>>>>>>> Yours sincerely,
>>>>>>>> Riyafa
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>
>>>>> *Regards,*
>>>>> Wail Alkowaileet
>>>>>
>>>>>
>>>>>
>>
>
--
Ahmed Eldawy
Assistant Professor
http://www.cs.ucr.edu/~eldawy
Tel: +1 (951) 827-5654
Re: License issue when using esri geometry api
Posted by Mike Carey <dt...@gmail.com>.
NICE!!!
On 7/11/17 9:39 AM, Ahmed Eldawy wrote:
> There's a good news. Riyafa has opened an issue on ESRI Geometry API
> project on Github about the license problem and they made the necessary
> changes to remove the bad dependency.
> https://github.com/Esri/geometry-api-java/issues/135
> The changes are on their github repository but they are not released yet. I
> think we can just continue what we're doing and wait for the new release to
> hit Maven repository.
>
> Thanks
> Ahmed
>
> On Mon, Jun 26, 2017 at 7:55 AM, Mike Carey <dt...@gmail.com> wrote:
>
>> It sounds like the best option is 4 minus parsing, then, if we can do
>> that. (Which would also address Wail's comments, which could be a killer
>> for big data eventually.) If not, we could go with 2 for the summer as a
>> first step, I guess? (But figuring out the feasibility of 4 would be
>> great...)
>>
>> Cheers,
>>
>> Mike
>>
>>
>>
>> On 6/26/17 2:59 AM, Ahmed Eldawy wrote:
>>
>>> It seems that (3) would require modifying the open source Esri API library
>>> which I don't like. Not only for the overhead of understanding and
>>> modifying the code, but also for deviating from the standard library which
>>> means we will miss future updates. One of the reasons we chose to use Esri
>>> API is the hope that it will be well-maintained in the future.
>>> This leaves us with (4). I don't know if it is technically possible to
>>> depend on the standard Esri API without using the non-compliant library or
>>> not. If this is possible, then we can just use the computational geometry
>>> (CG) functionality from the library, and provide our own GeoJSON parser.
>>> If
>>> this is not possible, then I would rather consider the use of another
>>> library, e.g., JTS.
>>>
>>>
>>> Thanks
>>> Ahmed
>>>
>>> On Sun, Jun 25, 2017 at 11:47 AM, Wail Alkowaileet <wa...@gmail.com>
>>> wrote:
>>>
>>> I can see from the code that there is a serder steps as such: Asterix
>>>> Object (binary) --> JSON (String) --> Esri geometry (Java object) -->
>>>> Esri
>>>> geometry (binary).
>>>> I think it would be nice if there is a binary-to-binary conversion
>>>> without
>>>> any deserialization (4th option).
>>>>
>>>> On Sun, Jun 25, 2017 at 6:36 PM, Mike Carey <dt...@gmail.com> wrote:
>>>>
>>>> Agreed that 3 or 4 are what we'll need to do....! (Sigh.)
>>>>>
>>>>>
>>>>> On 6/25/17 5:57 AM, Till Westmann wrote:
>>>>>
>>>>> Hi Riyafa,
>>>>>> I think that the problem is bigger than the failing test. The JSON
>>>>>> license itself is not acceptable for inclusion in an Apache artifact
>>>>>> [4]. So we cannot use the ESRI API as-is, if we want the GeoJSON
>>>>>> functionality be a non-optional part of AsterixDB.
>>>>>>
>>>>>> Here are a few options I see:
>>>>>> 1) Make GeoJSON an optional part of AsterixDB (separate download from a
>>>>>> non-Apache location).
>>>>>> 2) Make JSON.org a dependency that is not shipped (i.e. each user would
>>>>>> have to download and install those jars separately - and get error
>>>>>> messages if the jars are not available).
>>>>>> 3) Create a clone/copy of the ESRI API that uses another JSON library.
>>>>>> 4) Do all of the parsing independently from the ESRI API.
>>>>>>
>>>>>> I’m not sure if 1) is a good option as the extensibility in this part
>>>>>> of the code might not be sufficient to support this option easily.
>>>>>> 2) is technically easier, but it involves an unpleasant user
>>>>>> experience.
>>>>>> Also, I think that both 1) and 2) are not desirable, as GeoJSON should
>>>>>> be supported by vanilla AsterixDB.
>>>>>> For 3) and 4) we would need to look into the details to see how much
>>>>>> work is required for each of those options and if there are other legal
>>>>>> hurdles.
>>>>>>
>>>>>> Are there other options?
>>>>>> Other thoughts/concerns?
>>>>>>
>>>>>> Cheers,
>>>>>> Till
>>>>>>
>>>>>> [4] https://www.apache.org/legal/resolved.html#category-x
>>>>>>
>>>>>> On 25 Jun 2017, at 13:57, Riyafa Abdul Hameed wrote:
>>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>>> I implemented parse_geojon() function[1] using esri-geometry api[2]
>>>>>>>
>>>>>> which
>>>>> is apache-2.0 licensed. But this api uses org.json as a dependency.
>>>>>>> org.json is licensed under JSON which causes a license issue in the
>>>>>>>
>>>>>> code
>>>>> I
>>>>>>> have written[3]. What can I do about this issue?
>>>>>>>
>>>>>>> [1] https://asterix-gerrit.ics.uci.edu/1838
>>>>>>> [2]https://github.com/Esri/geometry-api-java
>>>>>>> [3]
>>>>>>> https://asterix-jenkins.ics.uci.edu/job/asterix-gerrit-integ
>>>>>>> ration-tests/3290/
>>>>>>>
>>>>>>> Thank you.
>>>>>>> Yours sincerely,
>>>>>>> Riyafa
>>>>>>>
>>>>>>>
>>>> --
>>>>
>>>> *Regards,*
>>>> Wail Alkowaileet
>>>>
>>>>
>