Packaging of Java components

At the suggestion of @jakirkham, I am opening this issue here to start a conversation about how conda might manage the packaging for Java components in a uniform way.

Quick introduction: I am maintainer of the [ImageJ](https://github.com/imagej/imagej) and [Fiji](https://github.com/fiji/fiji) projects for N-dimensional scientific image processing and analysis. A major interest of mine is making ImageJ accessible from other ecosystems such as PyData and Node.js. We now have an [imagej module on PyPI](https://pypi.org/project/imagej/) allowing to access an ImageJ installation as Python code in-process or interprocess. But it was suggested that we also create a conda package that ships all of ImageJ. @jakirkham indicated the most proper way to do this would be publish each Java component (i.e. JAR file) as its own conda package, with a dependency hierarchy matching that declared in the Maven POMs.

So my first question is: do others concur that the ideal thing would be a one-for-one correspondence between Java components and Conda packages?

If so, my second question then is: what would be the best way forward to achieve that?

@jakirkham suggested we could invent some machinery to auto-update conda packages of Java components based on their Maven releases. I countered with the idea that it would be more elegant to augment conda itself to understand Maven repositories directly, so that `conda install java:org.scijava:scijava-common` or some such would install the latest version of [org.scijava:scijava](http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.scijava%22%20a%3A%22scijava-common%22) directly from Maven Central.

A third related question is: would it be OK to simply ship binaries, rather than rebuilding from source? I am ignorant of the conda-forge (and conda in general) policy on building from source... but one nice thing about Java artifacts is that once a release is built, it is completely portable and there is no need to rebuild it—and in fact, rebuilding it can be problematic, since JAR files are typically signed by the author to ensure fidelity. (Of course, artifacts _can_ be rebuilt from source by third parties, but the resulting JAR itself will not be identical, even if the bytecode of all the .class files inside is the same.) So it would be ideal if conda could support _distributing the already-built artifacts_ rather than mandating rebuilds from source.

There are many issues here, and I expect the conversation will be quite complex—but I am willing to invest some energy if people in the community are earnestly interested in making Java components available via conda. See also imagej/imagej#162 which is about packaging Java components for Gentoo but has probably a high degree of overlap with many of the concerns here.

Thoughts? Questions? Ideas?