Develop Reference

How to publish a regular, non-Android Java library so that it becomes available for inclusion in Java projects via Maven & Gradle build scripts?

I recently authored a 3rd party library for Java. Currently, I'm distributing the library via Github and a website I own where I make it possible to download the JAR file. I want to make it so developers can use Gradle and Maven (and possibly other build automation tools) to easily include my 3rd party library in their projects.
I'm new to Maven, Gradle, Bintray, JCenter, MavenCentral, Ivy, etc. However, I do have experience with Ant, Java, and Linux.
I've been trying to learn how to publish my 3rd party library using the tools/platforms above, but I've become confused.
Based on what I've read, Gradle, Maven, and Ant are competing technologies. So, why then, in the context of actual use-case scenarios, does Gradle seem to be so intertwined with Maven?
Bintray advertises itself as a software publishing and distribution platform. So, why was there a need to create JCenter as something distinct from the rest of Bintray? What can JCenter do that Bintray can't?
I've created a test package and version on Bintray and I uploaded a JAR file to the version. Is it possible to write a Gradle script that will be able to include that JAR file as a dependency in a Java project? Or does the package need to be "linked" with JCenter?
Basically, can anyone tell me what's going on with all of the above technologies? Don't feel obligated to provide answers to all of the sentences in this post that end in a question mark. Those questions are primarily intended to demonstrate my current level of understanding. A simple overview of how the technologies work together would be great, and if possible, an answer to the question in the title of this post.

I will try answer to all the sentences ending with question marks :)
Based on what I've read, Gradle, Maven, and Ant are competing technologies. So, why then, in the context of actual use-case scenarios, does Gradle seem to be so intertwined with Maven?
Besides being a build tool and a dependency manager (in which Maven compete with Gradle), Maven introduced a standard artifact descriptor (the POM file), a standard project layout (src/main/java etc) and a standard artifact layout (groupId/version/artifactId-version.ext) that due to the popularity of Maven became a standard de-facto in the industry. They aren't particularly bad, so they stuck for now and Gradle works with them as well.
Also, Gradle appeared when Maven already been exceptionally popular. To overtake such a popular technology Gradle had to provide a clean and easy migration path, which means supporting Maven-structured projects, Maven-structured local caches, etc.
Bintray advertises itself as a software publishing and distribution
platform. So, why was there a need to create JCenter as something
distinct from the rest of Bintray? What can JCenter do that Bintray
can't?
JCenter is not "something distinct" from Bintray. JCenter is a repository inside Bintray. This repository is special (we call this type of repository a "Central Repository"), since it is maintained by Bintray team themselves, and include (or link) the biggest collection of Java libraries in the world. For a lot of Java (or Android for that matter) developers, who don't intend to publish their work through Bintray and don't care about other people's personal repositories the only thing of interest on Bintray is JCenter. As such, people refer to JCenter as a thing of its own.
I've created a test package and version on Bintray and I uploaded a
JAR file to the version. Is it possible to write a Gradle script that
will be able to include that JAR file as a dependency in a Java
project?
Absolutely. The "Set Me Up" button opens a window in which you'll find the instructions on how to add your personal repository in Gradle. Once done, the artifacts from your repository will be available for resolution in your Gradle project.
Or does the package need to be "linked" with JCenter?
The benefit of including your package in JCenter is that other developers who are familiar with JCenter as a source for 3rd party dependencies, but not familiar with your repository on Bintray will be able to find and use your library.
I hope it helped.
I am with JFrog, the company behind Bintray and [artifactory], see my profile for details and links.

It is really hard (next to impossible) to give an answer, because you are asking multiple questions (I count 5 question marks), plus you want an explanation of how all of the mentioned technologies play together (or not). This really exceeds the scope and usefulness of stackexchange.
However, if it's maven you could live with, then what you probably want is:
1) deploy your artifact to maven central repo ==> see https://maven.apache.org/guides/mini/guide-central-repository-upload.html
2) deploy to some other well known public maven repo (like sonatype)
3) host your own public maven repo (that can be used by others) and upload there, still keep "advertising" through web and github pages

What is Maven in Android Studio?

