(Actually I can't imagine the Maven/Gradle workflow to be considerably different: the principle of creating the application package and installing it plus all the JARs needed to the server and launching it there with proper classpath is completely independent on the toolchain, is is not?)
If I understand it well, the main difference is: Maven/Gradle also provide for dependency management.
If your only dependency is Groovy, you're very lucky. Usually
you'll depend on other modules, probably dozens of them: thinking
of handling them manually as you do produces the so called "JAR
hell".
To build project B to get an application B.woa with 3.0.3 groovyc, and to make sure at the deployment site that this application, when launched, gets all the proper groovy 3.0.3 libraries. This seems unnecessarily complicated compared with the above: either I am forced to create my own groovy-all-3.0.3-indy.jar myself (and then 3.0.4 again, etc. etc.), or I have to copy lots of JARs to the server and to the classpath separately. Ick.
What I am asking for is a reasonable way to do the B part, so that it is not unnecessarily much more complicated than A.
With Gradle, applying the "application plugin" will let you build a fat JAR or rather a ZIP file containing your application code and all of its dependency JARs, plus the scripts needed to run your application under different operating systems. Substantially for free.
So you can easily copy your JAR or your ZIP file from one
environment to the other and start your application, being sure it
will run properly.
Whilst I can easily integrate groovyc and the jar tool into Xcode's build system to do what's needed, I don't think it would be possible to do that with whole Maven/Gradle ecosystem. Or would it? How?
I don't know Xcode, sorry. However Gradle, by itself, is IDE
agnostic. It can integrate with some IDEs (like Eclipse or IDEA,
perhaps others?), but you may just use it on its own on the
command line.
That's my very point: why on earth this big fat JAR is not anymore part of the distro, if it is that easy for Groovy's own build (which itself would be presumably Maven- or Gradle-based)?!? Forcing instead to do it us end users for whom it is far from that easy :(
Because, as I said, for the vast majority of Groovy consumers nowadays that fat JAR does not make sense any more. For the few people that still want it, they can easily build it by themselves. I think this was the rationale behind this choice.
By the way: by using Gradle I think I've never used groovy-all
even when on 2.4.x. Never needed to bring it all with my
application. ;-)
Mauro
