I'm developing a java project that I'd eventually like to publish and make open source.

To make a executable jar file I use the maven-assembly-plugin. This includes my dependencies in the jar, which makes it easy to deploy as the user (currently only me) doesn't have to add the dependency jars in a different lib/ folder or something along those lines. For my personal use I don't think there should be any issue there.

Once I publish my project, how should I go about this?

I found many questions talking about how to accomplish a executable jar (on stackoverflow), but none talking about the fact whether I should or shouldn't publish it.

My main questions are the following:

  1. Is it legal to republish the dependencies in the jar directly in the same form as the maven-assembly-plugin produces the jar or do I have to include the licenses manually (e.g. Apache License 2.0) if my whole project is licensed under some more restrictive license?
  2. Is it good practice to republish the dependencies or should I let each user build their own version based on the pom.xml? In my opinion, aside from the legal aspect (if question 1 would be answered with yes or for self-authored dependencies where licensing is not an issue), it feels like a redundant copy of the dependency just for the sake of simplicity for the end user. Not sure if I should feel good about this.
  3. If question 1 and question 2 would be answered with yes, can I put the runnable jar on maven central (or github packages etc.) or only on my own personal website/ as an artifact in a github release?

I'm not entirely sure if this question is on-topic here, but I found other questions related to licensing and questions related to maven, so I figured a combination should fit as well. If I'm wrong feel free to mark as off-topic and please leave me a comment which tells me in which stackexchange network this would be on-topic.

  • Note that there are several ways to create and deploy complete Java programs. I would recommend that you look into creating an executable jar with your library jars next to it, and then create an appropriate classpath in the executable jar. This will allow you to distribute them unchanged. Dec 6, 2020 at 11:47
  • @ThorbjørnRavnAndersen Would you still include the dependency jars in the download (maybe as a zip file)? What are the benefits of this procedure? IMHO this feels even more redundant than including the extracted classes of a dependency.
    – Jojomatik
    Dec 6, 2020 at 12:18
  • As this is not a technical problem (could happen with signed jars) but a license problem, you might need to revise your line of thought. Unpacking and repacking a LGPL licensed class into your own binary may (I am not a lawyer) require you to license your own code under the GPL to be compliant. Just using the prepacked binary may not. Dec 6, 2020 at 13:37
  • And just to clarify. the executable jar should NOT contain the dependencies, just enough of your own code to run, with the dependent classes coming from the before mentioned classpath set up in the manifest. Dec 6, 2020 at 13:39
  • @ThorbjørnRavnAndersen Interesting point. Currently I'm not using any LGPL licensed libraries. When it comes to GPL libraries I'll have to release and license my code under GPL anyway, am I right? Even if I just developed a plugin for GPL software using their API, where distribution of their code would not be necessary at all (no matter if inside or outside of my jar), I'll have to compy with it, do I?
    – Jojomatik
    Dec 6, 2020 at 14:02

1 Answer 1

  1. You may by all means distribute third-party dependencies in your jar file provided you comply with all their licences. This can be done in your release notes or in a separate file on licensing which lists all the included dependencies and their licences, with links to the licences and, if you are inclined, their source code to forestall anyone asking you for it.

  2. Whether this is good practice really depends on your target user. If you anticipate your package to be used by Java developers, you can leave the dependencies out with the expectation that they can figure out how to resolve them. If your package will be used by non-programmers, it is best to make installation as simple as possible and bundling the dependencies could be very helpful.

  3. Anecdotally, I have published a jar file that included its dependencies within it, but the dependencies were all written by me and part of the same project. In practice, my decision would be based in part on how much the jar file grows with the dependencies, although I can’t provide a threshold size.

  • Thank you for your answer. I'd like to keep the release process as automated as possible. Is there a way to generate such a file? I've just been looking at the plugins maven-project-info-reports-plugin and maven-dependency-plugin. Would the files generated by those suffice? How would I include them in the runnable jar? Would love to see any further insight to this (such as an excerpt of the pom.xml) in your answer for me and future readers with the same question.
    – Jojomatik
    Dec 6, 2020 at 12:15
  • @Jojomatik, that might warrant a different question as it is tactical rather than philosophical. But see stackoverflow.com/questions/97640/…. Dec 6, 2020 at 12:41
  • I agree, another question might be the right choice for the "technical" aspect. With regards to the link that you provided, I think this is about including the dependencies themself, which I have already figured out. What I was asking was how to include the file containing the licenses for the dependencies.
    – Jojomatik
    Dec 6, 2020 at 13:17
  • Ah, gotcha. Not sure there are any tools for that (yet). Dec 6, 2020 at 13:19
  • 1
    Thank you nonetheless. I'll wait some time if there will be other answers and if nothing substantially better/ different pops up I'll propably accept yours :)
    – Jojomatik
    Dec 6, 2020 at 13:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.