There are lot of Answers on how to use Maven in Android and work with it.
However, As Gradle being already available, which manages the build process of Android projects and support complex scenarios in creating Android applications, such as Multi-distribution and Multi-apk,
What exactly is the role of Maven in Android Studio?
And how is it different from Gradle?

The short answer is: The tools do the same thing but in different ways. The difference is how you can use them to build your project. Apache Maven goes for "follow our convention" way and Gradle gives you flexibility. Some devs don't want a new tool or don't have time to learn how to use it properly.
Now the long answer...
To understand properly why some devs are attached to Apache Maven, we have to look at some years in the past.
Apache Maven is a build automation tool just like Gradle.
Maven got released on 2004. Gradle first version got out on 2007 but it did not become as popular as Maven in the early days.
Some devs don’t like having to learn anything new and most companies don't want to risk the exchange of an already running and mastered tool (Maven) for the new kid on the block.
Gradle became popular when the Android development raised. Android's project has a different project structure from Java EE/Web projects. Trying to use Maven on Android's project just feels unnatural, the tool was not prepared to provide flexibility.
Until now, Apache Maven can be used on simple Java EE projects without being a pain in the ass if you already know the forced conventions. So devs that aren't aware of Gradle/did not get in touch with Android apps don't have motivation to change to another tool.
In my opinion, Gradle is better than Apache Maven in every way that you could imagine. It gives you flexibility and tries not to get in your way, a "feature" that you cannot find in Apache Maven. If you don't follow Apache Maven life cycle, your build will fail, that's it.
For example, your code can be spread across many directories in any kind of layout if you are using Gradle. If you are on Maven and you don't follow the 'convention', you'll lose some hours changing your pom (Maven's build file) to be able to understand and handle your folder structure.
E.g.: Java source code must be on src/main/java folder. If you got an old project and the structure is src/java, sorry, You have no guarantee that all Maven plugins will run as expected.
Gradle does us a favor and puts more features for comparison in a very organized chart. Take a look. https://gradle.org/maven_vs_gradle/

Maven is just a tool that manages and simplifies how you build your project. Among many other things (running tests, managing conflicts, documentation, modularization), its most useful purpose is that of automatically fetching dependencies that your project needs and dependencies of those dependencies (transitive dependencies) if any. Dependencies are usually just JAR files that contain re-usable code.
So what does this mean. Suppose you want to use a library such as OpenCSV to generate a CSV file in your application. Non-Maven way: Google search for the library, check if it needs other libraries and if so download them, put them in your project's classpath then build. When you move your project to another PC, copy all the JAR's or it won't work. Maven way: insert something like this in a file named pom.xml:
<dependency>
<groupId>net.sf.opencsv</groupId>
<artifactId>opencsv</artifactId>
<version>2.3</version>
</dependency>
Done. Maven will do the rest for you when you build (download to local cache if not already existing, fetch dependencies, javadoc etc). Even if you were to copy your project to another PC without the JAR's, delete the JAR's etc, if Maven is present it will re-download them automatically when you build.
For more: Link

There a repository for Eclipse project jars?

There's a project within the Eclipse Foundation, DevTools, which holds a sub-project, SqlTools, which contains a few libraries related to parsing SQL. I'd like to be able to link those libraries to my own project. I just can't for the life of me figure out the right terms to Google to find some repository for those jars.
I've found the source code alright and cloned the git repository but that's source code. I'd like to avoid hosting not only my own project's jars but any dependency it might have. Anyone know where to get these? Already reached out to the mailing list but am impatient. I've finally got free time to hack on the weekend for my own interests...

The jars are published in a p2 repository. http://download.eclipse.org/datatools/updates
A content.jar file describes the repo, and the actual jars are in http://download.eclipse.org/datatools/updates/plugins
There is a nexus instance at http://maven.eclipse.org/nexus/index.html that contains some sqltools jars, but publishing jars to maven.eclipse.org is still under construction.

I use this one - http://search.maven.org/#browse
Better look. Clean, slick and more user friendly :)

I use mvnrepository.com to search for libraries.
http://mvnrepository.com/search.html?query=Eclipse

Applying Maven to a project

