add module-info.java and rename jar file name

TonalidadeHidrica commented 5 years ago

Hi. I found this project very useful. Thanks for make them as a library. By the way, I'm trying to use this library as a dependency but I encountered to a problem: I cannot use it from modular project (JDK >=9). The current file name of jar file is java-stream-player-V8.0.0.jar, which results in an invalid automatic module name java.stream.player.v8.0.0. So I have two proposals:

Specify the module name by either
- adding module-info.java, or
- adding Automatic-Module-Name attribute into MANIFEST.MF file
Renaming the jar file so that the module name would be valid. The java compiler regards the last dot-separated sequence of integer after a hyphen of jar file name as the version number and use the rest as the module name, the jar file name java-stream-player-8.0.0.jar would be much better.

either of the above would work fine to avoid the error, but I suggest applying both because both are important convention.

TonalidadeHidrica commented 5 years ago

Tried all the approaches by myself and got following results:

First, about the issue of automatic module name because of jar file name: jitpack seems to use tag name as version and the jar file name will be {project_name}-{version_name}.jar. That's why the jar file name was java-stream-player-v8.0.0.jar, which is very unfriendly to Java 9 automatic module system. One possible workaround is to use tag name without leading v's, such as 8.0.0. I confirmed that, with this way, the jar file name would be as expected. (cf. https://jitpack.io/#TonalidadeHidrica/java-stream-player)
Since this project is compiled with Java 8, it was not possible to add module-info.java . (Is it for backward compatibility?)
Adding Automatic-Module-Name worked well. To do so, you can specify manifest attribute in pom.xml like this. With this approach I could successfully specify the dependency to this library.
- However, the entire build still failed because another dependency of this library java-vorbis-support uses same tagging strategy (v1.0.0). Well, but don't worry, fortunately this library was published in Maven Central Repository.
- Now all the problem about automatic module name is resolved, but, here comes another problem - library tritonus-share and tritonus-all have several packages in common, such as org.tritonus.share. Oh, how hard is it to use non-modular intended project from strict modular system! Seems that it's still long way to use this library from my project. I'm going to struggle further later.

TonalidadeHidrica commented 5 years ago

It seems that, from me, tritonus-share is a subset of tritonus-all, so excluding tritonus-share from dependency has been successful. After adding excluding rule like this:

    compile(group = "com.github.tonalidadehidrica", name = "java-stream-player", version = "8.0.4",
            dependencyConfiguration = {
                exclude(group="com.googlecode.soundlibs", module = "tritonus-share")
            })

I could finally play an audio!!!!!!! Horray!!!

By the way, my only concern is that the version of tritonus-share is 0.3.7.4, while that of tritonus-all is 0.3.7.2. Would that cause problem? Whatever, this is off-topic from this issue.

Anyway, again, please consider adding Automatic-Module-Name attribute and/or renaming version tags. Thanks again for this awesome library.