Kimahriman commented on PR #647:
URL: https://github.com/apache/incubator-sedona/pull/647#issuecomment-1193123479

   Yeah that's what I ended up doing all the time, I just include the 
python-adapter and then it automatically includes all the dependencies I need, 
which is a little odd. In fact, python-adapter has things bundled inside of it 
_and_ has compile scope dependencies on all the things, so you end up double 
including all of the classes.
   
   From a Spark perspective (which is all I do, not Flink, and via Python, so 
not a Java/Scala/Maven expert by any means), I think the two main approaches to 
including dependencies are via `--packages` (or `spark.jars.packages`), which 
resolves and automatically includes compile scope dependencies, or creating a 
fat Jar if you're spark-submitting java/scala code. Either way lends itself to 
compile scope dependencies correctly, versus users having to know what 
transitive dependencies are required for them to manually include (and what 
version they should use). So if everything was just compile scope, and you just 
wanted to do Sedona SQL things, you could just do `--packages 
org.apache.sedona:sedona-sql-3.0_2.12:1.2.0` and have everything you need 
without worrying about anything else.
   
   Would you be open to switching to that type of setup? Then the "common" 
module would just be another compile scope module that gets automatically 
included for whatever needs it.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to