Thanks again, but... > On 18 May 2020, at 17:07, Mauro Molinari <mauro...@tiscali.it> wrote: > > Il 18/05/20 16:29, OCsite ha scritto: >> Or am I wrong and there is some magic which would prevent this scenario? > Your application will fail at compilation time if some JAR is missing. > ... I am afraid this won't do. At my build machine, there's of course a complete Groovy installation; the problem might occur at the deployment site.
Well I don't know how your workflow with Maven/Gradle looks like, but myself, I've simply got a build computer where Xcode sits for IDE (the thing has its shortcomings, some of them pretty ugly; but is infinitely better than the Eclipse disaster, and besides, I do my macOS/iOS work in there and it would be completely absurd to use different IDEs for different projects), a couple of scripts to integrate Groovy into Xcode build system, and the Groovy installation (and libraries like WebObjects, which is irrelevant to this debate). I write Groovy sources in Xcode, build-and-test as needed in the IDE, and when I want to deploy, I tell Xcode (and my scripts) to prepare a proper WebObjects application, pack it, and scp it to the server. The application then will be launched with java first at the test server, then, if all is ok, at the deployment server. All the JARs which are needed for the application to run must be installed in the server's Extensions folder and added to the classpath in the application run script. (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?) Anyway, we self-evidently need (a) either to be reasonably sure we have all needed JARs in the Extensions folder and on our classpath; (b) or, we need that the application crashes launch-time if some of them are lacking. Compile-time it obviously would never fail (for a lack of JAR, other causes of course happen); and run-time crash later, caused by user's action which might happen sort of randomly, is definitely a bad-bad. (Of course we can't completely prevent such a crash, e.g., an ugly NPE can cause that — but we want to reduce the number of causes of such crashes as much as reasonably possible, which is also why, as you might have noticed in previous debates, we do our best to disable NPEs altogether; but I am digressing, sorry :)) > If you plan to run with Groovy 3.x binary code previously compiled with > Groovy 2.4.x, then yes, it could fail at runtime if some JAR is missing. > I do apologise I probably did not explain it properly. I definitely don't want to use a code compiled with Groovy X with JARs of Groovy Y for X!=Y, ever; that would be another recipe for a complete disaster. What I want is: To build project A to get an application A.woa with 2.4.17 groovyc, and to make sure at the deployment site that this application, when launched, gets all the proper groovy 2.4.17 libraries. This is very easy, we do it for years — I just copy groovy-all-2.4.17-indy.jar to the server and put it into the classpath of the java launch in the application A.woa's launch script. 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. > Regarding this: > >> Well thanks, but I do not even know what Maven or Gradle is. I presume those >> probably would be build systems, which both could generate the proper >> groovy-all JAR, right? Systems presumably well-known and used daily by all >> those who maintain and improve Groovy itself (kudos to you all!), but of no >> use for us who only use Groovy to build other applications and who need just >> groovyc to compile, plus standard jar to pack the result and standard java >> to launch it. > I know this is not the answer you'd like to get, but the use of build tools > like Maven or Gradle is today the de facto standard when talking about > building, running and deploying JVM applications, so not only just libraries > like Groovy. > 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? And of course not to use the IDE's build system, keeping and maintaining manually separate makefiles independent on what the IDE does itself, launching the build command-line instead of from the IDE, not to have list of errors clickable, etc., well, that would be patently absurd. > I have been using Gradle for something like 10 years now for my applications, > both standalone and webapps, as well for my libraries. You should really > consider to have a look at it, once you've read some documentation you'll see > it's not so much of a overhead... probably just a text file of few lines > where you declare your dependencies (Groovy and anything else). And that text > file can be written in Groovy! > Still the result would be just one application JAR — containing my classes, built from my Groovy sources —, and some kind of reference to the Groovy package (plus of course my other libraries like WebObjects JARs and WOnder etc., but they are sort of irrelevant, they are once-installed on the server, once-added to classpath, and from that moment on happily forgotten for long years, until a new version of WOnder is about to be used). > With a tool like that, replacing the groovy-all:2.4.x with groovy-all:3.0.x > dependency for your Groovy application is about changing 2/3 characters in > that text file: you'll simply get many small JARS rather than just one big > JAR, automatically. Or even pack all in a big fat JAR, with just another line > in that text file and one command. > 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 :( Thanks, OC