I've been asked to apply Maven to a project. After browsing a dozen sites it appears that it's quite vast and I'm not familiar as I'd like with similar tools like Ant. Why is it used/preferred and what does it offer over a standard Eclipse project? Also, how could it be added to an existing project?

Why is it used/preferred and what does
it offer over a standard Eclipse
project?
It is a build tool which can build your project without the need for an IDE like Eclipse. It can create a jar or war or other artifacts from the source, performing a bunch of steps like compilation, running unit tests, etc.
Where maven scores over ant is in managing third-party dependencies and in convention over configuration (which mean less lines of build script if you follow convention).
Also, how could it be added to an
existing project?
You start by creating a new maven project, following the step here.
Place it in the root folder of your project
If your source and resource files do not follow maven folder convention, update maven properties suitably referring to this documentation.
Run mvn package
It will fail if it needs any third party dependencies, which you can add as specified in the doc
With some trial and error, you should have your project running with maven, possibly, much quicker than if you were to set up the same with ant.
Others are already provided sufficient resources to read more about maven.

I suggest to start reading here:
http://www.sonatype.com/books/mvnref-book/reference/public-book.html

Maven is a great tool when you know how to use it. Maven (at core) is a dependency manager.
You include in your pom.xml (similar in function to the build.xml from Ant) all the librairies your project depends on (example : apache commons) along with their version and Maven get them directly from a repository (by default, the central maven repository)
Then you do not have to manually install any jar to make your project work. All is downloaded and cached on your local machine. You can even create an enterprise repository where you put all the jars needed by your company
Maven uses the concept of artifacts which are pre-built library projects with their own dependencies
To mavenize a project, you'll have to write a pom.xml describing your project (examples are numerous), get rid of your libs directory (or whatever classpath you described under Eclipse) and add all your dependencies to your pom.xml
You could also check Mavenizer for a first-start
But Maven is a lot more what i've just said. Read the docs, read poms from librairies and you'll get used to it quickly ;-)

If you use the M2Eclipse plugin from Sonatype, it's just a matter of right clicking the project in the package explorer and choosing Enable Dependency Management in the Maven menu. You are also advised to adjust the directories that contain the sources to the Maven standard directory layout but if you absolutely can't, you can configure that later.
Apart from that: Well, look for tutorials and documentation (for example there is the free book Better builds with Maven. Maven is very complex (yes, I don't think it is simple) and very powerful.

Any best practices or tools for Ivy repositories?

we use Gradle for building Java projects and at the moment we have Ivy repositories to store third-party artifacts and also to publish our own artifacts into (repo is build using Gant scripts and the Ivy ANT tasks). but repo management is basic.
Gradle is able to work with a maven repo as well, so switching to a Maven artifact manager like Archiva or Nexus is an option, but perhaps unnecessary. do you know any tools or best practices than can help us in building and maintaining Ivy repos?
just to be clear: we have already read the tutorials and more and understand how to do it, but it's still basic to maintain.

In the past, I've only used an ivy repository for small private repositories publishing artifacts using simple low level protocols like an FTP site. (All the site needs is a versioned directory layout and an ivy.xml file describing the arifacts)
The maven based repository infrastructure is now so pervasive, with some many projects using it, it's almost pointless to promote an alternative repository management standard.
Sonatype (company behind Maven) make their repository product, Nexus, available to all, because it's in everyone's interest to keep the band-width requirements to Maven central under control.
Thankfully, ivy plays nice with Maven meaning you can take advantage of the best of both worlds.

I've created a blog entry about my Ivy repository layout and choices. You might have different requirements, but I think it is always good to check other's solutions to get some ideas...

There's a community project called Ivy Roundup that aims to build a consistent, up-to-date ivy repo of common third party libraries. It may be a good idea to match the naming conventions used there, or even better, just get modules from there using the <ivy:install> task.

In my opinion there isn't much in Ivy's repository to work with because it just works. What you can't do with Ivy's Ant tasks you can do directly from the file system, simple as that.
Admittedly something like changing the artefact name can be difficult but then again that's something you shouldn't do anyway.

What I am typically doing in practice when I need a third-party library is to search for it in the MVN repository and then click on the "Ivy" tab to get the Ivy dependency for my ivy.xml.