Great idea, Nick: Obviously, this would greatly simplify sharing of (hopefully larger and more complex) java projects by allowing Maven to manage dependencies.

I enclose a screen-shot of how we're doing in the large-and-complex stakes at the moment. Needless to say, this is all Maven-controlled, but max.jar and jitter.jar have to be planted into the repo. manually. (We also have Maven tasks for dumping all dependencies into one directory, for max.java.config.txt.)

As a complete aside, we're also generating our max.java.config.txt files from a Clojure DSL: https://github.com/cassiel/topherizer

This would be really helpful. I am preparing documentation to release a bunch of Java code I've written and most if it is going to go into the Maven central repository and it would be nice to be able to put my mxj stuff in there too.

I'd like to ping this request. I'm starting to roll stuff into Travis CI (http://travis-ci.org/) for continuous testing, but I can't do that for any of my Max projects because max.jar and jitter.jar can't be fetched via Maven.

Yes, this is very useful, and not too hard to do...a short look at the competing java classpaths in this note (I'm impressed/depressed by both!) will show you the advantage of a dependency/'library' manager, especially when we use areas like the new JVM based languages (e.g.: Clojure), and neat test/verification frameworks (e.g.: jmock) , etc., etc., etc.... Maven is the de-facto standard, and may other dev tools in java use it's repository. Let's go there... soon!

I just opened Cycling Java forum to check whether this question is already asked. Yes, it is. I would like to join this request for the benefit and happiness of all java/scala Max developers )

*PING* ... is this not going to happen? Waiting for research? Java dev to get back from vacation/other contract? Inquiring minds, etc.etc... Topher? Ben? Anyone? have mxj join the ranks of the *real* java libs, ok? ;-)... (just kiddin')...(but not...) charlieb

Yes, Cycling '74 please push max.jar and jitter.jar into the central Maven repo ! S'il vous plait!

Thanks for following up on this. Just a quick reply for the moment, that we are interested in solving this for all of you advanced Java in Max developers, but can't make a time commitment on it.

Just a quick reply for the moment, that we are interested in solving this for all of you advanced Java in Max developers, but can’t make a time commitment on it.

Hi Joshua (or anyone else who wants to take a look), I hope you are well. Any updates on this? What exactly do you need to solve? If it is a matter of resources to prepare and submit the sourceless jars I would be happy to help out.

I'm not trying to nag, but this would be really useful to me. I am working on preparing a bunch of my Max/mxj work for release---some of my jars have a number of dependencies to specific versions of other jars and this would be a big help to anyone that wanted to use my code.

I have been making double-clickable BASH scripts to help composers and other users of my code install and configure their Max environment to run my code. These scripts could be simplified if my code and its dependancies were in Maven Central.

Thanks!

I guess - giving this a little bit of thought - it would be necessary to do a bit of refactoring of the Cycling 74 namespace to make this work optimally. What's needed in the public repos is enough code (interfaces and implementations) to build up unit tests (including mocks and proxies) in order to test from the ground up in Travis in the absence of Max itself. Since max.jar contains JNI links into Max, it's not really a dependency in the usual sense.

Similarly, having max.jar as a dependency means that it's not possible to use Maven (or Leiningen or whatever) to build a usable dependency list since max.jar is already provided by Max. Strictly speaking from the Maven perspective, I suspect this shouldn't be so: MXJ packages should perhaps be responsible for wheeling in max[-x.y.z].jar themselves.

I'd like to extend to be able to fetch Maven dependencies; as things stand, it would make sense to have a max.jar dependency to interfaces and proxies, and then ignore this when assembling Java libraries for running in Max itself.

"extend to be able"

The insert-link tool is broken. I meant this:

https://github.com/cassiel/topherizer

Yay Nick! Your post analyzing the issue made a lightbulb go off in my head: I think I actually may have already written a library that solves all the issues you present.

I will sleep on this, look at my code tomorrow, and follow up. We may be much closer than we thought!