That's great!!
Hope to try it today.

On Fri, 18 Dec 2020 at 10:36, Jia Yu <ji...@apache.org> wrote:

> Hi Netanel and Paweł,
>
> The JTS issue has resolved. I am now waiting for JTS 1.18 release but we
> are currently using 1.17.1 + copied files. So we are good anyway.
>
> So the next step will be documentation and stage the first release.
> Although I really want to resolve the ST_Transform lock contention issue,
> it requires a new ST_FlipCoordinate which may take a few days. I will see
> whether I can finish this by Christmas but not sure.
>
> @Netanel Malka <netanel...@gmail.com> Could you please compile the master
> branch and try to deploy a SNAPSHOT release on your own? I have pushed a
> few snapshots but I would like to see whether you can do it too. Please
> follow the steps here:
> https://gist.github.com/jiayuasu/849e1f3bf7a2dd11593ca27c14e9e92d
>
> @Paweł Kociński <pawel93kocin...@gmail.com> Step 1. Could you please
> update
> the new Python Adaptor documentation? Step 2. Could you please try to
> deploy a SNAPSHOT release to PyPI? You can find some help here:
> https://incubator.apache.org/guides/distribution.html
>
> Thank you very much!
> Jia
>
>
> On Thu, Dec 10, 2020 at 3:26 PM Jim Hughes <jhug...@ccri.com> wrote:
>
> > Hi Jia,
> >
> > A JTS 1.18.0 release would not be just for Apache Sedona.;) Getting it
> > out sooner would let others projects adopt it sooner (I'm thinking of
> > GeoTools and GeoServer).  I'm excited to see the improvements to the
> > overlay operations...
> >
> > I've traded some emails and chats with Martin.  It sounds like he is ok
> > with cutting JTS 1.18.0 in the next week; I'll be working with him and
> > Jody to do our best to make that happen.
> >
> > Anyhow, in terms of shading, there are few things I'd suggest. First,
> > I'd suggest that libraries which can function as libraries have a
> > version of the jar which does not include any dependencies.  If you go
> > along with that, sedona-core should produce a jar on its own and another
> > module could build a "batteries included" jar for users to drop into
> Spark.
> >
> > Separate from that, I'd recommend that when you copy entire files into a
> > project that you change the package for those classes. Concretely, you
> > could just prepend org.apache.sedona to the package names for those 5
> > classes.  (This assumes that it is possible.  Sometimes there may be
> > issues around package protected access, etc.)
> >
> > As it stands right now, if a user tries to use Sedona with any other
> > library that pulls in JTS, then they will be at the mercy of the class
> > loading order.  If the JTS jar comes in elsewhere, your versions of the
> > RTree may not be loaded!  The exception would look like a JTS issue and
> > it be fairly confusing for most people to debug.
> >
> > With those issues taken together, a user could load up a sedona-core jar
> > (which wouldn't have JTS or org.wololo.geojson) with a different version
> > of JTS potentially provided by another project and be able to use Sedona
> > and other projects together.
> >
> > Thanks for working through the issues to be able to use a release of
> > JTS.  Hopefully we can knock this out over the next week, and if not,
> > you do have an approach which would let you release Sedona.
> >
> > Cheers,
> >
> > Jim
> >
> > On 12/10/2020 2:33 PM, Jia Yu wrote:
> > > Hi Jim,
> > >
> > > Thanks for your feedback.
> > >
> > > 1. I indeed asked Martin, Jody, and you in the JTS Gitter chat. It
> looks
> > > like Martin still needs some time to fix some functions. In fact, I
> feel
> > it
> > > is inappropriate to push Martin, an OSS contributor, to draw a release
> > just
> > > for us :)
> > > 2. I also saw your comment on the GitHub PR. My current solution in
> that
> > PR
> > > is that use JTS 1.17.1 official release + 5 copied JTS index classes. I
> > > also use the maven shade plugin to filter out the 5 corresponding
> classes
> > > in JTS 1.17.1 jar (
> > >
> >
> https://github.com/apache/incubator-sedona/pull/495/files#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R278
> > )
> > > to avoid duplicates . Do you think I should even use the shade plugin
> to
> > > relocate these classes to a different path?
> > >
> > > Thanks,
> > > Jia
> > >
> > > On Thu, Dec 10, 2020 at 6:25 AM Jim Hughes <jhug...@ccri.com> wrote:
> > >
> > >> Hi all,
> > >>
> > >> It may be worth discussing with the JTS directly what their schedule
> is
> > >> rather than guessing at it.
> > >>
> > >> I am for finding a way for Sedona to work with JTS with the least
> > >> friction for the Sedona development team and the Sedona users.  I feel
> > >> that copying or forking complex codebases will likely lead to bigger
> > >> issues downstream.
> > >>
> > >> Also, is the only hang-up around the serialization of R-Trees? If so,
> > >> could you use reflection with JTS 1.17.0?  That change may be pretty
> > >> quick to make...
> > >>
> > >> Cheers,
> > >>
> > >> Jim
> > >>
> > >> On 12/9/20 10:35 PM, Jia Yu wrote:
> > >>> Hi Felix, Jim and Netanel and other Sedona committers,
> > >>>
> > >>> As you know, my JTS PR has been accepted to JTS 1.18-SNAPSHOT and we
> > are
> > >>> waiting for the official release of JTS 1.18 on Maven. However, I
> > didn't
> > >>> see a clear date when JTS 1.18 will be published. I guess this will
> > take
> > >>> one or two months to happen.
> > >>>
> > >>> Currently, Sedona 1.0.0 release is blocked by this issue (Maven
> Central
> > >>> does not allow SNAPSHOTS to be dependencies). Since we are so
> desperate
> > >> to
> > >>> publish Sedona 1.0.0 as soon as possible, I proposed to copy the
> latest
> > >> JTS
> > >>> source code into Sedona-core in our 1.0.0 release. In the future
> > release
> > >>> (say Sedona 1.0.1), we can drop JTS source code and use their Maven
> > >>> release. JTS source code is dual-licensed under Eclipse Public
> License
> > >> 2.0
> > >>> and Eclipse Distribution License 1.0 (a BSD Style License). So it is
> > safe
> > >>> to keep it in Sedona.
> > >>>
> > >>> What do you think? @Jim Hughes <jhug...@ccri.com>  Is this a good
> > idea?
> > >>>
> > >>> Thanks,
> > >>> Jia
> > >>>
> > >>> On Fri, Dec 4, 2020 at 10:43 PM Jia Yu <jiayu198...@gmail.com>
> wrote:
> > >>>
> > >>>> Hi Netanel,
> > >>>>
> > >>>> So for Sedona SQL 1.0.0 on Spark 2.4, we can do
> > >>>> "sedona-sql_2.11-2.4-1.0.0-incubator" , right?
> > >>>>
> > >>>> Sedona 1.0 on Spark 2.4 and 3.0 will be compiled against Scala 2.11
> > and
> > >>>> 2.12. I believe this can be done via different compilation target in
> > >> Maven.
> > >>>> I am currently looking at whether I can do conditional compilation
> > using
> > >>>> Maven (similar to C++ #ifdef) because there is a change in
> Aggregator
> > in
> > >>>> Spark 3.0. Otherwise I always need to maintain a separate branch for
> > >> Sedona
> > >>>> on Spark 2.4
> > >>>>
> > >>>> It looks OK to me.
> > >>>>
> > >>>> On Fri, Dec 4, 2020 at 1:12 AM Netanel Malka <netanel...@gmail.com>
> > >> wrote:
> > >>>>> Hi,
> > >>>>> I think that we can follow the Apache Spark convention as you can
> see
> > >>>>> here
> > >>>>> <
> > >>
> https://repo1.maven.org/maven2/org/apache/spark/spark-core_2.12/3.0.1/
> > >.
> > >>>>> For example:
> > >>>>> sedona-sql_2.11-2.4, where 2.11 -> scala version and 2.4 -> spark
> > >> version
> > >>>>>    What do you think?
> > >>>>>
> > >>>>>
> > >>>>> On Fri, 4 Dec 2020 at 10:34, Jia Yu <jiayu198...@gmail.com> wrote:
> > >>>>>
> > >>>>>> Dear all,
> > >>>>>>
> > >>>>>> The current status:
> > >>>>>> 1. Move to JTS PR has been merged to the master branch. If JTS
> 1.18
> > >> gets
> > >>>>>> published in a few weeks, we will use the latest JTS. Otherwise,
> we
> > >> still
> > >>>>>> need to use my fork for this release. But Sedona API is now
> > >> finalized. From
> > >>>>>> the user perspective, use my fork or JTS official release should
> not
> > >> make
> > >>>>>> any difference.
> > >>>>>> 2. Sedona doc update is in progress. I am half way there. You can
> > >> track
> > >>>>>> the progress here:
> > >> https://github.com/apache/incubator-sedona/pull/493
> > >>>>>> 3. I will create a separate branch to test Spark 2.4 over this
> > >> weekend.
> > >>>>>> 4. Pawel is working on his improvement on RDD-SQL Python adapter.
> > >>>>>>
> > >>>>>> Question:
> > >>>>>>
> > >>>>>> What is the most appropriate maven artifact name for Sedona on
> Spark
> > >>>>>> 2.4? I used to put "sedona-sql_2.4". But it looks like "_2.4" is
> > >> usually
> > >>>>>> reserved for specifying the Scala version. How about
> > >> "sedona-sql-spark2"?
> > >>>>>> Should we also use "sedona-sql-spark3" for Spark 3.0?
> > >>>>>>
> > >>>>>> Thanks,
> > >>>>>> Jia
> > >>>>>>
> > >>>>>> On Tue, Nov 24, 2020 at 8:16 AM Jim Hughes <jhug...@ccri.com>
> > wrote:
> > >>>>>>
> > >>>>>>> Hi all,
> > >>>>>>>
> > >>>>>>> Felix, good to know that a WIP disclaimer is standard practice
> and
> > >> will
> > >>>>>>> let things move forward!
> > >>>>>>>
> > >>>>>>> Jia, I believe that page is explaining that a portion of the code
> > in
> > >>>>>>> various GeoTools modules has other licenses on it.  As such,
> > gt-main
> > >> is
> > >>>>>>> mostly LGPL with some BSD code as well.
> > >>>>>>>
> > >>>>>>> Cheers,
> > >>>>>>>
> > >>>>>>> Jim
> > >>>>>>>
> > >>>>>>> On 11/23/2020 9:50 PM, Jia Yu wrote:
> > >>>>>>>> Thank you, Felix. I will use the WIP disclaimer.
> > >>>>>>>>
> > >>>>>>>> To answer Jim's question, GeoTools components use different
> > >> licenses:
> > >>>>>>>> https://docs.geotools.org/latest/userguide/welcome/license.html
> > >>>>>>>>
> > >>>>>>>> GT-main uses BSD, so its binary can be included in Sedona's
> > release.
> > >>>>>>>> Other components in GeoTools use LGPL, but Sedona only uses them
> > for
> > >>>>>>> CRS
> > >>>>>>>> transformation. I already set the dependency scope to "provided"
> > in
> > >>>>>>>> Sedona's POM.xml. If a user wants to use CRS transformation in
> > >>>>>>> Sedona, they
> > >>>>>>>> will have to add some GeoTools library by themselves.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Mon, Nov 23, 2020 at 6:24 PM Felix Cheung <
> > >> felixche...@apache.org>
> > >>>>>>> wrote:
> > >>>>>>>>> On Mon, Nov 23, 2020 at 6:03 PM Felix Cheung <
> > >> felixche...@apache.org
> > >>>>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> I’d strongly recommend the community to move towards the first
> > >>>>>>> release
> > >>>>>>>>>> with the WIP disclaimer
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>
> >
> https://incubator.apache.org/policy/incubation.html#work_in_progress_disclaimer
> > >>>>>>>>>> https://incubator.apache.org/policy/incubation.html#releases
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> As for the LGPL dependency specifically, a replacement will be
> > >>>>>>> needed?
> > >>>>>>>>> To clarify, ok to note in the WIP disclaimer- so it can be
> > released
> > >>>>>>> with
> > >>>>>>>>> this.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>> On Mon, Nov 23, 2020 at 11:15 AM Jim Hughes <jhug...@ccri.com
> >
> > >>>>>>> wrote:
> > >>>>>>>>>>> Hi all,
> > >>>>>>>>>>>
> > >>>>>>>>>>> Has the fact that one of the dependencies is LGPL (GeoTools)
> > been
> > >>>>>>>>>>> discussed / addressed?  (See
> > >>>>>>>>>>> https://www.apache.org/legal/resolved.html#category-x)
> > >>>>>>>>>>>
> > >>>>>>>>>>> I'm asking since I don't know if the ASF has any recommended
> > work
> > >>>>>>>>>>> arounds for shipping code with licenses that it does not
> > approve
> > >>>>>>> of.
> > >>>>>>>>>>> Cheers,
> > >>>>>>>>>>>
> > >>>>>>>>>>> Jim
> > >>>>>>>>>>>
> > >>>>>>>>>>> On 11/23/20 1:41 PM, Felix Cheung wrote:
> > >>>>>>>>>>>> I can help review around Dev 13 to give a first pass. It
> > should
> > >>>>>>> give
> > >>>>>>>>>>> you an
> > >>>>>>>>>>>> easier path to IPMC vote.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Sun, Nov 22, 2020 at 10:50 PM Jia Yu <
> > jiayu198...@gmail.com>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>>>> Hi Pawel and everyone,
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Let's do this in the first Sedona release. But can you
> please
> > >>>>>>> first
> > >>>>>>>>>>> fix the
> > >>>>>>>>>>>>> Python API for our Move-to-JTS PR, and then work on this
> one?
> > >> If
> > >>>>>>> this
> > >>>>>>>>>>>>> Python RDD-DF Adapter PR might slow down our progress of
> > >>>>>>> releasing
> > >>>>>>>>>>> Sedona
> > >>>>>>>>>>>>> before Christmas, we can postpone it to Sedona 1.0.1 or
> > 1.1.0.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> @everyone
> > >>>>>>>>>>>>> Our top priority is to draw the first Sedona release ASAP.
> > >> Users
> > >>>>>>> have
> > >>>>>>>>>>> been
> > >>>>>>>>>>>>> waiting for almost six months. Let's push hard to publish
> the
> > >>>>>>> first
> > >>>>>>>>>>> Sedona
> > >>>>>>>>>>>>> release to Maven Central and PyPI before Christmas. In
> order
> > to
> > >>>>>>> make
> > >>>>>>>>> it
> > >>>>>>>>>>>>> happen,
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Finalize coding and documentation before Dec 6:
> > >>>>>>>>>>>>> 1. I believe the Move-to-JTS PR will be done in around one
> > >> week.
> > >>>>>>>>>>>>> 2. Then we can accept Pawel' Python RDD-DF Adapter PR, if
> > >>>>>>> necessary
> > >>>>>>>>>>>>> 3. I will work on Sedona documentation.
> > >>>>>>>>>>>>> 4. @Netanel will work on Sedona support of Spark 2.4 and
> > Scala
> > >>>>>>> 2.11.
> > >>>>>>>>> I
> > >>>>>>>>>>> will
> > >>>>>>>>>>>>> first create a branch for it to illustrate some necessary
> > >>>>>>> changes in
> > >>>>>>>>>>> Sedona
> > >>>>>>>>>>>>> SQL for Spark 2.4.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Final walk-through before Dec 13
> > >>>>>>>>>>>>> 1. Netanel can test the release management for Sedona.
> > >>>>>>>>>>>>> 2. Other committers can go through the docs, release notes
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Community voting before Dec 20
> > >>>>>>>>>>>>> 1. Sedona community voting: before Dec 16
> > >>>>>>>>>>>>> 2. Apache Incubator voting: before Dec 20
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Push to Maven Central and PyPi before Dec 24
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Please feel free to comment if you have any suggestions!
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Jia
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> On Sun, Nov 22, 2020 at 9:51 AM Paweł Kociński <
> > >>>>>>>>>>> pawel93kocin...@gmail.com>
> > >>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Hi,
> > >>>>>>>>>>>>>> I saw some users reported need to improve Python RDD API
> in
> > >> two
> > >>>>>>>>>>>>> scenarios:
> > >>>>>>>>>>>>>> - converting spatial flat join result to df
> > >>>>>>>>>>>>>> - saving spatial flat join result directly to external
> > storage
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Currently SerDe between jvm and Python causes additional
> > time
> > >>>>>>> needed
> > >>>>>>>>>>> to
> > >>>>>>>>>>>>>> compute the result. I have a local branch with tests where
> > >> this
> > >>>>>>>>>>>>>> functionality is available (need 3-4 days to make it 100%
> > >>>>>>> ready), in
> > >>>>>>>>>>> two
> > >>>>>>>>>>>>>> above scenarios there will be almost no difference between
> > >>>>>>> Python
> > >>>>>>>>> and
> > >>>>>>>>>>>>> Scala
> > >>>>>>>>>>>>>> or Java API. Should I create PR to include this feature
> > within
> > >>>>>>> the
> > >>>>>>>>>>> first
> > >>>>>>>>>>>>>> Sedona release ?
> > >>>>>>>>>>>>>> Regards,
> > >>>>>>>>>>>>>> Paweł
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> pon., 16 lis 2020 o 08:29 Jia Yu <jiayu198...@gmail.com>
> > >>>>>>>>> napisał(a):
> > >>>>>>>>>>>>>>> Dear all,
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Thanks for all your suggestions.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> 1. To completely solve the long-overdue JTS issue, I
> made a
> > >>>>>>> Sedona
> > >>>>>>>>> PR
> > >>>>>>>>>>>>> and
> > >>>>>>>>>>>>>>> two JTS PRs. @Jim Hughes <jhug...@ccri.com> , @Paweł
> > >> Kociński
> > >>>>>>>>>>>>>>> <pawel93kocin...@gmail.com> , I, and probably Martin
> from
> > >> JTS
> > >>>>>>> will
> > >>>>>>>>>>> take
> > >>>>>>>>>>>>>>> care of these PRs in the coming days.
> > >>>>>>>>>>>>>>> (1) Sedona PR:
> > >>>>>>> https://github.com/apache/incubator-sedona/pull/488
> > >>>>>>>>>>>>>>> (2) JTS PR: https://github.com/locationtech/jts/pull/633
> > >>>>>>>>>>>>>>> https://github.com/locationtech/jts/pull/634
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> 2. To move forward with the first release, I have deleted
> > the
> > >>>>>>>>>>> "SNAPSHOT"
> > >>>>>>>>>>>>>>> in my JTS 1.16 fork.
> > >>>>>>>>>>>>>>> Most likely, we have to move forward with my JTS 1.16
> fork
> > in
> > >>>>>>> the
> > >>>>>>>>>>> first
> > >>>>>>>>>>>>>>> Sedona release because of the conflict among
> JTStoGeoJSON,
> > >>>>>>>>> GeoTools,
> > >>>>>>>>>>> and
> > >>>>>>>>>>>>>>> JTS 1.17.
> > >>>>>>>>>>>>>>> So @Netanel Malka <netanel...@gmail.com>  could you
> please
> > >> do
> > >>>>>>>>>>> another
> > >>>>>>>>>>>>>>> dry-run on the Sedona first release on this Sedona
> branch:
> > >>>>>>>>>>>>> sedona-1.0-doc:
> > >> https://github.com/apache/incubator-sedona/tree/sedona-1.0-doc
> > >>>>>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>>>>> Jia
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> On Thu, Nov 12, 2020 at 11:36 AM Jim Hughes <
> > >> jhug...@ccri.com>
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>> Hi Mo,
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> I can definitely help.  The first step will be for Jia
> to
> > >>>>>>> push a
> > >>>>>>>>> PR
> > >>>>>>>>>>> for
> > >>>>>>>>>>>>>>>> the JTS changes.  (Since they are his changes, I cannot
> do
> > >>>>>>> this on
> > >>>>>>>>>>> his
> > >>>>>>>>>>>>>>>> behalf.)
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>      From talking to the lead JTS developer, he wanted
> to
> > see
> > >>>>>>> the
> > >>>>>>>>>>> previous
> > >>>>>>>>>>>>>>>> PR (from months/a year+ ago) split up.  I think the
> > initial
> > >> PR
> > >>>>>>>>>>> should
> > >>>>>>>>>>>>> be
> > >>>>>>>>>>>>>>>> used to discuss what changes are sensible for JTS and
> > where
> > >>>>>>> we'll
> > >>>>>>>>>>> need
> > >>>>>>>>>>>>>>>> to push some of the changes to Sedona.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Concretely, I noticed that the Sedona JTS fork changes
> the
> > >>>>>>>>> toString
> > >>>>>>>>>>> on
> > >>>>>>>>>>>>>>>> Geometry to include printing out the userData.  I
> imagine
> > >>>>>>> that may
> > >>>>>>>>>>>>> cause
> > >>>>>>>>>>>>>>>> trouble for downstream JTS users, so it'd be good to
> find
> > an
> > >>>>>>>>>>>>>>>> alternative.  One suggestion would to be add a static
> > method
> > >>>>>>> in
> > >>>>>>>>>>> Sedona
> > >>>>>>>>>>>>>>>> for printing a Geometry with its userData object.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Cheers,
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Jim
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> On 11/12/20 12:32 PM, Mohamed Sarwat wrote:
> > >>>>>>>>>>>>>>>>> Folks,
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> I totally agree with Jim on that. Jim, would you like
> to
> > >>>>>>> take the
> > >>>>>>>>>>>>> lead
> > >>>>>>>>>>>>>>>> on that - I trust that you can bring this task to
> > >> completion.
> > >>>>>>> Jia,
> > >>>>>>>>>>>>> would
> > >>>>>>>>>>>>>>>> you please let us know how we can incorporate the
> changes
> > >>>>>>> into the
> > >>>>>>>>>>> JTS
> > >>>>>>>>>>>>>>>> master branch?
> > >>>>>>>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> On Nov 12, 2020, at 10:10 AM, Jim Hughes <
> > >> jhug...@ccri.com>
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>> Hi all,
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> As a JTS committer, I have tried to request that the
> > >> Sedona
> > >>>>>>>>>>> project
> > >>>>>>>>>>>>>>>> discuss the desired changes to JTS previously.  I'd
> still
> > >>>>>>>>> encourage
> > >>>>>>>>>>>>> that.
> > >>>>>>>>>>>>>>>>>> JTS is an active project and I feel that maintaining a
> > >> fork
> > >>>>>>> of
> > >>>>>>>>> JTS
> > >>>>>>>>>>>>> is
> > >>>>>>>>>>>>>>>> unnecessary and inappropriate.
> > >>>>>>>>>>>>>>>>>> Cheers,
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Jim
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> On 11/11/20 9:04 PM, Felix Cheung wrote:
> > >>>>>>>>>>>>>>>>>>> Ah. You will need to publish it in order for the
> > >> dependency
> > >>>>>>>>> chain
> > >>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>> work
> > >>>>>>>>>>>>>>>>>>> on Maven Central
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> However, since you are not the project owner there
> you
> > >>>>>>> might
> > >>>>>>>>> need
> > >>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>> publish that under a different artifact id.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> In general, it would be best to avoid hard forking
> > >> another
> > >>>>>>>>>>> project
> > >>>>>>>>>>>>>>>> like
> > >>>>>>>>>>>>>>>>>>> this.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> On Wed, Nov 11, 2020 at 1:05 PM Jia Yu <
> > >>>>>>> jiayu198...@gmail.com
> > >>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>> Hi Netanel,
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> That links to this git submodule:
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>
> > https://github.com/jiayuasu/jts/blob/1.16.x/modules/core/pom.xml#L6
> > >>>>>>>>>>>>>>>>>>>> I can easily fix this by changing the version number
> > >> here
> > >>>>>>> to
> > >>>>>>>>>>>>> 1.16.2
> > >>>>>>>>>>>>>>>>>>>> excluding "SNAPSHOT":
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>
> > https://github.com/jiayuasu/jts/blob/1.16.x/modules/core/pom.xml#L6
> > >>>>>>>>>>>>>>>>>>>> Will this solve the problem?
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> On Wed, Nov 11, 2020 at 7:40 AM Netanel Malka <
> > >>>>>>>>>>>>> netanel...@gmail.com
> > >>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> Hi Folks,
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> I tried to make a release (dry-run) following by
> > >>>>>>>>>>>>>>>>>>>>> publishing-maven-artifacts
> > >>>>>>>>>>>>>>>>>>>>> <
> > >>>>>>> https://infra.apache.org/publishing-maven-artifacts.html>,
> > >>>>>>>>>>> and
> > >>>>>>>>>>>>> I
> > >>>>>>>>>>>>>>>>>>>>> encountered an issue.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> On sedona-core, we have jts-core as a dependency
> with
> > >> the
> > >>>>>>>>>>>>> SNAPSHOT
> > >>>>>>>>>>>>>>>>>>>>> version.
> > >>>>>>>>>>>>>>>>>>>>> (link
> > >>>>>>>>>>>>>>>>>>>>> <
> > >>>>>>>>>>>>>>>>>>>>>
> > >>
> >
> https://github.com/apache/incubator-sedona/blob/2e60fc07b0eae78ccae3876d970e677fc9319c40/core/pom.xml#L37
> > >>>>>>>>>>>>>>>>>>>>> )
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> As a prerequisite to the release process, we cannot
> > >> have
> > >>>>>>>>>>>>>>>> dependencies in a
> > >>>>>>>>>>>>>>>>>>>>> SNAPSHOT version.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> Do you have any clue about how to solve this?
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> On Mon, 9 Nov 2020 at 21:22, Netanel Malka <
> > >>>>>>>>>>> netan...@sela.co.il>
> > >>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>> OK. Thanks Felix.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> Updates:
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>        *
> > >>>>>>>>>>>>>>>>>>>>>>        *   Opened a ticket for INFRA to Enable
> Nexus
> > >>>>>>> Access For
> > >>>>>>>>>>>>>>>> Sedona<
> > >>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/INFRA-21085
> >
> > >>>>>>>>>>>>>>>>>>>>>>        *   Followed this<
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>> https://infra.apache.org/publishing-maven-artifacts.html>
> > >>>>>>>>>>> guide
> > >>>>>>>>>>>>>>>> to test
> > >>>>>>>>>>>>>>>>>>>>>> the maven release process
> > >>>>>>>>>>>>>>>>>>>>>>        *   I hope to create a PR soon for
> adjusting
> > the
> > >>>>>>> build
> > >>>>>>>>> to
> > >>>>>>>>>>>>>>>> deploy to
> > >>>>>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>>> ASF Nexus repository
> > >>>>>>>>>>>>>>>>>>>>>>        *   The key that signs the artifacts were
> > >> created
> > >>>>>>> and
> > >>>>>>>>>>> tested.
> > >>>>>>>>>>>>>>>>>>>>>> Do we want to create a candidate release for the
> > >> current
> > >>>>>>>>>>> master
> > >>>>>>>>>>>>>>>> branch?
> > >>>>>>>>>>>>>>>>>>>>>> Netanel Malka,
> > >>>>>>>>>>>>>>>>>>>>>> Big Data Consultant
> > >>>>>>>>>>>>>>>>>>>>>> [Description: Description: Description:
> Description:
> > >>>>>>>>>>>>>>>>>>>>>> cid:image001.jpg@01C85203.36A2AF30]
> > >>>>>>>>>>>>>>>>>>>>>> ________________________________
> > >>>>>>>>>>>>>>>>>>>>>> From: Felix Cheung <felixche...@apache.org>
> > >>>>>>>>>>>>>>>>>>>>>> Sent: Wednesday, November 4, 2020 19:57
> > >>>>>>>>>>>>>>>>>>>>>> To: dev@sedona.apache.org
> > >>>>>>>>>>>>>>>>>>>>>> Cc: Jinxuan Wu; Mohamed Sarwat; Netanel Malka;
> Paweł
> > >>>>>>>>> Kociński;
> > >>>>>>>>>>>>>>>> Zongsi
> > >>>>>>>>>>>>>>>>>>>>> Zhang
> > >>>>>>>>>>>>>>>>>>>>>> Subject: Re: First Sedona release
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> 1) No you don’t need KEYS file in github only on
> the
> > >>>>>>> release
> > >>>>>>>>>>>>> share
> > >>>>>>>>>>>>>>>>>>>>>> https://dist.apache.org/repos/dist/dev/incubator/
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> 2) as podling you add to
> > >>>>>>>>>>>>>>>>>>>>>> https://dist.apache.org/repos/dist/dev/incubator/
> > >>>>>>>>>>>>>>>>>>>>>> When you commit via svn you will be able to add a
> > >>>>>>>>> “directory”
> > >>>>>>>>>>>>> for
> > >>>>>>>>>>>>>>>> Sedona
> > >>>>>>>>>>>>>>>>>>>>>> 2a) for release, you basically do a svn rename to
> > move
> > >>>>>>> from
> > >>>>>>>>>>> dev
> > >>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>>>> release
> > >>>>>>>>>>>>>>>>>>>>>> “path”
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> 3) if you have java based artifacts, yes. You will
> > >>>>>>> publish
> > >>>>>>>>> to
> > >>>>>>>>>>>>>>>> Nexus,
> > >>>>>>>>>>>>>>>>>>>>>> staging first and when release is signed off, you
> > can
> > >>>>>>> click
> > >>>>>>>>> on
> > >>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>>> interface to make it official, which then
> > >> automatically
> > >>>>>>> sync
> > >>>>>>>>>>> to
> > >>>>>>>>>>>>>>>> Maven
> > >>>>>>>>>>>>>>>>>>>>>> central.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> Here is a script for example that does release
> > signing
> > >>>>>>> and
> > >>>>>>>>>>>>>>>> publication
> > >>>>>>>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>>>>> Nexus (and staging before release)
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>
> >
> https://github.com/apache/spark/blob/master/dev/create-release/release-build.sh
> > >>>>>>>>>>>>>>>>>>>>>> On Wed, Nov 4, 2020 at 2:50 AM Netanel Malka <
> > >>>>>>>>>>>>>>>> netanel...@gmail.com
> > >>>>>>>>>>>>>>>>>>>>> <mailto:
> > >>>>>>>>>>>>>>>>>>>>>> netanel...@gmail.com>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>> Hi,
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> I followed the release-signing
> > >>>>>>>>>>>>>>>>>>>>>> <https://infra.apache.org/release-signing.html>
> doc
> > >> and
> > >>>>>>>>>>> created
> > >>>>>>>>>>>>>>>> a key
> > >>>>>>>>>>>>>>>>>>>>> for
> > >>>>>>>>>>>>>>>>>>>>>> signing and hashing.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> I have a few questions:
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>         1. Should the KEYS file also be added to
> the
> > >>>>>>> project
> > >>>>>>>>> root
> > >>>>>>>>>>>>>>>> directory
> > >>>>>>>>>>>>>>>>>>>>> on
> > >>>>>>>>>>>>>>>>>>>>>>         Github? ( I saw it in Apache Ant)
> > >>>>>>>>>>>>>>>>>>>>>>         2. I saw in release-policy_upload-ci
> > >>>>>>>>>>>>>>>>>>>>>>         <
> > >>>>>>>>>>> http://www.apache.org/legal/release-policy.html#upload-ci>
> > >>>>>>>>>>>>>>>> that we
> > >>>>>>>>>>>>>>>>>>>>>> need
> > >>>>>>>>>>>>>>>>>>>>>>         to add a release candidate to
> > >>>>>>>>>>>>>>>>>>>>> https://dist.apache.org/repos/dist/*dev*/
> > >>>>>>>>>>>>>>>>>>>>>> <TLP
> > >>>>>>>>>>>>>>>>>>>>>>         name>/. However, there does not seem to
> be a
> > >>>>>>> directory
> > >>>>>>>>>>> with
> > >>>>>>>>>>>>>>>> Sedona as
> > >>>>>>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>>>         TLP name. How may we be able to get a
> > directory
> > >>>>>>> with
> > >>>>>>>>> that
> > >>>>>>>>>>>>>>>> name? (Also
> > >>>>>>>>>>>>>>>>>>>>>> for
> > >>>>>>>>>>>>>>>>>>>>>>         the *release*)
> > >>>>>>>>>>>>>>>>>>>>>>         3. Do we need to push the artifacts also
> to
> > ASF
> > >>>>>>> Nexus
> > >>>>>>>>>>>>>>>> Repository
> > >>>>>>>>>>>>>>>>>>>>> (beside
> > >>>>>>>>>>>>>>>>>>>>>>         Maven Central)?
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> Thanks.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> On Mon, 2 Nov 2020 at 19:21, Netanel Malka <
> > >>>>>>>>>>>>> netanel...@gmail.com
> > >>>>>>>>>>>>>>>>>>>>> <mailto:
> > >>>>>>>>>>>>>>>>>>>>>> netanel...@gmail.com>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> Thanks Felix.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> I would be delighted to help.
> > >>>>>>>>>>>>>>>>>>>>>>> I can start with the GPG.
> > >>>>>>>>>>>>>>>>>>>>>>>       Can I test it on a some artifact, or I need
> > to
> > >>>>>>> wait for
> > >>>>>>>>>>> the
> > >>>>>>>>>>>>>>>> first
> > >>>>>>>>>>>>>>>>>>>>>> release?
> > >>>>>>>>>>>>>>>>>>>>>>> On Mon, 2 Nov 2020 at 03:17, Felix Cheung <
> > >>>>>>>>>>>>>>>> felixche...@apache.org
> > >>>>>>>>>>>>>>>>>>>>>> <mailto:felixche...@apache.org>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>> Great progress!
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> To add,
> > >>>>>>>>>>>>>>>>>>>>>>>> A) I’d strongly recommend the WIP disclaimer -
> it
> > >>>>>>> would be
> > >>>>>>>>>>>>> much
> > >>>>>>>>>>>>>>>>>>>>> easier
> > >>>>>>>>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>>>>>>> pass with in the first release
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >> https://incubator.apache.org/policy/incubation.html#disclaimers
> > >>>>>>>>>>>>>>>>>>>>>>>> B) more info in signing, checksum
> > >>>>>>>>>>>>>>>>>>>>>>>> https://infra.apache.org/release-signing.html
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> C) signing key should be individual’s and
> (public
> > >> key
> > >>>>>>> )
> > >>>>>>>>>>>>>>>> published and
> > >>>>>>>>>>>>>>>>>>>>>> also
> > >>>>>>>>>>>>>>>>>>>>>>>> listed in KEYS file - KEYS file  should be
> located
> > >>>>>>> next to
> > >>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>> staging
> > >>>>>>>>>>>>>>>>>>>>>>>> (and
> > >>>>>>>>>>>>>>>>>>>>>>>> later release) location, see above
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>> D) “correct place” - this is in reference to ASF
> > >>>>>>> officIal
> > >>>>>>>>>>>>>>>> staging
> > >>>>>>>>>>>>>>>>>>>>> server
> > >> http://www.apache.org/legal/release-policy.html#stage
> > >>>>>>>>>>>>>>>>>>>>>>>> And can be “uploaded” by committing to svn
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>> http://www.apache.org/legal/release-policy.html#upload-ci
> > >>>>>>>>>>>>>>>>>>>>>>>> E) python / PyPI -
> > >>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>> https://incubator.apache.org/guides/distribution.html#pypi
> > >>>>>>>>>>>>>>>>>>>>>>>> On Sun, Nov 1, 2020 at 2:17 PM Jia Yu <
> > >>>>>>> ji...@apache.org
> > >>>>>>>>>>>>> <mailto:
> > >>>>>>>>>>>>>>>>>>>>>> ji...@apache.org>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>> Hi Netanel, Pawel and other committers,
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> While Pawel is working on Python code of Sedona
> > >> 1.0,
> > >>>>>>>>> let's
> > >>>>>>>>>>>>>>>> focus on
> > >>>>>>>>>>>>>>>>>>>>>>>> other
> > >>>>>>>>>>>>>>>>>>>>>>>>> parts required by the release. Netanel, can you
> > >> help
> > >>>>>>> me
> > >>>>>>>>>>> with
> > >>>>>>>>>>>>>>>> all
> > >>>>>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>>> ASF
> > >>>>>>>>>>>>>>>>>>>>>>>>> incubator requirement items that are not DONE?
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> *Here is a checklist for our first Sedona
> > release*
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> *ASF incubator requirement
> > >>>>>>>>>>>>>>>>>>>>>>>>> (
> > >>>>>>>>>>> https://incubator.apache.org/guides/releasemanagement.html
> > >>>>>>>>>>>>>>>>>>>>>>>>> <
> > >>>>>>>>>>> https://incubator.apache.org/guides/releasemanagement.html
> > >>>>>>>>>>>>>> ,
> > >>>>>>>>>>>>>>>> we
> > >>>>>>>>>>>>>>>>>>>>>>>> probably
> > >>>>>>>>>>>>>>>>>>>>>>>>> should read ASF release requirement as well):*
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> 1 .Include the word incubating in the release
> > file
> > >>>>>>> name:
> > >>>>>>>>>>>>> DONE.
> > >>>>>>>>>>>>>>>>>>>>> Please
> > >>>>>>>>>>>>>>>>>>>>>>>> see
> > >>>>>>>>>>>>>>>>>>>>>>>>> the POM.xml in all directories.
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> 2. Include an ASF LICENSE and NOTICE file:
> DONE.
> > >>>>>>> Please
> > >>>>>>>>> see
> > >>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>> GitHub
> > >>>>>>>>>>>>>>>>>>>>>>>>> repo.
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> 3. Have valid checksums or signatures: I
> believe
> > >>>>>>>>> signature
> > >>>>>>>>>>>>>>>> should
> > >>>>>>>>>>>>>>>>>>>>> be
> > >>>>>>>>>>>>>>>>>>>>>>>> done
> > >>>>>>>>>>>>>>>>>>>>>>>>> by the GPG key. Not sure about the checksum. I
> am
> > >>>>>>> also
> > >>>>>>>>> not
> > >>>>>>>>>>>>> sure
> > >>>>>>>>>>>>>>>>>>>>> about
> > >>>>>>>>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>>>>>> GPG key requirement of ASF. I use GPG key to
> sign
> > >>>>>>>>> releases
> > >>>>>>>>>>> of
> > >>>>>>>>>>>>>>>>>>>>> GeoSpark
> > >>>>>>>>>>>>>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>>>>>>>>>>>> the past.
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> 4. Be placed in the correct place on the ASF’s
> > >>>>>>>>>>>>> infrastructure:
> > >>>>>>>>>>>>>>>> we
> > >>>>>>>>>>>>>>>>>>>>>> should
> > >>>>>>>>>>>>>>>>>>>>>>>>> place our releases in two places: Maven, and
> > PyPi.
> > >>>>>>> Not
> > >>>>>>>>> sure
> > >>>>>>>>>>>>>>>> how to
> > >>>>>>>>>>>>>>>>>>>>>>>> relate
> > >>>>>>>>>>>>>>>>>>>>>>>>> them to ASF.
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> 5. Have a KEYS file to validate the release:
> this
> > >>>>>>> should
> > >>>>>>>>> be
> > >>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>> public
> > >>>>>>>>>>>>>>>>>>>>>>>> key
> > >>>>>>>>>>>>>>>>>>>>>>>>> of our GPG key?
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> *Sedona requirement*
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> 1. Python path name, file headers, and jars
> > >>>>>>>>>>>>>>>>>>>>>>>>> 2. Project website docs: documentation should
> use
> > >> the
> > >>>>>>>>> name,
> > >>>>>>>>>>>>>>>>>>>>> Sedona, in
> > >>>>>>>>>>>>>>>>>>>>>>>> all
> > >>>>>>>>>>>>>>>>>>>>>>>>> tutorials. We should also include the situation
> > of
> > >>>>>>>>> GeoTools
> > >>>>>>>>>>>>>>>>>>>>>>>> dependencies.
> > >>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>>>>>>>>>>>>>>> Jia
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Oct 14, 2020 at 10:08 PM Jia Yu <
> > >>>>>>>>> ji...@apache.org
> > >>>>>>>>>>>>>>>> <mailto:
> > >>>>>>>>>>>>>>>>>>>>>> ji...@apache.org>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Hi folks,
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>>>>> We will be working on the first Sedona. Please
> > see
> > >>>>>>> the
> > >>>>>>>>>>> JIRA
> > >>>>>>>>>>>>>>>>>>>>> ticket
> > >>>>>>>>>>>>>>>>>>>>>>>> here:
> > >>
> >
> https://issues.apache.org/jira/projects/SEDONA/issues/SEDONA-3?filter=allopenissues
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Do you think there are any outstanding issues
> to
> > >> be
> > >>>>>>>>> fixed
> > >>>>>>>>>>> as
> > >>>>>>>>>>>>>>>>>>>>> well?
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>>>>>>>>>>>>>>>> Jia
> > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>>> Best regards,
> > >>>>>>>>>>>>>>>>>>>>>>> Netanel Malka.
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>>> Best regards,
> > >>>>>>>>>>>>>>>>>>>>>> Netanel Malka.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>>>> Best regards,
> > >>>>>>>>>>>>>>>>>>>>> Netanel Malka.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>> --
> > >>>>> Best regards,
> > >>>>> Netanel Malka.
> > >>>>>
> > >>
> >
>


-- 
Best regards,
Netanel Malka.

Reply via email to