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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>>>> 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 <[email protected]> >>>>>>>> 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 < >>>>>>>>>> >>>>>>>>> [email protected]> >>>>>> >>>>>>> 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 <[email protected]> >>>>>>>>>>> >>>>>>>>>> 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: [email protected] >>>>> 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: [email protected] > 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: [email protected] Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/> <http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa> <http://twitter.com/Riyafa1>
