Depending on com.github.EmbroidePy:EmbroideryIO:0.0.2 downloads a ton of android stuff

[megri]

Heya!

Just found this very interesting lib and tried to add it to my build but it's half of android. Would it be possible to package it so that it doesn't require the android libs?

(Specifically the stuff in "com.android.support")

[tatarize]

Yeah, it should actually need the support stuff. It's generally stand alone. If the import doesn't work like that you can download it and just insert it directly into the project. The jitpack stuff is supposed to help, but it might get in the way at points. I'll double check. Must have left unneeded dependencies somewhere. It should literally have no need for any dependencies.

[tatarize]

Yeah, bunch of generally unneeded stuff in:

https://github.com/EmbroidePy/EmbroideryIO/blob/master/app/build.gradle

I'll fix that up shortly.

[tatarize]

Okay, released 0.0.3 and tested it in a new build I made of Touch Embroidery. Works.

I had wanted to have a large testing suite like I have for the python version of EmbroideryIO (PyEmbroidery), but getting it working was weird and didn't really have the easy Travis testing stuff to make it work extremely well. So I removed that stuff and it shouldn't try to download the world to work. Just the couple classes in the library.

[megri]

That's awesome, I'll give it a try.

I actually went ahead and forked + made some "disruptive" changes to the build to suit my needs before I noticed your reply. Basically stripped out all traces of Android. If anyone's interested this fork is here: https://github.com/megri/embroideryio

EDIT: Basically, I think the project could be split into two paths: one for Android and one for JVM, with the only change residing in EmbMatrix.java. Everything else seems to be completely stand alone.

Not sure how to configure this with Gradle as I'm not used to that build system, but in my mind I envision three modules:

1. core-module
2. android module (depends on core-module)
3. jvm-module (depends on core-module)

All classes except EmbMatrix.java are kept in core. The android-module build pulls in the extra dependency on com.android.tools.build and defines an EmbMatrix.java that uses it. The jvm-module does not need any extra dependencies, it just defines an EmbMatrix.java

The end result would be two separate artifacts, something like embroideryio-jvm and embroideryio-android. I'm not sure how this would work with jitpack.io. Maybe the configurations would need to reside on separate branches/extended tags in the format 0.0.x-jvm/0.0.x-android.

[megri]

@tatarize I updated my build a bit, it seems to do the Right Thing™ now, but I'm not 100 % sure. Please have a look. If it looks fine I'll open a pull request :)

(note that it is not ready for PR at the moment, as some build.gradle-settings are specific to my fork)

[tatarize]

https://github.com/megri/EmbroideryIO/blob/master/android/build.gradle seems to include those elements I previously removed because they installed a bunch of stuff. I'm not really sure how it would work with jitpack either so I'm reluctant to merge it. The difference for the jvm is really just one character and I drag and drop in my jvm project. And I'm pretty sure jitpack only cares about android. It might be better to just start another repository with the jvm version, especially if there's some easier way to install such a thing.

I ported it over from my python version, and very few things have come up requiring any changes, so hopefully having a bunch of unshared code bases won't become intractable. Though jitpack seems to have something with jvm and android versions of the same code base but I didn't study it that much.

[megri]

I'm pretty sure jitpack just packages any kind of JVM artifact that's available on github. It's basically a more convenient form of maven, with a build-server integrated :)

I'm actually using the jvm-branch of megri/embroideryio in a personal project right now.

I followed the docs at https://jitpack.io/docs/BUILDING/#multi-module-projects and amended the theoretical setup described above by having core be a standalone include—that is, not a published module of its own—which modules jvm and android add to their source path.

I'm sorry but I don't understand what you mean when you say "the difference for the jvm is really just one character and I drag and drop". What is being dragged and dropped? :)

Oh, and I can't figure out where EmbMatrix is used. It seems like it's just sitting there; couldn't find any references to it anywhere.

EDIT:

I thought maybe the benefits were unclear, so here goes.

Right now, adding a dependency on com.github.megri.EmbroideryIO:jvm:0.0.4 pulls down the jvm-branch of things. No android-artifacts are bundled with this, so it's very lean.

In contrast, if one were to add the dependency com.github.megri.EmbroideryIO:android:0.0.4, all of the android stuff would be included. This is basically only needed to build the specific EmbMatrix.java-file located under the android/ directory, so I'm not sure if it's actually desired. In short this artifact should perform exactly as version 0.0.2 of this github repo.

[tatarize]

I checked the android version there and com.github.megri.EmbroideryIO:android:0.0.4 seems to work. That's all the current version currently has working, so it's at least as functional as my previous packaging, and won't lose any functionality. And checking it against the jitpack docs it seems to be totally correct. And the versioning ensures things won't suddenly stop functioning. So there's half a dozen solid safeguards. So go ahead and open a pull request.

[tatarize]

EmbMatrix is used by the EmbEncoder class. Since there's a bunch of different embroidery file formats and it is mission statement to preserve whatever I can between these, the encoder needs to do a bunch of different conversion stuff to make sure it can do things like read from dst files without overt trims and then write to an u01 file with overt trims without any problems. That means I have to process everything to standardize the commands being used, sometimes differently depending on the format being encoded to, and account for a lot of potential pitfalls. The encoder gives a central location where everything is processed, and since it's all being processed, it can be tweaked there too and so I added in matrix commands there, so you could rotate, scale, flip, translate, etc a design to your heart's desire. It already has to fix any length issues with the size of the stitch requested (so formats can permit larger stitches than others and these must be corrected), and any non-exact locations etc. So it was just a feature rich thing to add in there.

JVM uses AffineTransformation for that stuff, and Android uses a Matrix class, and I tweaked the file based on which version was needed. The 1 character difference refers to a comment in the EmbMatrix file that when changed flips the commenting to the other version of the file depending on whether it starts with '//' or '/' with a somewhat clever use of '//*/' which changes meaning if it's in a comment block or not.

In the python version I cooked up an EmbMatrix class from scratch (https://github.com/EmbroidePy/pyembroidery/blob/master/pyembroidery/EmbMatrix.py). I considered just cooking up another matrix class from scratch for java to use in both much like I did in the python version, but android does the matrix stuff in native and I already had it already worked. So the JVM and Android versions just use a different version of that file. And I had already kind of modeled my python version after the android version of Matrix already since I had a lot of experience with that. Though I needed a jvm version too for a different project, so I initially used Matrix then converted to EmbMatrix and added in the stuff needed to convert the code calls in JVM.

[megri]

Alright, cool :) I'll make the adjustments to my project and create a pull request shortly

[megri]

https://github.com/EmbroidePy/EmbroideryIO/pull/5 :)