Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use gradle / add to artifactory #49

Open
ligi opened this issue Jan 11, 2017 · 3 comments
Open

use gradle / add to artifactory #49

ligi opened this issue Jan 11, 2017 · 3 comments
Milestone

Comments

@ligi
Copy link
Contributor

ligi commented Jan 11, 2017

I want to consume this library in one android-application - looks really useful and seems to work nice - but currently I would have to drop in the jar which I do not find appealing. My solution now is to use @jitpack which points to a fork of jsyn where I added gradle build-files:

ligi/MassiveSignal@de89817

https://github.com/ligi/jsyn

also there I removed JPortAudioDevice and the corresponding dependency as I do not want this on android. Ideally I would see 3 artifacts here jsyn-core, then jsyn-android ( depends on core ) and jsyn-portaudio ( also depends on core ).
Not sure what your take on this is - could also provide a PR in this direction but would like to know your opinion on this before. Do you want to keep ant? What do you think about splitting into 3 artifacts?

cc @ptrv

@philburk
Copy link
Owner

I'm glad you like JSyn. I want to make it useful for people. Different people need different things. So I have not yet tried to optimize the build for specific targets. I'm not opposed to it. It just hasn't been a priority. You're the first person to ask.

I would have to drop in the jar which I do not find appealing.

Does the JAR cause technical problems? It is handy for me to publish one JAR on the website.

I removed JPortAudioDevice and the corresponding dependency as I do not want this on android.

Was there a specific build problem with JPortAudioDevice? JSyn also has over a hundred unit generators and you probably only use a few. The JavaSound code is also not used on Android. ProGuard should strip out unused code.

What do you think about splitting into 3 artifacts?

I want to understand. Are you proposing 3 git repositories or are the artifacts just gradle build targets?

@ligi
Copy link
Contributor Author

ligi commented Jan 12, 2017

JARs have the following problems:

  • they are not really versioned and being able to easily correlate them to the source-code
  • it makes the repo bigger than needed ( you do not really want binaries in your git repo )
  • when using the jar it is harder to get the attached sourcecode in the IDE ( when from artifact-repo like maven-central, jcenter or jitpack you can easily attach the sources for nicer development )
  • It makes it hard to publish your app on fdroid ( https://fdroid.org ) as you have to show that the binary jar resulted from given source and there is no binary without attached source-code
  • It's easy to find out that there are updates to an artifact ( there are even plugins for that ) - with the jar I would have to poll for new versions.

Regarding the split - I would suggest to do a multi-module gradle build: https://jitpack.io/docs/BUILDING/#multi-module-projects

@ligi
Copy link
Contributor Author

ligi commented Aug 25, 2021

oh nice - just saw that a lot of work towards this was done in 46888fa by @RubbaBoy

@philburk philburk added this to the v17.1.0 milestone Apr 10, 2023
@philburk philburk modified the milestones: v17.1.0, v17.2.0 Apr 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants