More Groovy 3 woes

["ocs@ocs.cz" <oc...@ocs.cz>]

Hi there,

having enclosed all the “foo as bar”'s in ternary operators in parentheses, I have bumped into a completely weird problem which I can't wrap my head on -- for many classes I am with Groovy 3 getting completely weird errors of kind

“constructor X in class Y cannot be applied to given types”

What gives and how to solve the problem? Note again that the code _did_ build and _did work properly_ (tested zillion times) with Groovy 2, so there can't be anything seriously wrong with the sources. Looks like another breaking change :(

I succeeded to isolate it into a pretty small source with just one pretty standard JAR like this:

===
194 ocs /tmp> <CreateSignatureBase.java 
/*
 * Copyright 2015 The Apache Software Foundation.

 * OC: removed almost all code, leaving just what's needed to crash

 */

package org.apache.pdfbox.examples.signature;

import java.io.IOException;
import java.io.InputStream;
import java.security.KeyStore;
import java.security.KeyStoreException;
import java.security.NoSuchAlgorithmException;
import java.security.UnrecoverableKeyException;
import java.security.cert.CertificateException;
import org.apache.pdfbox.pdmodel.interactive.digitalsignature.SignatureInterface;

public abstract class CreateSignatureBase implements SignatureInterface
{
    public CreateSignatureBase(KeyStore keystore, char[] pin)
            throws KeyStoreException, UnrecoverableKeyException, NoSuchAlgorithmException, IOException, CertificateException
    { }
    @Override
    public byte[] sign(InputStream content) throws IOException
    {
        return null;
    }
}

195 ocs /tmp> <myclass.groovy 
package cz.ocs.utilities

import groovy.transform.*
import org.apache.pdfbox.pdmodel.*
import org.apache.pdfbox.examples.signature.CreateSignatureBase

@InheritConstructors class CreateSignature extends CreateSignatureBase {
    void signPDF(PDDocument pdd, OutputStream out) {

    }
}

196 ocs /tmp> /usr/local/groovy-2.4.17/bin/groovyc -cp /Extensions/pdfbox-2.0.17.jar -j myclass.groovy CreateSignatureBase.java
197 ocs /tmp> /usr/local/groovy-3.0.3/bin/groovyc -cp /Extensions/pdfbox-2.0.17.jar -j myclass.groovy CreateSignatureBase.java
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Compile error during compilation with javac.
/var/folders/zh/h4cv6xjx033frtt9y72ch8980000gp/T/groovy-generated-8946934250394256568-java-source/cz/ocs/utilities/CreateSignature.java:12: error: constructor CreateSignatureBase in class CreateSignatureBase cannot be applied to given types;
@groovy.transform.InheritConstructors() public class CreateSignature
                                               ^
  required: KeyStore,char[]
  found: no arguments
  reason: actual and formal argument lists differ in length
1 error


1 error

198 ocs /tmp> 

===

Thanks and all the best,
OC

Re: More Groovy 3 woes

[OCsite <oc...@ocs.cz>]

Daniel,

> On 16 May 2020, at 2:42, Daniel.Sun <su...@apache.org> wrote:
>> having enclosed all the “foo as bar”'s in ternary operators in parentheses
> We have fixed some issues related to ternary operator since Groovy 3 was
> released. Please provide a code snippet to show the ternary operator issue
> you mentioned.

I actually have, “1>2?[3] as Set:null”. I'll get shortly back to it in an answer to your next message.

> P.S. long time no see, welcome back to groovy mailing list ;-)

Thanks! Well for a long time I had to focus on the application itself, keeping the build scripts, ASTTs and version of groovy itself unchanged :) Now's the time we are refactoring our application core, which |'d like to accompany by switching to the newest (stable) Groovy available, so I'm back with new problems :)

Thanks and all the best,
OC

Re: More Groovy 3 woes

["Daniel.Sun" <su...@apache.org>]

Hi OC,

> having enclosed all the “foo as bar”'s in ternary operators in parentheses
We have fixed some issues related to ternary operator since Groovy 3 was
released. Please provide a code snippet to show the ternary operator issue
you mentioned.

> “constructor X in class Y cannot be applied to given types”
I find you are trying to compile a groovy file and a java file together. It
looks like a joint compilation issue. Let me try to reproduce the issue on
my machine and fix it.

P.S. long time no see, welcome back to groovy mailing list ;-)

Cheers,
Daniel Sun



-----
Apache Groovy committer & PMC member 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html

With indy, which JARs to classpath? (was:How to test and deploy without groovy-all?)

["ocs@ocs.cz" <oc...@ocs.cz>]

Well, one (most probably and hopefully) last question in this thread. It's probably pretty stupid and (ii)'s probably the self-evident answer, but after the previous debate, I do not quite trust my intuition with using JARs anymore :)

With the 4.0 snapshot which I have used so far, the classpath contents was simply groovy-4.0.0_S/lib/*.jar. That was easy.

Now with 3.0.4 I wonder: since we use indy (and we compile all our sources with the --indy switch), groovy-3.0.4/indy/*.jar seems to be in order, but I've happened to notice the other non-groovy JARs from lib aren't linked into this folder at all. So ... what's the best way to solve that?

(i) copy to the deployment site and classpath only the groovy-3.0.4/indy contents. I have actually tried and seems to work... so far. But, might it lead to a crash due to a class not found in future/when some user tries a functionality we haven't ourselves?

(ii) first hard-link all the JARs from groovy-3.0.4/indy whose names do not start with “groovy” to groovy-3.0.4/indy, and then do (i). Seems pretty easy, but won't it bring any kind of havoc? Might not there be some kind of clash?

(iii) create a script which would copy to server and create the classpath with groovy-3.0.4/indy/*.jar plus (with extended glob) lib/*.jar~lib/groovy*, or something like that?

What's the proper and least-dangerous way to do that? So that it works properly Java 8+ anywhere?

Thanks,
OC

> On 20. 5. 2020, at 10:19 PM, MG <mg...@arscreat.com> wrote:
> 
> Hi Mauro,
> 
> I think I can shed some light at where OC is coming from. Basically, if you have a project with very few dependencies and therefore few JARs, it is without any doubt convenient to have just a single groovy-all-<version> JAR: You can check with one glance what Groovy version you are using, and upgrading to another Groovy version is deleting or moving away the existing groovy-all JAR and replacing it with the new one. It does not get any easier than that.
> 
> Now if you have an automated build process with dependency resolution, plus a corresponding fully automated deployment, then all of the above makes little to no sense. If, like in my case, automatic dependency resolution is a dream (secure network, no access to any Maven server), and deployment is only semi-automated, then it is not. Due to no automatic dependency resolution, I deploy all the Groovy JARs, and those are quite a lot (I have run into (small) problems since there were two different Groovy versions deployed in my JAR dir, and I overlooked one JAR when cleaning up manually). 
> 
> It is no big deal, but if "all you want to do" is quickly (meaning: download one JAR and replace in build & (maybe multiple) deployment dirs) check out a new Groovy version, because you have a million other things to do (if I had spare time for stuff like that, I would much rather spend it on refactoring several years old, way-too-dynamic Groovy code and make it @CompileStatic, improve my core framework, etc), then the suggestion to set up a Gradle project just for that does sound a bit absurd (even if it might pay dividend later on - I personally don't like the fact that Gradle's minimal rebuidl capabilities (the last time I checked), still seemed to lag quite a bit behind using IntelliJ native builds) :-)
> 
> So while we all understand that Groovy being modular is the what is required / here to stay, for all non-fully-automated people, asking where groovy-all went is a very obvious question - and the answer "just build it yourself" is quite confusing at first glance, since if I can build it myself, why can't the Groovy project supply it in the first place* ? G-)
> 
> Cheers,
> mg
> 
> *To which the answer is: Since only your project knows all its dependencies and can therefore avoid the problems Paul mentioned -  but in a world where Java 8 is still going strong (we are on Java 11, but as we use Groovy exclusively, I am not sure if we would miss much/anything if we would still use 8, security issues aside) that is still new thinking to many people.
> 
> 
> On 19/05/2020 09:02, Mauro Molinari wrote:
>> Il 18/05/20 18:47, OCsite ha scritto:
>>> To write and maintain my own launch script takes about one thousandth time and effort as compared with learning a whole new ecosystem which I do not need at all (well, perhaps now for the first time and for the one and one sole thing, i.e., creating my own groovy-all, which should be part of the distro).
>> IMHO Learning Gradle to build a simple Groovy project does not imply learning "a whole ecosystem".
>> 
>>> 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. ;-)
>>> 
>>> If you embed all libraries and each your app is a multigigabyte monster, then of course. If I embedded complete groovy/lib to my application, I would not need groovy-all in my Extension folder either; but that would be one terribly wrong engineering, as detailed above.
>> "multigigabyte monster" is a hyperbole ;-)
>> 
>> Some tens of megabytes for complex webapps with ~120 dependencies (either direct or transitive) is reality. I don't think this is a huge problem nowadays, it of course depends on what you're targeting. 
>> 
>> In any case I can hardly follow you. You say you don't want to embed all your dependencies into a fat JAR or into a lib directory for each of your applications, because you have many dependencies and you don't want to duplicate them among your applications. But at the same time you're complaining because you'll now need I guess 2 or 3 small Groovy JARs rather than one fat JAR. It sounds like a contradiction to me. I can't understand what is stopping you from treating Groovy just like any other dependency of your project, like the mentioned fop, or xmlgraphics-commons, or any logging library you may use, or a JDBC driver, or whatsoever...
>> 
>> If the problem is "how do I know which Groovy JARs I need", perhaps you may again use Gradle to build the mentioned ZIP file, then look into the lib directory of that JAR and you'll discover all the JARs (including Groovy ones) that your application actually depends on, either directly or transitively. Then you can take what you need to adjust your deploy and share JARs among all your applications if you need to follow this route.
>> 
>> Mauro
>> 
> 

Re: How to test and deploy without groovy-all?

[MG <mg...@arscreat.com>]

Hi Mauro,

I think I can shed some light at where OC is coming from. Basically, if 
you have a project with very few dependencies and therefore few JARs, it 
is without any doubt convenient to have just a single 
groovy-all-<version> JAR: You can check with one glance what Groovy 
version you are using, and upgrading to another Groovy version is 
deleting or moving away the existing groovy-all JAR and replacing it 
with the new one. It does not get any easier than that.

Now if you have an automated build process with dependency resolution, 
plus a corresponding fully automated deployment, then all of the above 
makes little to no sense. If, like in my case, automatic dependency 
resolution is a dream (secure network, no access to any Maven server), 
and deployment is only semi-automated, then it is not. Due to no 
automatic dependency resolution, I deploy all the Groovy JARs, and those 
are quite a lot (I have run into (small) problems since there were two 
different Groovy versions deployed in my JAR dir, and I overlooked one 
JAR when cleaning up manually).

It is no big deal, but if "all you want to do" is quickly (meaning: 
download one JAR and replace in build & (maybe multiple) deployment 
dirs) check out a new Groovy version, because you have a million other 
things to do (if I had spare time for stuff like that, I would much 
rather spend it on refactoring several years old, way-too-dynamic Groovy 
code and make it @CompileStatic, improve my core framework, etc), then 
the suggestion to set up a Gradle project just for that does sound a bit 
absurd (even if it might pay dividend later on - I personally don't like 
the fact that Gradle's minimal rebuidl capabilities (the last time I 
checked), still seemed to lag quite a bit behind using IntelliJ native 
builds) :-)

So while we all understand that Groovy being modular is the what is 
required / here to stay, for all non-fully-automated people, asking 
where groovy-all went is a very obvious question - and the answer "just 
build it yourself" is quite confusing at first glance, since if I can 
build it myself, why can't the Groovy project supply it in the first 
place* ? G-)

Cheers,
mg

*To which the answer is: Since only your project knows all its 
dependencies and can therefore avoid the problems Paul mentioned - but 
in a world where Java 8 is still going strong (we are on Java 11, but as 
we use Groovy exclusively, I am not sure if we would miss much/anything 
if we would still use 8, security issues aside) that is still new 
thinking to many people.


On 19/05/2020 09:02, Mauro Molinari wrote:
> Il 18/05/20 18:47, OCsite ha scritto:
>> To write and maintain my own launch script takes about one thousandth 
>> time and effort as compared with learning a whole new ecosystem which 
>> I do not need at all (well, perhaps now for the first time and for 
>> the one and one sole thing, i.e., creating my own groovy-all, which 
>> /should/ be part of the distro).
>
> IMHO Learning Gradle to build a simple Groovy project does not imply 
> learning "a whole ecosystem".
>
>> 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. ;-)
>>
>> If you embed all libraries and each your app is a multigigabyte 
>> monster, then of course. If I embedded complete groovy/lib to my 
>> application, I would not need groovy-all in my Extension folder 
>> either; but that would be one terribly wrong engineering, as detailed 
>> above.
>
> "multigigabyte monster" is a hyperbole ;-)
>
> Some tens of megabytes for complex webapps with ~120 dependencies 
> (either direct or transitive) is reality. I don't think this is a huge 
> problem nowadays, it of course depends on what you're targeting.
>
> In any case I can hardly follow you. You say you don't want to embed 
> all your dependencies into a fat JAR or into a lib directory for each 
> of your applications, because you have many dependencies and you don't 
> want to duplicate them among your applications. But at the same time 
> you're complaining because you'll now need I guess 2 or 3 small Groovy 
> JARs rather than one fat JAR. It sounds like a contradiction to me. I 
> can't understand what is stopping you from treating Groovy just like 
> any other dependency of your project, like the mentioned fop, or 
> xmlgraphics-commons, or any logging library you may use, or a JDBC 
> driver, or whatsoever...
>
> If the problem is "how do I know which Groovy JARs I need", perhaps 
> you may again use Gradle to build the mentioned ZIP file, then look 
> into the lib directory of that JAR and you'll discover all the JARs 
> (including Groovy ones) that your application actually depends on, 
> either directly or transitively. Then you can take what you need to 
> adjust your deploy and share JARs among all your applications if you 
> need to follow this route.
>
> Mauro
>

Re: How to test and deploy without groovy-all?

[Mauro Molinari <ma...@tiscali.it>]

Il 19/05/20 12:37, Andy Duncan ha scritto:
> I woke up early this morning and thought I could put my time to use 
> writing a simple Gradle project that demonstrates how effective it can 
> be at getting a project up and running; 
> https://github.com/andyjduncan/gradle-example

And let's not forget Gradle init: 
https://docs.gradle.org/current/userguide/build_init_plugin.html

Mauro

Re: How to test and deploy without groovy-all?

[Andy Duncan <an...@adjectivecolournoun.com>]

I woke up early this morning and thought I could put my time to use writing
a simple Gradle project that demonstrates how effective it can be at
getting a project up and running;
https://github.com/andyjduncan/gradle-example

Cloning a repository and bootstrapping the whole build process with nothing
more than a JDK still seems magical to me at times. especially when doing
something like exploring a new CI tool or something.  Sure, there's a steep
learning curve initially, but it pays for itself many times over.

Hopefully this is of use to someone, even if that's just me next time I
forget how to start a basic project.

Andy

On Tue, May 19, 2020 at 8:02 AM Mauro Molinari <ma...@tiscali.it> wrote:

> Il 18/05/20 18:47, OCsite ha scritto:
>
> To write and maintain my own launch script takes about one thousandth time
> and effort as compared with learning a whole new ecosystem which I do not
> need at all (well, perhaps now for the first time and for the one and one
> sole thing, i.e., creating my own groovy-all, which *should* be part of
> the distro).
>
> IMHO Learning Gradle to build a simple Groovy project does not imply
> learning "a whole ecosystem".
>
> 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. ;-)
> If you embed all libraries and each your app is a multigigabyte monster,
> then of course. If I embedded complete groovy/lib to my application, I
> would not need groovy-all in my Extension folder either; but that would be
> one terribly wrong engineering, as detailed above.
>
> "multigigabyte monster" is a hyperbole ;-)
>
> Some tens of megabytes for complex webapps with ~120 dependencies (either
> direct or transitive) is reality. I don't think this is a huge problem
> nowadays, it of course depends on what you're targeting.
>
> In any case I can hardly follow you. You say you don't want to embed all
> your dependencies into a fat JAR or into a lib directory for each of your
> applications, because you have many dependencies and you don't want to
> duplicate them among your applications. But at the same time you're
> complaining because you'll now need I guess 2 or 3 small Groovy JARs rather
> than one fat JAR. It sounds like a contradiction to me. I can't understand
> what is stopping you from treating Groovy just like any other dependency of
> your project, like the mentioned fop, or xmlgraphics-commons, or any
> logging library you may use, or a JDBC driver, or whatsoever...
>
> If the problem is "how do I know which Groovy JARs I need", perhaps you
> may again use Gradle to build the mentioned ZIP file, then look into the
> lib directory of that JAR and you'll discover all the JARs (including
> Groovy ones) that your application actually depends on, either directly or
> transitively. Then you can take what you need to adjust your deploy and
> share JARs among all your applications if you need to follow this route.
>
> Mauro
>

Re: How to test and deploy without groovy-all?

[Mauro Molinari <ma...@tiscali.it>]

Il 18/05/20 18:47, OCsite ha scritto:  

> To write and maintain my own launch script takes about one thousandth time
and effort as compared with learning a whole new ecosystem which I do not need
at all (well, perhaps now for the first time and for the one and one sole
thing, i.e., creating my own groovy-all, which _should_ be part of the
distro).  
>

IMHO Learning Gradle to build a simple Groovy project does not imply learning
"a whole ecosystem".  

> 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. ;-)

>

> If you embed all libraries and each your app is a multigigabyte monster,
then of course. If I embedded complete groovy/lib to my application, I would
not need groovy-all in my Extension folder either; but that would be one
terribly wrong engineering, as detailed above.

"multigigabyte monster" is a hyperbole ;-)

Some tens of megabytes for complex webapps with ~120 dependencies (either
direct or transitive) is reality. I don't think this is a huge problem
nowadays, it of course depends on what you're targeting.  

In any case I can hardly follow you. You say you don't want to embed all your
dependencies into a fat JAR or into a lib directory for each of your
applications, because you have many dependencies and you don't want to
duplicate them among your applications. But at the same time you're
complaining because you'll now need I guess 2 or 3 small Groovy JARs rather
than one fat JAR. It sounds like a contradiction to me. I can't understand
what is stopping you from treating Groovy just like any other dependency of
your project, like the mentioned fop, or xmlgraphics-commons, or any logging
library you may use, or a JDBC driver, or whatsoever...

If the problem is "how do I know which Groovy JARs I need", perhaps you may
again use Gradle to build the mentioned ZIP file, then look into the lib
directory of that JAR and you'll discover all the JARs (including Groovy ones)
that your application actually depends on, either directly or transitively.
Then you can take what you need to adjust your deploy and share JARs among all
your applications if you need to follow this route.  

Mauro

Re: How to test and deploy without groovy-all?

[OCsite <oc...@ocs.cz>]

Paul,

I guess I should definitely refrain from further debating this until I actually learn the darned JMS stuff (which won't happen anytime soon, given we stick with Java 8, and will for some time to come).

> Well, suppose your project used Groovy and Spock. Perhaps you chose the all jar and Spock has a dependency on the non-all jar?


I'd say the module concept went heel over the head somehow. In my opinion, both my project and Spock should simply reference the classes needed, nothing more[1], nothing less, and runtime, these classes should come from either all-jar or separate small jars or whatever else, depending on what's chosen to be used for the deployment and put into the classpath.

Self-evidently it does not work like that anymore. Quadruple ick :/

Thanks and all the best,
OC

[1] in a purely hypothetical better world than the Java ecosystem actually is, along with the version built against, which coupled with the information of inter-version compatibility stored in frameworks would allow the system either to choose the proper library version to load automatically, or report reliably at launch-time that it is not possible. Alas, that approach, far as I know that is, is impossible with JARs, for there's no information of the inter-version compatibility at all, so the point is moot.

> On 19 May 2020, at 13:32, Paul King <pa...@asert.com.au> wrote:
> 
> 
> On Tue, May 19, 2020 at 8:32 PM OCsite <ocs@ocs.cz <ma...@ocs.cz>> wrote:
> Paul,
> 
>> On 19 May 2020, at 7:09, Paul King <paulk@asert.com.au <ma...@asert.com.au>> wrote:
>> On Tue, May 19, 2020 at 2:58 AM Corum, Michael <mcorum@rgare.com <ma...@rgare.com>> wrote:
>> 
>> The TL;DR version, slightly simplified: If two jars containing the same package, e.g. the non-all jar and the all jar were both on the module path (and one might be there indirectly), the VM may refuse to start. .... Our options were all jar only (forcing all users to always have all modules - basically no modules any more) or no all jar. ...
> 
> Well I know next-to-nothing of Java modules — at the moment, we need to be able to run with Java 8, so we can't use the thing even should we want to, which I doubt —, so my question is probably über-stupid and based only on my massive ignorance of that stuff, but anyway: how on earth could a groovy/embedded/groovy-all.jar (or any other JAR from any other directory not explicitly used in the project) ever get into there unwanted, unless the user intentionally adds its path to --module-path?
> 
> Well, suppose your project used Groovy and Spock. Perhaps you chose the all jar and Spock has a dependency on the non-all jar?
>> One thing we thought about to reduce the pain for embedded Groovy users was to create an embedded folder in the distro zip with the fat jar (like in 2.4) but not publishing the fat jar to any repo. We worried that someone else might publish it, so never followed through.
> 
> Well again I freely admit I do not understand the stuff at all, but still, I can't see that a sole publication of a JAR could ever break projects which do not explicitly use it — otherwise, since anybody can (and does) publish nearly anything, no project ever would work Java 9+ anymore?!?
> 
> It could be a transitive dependency. And yes, JDK9 was quite some work for many projects. E.g.:
> https://github.com/google/flogger/issues/22 <https://github.com/google/flogger/issues/22> 
>  
>> Perhaps that is still viable.
> 
> From my POV it would be the easiest way for all — simply to add embedded/groovy-all.jar to the binary distro, nothing more, nothing less.
> 
> Is there really any danger that such a JAR would get amongst the other modules unintentionally and unwanted?!? Again, I do apologise for my massive ignorance, but I really can't see how :-
> 
> If it never gets in a repo, I would say the risk is low. If anyone ever puts it in a repo (without embedding under a different package name) then all bets would be off.
> 
> Cheers, Paul.
> 
>  
> Thanks,
> OC
> 
>> From: OCsite <ocs@ocs.cz <ma...@ocs.cz>>
>> Reply-To: "users@groovy.apache.org <ma...@groovy.apache.org>" <users@groovy.apache.org <ma...@groovy.apache.org>>
>> Date: Monday, May 18, 2020 at 11:47 AM
>> To: "users@groovy.apache.org <ma...@groovy.apache.org>" <users@groovy.apache.org <ma...@groovy.apache.org>>
>> Subject: Re: How to test and deploy without groovy-all?
>> 
>>  
>> 
>> External e-mail. Use caution! / Courriel externe. Faites attention!
>> 
>>  
>> 
>> On 18 May 2020, at 18:12, Mauro Molinari <mauromol@tiscali.it <ma...@tiscali.it>> wrote:
>> 
>>  
>> 
>> Il 18/05/20 17:48, OCsite ha scritto:
>> 
>> (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.
>> 
>> I can't see how. Embedding all the dependencies is not reasonable: that way, your application gets monstrously big, and you either waste both the bandwidth installing and the space on all the servers, or you need to have a smart installation script, probably rsync-based. Still, even with this, you won't be able to easily keep old application versions (again, unless you make some smart tools based on hardlinks), etc.
>> 
>>  
>> 
>> Embedding makes sense where the thing does not change often. It very definitely makes an excellent sense to embed all the Groovy JARs into groovy-all, for there's a small number of separate Groovy versions to keep for a particular server. It would be completely absurd to embed groovy (and other libraries, which change even seldom than Groovy) into the application, whose new version is deployed pretty often.
>> 
>>  
>> 
>> Aside of that, there's sharing of resources: whilst we do need for application A to use Groovy 2.4.17 and B to use 3.0.3, there's also C, D and E, which all use 2.4.17, and F and G which both use 3.0.3. Aside of that, all the application share the WebObjects and WOnder libraries and a number of other JARs. Embedding them all into each the application would be a nonsense.
>> 
>> 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".
>> 
>> Actually JAR hell is not caused by manual handling of libraries, but by the completely stupid Java JAR design. Given the Sun engineers already had had an experience with an infinitely better OpenStep, which they had co-designed with NeXT and whose frameworks do not sport this problem, it is very sad; and precisely the same applies to the language itself: how on earth can somebody who already experienced the elegance and power of Objective C invent an übercrap like Java?!? Anyway, I am digressing again, sorry for that :(
>> 
>>  
>> 
>> Anyway, with groovy-all there's no JAR-hell at least far as Groovy itself is concerned. Removing groovy-all brings it, or at the very least its potential, to Groovy itself too :(
>> 
>> 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
>> 
>> Which is precisely what you do not want to do, at least, not if you use a big number of big libraries, as detailed above.
>> 
>> plus the scripts needed to run your application under different operating systems. Substantially for free.
>> 
>> To write and maintain my own launch script takes about one thousandth time and effort as compared with learning a whole new ecosystem which I do not need at all (well, perhaps now for the first time and for the one and one sole thing, i.e., creating my own groovy-all, which should be part of the distro).
>> 
>> 
>> 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.-
>> 
>> Creating so either hundreds of copies of all the libraries on each the server, which would be patently absurd (not speaking of the bandwidth copying them again and again and again completely unnecessarily upon each new app version), or having to prepare a pretty smart hardlink-based environment for keeping old copies, which would be possible, but again pretty difficult and time- and effort-consuming, with a danger of errors.
>> 
>> 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.
>> 
>> Perhaps so, but what would I get, as compared with launching groovyc directly? Gradle can't be used to keep track of project changes — IDE does that itself. And embedding all the libraries into the application, which I would get for free, is definitely what I do not want, as detailed above (besides, if I wanted it, I would simply mark those libraries as resources in Xcode and would get that for free too).
>> 
>> 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.
>> 
>> For one, I don't want it, but far as I can say, I need it; and I can't see any easy way to build it, unless I learn a whole new build system which I do not need for anything else.
>> 
>> 
>> 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. ;-)
>> 
>> If you embed all libraries and each your app is a multigigabyte monster, then of course. If I embedded complete groovy/lib to my application, I would not need groovy-all in my Extension folder either; but that would be one terribly wrong engineering, as detailed above.
>> 
>>  
>> 
>> Thanks,
>> 
>> OC
>> 
> 

Re: How to test and deploy without groovy-all?

[Paul King <pa...@asert.com.au>]

On Tue, May 19, 2020 at 8:32 PM OCsite <oc...@ocs.cz> wrote:

> Paul,
>
> On 19 May 2020, at 7:09, Paul King <pa...@asert.com.au> wrote:
> On Tue, May 19, 2020 at 2:58 AM Corum, Michael <mc...@rgare.com> wrote:
>
> The TL;DR version, slightly simplified: If two jars containing the same
> package, e.g. the non-all jar and the all jar were both on the module path
> (and one might be there indirectly), the VM may refuse to start. .... Our
> options were all jar only (forcing all users to always have all modules -
> basically no modules any more) or no all jar. ...
>
>
> Well I know next-to-nothing of Java modules — at the moment, we need to be
> able to run with Java 8, so we can't use the thing even should we want to,
> which I doubt —, so my question is probably über-stupid and based only on
> my massive ignorance of that stuff, but anyway: how on earth could a
> groovy/embedded/groovy-all.jar (or *any* other JAR from *any* other
> directory not explicitly used in the project) ever get into there unwanted,
> unless the user *intentionally* adds its path to --module-path?
>

Well, suppose your project used Groovy and Spock. Perhaps you chose the all
jar and Spock has a dependency on the non-all jar?

> One thing we thought about to reduce the pain for embedded Groovy users
> was to create an embedded folder in the distro zip with the fat jar (like
> in 2.4) but not publishing the fat jar to any repo. We worried that someone
> else might publish it, so never followed through.
>
>
> Well again I freely admit I do not understand the stuff at all, but still,
> I can't see that a sole publication of a JAR could ever break projects
> which do not explicitly use it — otherwise, since anybody can (and does)
> publish nearly anything, no project ever would work Java 9+ anymore?!?
>

It could be a transitive dependency. And yes, JDK9 was quite some work for
many projects. E.g.:
https://github.com/google/flogger/issues/22


> Perhaps that is still viable.
>
>
> From my POV it would be the easiest way for all — simply to add
> embedded/groovy-all.jar to the binary distro, nothing more, nothing less.
>
> Is there *really* any danger that such a JAR would get amongst the other
> modules unintentionally and unwanted?!? Again, I do apologise for my
> massive ignorance, but I really can't see how :-
>

If it never gets in a repo, I would say the risk is low. If anyone ever
puts it in a repo (without embedding under a different package name) then
all bets would be off.

Cheers, Paul.



> Thanks,
> OC
>
> *From: *OCsite <oc...@ocs.cz>
>> *Reply-To: *"users@groovy.apache.org" <us...@groovy.apache.org>
>> *Date: *Monday, May 18, 2020 at 11:47 AM
>> *To: *"users@groovy.apache.org" <us...@groovy.apache.org>
>> *Subject: *Re: How to test and deploy without groovy-all?
>>
>>
>>
>> External e-mail. Use caution! / Courriel externe. Faites attention!
>> ------------------------------
>>
>>
>>
>> On 18 May 2020, at 18:12, Mauro Molinari <ma...@tiscali.it> wrote:
>>
>>
>>
>> Il 18/05/20 17:48, OCsite ha scritto:
>>
>> (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.
>>
>> I can't see how. Embedding all the dependencies is not reasonable: that
>> way, your application gets monstrously big, and you either waste both the
>> bandwidth installing and the space on all the servers, or you need to have
>> a smart installation script, probably rsync-based. Still, even with this,
>> you won't be able to easily keep old application versions (again, unless
>> you make some smart tools based on hardlinks), etc.
>>
>>
>>
>> Embedding makes sense where the thing does not change often. It very
>> definitely makes an excellent sense to embed all the Groovy JARs into
>> groovy-all, for there's a small number of separate Groovy versions to keep
>> for a particular server. It would be completely absurd to embed groovy (and
>> other libraries, which change even seldom than Groovy) into the
>> application, whose new version is deployed pretty often.
>>
>>
>>
>> Aside of that, there's sharing of resources: whilst we do need for
>> application A to use Groovy 2.4.17 and B to use 3.0.3, there's also C, D
>> and E, which all use 2.4.17, and F and G which both use 3.0.3. Aside of
>> that, *all* the application share the WebObjects and WOnder libraries
>> and a number of other JARs. Embedding them all into each the application
>> would be a nonsense.
>>
>> 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".
>>
>> Actually JAR hell is not caused by manual handling of libraries, but by
>> the completely stupid Java JAR design. Given the Sun engineers already had
>> had an experience with an infinitely better OpenStep, which they had
>> co-designed with NeXT and whose frameworks do not sport this problem, it is
>> very sad; and precisely the same applies to the language itself: how on
>> earth can somebody who already experienced the elegance and power of
>> Objective C invent an übercrap like Java?!? Anyway, I am digressing again,
>> sorry for that :(
>>
>>
>>
>> Anyway, with groovy-all there's no JAR-hell at least far as Groovy itself
>> is concerned. Removing groovy-all brings it, or at the very least its
>> potential, to Groovy itself too :(
>>
>> 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
>>
>> Which is precisely what you *do not* want to do, at least, not if you
>> use a big number of big libraries, as detailed above.
>>
>> plus the scripts needed to run your application under different operating
>> systems. Substantially for free.
>>
>> To write and maintain my own launch script takes about one thousandth
>> time and effort as compared with learning a whole new ecosystem which I do
>> not need at all (well, perhaps now for the first time and for the one and
>> one sole thing, i.e., creating my own groovy-all, which *should* be part
>> of the distro).
>>
>> 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.-
>>
>> Creating so either hundreds of copies of all the libraries on each the
>> server, which would be patently absurd (not speaking of the bandwidth
>> copying them again and again and again completely unnecessarily upon each
>> new app version), or having to prepare a pretty smart hardlink-based
>> environment for keeping old copies, which would be possible, but again
>> pretty difficult and time- and effort-consuming, with a danger of errors.
>>
>> 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.
>>
>> Perhaps so, but what would I get, as compared with launching groovyc
>> directly? Gradle can't be used to keep track of project changes — IDE does
>> that itself. And embedding all the libraries into the application, which I
>> would get for free, is definitely what I do not want, as detailed above
>> (besides, *if* I wanted it, I would simply mark those libraries as
>> resources in Xcode and would get that for free too).
>>
>> 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.
>>
>> For one, I don't want it, but far as I can say, I need it; and I can't
>> see any easy way to build it, unless I learn a whole new build system which
>> I do not need for anything else.
>>
>> 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. ;-)
>>
>> If you embed all libraries and each your app is a multigigabyte monster,
>> then of course. If I embedded complete groovy/lib to my application, I
>> would not need groovy-all in my Extension folder either; but that would be
>> one terribly wrong engineering, as detailed above.
>>
>>
>>
>> Thanks,
>>
>> OC
>>
>
>

Re: How to test and deploy without groovy-all?

[OCsite <oc...@ocs.cz>]

Paul,

> On 19 May 2020, at 7:09, Paul King <pa...@asert.com.au> wrote:
> On Tue, May 19, 2020 at 2:58 AM Corum, Michael <mcorum@rgare.com <ma...@rgare.com>> wrote:
> 
> The TL;DR version, slightly simplified: If two jars containing the same package, e.g. the non-all jar and the all jar were both on the module path (and one might be there indirectly), the VM may refuse to start. .... Our options were all jar only (forcing all users to always have all modules - basically no modules any more) or no all jar. ...

Well I know next-to-nothing of Java modules — at the moment, we need to be able to run with Java 8, so we can't use the thing even should we want to, which I doubt —, so my question is probably über-stupid and based only on my massive ignorance of that stuff, but anyway: how on earth could a groovy/embedded/groovy-all.jar (or any other JAR from any other directory not explicitly used in the project) ever get into there unwanted, unless the user intentionally adds its path to --module-path?

> One thing we thought about to reduce the pain for embedded Groovy users was to create an embedded folder in the distro zip with the fat jar (like in 2.4) but not publishing the fat jar to any repo. We worried that someone else might publish it, so never followed through.

Well again I freely admit I do not understand the stuff at all, but still, I can't see that a sole publication of a JAR could ever break projects which do not explicitly use it — otherwise, since anybody can (and does) publish nearly anything, no project ever would work Java 9+ anymore?!?

> Perhaps that is still viable.

From my POV it would be the easiest way for all — simply to add embedded/groovy-all.jar to the binary distro, nothing more, nothing less.

Is there really any danger that such a JAR would get amongst the other modules unintentionally and unwanted?!? Again, I do apologise for my massive ignorance, but I really can't see how :-O

Thanks,
OC

> From: OCsite <ocs@ocs.cz <ma...@ocs.cz>>
> Reply-To: "users@groovy.apache.org <ma...@groovy.apache.org>" <users@groovy.apache.org <ma...@groovy.apache.org>>
> Date: Monday, May 18, 2020 at 11:47 AM
> To: "users@groovy.apache.org <ma...@groovy.apache.org>" <users@groovy.apache.org <ma...@groovy.apache.org>>
> Subject: Re: How to test and deploy without groovy-all?
> 
>  
> 
> External e-mail. Use caution! / Courriel externe. Faites attention!
> 
>  
> 
> On 18 May 2020, at 18:12, Mauro Molinari <mauromol@tiscali.it <ma...@tiscali.it>> wrote:
> 
>  
> 
> Il 18/05/20 17:48, OCsite ha scritto:
> 
> (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.
> 
> I can't see how. Embedding all the dependencies is not reasonable: that way, your application gets monstrously big, and you either waste both the bandwidth installing and the space on all the servers, or you need to have a smart installation script, probably rsync-based. Still, even with this, you won't be able to easily keep old application versions (again, unless you make some smart tools based on hardlinks), etc.
> 
>  
> 
> Embedding makes sense where the thing does not change often. It very definitely makes an excellent sense to embed all the Groovy JARs into groovy-all, for there's a small number of separate Groovy versions to keep for a particular server. It would be completely absurd to embed groovy (and other libraries, which change even seldom than Groovy) into the application, whose new version is deployed pretty often.
> 
>  
> 
> Aside of that, there's sharing of resources: whilst we do need for application A to use Groovy 2.4.17 and B to use 3.0.3, there's also C, D and E, which all use 2.4.17, and F and G which both use 3.0.3. Aside of that, all the application share the WebObjects and WOnder libraries and a number of other JARs. Embedding them all into each the application would be a nonsense.
> 
> 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".
> 
> Actually JAR hell is not caused by manual handling of libraries, but by the completely stupid Java JAR design. Given the Sun engineers already had had an experience with an infinitely better OpenStep, which they had co-designed with NeXT and whose frameworks do not sport this problem, it is very sad; and precisely the same applies to the language itself: how on earth can somebody who already experienced the elegance and power of Objective C invent an übercrap like Java?!? Anyway, I am digressing  again, sorry for that :(
> 
>  
> 
> Anyway, with groovy-all there's no JAR-hell at least far as Groovy itself is concerned. Removing groovy-all brings it, or at the very least its potential, to Groovy itself too :(
> 
> 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
> 
> Which is precisely what you do not want to do, at least, not if you use a big number of big libraries, as detailed above.
> 
> plus the scripts needed to run your application under different operating systems. Substantially for free.
> 
> To write and maintain my own launch script takes about one thousandth time and effort as compared with learning a whole new ecosystem which I do not need at all (well, perhaps now for the first time and for the one and one sole thing, i.e., creating my own groovy-all, which should be part of the distro).
> 
> 
> 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.-
> 
> Creating so either hundreds of copies of all the libraries on each the server, which would be patently absurd (not speaking of the bandwidth copying them again and again and again completely unnecessarily upon each new app version), or having to prepare a pretty smart hardlink-based environment for keeping old copies, which would be possible, but again pretty difficult and time- and effort-consuming, with a danger of errors.
> 
> 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.
> 
> Perhaps so, but what would I get, as compared with launching groovyc directly? Gradle can't be used to keep track of project changes — IDE does that itself. And embedding all the libraries into the application, which I would get for free, is definitely what I do not want, as detailed above (besides, if I wanted it, I would simply mark those libraries as resources in Xcode and would get that for free too).
> 
> 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.
> 
> For one, I don't want it, but far as I can say, I need it; and I can't see any easy way to build it, unless I learn a whole new build system which I do not need for anything else.
> 
> 
> 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. ;-)
> 
> If you embed all libraries and each your app is a multigigabyte monster, then of course. If I embedded complete groovy/lib to my application, I would not need groovy-all in my Extension folder either; but that would be one terribly wrong engineering, as detailed above.
> 
>  
> 
> Thanks,
> 
> OC
> 

Re: How to test and deploy without groovy-all?

[Paul King <pa...@asert.com.au>]

On Tue, May 19, 2020 at 2:58 AM Corum, Michael <mc...@rgare.com> wrote:

> I’ve noticed that there is a general sense that the majority of the users
> don’t need groovy-all.  How did that knowledge come about?  Was there a
> survey that I missed?  Is there a place I can go to see the survey
> results?  (By the way – we depend on it in our projects).
>

The dropping of support for the "all" jar was the only viable solution to
meet the JPMS split package requirements for JDK9+. Otherwise, we certainly
would have kept it.

The TL;DR version, slightly simplified: If two jars containing the same
package, e.g. the non-all jar and the all jar were both on the module path
(and one might be there indirectly), the VM may refuse to start. In other
scenarios like one on classpath and one on module path, one might load and
the other silently ignored and then weird classloader issues arise. Our
options were all jar only (forcing all users to always have all modules -
basically no modules any more) or no all jar. We didn't like either option
but the all pom was our best attempt to minimise the pain for users with
access to common build tools.

One thing we thought about to reduce the pain for embedded Groovy users was
to create an embedded folder in the distro zip with the fat jar (like in
2.4) but not publishing the fat jar to any repo. We worried that someone
else might publish it, so never followed through. Perhaps that is still
viable.

Cheers, Paul.


> *Michael Corum*
>
> VP, Technical Architecture Solutions
>
>
>
> *RGA Reinsurance Company*
>
> *16600 Swingley Ridge Road*
>
> *Chesterfield, Missouri 6301701706*
>
> *T* 636.736.7066
>
> *www.rgare.com <http://www.rgare.com>*
>
>
>
>
>
>
>
> *From: *OCsite <oc...@ocs.cz>
> *Reply-To: *"users@groovy.apache.org" <us...@groovy.apache.org>
> *Date: *Monday, May 18, 2020 at 11:47 AM
> *To: *"users@groovy.apache.org" <us...@groovy.apache.org>
> *Subject: *Re: How to test and deploy without groovy-all?
>
>
>
> External e-mail. Use caution! / Courriel externe. Faites attention!
> ------------------------------
>
>
>
> On 18 May 2020, at 18:12, Mauro Molinari <ma...@tiscali.it> wrote:
>
>
>
> Il 18/05/20 17:48, OCsite ha scritto:
>
> (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.
>
> I can't see how. Embedding all the dependencies is not reasonable: that
> way, your application gets monstrously big, and you either waste both the
> bandwidth installing and the space on all the servers, or you need to have
> a smart installation script, probably rsync-based. Still, even with this,
> you won't be able to easily keep old application versions (again, unless
> you make some smart tools based on hardlinks), etc.
>
>
>
> Embedding makes sense where the thing does not change often. It very
> definitely makes an excellent sense to embed all the Groovy JARs into
> groovy-all, for there's a small number of separate Groovy versions to keep
> for a particular server. It would be completely absurd to embed groovy (and
> other libraries, which change even seldom than Groovy) into the
> application, whose new version is deployed pretty often.
>
>
>
> Aside of that, there's sharing of resources: whilst we do need for
> application A to use Groovy 2.4.17 and B to use 3.0.3, there's also C, D
> and E, which all use 2.4.17, and F and G which both use 3.0.3. Aside of
> that, *all* the application share the WebObjects and WOnder libraries and
> a number of other JARs. Embedding them all into each the application would
> be a nonsense.
>
> 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".
>
> Actually JAR hell is not caused by manual handling of libraries, but by
> the completely stupid Java JAR design. Given the Sun engineers already had
> had an experience with an infinitely better OpenStep, which they had
> co-designed with NeXT and whose frameworks do not sport this problem, it is
> very sad; and precisely the same applies to the language itself: how on
> earth can somebody who already experienced the elegance and power of
> Objective C invent an übercrap like Java?!? Anyway, I am digressing again,
> sorry for that :(
>
>
>
> Anyway, with groovy-all there's no JAR-hell at least far as Groovy itself
> is concerned. Removing groovy-all brings it, or at the very least its
> potential, to Groovy itself too :(
>
> 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
>
> Which is precisely what you *do not* want to do, at least, not if you use
> a big number of big libraries, as detailed above.
>
> plus the scripts needed to run your application under different operating
> systems. Substantially for free.
>
> To write and maintain my own launch script takes about one thousandth time
> and effort as compared with learning a whole new ecosystem which I do not
> need at all (well, perhaps now for the first time and for the one and one
> sole thing, i.e., creating my own groovy-all, which *should* be part of
> the distro).
>
> 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.-
>
> Creating so either hundreds of copies of all the libraries on each the
> server, which would be patently absurd (not speaking of the bandwidth
> copying them again and again and again completely unnecessarily upon each
> new app version), or having to prepare a pretty smart hardlink-based
> environment for keeping old copies, which would be possible, but again
> pretty difficult and time- and effort-consuming, with a danger of errors.
>
> 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.
>
> Perhaps so, but what would I get, as compared with launching groovyc
> directly? Gradle can't be used to keep track of project changes — IDE does
> that itself. And embedding all the libraries into the application, which I
> would get for free, is definitely what I do not want, as detailed above
> (besides, *if* I wanted it, I would simply mark those libraries as
> resources in Xcode and would get that for free too).
>
> 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.
>
> For one, I don't want it, but far as I can say, I need it; and I can't see
> any easy way to build it, unless I learn a whole new build system which I
> do not need for anything else.
>
> 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. ;-)
>
> If you embed all libraries and each your app is a multigigabyte monster,
> then of course. If I embedded complete groovy/lib to my application, I
> would not need groovy-all in my Extension folder either; but that would be
> one terribly wrong engineering, as detailed above.
>
>
>
> Thanks,
>
> OC
>

Re: How to test and deploy without groovy-all?

["Corum, Michael" <mc...@rgare.com>]

I’ve noticed that there is a general sense that the majority of the users don’t need groovy-all.  How did that knowledge come about?  Was there a survey that I missed?  Is there a place I can go to see the survey results?  (By the way – we depend on it in our projects).

Michael Corum
VP, Technical Architecture Solutions

RGA Reinsurance Company
16600 Swingley Ridge Road
Chesterfield, Missouri 6301701706
T 636.736.7066
www.rgare.com



From: OCsite <oc...@ocs.cz>
Reply-To: "users@groovy.apache.org" <us...@groovy.apache.org>
Date: Monday, May 18, 2020 at 11:47 AM
To: "users@groovy.apache.org" <us...@groovy.apache.org>
Subject: Re: How to test and deploy without groovy-all?

External e-mail. Use caution! / Courriel externe. Faites attention!
________________________________

On 18 May 2020, at 18:12, Mauro Molinari <ma...@tiscali.it>> wrote:

Il 18/05/20 17:48, OCsite ha scritto:
(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.
I can't see how. Embedding all the dependencies is not reasonable: that way, your application gets monstrously big, and you either waste both the bandwidth installing and the space on all the servers, or you need to have a smart installation script, probably rsync-based. Still, even with this, you won't be able to easily keep old application versions (again, unless you make some smart tools based on hardlinks), etc.

Embedding makes sense where the thing does not change often. It very definitely makes an excellent sense to embed all the Groovy JARs into groovy-all, for there's a small number of separate Groovy versions to keep for a particular server. It would be completely absurd to embed groovy (and other libraries, which change even seldom than Groovy) into the application, whose new version is deployed pretty often.

Aside of that, there's sharing of resources: whilst we do need for application A to use Groovy 2.4.17 and B to use 3.0.3, there's also C, D and E, which all use 2.4.17, and F and G which both use 3.0.3. Aside of that, all the application share the WebObjects and WOnder libraries and a number of other JARs. Embedding them all into each the application would be a nonsense.
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".
Actually JAR hell is not caused by manual handling of libraries, but by the completely stupid Java JAR design. Given the Sun engineers already had had an experience with an infinitely better OpenStep, which they had co-designed with NeXT and whose frameworks do not sport this problem, it is very sad; and precisely the same applies to the language itself: how on earth can somebody who already experienced the elegance and power of Objective C invent an übercrap like Java?!? Anyway, I am digressing again, sorry for that :(

Anyway, with groovy-all there's no JAR-hell at least far as Groovy itself is concerned. Removing groovy-all brings it, or at the very least its potential, to Groovy itself too :(
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
Which is precisely what you do not want to do, at least, not if you use a big number of big libraries, as detailed above.
plus the scripts needed to run your application under different operating systems. Substantially for free.
To write and maintain my own launch script takes about one thousandth time and effort as compared with learning a whole new ecosystem which I do not need at all (well, perhaps now for the first time and for the one and one sole thing, i.e., creating my own groovy-all, which should be part of the distro).

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.-
Creating so either hundreds of copies of all the libraries on each the server, which would be patently absurd (not speaking of the bandwidth copying them again and again and again completely unnecessarily upon each new app version), or having to prepare a pretty smart hardlink-based environment for keeping old copies, which would be possible, but again pretty difficult and time- and effort-consuming, with a danger of errors.
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.
Perhaps so, but what would I get, as compared with launching groovyc directly? Gradle can't be used to keep track of project changes — IDE does that itself. And embedding all the libraries into the application, which I would get for free, is definitely what I do not want, as detailed above (besides, if I wanted it, I would simply mark those libraries as resources in Xcode and would get that for free too).
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.
For one, I don't want it, but far as I can say, I need it; and I can't see any easy way to build it, unless I learn a whole new build system which I do not need for anything else.

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. ;-)
If you embed all libraries and each your app is a multigigabyte monster, then of course. If I embedded complete groovy/lib to my application, I would not need groovy-all in my Extension folder either; but that would be one terribly wrong engineering, as detailed above.

Thanks,
OC

Re: How to test and deploy without groovy-all?

[OCsite <oc...@ocs.cz>]

Jochen,

first, this debate might be getting a bit at the moot side: meantime, I have decided just to slightly improve my scripts to simply add  groovy/lib/*.jar to the classpath for the deployment.

It will make installation of new Groovy versions to the servers a bit more difficult than it used to be with -all, but the difference's not that big, and after all, we won't install too many Groovys in there — 3.0.4 definitely, one or two newer ones possibly if they happen to fix some bug important to us. 4.x hardly, too soon for that; and I guess when we do the next refactorisation, there'll be 5 or 6 out :)

> On 19 May 2020, at 7:15, Jochen Theodorou <bl...@gmx.org> wrote:
> On 19.05.20 03:53, OCsite wrote:
>> Well, thanks, I'll check the thing, though at the first look it rather
>> seems to be a tool for a Gradle project owner who wants to move his
>> projects into Xcode. Me, I'm precisely the opposite case — I've got
>> Xcode projects which I /possibly might/ want to move into Gradle.
> 
> I think you need to explain your deployment situation a bit more. Just
> some rough numbers... to how many computers do you deploy

The number of servers changes and I am not sure of it (I do just the development, and I work directly with the test servers, but I do not do administration of the deployment sites at all, there are much better people for that :)), but far as I know, at the moment it's five-odd, presuming to go ten-plus in a very near future.

> and how many applications?

At the moment three of them actively developed plus ten-odd more-or-less legacy ones, just maintained (some of them waiting to massive refactoring and resurrection soon as there's time for that, others waiting to be silently forgotten in near future :))

> All Mac?

Most of the servers are, at the moment, CentOS; a couple of them still Macs. As mentioned above, I do not maintain the servers myself, my admin skills are not that great — but I'm told the client has encountered some hard-to-solve problems with newer macOS servers (whilst old ones beginning not to be viable alternative due to security holes which Apple does not fix anymore in the legacy software) which is, I am told, along with easy and reliable virtualisation, the main reason of the move to CentOS.

From my point of view there's essentially no difference, just different deployment/extension paths, which our launch script solves automagically based on a couple of environment variables.

Anyway, the thing is, we rarely add new functionalities which would need to change the list of JARs, and thus we don't really need an automated dependency management. During the last, ahem... four or five years, far as I can recall without checking the project history files, we added just the aforementioned Fop and Apache POI, and for new apps only switched WOnder 6 to WOnder 7; nothing else. In general, we rather stick with old versions of everything embracing the devil we know (with work-arounds well-tested), instead of continuously upgrading and getting thus fixes of known problems (which we don't really need, for we already have worked around them) for a price of new unknown bugs (which could bit us in our tender parts). Hence, incidentally, also the Java 8, and Groovy 2.4- until very recently.

Thus, our set of libraries is pretty at the static side:

- WebObjects JARs which never change and never will
- FrontBase JAR which did not change for years and hardly will in a foreseeable future
- WOnder JARs which change every five-odd years when we decide to embrace a new release (and even that for new apps only)
- a couple of external JARs for extra functionalities like Fop or POI. Again, we never upgrade to newer release unless we have to or unless we refactor the whole app
- Groovy JAR (now will become all JARs from /lib) as needed by the Groovy version for the particular application.

Again, for the reasons aforementioned, until we refactor our older apps, we definitely want to stick with the very Groovy version we tested the app heavily against (2.4.17 for most, 2.3.8 for a couple of older ones). Nevertheless we just now are refactoring one of our apps very heavily, and for it, I'd like to go Groovy 3 (presuming 4 won't be stable enough for some time to come).

>> If at all. I still can't see any advantage it would bring to me. It
>> would automatically maintain dependencies, which is something I have
>> never really needed (at least, not until groovy-all disappeared).
> 
> there have been afaik 2 main reasons to remove groovy-all...
> (1) Java module system (JMS).
> ... At the same time the dependency on the module name is part of the Java
> code now. So if you make one library that depends on groovy-all and one
> that depends on groovy-core you are screwed...

So I can't anymore freely decide whether to classpath lib/*.jar or embedded/-all.jar to run one and the same app build?

Brave new world indeed :( Lucky us we stick with Java 8. Looks like lots of fun awaits us in future when we are forced to go 9 :(

> (2) People were asking for a smaller groovy jar for years.

I absolutely understand that need for people who embed all the JARs into their applications, and deploy the whole monster.

We — perhaps as one rara avis — do otherwise: we strive to put as much of the functionality shared amongst our apps as reasonably possible to the Extensions folder, only referencing those shared JARs in the classpath. Seems much more reasonable to us.

> As I understood it, you care not so much about these points. I assume
> you do not plan to switch to JMS in the next years at all

The more I hear of the thing, the more I intend to dodge it as long as reasonably possible :)

>> Besides, I wonder how reliably it could in principle work. Most of the
>> JAR-hell problems we have encountered happened when there were more
>> versions of the same library and some of them did work OK, some of them
>> did not: for example, having added Fop support, we had to
>> remove xmlgraphics-commons-2.3.jar which we used before without any
>> problem, and had to switch back to xmlgraphics-commons-1.5.jar, which
>> works OK with the Fop thing, whilst 2.3 does not[1]. I /do/ wonder
>> whether Gradle or any other auto-dependency manager /could ever/automate
>> properly and without problems /this/? Is there such kind of information
>> anywhere for the manager to do such decisions reliably?
> 
> I am not 100% sure what you mean with "this".

„This“ problem of decision which version of the JAR to use so that it works properly, e.g., whether to classpath xmlgraphics-commons-2.3.jar or xmlgraphics-commons-1.5.jar.

It's actually a bit at the difficult side: the information of the version used for compilation does not suffice, you need also information of inter-version backward compatibility and breaking changes. This is what the aforementioned OpenStep frameworks did provide, but JARs — far as I know — do not; thus, — again only far as I know (and I can be easily wrong!) — such decisions can't be automated reliably with JARs and must be left to the user, who would force versions manually. (That's essentially the gist of the cesspool what's usually called JAR-hell, far as I can say.)

In that case it's infinitely easier not to use a semi-automated-tool-which-needs-hints-anyway-otherwise-doesnot-work-well, and simply put the JARs needed to the classpath (more or less) manually.

(Perhaps the JMS thing strives to solve this very problem, I don't know. Even if so, knowing Java, I don't believe they would to that right — almost nothing they ever did :( )

> Right now you manage dependencies manually I assume.

Precisely. Conceptually, I create manually the full contents of the classpath (employing a couple of simple scripts which help e.g., to find JARs in WO/WOnder frameworks or to auto-add proper JAR /now will be JARs/ for the Groovy the app has been built with etc., but that makes no difference in principle).

And, very rarely it brought any problems (about the only cases I can recall were those when we had to try different versions of a JAR to find the one other JARs work with, like the aforementioned xmlgraphics 2.3 vs 1.5; and as I wrote, I would be really surprised if this could be automated reliably — could it?)

Thanks and all the best,
OC

Re: How to test and deploy without groovy-all?

[Jochen Theodorou <bl...@gmx.org>]

On 19.05.20 03:53, OCsite wrote:
> Well, thanks, I'll check the thing, though at the first look it rather
> seems to be a tool for a Gradle project owner who wants to move his
> projects into Xcode. Me, I'm precisely the opposite case — I've got
> Xcode projects which I /possibly might/ want to move into Gradle.

I think you need to explain your deployment situation a bit more. Just
some rough numbers... to how many computers do you deploy and how many
applications? All Mac?

> If at all. I still can't see any advantage it would bring to me. It
> would automatically maintain dependencies, which is something I have
> never really needed (at least, not until groovy-all disappeared).

there have been afaik 2 main reasons to remove groovy-all...
(1) Java module system (JMS).
To use Groovy as automatic module we have to make Groovy JMS-ready. We
did that in code in some places, but also by providing an automated
module name. The problem is no two modules can share the same packages.
At the same time the dependency on the module name is part of the Java
code now. So if you make one library that depends on groovy-all and one
that depends on groovy-core you are screwed. You would have to start
patching modules, to supply an alternate module-info.class and many
other things, that basically do not allow you to deploy the original
version of the library in any way anymore.
(2) People were asking for a smaller groovy jar for years. That is not a
new request, which actually tends not to come up on the list as often,
but more on conferences and when talking with people privately. But in
general the trend goes more to lean libraries and a several MB big lib
like Groovy does not make a good figure here.

As I understood it, you care not so much about these points. I assume
you do not plan to switch to JMS in the next years at all (the command
line is pure terror if you do not keep the conventions they invented are
totally orthogonal to what people commonly use) for example.

> Besides, I wonder how reliably it could in principle work. Most of the
> JAR-hell problems we have encountered happened when there were more
> versions of the same library and some of them did work OK, some of them
> did not: for example, having added Fop support, we had to
> remove xmlgraphics-commons-2.3.jar which we used before without any
> problem, and had to switch back to xmlgraphics-commons-1.5.jar, which
> works OK with the Fop thing, whilst 2.3 does not[1]. I /do/ wonder
> whether Gradle or any other auto-dependency manager /could ever/automate
> properly and without problems /this/? Is there such kind of information
> anywhere for the manager to do such decisions reliably?

I am not 100% sure what you mean with "this". What you can do in Gradle
is to change the dependency resolution to exclude dependencies, to force
certain versions of dependencies, to fail the build if two version of
the same dependency are to be used (does not work for for example
groovy-all and groovy-core being used at the same time, since their name
is different)

Right now you manage dependencies manually I assume.

bye Jochen

Re: How to test and deploy without groovy-all?

[OCsite <oc...@ocs.cz>]

Well, thanks, I'll check the thing, though at the first look it rather seems to be a tool for a Gradle project owner who wants to move his projects into Xcode. Me, I'm precisely the opposite case — I've got Xcode projects which I possibly might want to move into Gradle.

If at all. I still can't see any advantage it would bring to me. It would automatically maintain dependencies, which is something I have never really needed (at least, not until groovy-all disappeared).

Besides, I wonder how reliably it could in principle work. Most of the JAR-hell problems we have encountered happened when there were more versions of the same library and some of them did work OK, some of them did not: for example, having added Fop support, we had to remove xmlgraphics-commons-2.3.jar which we used before without any problem, and had to switch back to xmlgraphics-commons-1.5.jar, which works OK with the Fop thing, whilst 2.3 does not[1]. I do wonder whether Gradle or any other auto-dependency manager could ever automate properly and without problems this? Is there such kind of information anywhere for the manager to do such decisions reliably?

Thanks and all the best,
OC

[1] Fop+2.3 caused things like “[java.lang.NoSuchMethodError] 'void org.apache.xmlgraphics.xmp.Metadata.mergeInto(org.apache.xmlgraphics.xmp.Metadata)'”.

> On 18 May 2020, at 21:42, sigzero <si...@gmail.com> wrote:
> 
> Gradle has a plugin for XCode anyway (never used it).
> 
> https://docs.gradle.org/current/userguide/xcode_plugin.html <https://docs.gradle.org/current/userguide/xcode_plugin.html>
> 
> --
> Bob
> 
> On Mon, May 18, 2020 at 3:38 PM Andy Duncan <andy@adjectivecolournoun.com <ma...@adjectivecolournoun.com>> wrote:
> Hi,
> 
> If you're bundling up Grooby applications for deployment on to servers,, I would echo what others have said and look into Gradle, along with the Shadow plugin [1]
> .  Having lived through the age of Ant and committing all of the binary dependencies in my projects to source control, having a build system that can bootstrap itself from nothing, manage all of the dependencies, _and_ package only the classes my project actually needs into a single jar still seems a bit like magic!
> 
> I've got a project [2] implementing AWS Lambda functions in Groovy that does substantially the same thing.  The functions are packaged up into a single file and deployed to AWS, but the same principle would apply for an executable jar.  There's an example of doing that in the Shadow documentation.
> 
> I don't know how Xcode handles it, but IDEA has very good support for Gradle.  It can import the project directly from the build.gradle file, and by default defers to Gradle to do the building, so the result is exactly the same as on a build server.
> 
> I hope this example helps, it really is so much easier than managing pre-installed dependencies on a build server.
> 
> Andy
> 
> [1] https://imperceptiblethoughts.com/shadow/ <https://imperceptiblethoughts.com/shadow/>
> [2] https://github.com/andyjduncan/serverless-dyndns <https://github.com/andyjduncan/serverless-dyndns>
> On Mon, May 18, 2020 at 7:16 PM OCsite <ocs@ocs.cz <ma...@ocs.cz>> wrote:
> Thanks! This is one absolutely excellent example of the Java approach to all problems :)
> 
> So as I “save bytes, CPU cycles etc.”, namely, so as I do not need to put one groovy-all for each Groovy version we need to support once to each of our servers — which JAR indeed would contain a few parts we won't ever use, at the first look it might seem to be wasting resources — ...
> 
> ... I am told to embed most of Groovy and other libraries into each application, having thus at the very least as many copies of each JAR on each server as there is separate applications (i.e., tens — definitely more than the number of Groovy versions we shall support concurrently) and also, unless we spend extra time creating some hardlink-based error-prone copy-only-what-changed scheme, also as many of them as there is stored older versions (hundreds). Not speaking of sending unnecessarily all the big stuff over the Net again and again and again installing each new app version (well, unless we put extra effort into some smart and error-and-problem-prone rsync-based installation scheme instead of our current extremely plain, easy and totally reliable scp). Add to the sum the effort needed to resolve the JAR-hell problems, which with this approach definitely will occur sooner or later (most probably sooner).
> 
> That all, of course, inevitably causes wasting resources, both human and machine, several orders of magnitude worse than the single, cheap and easy monolithic -all JAR ever could in the worst case imaginable.
> 
> Well indeed, that's precisely what Java teaches us. Nevertheless, I'd prefer just a slightest bit groovier approach :)
> OC
> 
>> On 18 May 2020, at 19:22, Tamás Cservenák <tamas@cservenak.net <ma...@cservenak.net>> wrote:
>> 
>> The lack of groovy-all is just on par with literally everything else "monolithic". You don't have spring-all, jetty-all, jackson-all, do you?
>> 
>> Nowadays developers use tools to maintain their dependencies (and transitive ones). Basically no need for a "monolithic" ALL that you for sure does not use 100% of it, just pick what you need: less bytes, less CPU cycles, less CO2 :)
>> 
>> OTOH, you DO have _distributions_, binary blobs that are not build artifacts (JARs so to say), but are laid in specific was that should make them easy to integrate into any "custom" scripted build environment (Jetty is even encouraging their layout for prod). It could serve for your case a "groovy all", no? (as it does have all)
>> 
>> Maybe what you need is to integrate Groovy Distribution into your custom build scripts (as I understand, you do have some custom build environment, not some "common build too"), and not "just JAR"s?
>> 
>> My 5 cents,
>> T
>> 
>> On Mon, May 18, 2020 at 6:47 PM OCsite <ocs@ocs.cz <ma...@ocs.cz>> wrote:
>> 
>>> On 18 May 2020, at 18:12, Mauro Molinari <mauromol@tiscali.it <ma...@tiscali.it>> wrote:
>>> 
>>> Il 18/05/20 17:48, OCsite ha scritto:
>>>> (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.
>>> 
>> I can't see how. Embedding all the dependencies is not reasonable: that way, your application gets monstrously big, and you either waste both the bandwidth installing and the space on all the servers, or you need to have a smart installation script, probably rsync-based. Still, even with this, you won't be able to easily keep old application versions (again, unless you make some smart tools based on hardlinks), etc.
>> 
>> Embedding makes sense where the thing does not change often. It very definitely makes an excellent sense to embed all the Groovy JARs into groovy-all, for there's a small number of separate Groovy versions to keep for a particular server. It would be completely absurd to embed groovy (and other libraries, which change even seldom than Groovy) into the application, whose new version is deployed pretty often.
>> 
>> Aside of that, there's sharing of resources: whilst we do need for application A to use Groovy 2.4.17 and B to use 3.0.3, there's also C, D and E, which all use 2.4.17, and F and G which both use 3.0.3. Aside of that, all the application share the WebObjects and WOnder libraries and a number of other JARs. Embedding them all into each the application would be a nonsense.
>>> 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".
>>> 
>> Actually JAR hell is not caused by manual handling of libraries, but by the completely stupid Java JAR design. Given the Sun engineers already had had an experience with an infinitely better OpenStep, which they had co-designed with NeXT and whose frameworks do not sport this problem, it is very sad; and precisely the same applies to the language itself: how on earth can somebody who already experienced the elegance and power of Objective C invent an übercrap like Java?!? Anyway, I am digressing again, sorry for that :(
>> 
>> Anyway, with groovy-all there's no JAR-hell at least far as Groovy itself is concerned. Removing groovy-all brings it, or at the very least its potential, to Groovy itself too :(
>>> 
>>>> 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
>>> 
>> Which is precisely what you do not want to do, at least, not if you use a big number of big libraries, as detailed above.
>>> plus the scripts needed to run your application under different operating systems. Substantially for free.
>>> 
>> To write and maintain my own launch script takes about one thousandth time and effort as compared with learning a whole new ecosystem which I do not need at all (well, perhaps now for the first time and for the one and one sole thing, i.e., creating my own groovy-all, which should be part of the distro).
>>> 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.-
>>> 
>> Creating so either hundreds of copies of all the libraries on each the server, which would be patently absurd (not speaking of the bandwidth copying them again and again and again completely unnecessarily upon each new app version), or having to prepare a pretty smart hardlink-based environment for keeping old copies, which would be possible, but again pretty difficult and time- and effort-consuming, with a danger of errors.
>>> 
>>>> 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.
>>> 
>> Perhaps so, but what would I get, as compared with launching groovyc directly? Gradle can't be used to keep track of project changes — IDE does that itself. And embedding all the libraries into the application, which I would get for free, is definitely what I do not want, as detailed above (besides, if I wanted it, I would simply mark those libraries as resources in Xcode and would get that for free too).
>>> 
>>>> 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.
>>> 
>> For one, I don't want it, but far as I can say, I need it; and I can't see any easy way to build it, unless I learn a whole new build system which I do not need for anything else.
>>> 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. ;-)
>>> 
>> If you embed all libraries and each your app is a multigigabyte monster, then of course. If I embedded complete groovy/lib to my application, I would not need groovy-all in my Extension folder either; but that would be one terribly wrong engineering, as detailed above.
>> 
>> Thanks,
>> OC
> 

Re: How to test and deploy without groovy-all?

[sigzero <si...@gmail.com>]

Gradle has a plugin for XCode anyway (never used it).

https://docs.gradle.org/current/userguide/xcode_plugin.html

--
Bob

On Mon, May 18, 2020 at 3:38 PM Andy Duncan <an...@adjectivecolournoun.com>
wrote:

> Hi,
>
> If you're bundling up Grooby applications for deployment on to servers,, I
> would echo what others have said and look into Gradle, along with the
> Shadow plugin [1]
> .  Having lived through the age of Ant and committing all of the binary
> dependencies in my projects to source control, having a build system that
> can bootstrap itself from nothing, manage all of the dependencies, _and_
> package only the classes my project actually needs into a single jar still
> seems a bit like magic!
>
> I've got a project [2] implementing AWS Lambda functions in Groovy that
> does substantially the same thing.  The functions are packaged up into a
> single file and deployed to AWS, but the same principle would apply for an
> executable jar.  There's an example of doing that in the Shadow
> documentation.
>
> I don't know how Xcode handles it, but IDEA has very good support for
> Gradle.  It can import the project directly from the build.gradle file, and
> by default defers to Gradle to do the building, so the result is exactly
> the same as on a build server.
>
> I hope this example helps, it really is so much easier than managing
> pre-installed dependencies on a build server.
>
> Andy
>
> [1] https://imperceptiblethoughts.com/shadow/
> [2] https://github.com/andyjduncan/serverless-dyndns
>
> On Mon, May 18, 2020 at 7:16 PM OCsite <oc...@ocs.cz> wrote:
>
>> Thanks! This is one absolutely excellent example of the Java approach to
>> all problems :)
>>
>> So as I “save bytes, CPU cycles etc.”, namely, so as I do not need to put
>> *one* groovy-all for each Groovy version we need to support *once* to
>> each of our servers — which JAR indeed would contain a few parts we won't
>> ever use, at the first look it might *seem* to be wasting resources — ...
>>
>> ... I am told to *embed* most of Groovy and other libraries into *each*
>> application, having thus at the very least as many copies of each JAR on
>> each server as there is separate applications (i.e., *tens* — definitely
>> more than the number of Groovy versions we shall support concurrently) and
>> *also*, unless we spend extra time creating some hardlink-based
>> error-prone copy-only-what-changed scheme, also as many of them as there is
>> stored older versions (*hundreds*). Not speaking of sending
>> unnecessarily all the big stuff over the Net again and again and again
>> installing each new app version (well, unless we put extra effort into some
>> smart and error-and-problem-prone rsync-based installation scheme instead
>> of our current extremely plain, easy and totally reliable scp). Add to the
>> sum the effort needed to resolve the JAR-hell problems, which with this
>> approach definitely *will* occur sooner or later (most probably sooner).
>>
>> That all, of course, inevitably causes wasting resources, both human and
>> machine, several orders of magnitude worse than the single, cheap and easy
>> monolithic -all JAR ever could in the worst case imaginable.
>>
>> Well indeed, that's precisely what Java teaches us. Nevertheless, I'd
>> prefer just a slightest bit groovier approach :)
>> OC
>>
>> On 18 May 2020, at 19:22, Tamás Cservenák <ta...@cservenak.net> wrote:
>>
>> The lack of groovy-all is just on par with literally everything else
>> "monolithic". You don't have spring-all, jetty-all, jackson-all, do you?
>>
>> Nowadays developers use tools to maintain their dependencies (and
>> transitive ones). Basically no need for a "monolithic" ALL that you for
>> sure does not use 100% of it, just pick what you need: less bytes, less CPU
>> cycles, less CO2 :)
>>
>> OTOH, you DO have _distributions_, binary blobs that are not build
>> artifacts (JARs so to say), but are laid in specific was that should make
>> them easy to integrate into any "custom" scripted build environment (Jetty
>> is even encouraging their layout for prod). It could serve for your case a
>> "groovy all", no? (as it does have all)
>>
>> Maybe what you need is to integrate Groovy Distribution into your custom
>> build scripts (as I understand, you do have some custom build environment,
>> not some "common build too"), and not "just JAR"s?
>>
>> My 5 cents,
>> T
>>
>> On Mon, May 18, 2020 at 6:47 PM OCsite <oc...@ocs.cz> wrote:
>>
>>>
>>> On 18 May 2020, at 18:12, Mauro Molinari <ma...@tiscali.it> wrote:
>>>
>>> Il 18/05/20 17:48, OCsite ha scritto:
>>>
>>> (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.
>>>
>>> I can't see how. Embedding all the dependencies is not reasonable: that
>>> way, your application gets monstrously big, and you either waste both the
>>> bandwidth installing and the space on all the servers, or you need to have
>>> a smart installation script, probably rsync-based. Still, even with this,
>>> you won't be able to easily keep old application versions (again, unless
>>> you make some smart tools based on hardlinks), etc.
>>>
>>> Embedding makes sense where the thing does not change often. It very
>>> definitely makes an excellent sense to embed all the Groovy JARs into
>>> groovy-all, for there's a small number of separate Groovy versions to keep
>>> for a particular server. It would be completely absurd to embed groovy (and
>>> other libraries, which change even seldom than Groovy) into the
>>> application, whose new version is deployed pretty often.
>>>
>>> Aside of that, there's sharing of resources: whilst we do need for
>>> application A to use Groovy 2.4.17 and B to use 3.0.3, there's also C, D
>>> and E, which all use 2.4.17, and F and G which both use 3.0.3. Aside of
>>> that, *all* the application share the WebObjects and WOnder libraries
>>> and a number of other JARs. Embedding them all into each the application
>>> would be a nonsense.
>>>
>>> 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".
>>>
>>> Actually JAR hell is not caused by manual handling of libraries, but by
>>> the completely stupid Java JAR design. Given the Sun engineers already had
>>> had an experience with an infinitely better OpenStep, which they had
>>> co-designed with NeXT and whose frameworks do not sport this problem, it is
>>> very sad; and precisely the same applies to the language itself: how on
>>> earth can somebody who already experienced the elegance and power of
>>> Objective C invent an übercrap like Java?!? Anyway, I am digressing again,
>>> sorry for that :(
>>>
>>> Anyway, with groovy-all there's no JAR-hell at least far as Groovy
>>> itself is concerned. Removing groovy-all brings it, or at the very least
>>> its potential, to Groovy itself too :(
>>>
>>>
>>> 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
>>>
>>> Which is precisely what you *do not* want to do, at least, not if you
>>> use a big number of big libraries, as detailed above.
>>>
>>> plus the scripts needed to run your application under different
>>> operating systems. Substantially for free.
>>>
>>> To write and maintain my own launch script takes about one thousandth
>>> time and effort as compared with learning a whole new ecosystem which I do
>>> not need at all (well, perhaps now for the first time and for the one and
>>> one sole thing, i.e., creating my own groovy-all, which *should* be
>>> part of the distro).
>>>
>>> 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.-
>>>
>>> Creating so either hundreds of copies of all the libraries on each the
>>> server, which would be patently absurd (not speaking of the bandwidth
>>> copying them again and again and again completely unnecessarily upon each
>>> new app version), or having to prepare a pretty smart hardlink-based
>>> environment for keeping old copies, which would be possible, but again
>>> pretty difficult and time- and effort-consuming, with a danger of errors.
>>>
>>>
>>> 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.
>>>
>>> Perhaps so, but what would I get, as compared with launching groovyc
>>> directly? Gradle can't be used to keep track of project changes — IDE does
>>> that itself. And embedding all the libraries into the application, which I
>>> would get for free, is definitely what I do not want, as detailed above
>>> (besides, *if* I wanted it, I would simply mark those libraries as
>>> resources in Xcode and would get that for free too).
>>>
>>>
>>> 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.
>>>
>>> For one, I don't want it, but far as I can say, I need it; and I can't
>>> see any easy way to build it, unless I learn a whole new build system which
>>> I do not need for anything else.
>>>
>>> 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. ;-)
>>>
>>> If you embed all libraries and each your app is a multigigabyte monster,
>>> then of course. If I embedded complete groovy/lib to my application, I
>>> would not need groovy-all in my Extension folder either; but that would be
>>> one terribly wrong engineering, as detailed above.
>>>
>>> Thanks,
>>> OC
>>>
>>
>>

Re: How to test and deploy without groovy-all?

[Andy Duncan <an...@adjectivecolournoun.com>]

Hi,

If you're bundling up Grooby applications for deployment on to servers,, I
would echo what others have said and look into Gradle, along with the
Shadow plugin [1]
.  Having lived through the age of Ant and committing all of the binary
dependencies in my projects to source control, having a build system that
can bootstrap itself from nothing, manage all of the dependencies, _and_
package only the classes my project actually needs into a single jar still
seems a bit like magic!

I've got a project [2] implementing AWS Lambda functions in Groovy that
does substantially the same thing.  The functions are packaged up into a
single file and deployed to AWS, but the same principle would apply for an
executable jar.  There's an example of doing that in the Shadow
documentation.

I don't know how Xcode handles it, but IDEA has very good support for
Gradle.  It can import the project directly from the build.gradle file, and
by default defers to Gradle to do the building, so the result is exactly
the same as on a build server.

I hope this example helps, it really is so much easier than managing
pre-installed dependencies on a build server.

Andy

[1] https://imperceptiblethoughts.com/shadow/
[2] https://github.com/andyjduncan/serverless-dyndns

On Mon, May 18, 2020 at 7:16 PM OCsite <oc...@ocs.cz> wrote:

> Thanks! This is one absolutely excellent example of the Java approach to
> all problems :)
>
> So as I “save bytes, CPU cycles etc.”, namely, so as I do not need to put
> *one* groovy-all for each Groovy version we need to support *once* to
> each of our servers — which JAR indeed would contain a few parts we won't
> ever use, at the first look it might *seem* to be wasting resources — ...
>
> ... I am told to *embed* most of Groovy and other libraries into *each*
> application, having thus at the very least as many copies of each JAR on
> each server as there is separate applications (i.e., *tens* — definitely
> more than the number of Groovy versions we shall support concurrently) and
> *also*, unless we spend extra time creating some hardlink-based
> error-prone copy-only-what-changed scheme, also as many of them as there is
> stored older versions (*hundreds*). Not speaking of sending unnecessarily
> all the big stuff over the Net again and again and again installing each
> new app version (well, unless we put extra effort into some smart and
> error-and-problem-prone rsync-based installation scheme instead of our
> current extremely plain, easy and totally reliable scp). Add to the sum the
> effort needed to resolve the JAR-hell problems, which with this approach
> definitely *will* occur sooner or later (most probably sooner).
>
> That all, of course, inevitably causes wasting resources, both human and
> machine, several orders of magnitude worse than the single, cheap and easy
> monolithic -all JAR ever could in the worst case imaginable.
>
> Well indeed, that's precisely what Java teaches us. Nevertheless, I'd
> prefer just a slightest bit groovier approach :)
> OC
>
> On 18 May 2020, at 19:22, Tamás Cservenák <ta...@cservenak.net> wrote:
>
> The lack of groovy-all is just on par with literally everything else
> "monolithic". You don't have spring-all, jetty-all, jackson-all, do you?
>
> Nowadays developers use tools to maintain their dependencies (and
> transitive ones). Basically no need for a "monolithic" ALL that you for
> sure does not use 100% of it, just pick what you need: less bytes, less CPU
> cycles, less CO2 :)
>
> OTOH, you DO have _distributions_, binary blobs that are not build
> artifacts (JARs so to say), but are laid in specific was that should make
> them easy to integrate into any "custom" scripted build environment (Jetty
> is even encouraging their layout for prod). It could serve for your case a
> "groovy all", no? (as it does have all)
>
> Maybe what you need is to integrate Groovy Distribution into your custom
> build scripts (as I understand, you do have some custom build environment,
> not some "common build too"), and not "just JAR"s?
>
> My 5 cents,
> T
>
> On Mon, May 18, 2020 at 6:47 PM OCsite <oc...@ocs.cz> wrote:
>
>>
>> On 18 May 2020, at 18:12, Mauro Molinari <ma...@tiscali.it> wrote:
>>
>> Il 18/05/20 17:48, OCsite ha scritto:
>>
>> (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.
>>
>> I can't see how. Embedding all the dependencies is not reasonable: that
>> way, your application gets monstrously big, and you either waste both the
>> bandwidth installing and the space on all the servers, or you need to have
>> a smart installation script, probably rsync-based. Still, even with this,
>> you won't be able to easily keep old application versions (again, unless
>> you make some smart tools based on hardlinks), etc.
>>
>> Embedding makes sense where the thing does not change often. It very
>> definitely makes an excellent sense to embed all the Groovy JARs into
>> groovy-all, for there's a small number of separate Groovy versions to keep
>> for a particular server. It would be completely absurd to embed groovy (and
>> other libraries, which change even seldom than Groovy) into the
>> application, whose new version is deployed pretty often.
>>
>> Aside of that, there's sharing of resources: whilst we do need for
>> application A to use Groovy 2.4.17 and B to use 3.0.3, there's also C, D
>> and E, which all use 2.4.17, and F and G which both use 3.0.3. Aside of
>> that, *all* the application share the WebObjects and WOnder libraries
>> and a number of other JARs. Embedding them all into each the application
>> would be a nonsense.
>>
>> 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".
>>
>> Actually JAR hell is not caused by manual handling of libraries, but by
>> the completely stupid Java JAR design. Given the Sun engineers already had
>> had an experience with an infinitely better OpenStep, which they had
>> co-designed with NeXT and whose frameworks do not sport this problem, it is
>> very sad; and precisely the same applies to the language itself: how on
>> earth can somebody who already experienced the elegance and power of
>> Objective C invent an übercrap like Java?!? Anyway, I am digressing again,
>> sorry for that :(
>>
>> Anyway, with groovy-all there's no JAR-hell at least far as Groovy itself
>> is concerned. Removing groovy-all brings it, or at the very least its
>> potential, to Groovy itself too :(
>>
>>
>> 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
>>
>> Which is precisely what you *do not* want to do, at least, not if you
>> use a big number of big libraries, as detailed above.
>>
>> plus the scripts needed to run your application under different operating
>> systems. Substantially for free.
>>
>> To write and maintain my own launch script takes about one thousandth
>> time and effort as compared with learning a whole new ecosystem which I do
>> not need at all (well, perhaps now for the first time and for the one and
>> one sole thing, i.e., creating my own groovy-all, which *should* be part
>> of the distro).
>>
>> 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.-
>>
>> Creating so either hundreds of copies of all the libraries on each the
>> server, which would be patently absurd (not speaking of the bandwidth
>> copying them again and again and again completely unnecessarily upon each
>> new app version), or having to prepare a pretty smart hardlink-based
>> environment for keeping old copies, which would be possible, but again
>> pretty difficult and time- and effort-consuming, with a danger of errors.
>>
>>
>> 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.
>>
>> Perhaps so, but what would I get, as compared with launching groovyc
>> directly? Gradle can't be used to keep track of project changes — IDE does
>> that itself. And embedding all the libraries into the application, which I
>> would get for free, is definitely what I do not want, as detailed above
>> (besides, *if* I wanted it, I would simply mark those libraries as
>> resources in Xcode and would get that for free too).
>>
>>
>> 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.
>>
>> For one, I don't want it, but far as I can say, I need it; and I can't
>> see any easy way to build it, unless I learn a whole new build system which
>> I do not need for anything else.
>>
>> 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. ;-)
>>
>> If you embed all libraries and each your app is a multigigabyte monster,
>> then of course. If I embedded complete groovy/lib to my application, I
>> would not need groovy-all in my Extension folder either; but that would be
>> one terribly wrong engineering, as detailed above.
>>
>> Thanks,
>> OC
>>
>
>

Re: How to test and deploy without groovy-all?

[Tamás Cservenák <ta...@cservenak.net>]

You misread or misinterpreted what i said: i never said "I am told to
*embed* most of Groovy and other libraries into *each application".*

I was talking about* builds.*

*T*

On Mon, May 18, 2020, 20:16 OCsite <oc...@ocs.cz> wrote:

> Thanks! This is one absolutely excellent example of the Java approach to
> all problems :)
>
> So as I “save bytes, CPU cycles etc.”, namely, so as I do not need to put
> *one* groovy-all for each Groovy version we need to support *once* to
> each of our servers — which JAR indeed would contain a few parts we won't
> ever use, at the first look it might *seem* to be wasting resources — ...
>
> ... I am told to *embed* most of Groovy and other libraries into *each*
> application, having thus at the very least as many copies of each JAR on
> each server as there is separate applications (i.e., *tens* — definitely
> more than the number of Groovy versions we shall support concurrently) and
> *also*, unless we spend extra time creating some hardlink-based
> error-prone copy-only-what-changed scheme, also as many of them as there is
> stored older versions (*hundreds*). Not speaking of sending unnecessarily
> all the big stuff over the Net again and again and again installing each
> new app version (well, unless we put extra effort into some smart and
> error-and-problem-prone rsync-based installation scheme instead of our
> current extremely plain, easy and totally reliable scp). Add to the sum the
> effort needed to resolve the JAR-hell problems, which with this approach
> definitely *will* occur sooner or later (most probably sooner).
>
> That all, of course, inevitably causes wasting resources, both human and
> machine, several orders of magnitude worse than the single, cheap and easy
> monolithic -all JAR ever could in the worst case imaginable.
>
> Well indeed, that's precisely what Java teaches us. Nevertheless, I'd
> prefer just a slightest bit groovier approach :)
> OC
>
> On 18 May 2020, at 19:22, Tamás Cservenák <ta...@cservenak.net> wrote:
>
> The lack of groovy-all is just on par with literally everything else
> "monolithic". You don't have spring-all, jetty-all, jackson-all, do you?
>
> Nowadays developers use tools to maintain their dependencies (and
> transitive ones). Basically no need for a "monolithic" ALL that you for
> sure does not use 100% of it, just pick what you need: less bytes, less CPU
> cycles, less CO2 :)
>
> OTOH, you DO have _distributions_, binary blobs that are not build
> artifacts (JARs so to say), but are laid in specific was that should make
> them easy to integrate into any "custom" scripted build environment (Jetty
> is even encouraging their layout for prod). It could serve for your case a
> "groovy all", no? (as it does have all)
>
> Maybe what you need is to integrate Groovy Distribution into your custom
> build scripts (as I understand, you do have some custom build environment,
> not some "common build too"), and not "just JAR"s?
>
> My 5 cents,
> T
>
> On Mon, May 18, 2020 at 6:47 PM OCsite <oc...@ocs.cz> wrote:
>
>>
>> On 18 May 2020, at 18:12, Mauro Molinari <ma...@tiscali.it> wrote:
>>
>> Il 18/05/20 17:48, OCsite ha scritto:
>>
>> (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.
>>
>> I can't see how. Embedding all the dependencies is not reasonable: that
>> way, your application gets monstrously big, and you either waste both the
>> bandwidth installing and the space on all the servers, or you need to have
>> a smart installation script, probably rsync-based. Still, even with this,
>> you won't be able to easily keep old application versions (again, unless
>> you make some smart tools based on hardlinks), etc.
>>
>> Embedding makes sense where the thing does not change often. It very
>> definitely makes an excellent sense to embed all the Groovy JARs into
>> groovy-all, for there's a small number of separate Groovy versions to keep
>> for a particular server. It would be completely absurd to embed groovy (and
>> other libraries, which change even seldom than Groovy) into the
>> application, whose new version is deployed pretty often.
>>
>> Aside of that, there's sharing of resources: whilst we do need for
>> application A to use Groovy 2.4.17 and B to use 3.0.3, there's also C, D
>> and E, which all use 2.4.17, and F and G which both use 3.0.3. Aside of
>> that, *all* the application share the WebObjects and WOnder libraries
>> and a number of other JARs. Embedding them all into each the application
>> would be a nonsense.
>>
>> 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".
>>
>> Actually JAR hell is not caused by manual handling of libraries, but by
>> the completely stupid Java JAR design. Given the Sun engineers already had
>> had an experience with an infinitely better OpenStep, which they had
>> co-designed with NeXT and whose frameworks do not sport this problem, it is
>> very sad; and precisely the same applies to the language itself: how on
>> earth can somebody who already experienced the elegance and power of
>> Objective C invent an übercrap like Java?!? Anyway, I am digressing again,
>> sorry for that :(
>>
>> Anyway, with groovy-all there's no JAR-hell at least far as Groovy itself
>> is concerned. Removing groovy-all brings it, or at the very least its
>> potential, to Groovy itself too :(
>>
>>
>> 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
>>
>> Which is precisely what you *do not* want to do, at least, not if you
>> use a big number of big libraries, as detailed above.
>>
>> plus the scripts needed to run your application under different operating
>> systems. Substantially for free.
>>
>> To write and maintain my own launch script takes about one thousandth
>> time and effort as compared with learning a whole new ecosystem which I do
>> not need at all (well, perhaps now for the first time and for the one and
>> one sole thing, i.e., creating my own groovy-all, which *should* be part
>> of the distro).
>>
>> 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.-
>>
>> Creating so either hundreds of copies of all the libraries on each the
>> server, which would be patently absurd (not speaking of the bandwidth
>> copying them again and again and again completely unnecessarily upon each
>> new app version), or having to prepare a pretty smart hardlink-based
>> environment for keeping old copies, which would be possible, but again
>> pretty difficult and time- and effort-consuming, with a danger of errors.
>>
>>
>> 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.
>>
>> Perhaps so, but what would I get, as compared with launching groovyc
>> directly? Gradle can't be used to keep track of project changes — IDE does
>> that itself. And embedding all the libraries into the application, which I
>> would get for free, is definitely what I do not want, as detailed above
>> (besides, *if* I wanted it, I would simply mark those libraries as
>> resources in Xcode and would get that for free too).
>>
>>
>> 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.
>>
>> For one, I don't want it, but far as I can say, I need it; and I can't
>> see any easy way to build it, unless I learn a whole new build system which
>> I do not need for anything else.
>>
>> 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. ;-)
>>
>> If you embed all libraries and each your app is a multigigabyte monster,
>> then of course. If I embedded complete groovy/lib to my application, I
>> would not need groovy-all in my Extension folder either; but that would be
>> one terribly wrong engineering, as detailed above.
>>
>> Thanks,
>> OC
>>
>
>

Re: How to test and deploy without groovy-all?

[OCsite <oc...@ocs.cz>]

Thanks! This is one absolutely excellent example of the Java approach to all problems :)

So as I “save bytes, CPU cycles etc.”, namely, so as I do not need to put one groovy-all for each Groovy version we need to support once to each of our servers — which JAR indeed would contain a few parts we won't ever use, at the first look it might seem to be wasting resources — ...

... I am told to embed most of Groovy and other libraries into each application, having thus at the very least as many copies of each JAR on each server as there is separate applications (i.e., tens — definitely more than the number of Groovy versions we shall support concurrently) and also, unless we spend extra time creating some hardlink-based error-prone copy-only-what-changed scheme, also as many of them as there is stored older versions (hundreds). Not speaking of sending unnecessarily all the big stuff over the Net again and again and again installing each new app version (well, unless we put extra effort into some smart and error-and-problem-prone rsync-based installation scheme instead of our current extremely plain, easy and totally reliable scp). Add to the sum the effort needed to resolve the JAR-hell problems, which with this approach definitely will occur sooner or later (most probably sooner).

That all, of course, inevitably causes wasting resources, both human and machine, several orders of magnitude worse than the single, cheap and easy monolithic -all JAR ever could in the worst case imaginable.

Well indeed, that's precisely what Java teaches us. Nevertheless, I'd prefer just a slightest bit groovier approach :)
OC

> On 18 May 2020, at 19:22, Tamás Cservenák <ta...@cservenak.net> wrote:
> 
> The lack of groovy-all is just on par with literally everything else "monolithic". You don't have spring-all, jetty-all, jackson-all, do you?
> 
> Nowadays developers use tools to maintain their dependencies (and transitive ones). Basically no need for a "monolithic" ALL that you for sure does not use 100% of it, just pick what you need: less bytes, less CPU cycles, less CO2 :)
> 
> OTOH, you DO have _distributions_, binary blobs that are not build artifacts (JARs so to say), but are laid in specific was that should make them easy to integrate into any "custom" scripted build environment (Jetty is even encouraging their layout for prod). It could serve for your case a "groovy all", no? (as it does have all)
> 
> Maybe what you need is to integrate Groovy Distribution into your custom build scripts (as I understand, you do have some custom build environment, not some "common build too"), and not "just JAR"s?
> 
> My 5 cents,
> T
> 
> On Mon, May 18, 2020 at 6:47 PM OCsite <ocs@ocs.cz <ma...@ocs.cz>> wrote:
> 
>> On 18 May 2020, at 18:12, Mauro Molinari <mauromol@tiscali.it <ma...@tiscali.it>> wrote:
>> 
>> Il 18/05/20 17:48, OCsite ha scritto:
>>> (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.
>> 
> I can't see how. Embedding all the dependencies is not reasonable: that way, your application gets monstrously big, and you either waste both the bandwidth installing and the space on all the servers, or you need to have a smart installation script, probably rsync-based. Still, even with this, you won't be able to easily keep old application versions (again, unless you make some smart tools based on hardlinks), etc.
> 
> Embedding makes sense where the thing does not change often. It very definitely makes an excellent sense to embed all the Groovy JARs into groovy-all, for there's a small number of separate Groovy versions to keep for a particular server. It would be completely absurd to embed groovy (and other libraries, which change even seldom than Groovy) into the application, whose new version is deployed pretty often.
> 
> Aside of that, there's sharing of resources: whilst we do need for application A to use Groovy 2.4.17 and B to use 3.0.3, there's also C, D and E, which all use 2.4.17, and F and G which both use 3.0.3. Aside of that, all the application share the WebObjects and WOnder libraries and a number of other JARs. Embedding them all into each the application would be a nonsense.
>> 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".
>> 
> Actually JAR hell is not caused by manual handling of libraries, but by the completely stupid Java JAR design. Given the Sun engineers already had had an experience with an infinitely better OpenStep, which they had co-designed with NeXT and whose frameworks do not sport this problem, it is very sad; and precisely the same applies to the language itself: how on earth can somebody who already experienced the elegance and power of Objective C invent an übercrap like Java?!? Anyway, I am digressing again, sorry for that :(
> 
> Anyway, with groovy-all there's no JAR-hell at least far as Groovy itself is concerned. Removing groovy-all brings it, or at the very least its potential, to Groovy itself too :(
>> 
>>> 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
>> 
> Which is precisely what you do not want to do, at least, not if you use a big number of big libraries, as detailed above.
>> plus the scripts needed to run your application under different operating systems. Substantially for free.
>> 
> To write and maintain my own launch script takes about one thousandth time and effort as compared with learning a whole new ecosystem which I do not need at all (well, perhaps now for the first time and for the one and one sole thing, i.e., creating my own groovy-all, which should be part of the distro).
>> 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.-
>> 
> Creating so either hundreds of copies of all the libraries on each the server, which would be patently absurd (not speaking of the bandwidth copying them again and again and again completely unnecessarily upon each new app version), or having to prepare a pretty smart hardlink-based environment for keeping old copies, which would be possible, but again pretty difficult and time- and effort-consuming, with a danger of errors.
>> 
>>> 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.
>> 
> Perhaps so, but what would I get, as compared with launching groovyc directly? Gradle can't be used to keep track of project changes — IDE does that itself. And embedding all the libraries into the application, which I would get for free, is definitely what I do not want, as detailed above (besides, if I wanted it, I would simply mark those libraries as resources in Xcode and would get that for free too).
>> 
>>> 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.
>> 
> For one, I don't want it, but far as I can say, I need it; and I can't see any easy way to build it, unless I learn a whole new build system which I do not need for anything else.
>> 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. ;-)
>> 
> If you embed all libraries and each your app is a multigigabyte monster, then of course. If I embedded complete groovy/lib to my application, I would not need groovy-all in my Extension folder either; but that would be one terribly wrong engineering, as detailed above.
> 
> Thanks,
> OC

Re: How to test and deploy without groovy-all?

[Tamás Cservenák <ta...@cservenak.net>]

The lack of groovy-all is just on par with literally everything else
"monolithic". You don't have spring-all, jetty-all, jackson-all, do you?

Nowadays developers use tools to maintain their dependencies (and
transitive ones). Basically no need for a "monolithic" ALL that you for
sure does not use 100% of it, just pick what you need: less bytes, less CPU
cycles, less CO2 :)

OTOH, you DO have _distributions_, binary blobs that are not build
artifacts (JARs so to say), but are laid in specific was that should make
them easy to integrate into any "custom" scripted build environment (Jetty
is even encouraging their layout for prod). It could serve for your case a
"groovy all", no? (as it does have all)

Maybe what you need is to integrate Groovy Distribution into your custom
build scripts (as I understand, you do have some custom build environment,
not some "common build too"), and not "just JAR"s?

My 5 cents,
T

On Mon, May 18, 2020 at 6:47 PM OCsite <oc...@ocs.cz> wrote:

>
> On 18 May 2020, at 18:12, Mauro Molinari <ma...@tiscali.it> wrote:
>
> Il 18/05/20 17:48, OCsite ha scritto:
>
> (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.
>
> I can't see how. Embedding all the dependencies is not reasonable: that
> way, your application gets monstrously big, and you either waste both the
> bandwidth installing and the space on all the servers, or you need to have
> a smart installation script, probably rsync-based. Still, even with this,
> you won't be able to easily keep old application versions (again, unless
> you make some smart tools based on hardlinks), etc.
>
> Embedding makes sense where the thing does not change often. It very
> definitely makes an excellent sense to embed all the Groovy JARs into
> groovy-all, for there's a small number of separate Groovy versions to keep
> for a particular server. It would be completely absurd to embed groovy (and
> other libraries, which change even seldom than Groovy) into the
> application, whose new version is deployed pretty often.
>
> Aside of that, there's sharing of resources: whilst we do need for
> application A to use Groovy 2.4.17 and B to use 3.0.3, there's also C, D
> and E, which all use 2.4.17, and F and G which both use 3.0.3. Aside of
> that, *all* the application share the WebObjects and WOnder libraries and
> a number of other JARs. Embedding them all into each the application would
> be a nonsense.
>
> 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".
>
> Actually JAR hell is not caused by manual handling of libraries, but by
> the completely stupid Java JAR design. Given the Sun engineers already had
> had an experience with an infinitely better OpenStep, which they had
> co-designed with NeXT and whose frameworks do not sport this problem, it is
> very sad; and precisely the same applies to the language itself: how on
> earth can somebody who already experienced the elegance and power of
> Objective C invent an übercrap like Java?!? Anyway, I am digressing again,
> sorry for that :(
>
> Anyway, with groovy-all there's no JAR-hell at least far as Groovy itself
> is concerned. Removing groovy-all brings it, or at the very least its
> potential, to Groovy itself too :(
>
> 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
>
> Which is precisely what you *do not* want to do, at least, not if you use
> a big number of big libraries, as detailed above.
>
> plus the scripts needed to run your application under different operating
> systems. Substantially for free.
>
> To write and maintain my own launch script takes about one thousandth time
> and effort as compared with learning a whole new ecosystem which I do not
> need at all (well, perhaps now for the first time and for the one and one
> sole thing, i.e., creating my own groovy-all, which *should* be part of
> the distro).
>
> 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.-
>
> Creating so either hundreds of copies of all the libraries on each the
> server, which would be patently absurd (not speaking of the bandwidth
> copying them again and again and again completely unnecessarily upon each
> new app version), or having to prepare a pretty smart hardlink-based
> environment for keeping old copies, which would be possible, but again
> pretty difficult and time- and effort-consuming, with a danger of errors.
>
> 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.
>
> Perhaps so, but what would I get, as compared with launching groovyc
> directly? Gradle can't be used to keep track of project changes — IDE does
> that itself. And embedding all the libraries into the application, which I
> would get for free, is definitely what I do not want, as detailed above
> (besides, *if* I wanted it, I would simply mark those libraries as
> resources in Xcode and would get that for free too).
>
> 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.
>
> For one, I don't want it, but far as I can say, I need it; and I can't see
> any easy way to build it, unless I learn a whole new build system which I
> do not need for anything else.
>
> 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. ;-)
>
> If you embed all libraries and each your app is a multigigabyte monster,
> then of course. If I embedded complete groovy/lib to my application, I
> would not need groovy-all in my Extension folder either; but that would be
> one terribly wrong engineering, as detailed above.
>
> Thanks,
> OC
>

Re: How to test and deploy without groovy-all?

[OCsite <oc...@ocs.cz>]

> On 18 May 2020, at 18:12, Mauro Molinari <ma...@tiscali.it> wrote:
> 
> Il 18/05/20 17:48, OCsite ha scritto:
>> (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.
> 
I can't see how. Embedding all the dependencies is not reasonable: that way, your application gets monstrously big, and you either waste both the bandwidth installing and the space on all the servers, or you need to have a smart installation script, probably rsync-based. Still, even with this, you won't be able to easily keep old application versions (again, unless you make some smart tools based on hardlinks), etc.

Embedding makes sense where the thing does not change often. It very definitely makes an excellent sense to embed all the Groovy JARs into groovy-all, for there's a small number of separate Groovy versions to keep for a particular server. It would be completely absurd to embed groovy (and other libraries, which change even seldom than Groovy) into the application, whose new version is deployed pretty often.

Aside of that, there's sharing of resources: whilst we do need for application A to use Groovy 2.4.17 and B to use 3.0.3, there's also C, D and E, which all use 2.4.17, and F and G which both use 3.0.3. Aside of that, all the application share the WebObjects and WOnder libraries and a number of other JARs. Embedding them all into each the application would be a nonsense.
> 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".
> 
Actually JAR hell is not caused by manual handling of libraries, but by the completely stupid Java JAR design. Given the Sun engineers already had had an experience with an infinitely better OpenStep, which they had co-designed with NeXT and whose frameworks do not sport this problem, it is very sad; and precisely the same applies to the language itself: how on earth can somebody who already experienced the elegance and power of Objective C invent an übercrap like Java?!? Anyway, I am digressing again, sorry for that :(

Anyway, with groovy-all there's no JAR-hell at least far as Groovy itself is concerned. Removing groovy-all brings it, or at the very least its potential, to Groovy itself too :(
>> 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
> 
Which is precisely what you do not want to do, at least, not if you use a big number of big libraries, as detailed above.
> plus the scripts needed to run your application under different operating systems. Substantially for free.
> 
To write and maintain my own launch script takes about one thousandth time and effort as compared with learning a whole new ecosystem which I do not need at all (well, perhaps now for the first time and for the one and one sole thing, i.e., creating my own groovy-all, which should be part of the distro).
> 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.-
> 
Creating so either hundreds of copies of all the libraries on each the server, which would be patently absurd (not speaking of the bandwidth copying them again and again and again completely unnecessarily upon each new app version), or having to prepare a pretty smart hardlink-based environment for keeping old copies, which would be possible, but again pretty difficult and time- and effort-consuming, with a danger of errors.
>> 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.
> 
Perhaps so, but what would I get, as compared with launching groovyc directly? Gradle can't be used to keep track of project changes — IDE does that itself. And embedding all the libraries into the application, which I would get for free, is definitely what I do not want, as detailed above (besides, if I wanted it, I would simply mark those libraries as resources in Xcode and would get that for free too).
>> 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.
> 
For one, I don't want it, but far as I can say, I need it; and I can't see any easy way to build it, unless I learn a whole new build system which I do not need for anything else.
> 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. ;-)
> 
If you embed all libraries and each your app is a multigigabyte monster, then of course. If I embedded complete groovy/lib to my application, I would not need groovy-all in my Extension folder either; but that would be one terribly wrong engineering, as detailed above.

Thanks,
OC

Re: How to test and deploy without groovy-all?

[Mauro Molinari <ma...@tiscali.it>]

Il 18/05/20 17:48, OCsite ha scritto:  

> (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  

Re: How to test and deploy without groovy-all?

[OCsite <oc...@ocs.cz>]

Thanks again, but...

> On 18 May 2020, at 17:07, Mauro Molinari <ma...@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

Re: How to test and deploy without groovy-all?

[Mauro Molinari <ma...@tiscali.it>]

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. 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.

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. 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!  

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.  

Mauro

Re: How to test and deploy without groovy-all? (was: More Groovy 3 woes)

[OCsite <oc...@ocs.cz>]

Again thanks, but this seems sort of at the dangerous side. Correct me please if I am wrong, but I understand JVM loads the classes on-demand when they are needed, not all at the launch time.

That would mean that a well- but not completely-tested application (and we all know it is just not possible to test completely!) still could crash when a user tries something different from all the testers (and we all know users do that!) due to some JAR not available at the deployment site.

Or am I wrong and there is some magic which would prevent this scenario?

Thanks!
OC

> On 18 May 2020, at 16:16, Keith Suderman <su...@anc.org> wrote:
> 
> I can only comment on our experience:
> 
> - For most of our projects simply replacing groovy-all with the core groovy module has worked fine as most of our projects don't (didn't) make use of the classes that are not present in the core groovy module.
> - For the projects that did need missing classes we simply add the needed groovy-* modules.  We've never had to add more that two or three other modules and it is almost always just groovy-json and/or groovy-xml
> - If you _really_ need the entire contents of groovy/lib on the classpath you can try building your own groovy-all jar file.  There are instructions for doing this with 2.5.x [1], but it should be possible to do the same for 3.x
> 
> I am not sure of your use case, but we've never even come close to needing everything from groovy/lib on the classpath.
> 
> I hope that gives you some ideas.
> - Keith
> 
> 1. https://github.com/gradle/gradle-groovy-all <https://github.com/gradle/gradle-groovy-all>
> 
>> On May 18, 2020, at 8:43 AM, OCsite <ocs@ocs.cz <ma...@ocs.cz>> wrote:
>> 
>> Hi there,
>> 
>>> On 16 May 2020, at 14:17, OCsite <ocs@ocs.cz <ma...@ocs.cz>> wrote:
>>> First, can you (or anyone) please suggest what to do with my classpath now when groovy-all's gone?
>> 
>> I still can't see a reasonable solution for that :( All the documentation I've found so far is
>> 
>>> http://groovy-lang.org/releasenotes/groovy-2.5.html <http://groovy-lang.org/releasenotes/groovy-2.5.html>
>> which alas does not help at all. Especially I can't see how “simply bumping the version number” could “be sufficient”?
>> 
>> Up to 2.4, indeed simply changing the version number did suffice: my build scripts did select the proper compiler at .../groovy{VERSION}/bin/groovyc, and to the run script was similarly added .../Extensions/groovy-all-{VERSION}-indy.jar to the classpath. Worked like a charm.
>> 
>> The build still works all right, but how on earth should I run the application? Without groovy on classpath it just reports that it can't load the app.Application class (which is quite understandable, for the class implementation uses Groovy, and java does not have an access to its JARs at all, so loading the class fails).
>> 
>> So far the only way I have found to test was to add a complete contents of groovy/lib to the classpath. That's darn inconvenient for testing at my side, and would get extremely inconvenient at the deployment site.
>> 
>> What's the proper way to launch an application written in Groovy from 2.5 up on a deployment site (where there's of course no Groovy installation at all)? Up to 2.4, simple
>> 
>> java -classpath '...groovy-all-{VERSION}-indy.jar...' app.Application
>> 
>> did suffice, all what was needed was to place the one groovy-all JAR for each version of groovy we build with[1] to the Extensions folder, and it worked perfectly.
>> 
>> What should I do now instead? I can see I could put all the JARs of all the groovys we use in there and add them all explicitly to the classpath; but it will be darn ugly; adding a new groovy release would get rather difficult, not speaking of switching betwixt different groovy versions for different applications.
>> 
>> Thanks a lot,
>> OC
>> 
>> [1] for some of our applications we use a fixed groovy version against which the app was extensively tested, lest we bump into some breaking change in a newer groovy. Thus, we build and run different applications with different groovy versions. Up to 2.4, no problem at all, with all the groovy-alls in the Extensions folder and the proper one in classpath of each run script worked like a charm.
> 

Re: How to test and deploy without groovy-all? (was: More Groovy 3 woes)

[Keith Suderman <su...@anc.org>]

I can only comment on our experience:

- For most of our projects simply replacing groovy-all with the core groovy module has worked fine as most of our projects don't (didn't) make use of the classes that are not present in the core groovy module.
- For the projects that did need missing classes we simply add the needed groovy-* modules.  We've never had to add more that two or three other modules and it is almost always just groovy-json and/or groovy-xml
- If you _really_ need the entire contents of groovy/lib on the classpath you can try building your own groovy-all jar file.  There are instructions for doing this with 2.5.x [1], but it should be possible to do the same for 3.x

I am not sure of your use case, but we've never even come close to needing everything from groovy/lib on the classpath.

I hope that gives you some ideas.
- Keith

1. https://github.com/gradle/gradle-groovy-all

> On May 18, 2020, at 8:43 AM, OCsite <oc...@ocs.cz> wrote:
> 
> Hi there,
> 
>> On 16 May 2020, at 14:17, OCsite <ocs@ocs.cz <ma...@ocs.cz>> wrote:
>> First, can you (or anyone) please suggest what to do with my classpath now when groovy-all's gone?
> 
> I still can't see a reasonable solution for that :( All the documentation I've found so far is
> 
>> http://groovy-lang.org/releasenotes/groovy-2.5.html <http://groovy-lang.org/releasenotes/groovy-2.5.html>
> which alas does not help at all. Especially I can't see how “simply bumping the version number” could “be sufficient”?
> 
> Up to 2.4, indeed simply changing the version number did suffice: my build scripts did select the proper compiler at .../groovy{VERSION}/bin/groovyc, and to the run script was similarly added .../Extensions/groovy-all-{VERSION}-indy.jar to the classpath. Worked like a charm.
> 
> The build still works all right, but how on earth should I run the application? Without groovy on classpath it just reports that it can't load the app.Application class (which is quite understandable, for the class implementation uses Groovy, and java does not have an access to its JARs at all, so loading the class fails).
> 
> So far the only way I have found to test was to add a complete contents of groovy/lib to the classpath. That's darn inconvenient for testing at my side, and would get extremely inconvenient at the deployment site.
> 
> What's the proper way to launch an application written in Groovy from 2.5 up on a deployment site (where there's of course no Groovy installation at all)? Up to 2.4, simple
> 
> java -classpath '...groovy-all-{VERSION}-indy.jar...' app.Application
> 
> did suffice, all what was needed was to place the one groovy-all JAR for each version of groovy we build with[1] to the Extensions folder, and it worked perfectly.
> 
> What should I do now instead? I can see I could put all the JARs of all the groovys we use in there and add them all explicitly to the classpath; but it will be darn ugly; adding a new groovy release would get rather difficult, not speaking of switching betwixt different groovy versions for different applications.
> 
> Thanks a lot,
> OC
> 
> [1] for some of our applications we use a fixed groovy version against which the app was extensively tested, lest we bump into some breaking change in a newer groovy. Thus, we build and run different applications with different groovy versions. Up to 2.4, no problem at all, with all the groovy-alls in the Extensions folder and the proper one in classpath of each run script worked like a charm.

Re: How to test and deploy without groovy-all? (was: More Groovy 3 woes)

[Erik Husby <mh...@broadinstitute.org>]

I use the Maven-shade-plugin that produces a single jar that contains all
the dependencies of the project.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>2.4.3</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
        </execution>
    </executions>
</plugin>

I can then use a script that contains the Java command like so. (as part of
the build, the script is filtered to get the project variables inserted.)

java -cp `dirname $0`/${project.build.finalName}.jar ${main.class} $@


On Mon, May 18, 2020 at 9:59 AM Nelson, Erick <Er...@hdsupply.com>
wrote:

> I use Maven to do my build-test-deploy, and I am currently researching
> converting to Gradle.
>
> Here is my maven dependency…
>
>
>
>     <dependency>
>
>       <groupId>org.codehaus.groovy</groupId>
>
>       <artifactId>groovy-all</artifactId>
>
>       <version>2.5.9</version>
>
>       <scope>provided</scope>
>
>       <type>pom</type>
>
>     </dependency>
>
>
>
> Now, while I do admit I have not tried a build yet with Groovy 3, the
> Maven dependency for groovy-all does exist…
>
>
>
>
>
>
>
> *From: *OCsite <oc...@ocs.cz>
> *Reply-To: *"users@groovy.apache.org" <us...@groovy.apache.org>
> *Date: *Monday, May 18, 2020 at 5:43 AM
> *To: *"users@groovy.apache.org" <us...@groovy.apache.org>
> *Subject: *How to test and deploy without groovy-all? (was: More Groovy 3
> woes)
>
>
>
> Hi there,
>
>
>
> On 16 May 2020, at 14:17, OCsite <oc...@ocs.cz> wrote:
>
> First, can you (or anyone) please suggest what to do with my classpath now
> when groovy-all's gone?
>
>
>
> I still can't see a reasonable solution for that :( All the documentation
> I've found so far is
>
>
>
> http://groovy-lang.org/releasenotes/groovy-2.5.html
>
>
>
> which alas does not help at all. Especially I can't see how “simply
> bumping the version number” could “be sufficient”?
>
>
>
> Up to 2.4, indeed simply changing the version number did suffice: my build
> scripts did select the proper compiler at
> *.../groovy{VERSION}/bin/groovyc*, and to the run script was similarly
> added *.../Extensions/groovy-all-{VERSION}-indy.jar* to the classpath.
> Worked like a charm.
>
>
>
> The build still works all right, but how on earth should I run the
> application? Without groovy on classpath it just reports that it can't load
> the *app.Application* class (which is quite understandable, for the class
> implementation uses Groovy, and java does not have an access to its JARs at
> all, so loading the class fails).
>
>
>
> So far the only way I have found to test was to add a complete contents of
> groovy/lib to the classpath. That's darn inconvenient for testing at my
> side, and would get *extremely* inconvenient at the deployment site.
>
>
>
> What's the proper way to launch an application written in Groovy from 2.5
> up on a deployment site (where there's of course no Groovy installation at
> all)? Up to 2.4, simple
>
>
>
> *java -classpath '...groovy-all-{VERSION}-indy.jar...' app.Application*
>
>
>
> did suffice, all what was needed was to place the one groovy-all JAR for
> each version of groovy we build with[1] to the Extensions folder, and it
> worked perfectly.
>
>
>
> What should I do now instead? I can see I *could* put all the JARs of all
> the groovys we use in there and add them all explicitly to the classpath;
> but it will be darn ugly; adding a new groovy release would get rather
> difficult, not speaking of switching betwixt different groovy versions for
> different applications.
>
>
>
> Thanks a lot,
>
> OC
>
>
>
> [1] for some of our applications we use a fixed groovy version against
> which the app was extensively tested, lest we bump into some breaking
> change in a newer groovy. Thus, we build and run different applications
> with different groovy versions. Up to 2.4, no problem at all, with all the
> groovy-alls in the Extensions folder and the proper one in classpath of
> each run script worked like a charm.
>


-- 
---

Erik Husby
Principal Development Operations Engineer
Broad Institute
Rm. 2195, 320 Charles St, Cambridge, MA 02141-2023
mobile: 781.354.6669, office: 617.714.8443
email: mhusby@broadinstitute.org

Re: How to test and deploy without groovy-all? (was: More Groovy 3 woes)

[OCsite <oc...@ocs.cz>]

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.

Of course if need be I could learn and use one of them, but it seems sort of at the superfluous side to learn a whole new ecosystem, completely unneeded otherwise, just to create the one sole JAR needed for deployment. Aside of that it seems sort of at the absurd side that each Groovy user does this by himself again, again and again, for each new version? Wouldn't it be infinitely better, more convenient and reasonable to do this task only once at the build site and include the -all JAR to the binary distro, precisely the same way it used to be before 2.5?

Incidentally meantime I have searched the maillist too, and found Cédric's recommendation to do without the thing:

> On 24 Oct 2019, at 9:51, Cédric Champeau <ce...@gmail.com> wrote:
> Easiest is _not_ to use groovy-all, which is really a convenience to get _all_ Groovy modules. It's extremely unlikely you need them all, as your message indicates (you don't need testng, but I'm pretty sure you don't need groovy-swing either).

That, of course, would be a best approach, but I can't see how to ensure that?

Actually when I have read the 2.5 release notes for the first time, I presumed that's precisely what happened: that groovy-all is not needed anymore, for the excellent Groovy team, ever on search for improvements, invented some smart magical way to import all the needed JARs automatically without a need to install them at the deployment site manually and placing them to the classpath (presumably, loading them from the Net and caching somehow in case upon the next launch the site happens to be offline, yadda yadda yadda). That would be a help indeed. Alas, when I launched my first 3-based build, the “cannot load app.Application” result proved it is not so :(

Thanks again and do please forgive if this sounds a bit rant-like, but this really seems a bit absurd. I could understand if for some reason the Groovy team decided to distribute just the sources and whomever who wants to use Groovy would have to build and pack himself, that would make sense; but given there actually is a binary distro, I can't see why it lacks the -all JAR far as it still is needed for deployment, and leaves it on each user to find a way to build the thing himself :/

All the best,
OC

> On 18 May 2020, at 15:59, Nelson, Erick <Er...@hdsupply.com> wrote:
> 
> I use Maven to do my build-test-deploy, and I am currently researching converting to Gradle.
> Here is my maven dependency…
>  
>     <dependency>
>       <groupId>org.codehaus.groovy</groupId>
>       <artifactId>groovy-all</artifactId>
>       <version>2.5.9</version>
>       <scope>provided</scope>
>       <type>pom</type>
>     </dependency>
>  
> Now, while I do admit I have not tried a build yet with Groovy 3, the Maven dependency for groovy-all does exist…
>  
> <image001.png>
>  
>  
> From: OCsite <ocs@ocs.cz <ma...@ocs.cz>>
> Reply-To: "users@groovy.apache.org <ma...@groovy.apache.org>" <users@groovy.apache.org <ma...@groovy.apache.org>>
> Date: Monday, May 18, 2020 at 5:43 AM
> To: "users@groovy.apache.org <ma...@groovy.apache.org>" <users@groovy.apache.org <ma...@groovy.apache.org>>
> Subject: How to test and deploy without groovy-all? (was: More Groovy 3 woes)
>  
> Hi there,
> 
> 
>> On 16 May 2020, at 14:17, OCsite <ocs@ocs.cz <ma...@ocs.cz>> wrote:
>> First, can you (or anyone) please suggest what to do with my classpath now when groovy-all's gone?
> 
>  
> I still can't see a reasonable solution for that :( All the documentation I've found so far is
>  
>> http://groovy-lang.org/releasenotes/groovy-2.5.html <http://groovy-lang.org/releasenotes/groovy-2.5.html> 
> which alas does not help at all. Especially I can't see how “simply bumping the version number” could “be sufficient”?
>  
> Up to 2.4, indeed simply changing the version number did suffice: my build scripts did select the proper compiler at.../groovy{VERSION}/bin/groovyc, and to the run script was similarly added .../Extensions/groovy-all-{VERSION}-indy.jar to the classpath. Worked like a charm.
>  
> The build still works all right, but how on earth should I run the application? Without groovy on classpath it just reports that it can't load theapp.Application class (which is quite understandable, for the class implementation uses Groovy, and java does not have an access to its JARs at all, so loading the class fails).
>  
> So far the only way I have found to test was to add a complete contents of groovy/lib to the classpath. That's darn inconvenient for testing at my side, and would get extremely inconvenient at the deployment site.
>  
> What's the proper way to launch an application written in Groovy from 2.5 up on a deployment site (where there's of course no Groovy installation at all)? Up to 2.4, simple
>  
> java -classpath '...groovy-all-{VERSION}-indy.jar...' app.Application
>  
> did suffice, all what was needed was to place the one groovy-all JAR for each version of groovy we build with[1] to the Extensions folder, and it worked perfectly.
>  
> What should I do now instead? I can see I could put all the JARs of all the groovys we use in there and add them all explicitly to the classpath; but it will be darn ugly; adding a new groovy release would get rather difficult, not speaking of switching betwixt different groovy versions for different applications.
>  
> Thanks a lot,
> OC
>  
> [1] for some of our applications we use a fixed groovy version against which the app was extensively tested, lest we bump into some breaking change in a newer groovy. Thus, we build and run different applications with different groovy versions. Up to 2.4, no problem at all, with all the groovy-alls in the Extensions folder and the proper one in classpath of each run script worked like a charm.

Re: How to test and deploy without groovy-all? (was: More Groovy 3 woes)

["Nelson, Erick" <Er...@hdsupply.com>]

I use Maven to do my build-test-deploy, and I am currently researching converting to Gradle.
Here is my maven dependency…

    <dependency>
      <groupId>org.codehaus.groovy</groupId>
      <artifactId>groovy-all</artifactId>
      <version>2.5.9</version>
      <scope>provided</scope>
      <type>pom</type>
    </dependency>

Now, while I do admit I have not tried a build yet with Groovy 3, the Maven dependency for groovy-all does exist…

[cid:image001.png@01D62CE1.D7946A20]


From: OCsite <oc...@ocs.cz>
Reply-To: "users@groovy.apache.org" <us...@groovy.apache.org>
Date: Monday, May 18, 2020 at 5:43 AM
To: "users@groovy.apache.org" <us...@groovy.apache.org>
Subject: How to test and deploy without groovy-all? (was: More Groovy 3 woes)

Hi there,


On 16 May 2020, at 14:17, OCsite <oc...@ocs.cz>> wrote:
First, can you (or anyone) please suggest what to do with my classpath now when groovy-all's gone?

I still can't see a reasonable solution for that :( All the documentation I've found so far is

http://groovy-lang.org/releasenotes/groovy-2.5.html

which alas does not help at all. Especially I can't see how “simply bumping the version number” could “be sufficient”?

Up to 2.4, indeed simply changing the version number did suffice: my build scripts did select the proper compiler at .../groovy{VERSION}/bin/groovyc, and to the run script was similarly added .../Extensions/groovy-all-{VERSION}-indy.jar to the classpath. Worked like a charm.

The build still works all right, but how on earth should I run the application? Without groovy on classpath it just reports that it can't load the app.Application class (which is quite understandable, for the class implementation uses Groovy, and java does not have an access to its JARs at all, so loading the class fails).

So far the only way I have found to test was to add a complete contents of groovy/lib to the classpath. That's darn inconvenient for testing at my side, and would get extremely inconvenient at the deployment site.

What's the proper way to launch an application written in Groovy from 2.5 up on a deployment site (where there's of course no Groovy installation at all)? Up to 2.4, simple

java -classpath '...groovy-all-{VERSION}-indy.jar...' app.Application

did suffice, all what was needed was to place the one groovy-all JAR for each version of groovy we build with[1] to the Extensions folder, and it worked perfectly.

What should I do now instead? I can see I could put all the JARs of all the groovys we use in there and add them all explicitly to the classpath; but it will be darn ugly; adding a new groovy release would get rather difficult, not speaking of switching betwixt different groovy versions for different applications.

Thanks a lot,
OC

[1] for some of our applications we use a fixed groovy version against which the app was extensively tested, lest we bump into some breaking change in a newer groovy. Thus, we build and run different applications with different groovy versions. Up to 2.4, no problem at all, with all the groovy-alls in the Extensions folder and the proper one in classpath of each run script worked like a charm.

How to test and deploy without groovy-all? (was: More Groovy 3 woes)

[OCsite <oc...@ocs.cz>]

Hi there,

> On 16 May 2020, at 14:17, OCsite <oc...@ocs.cz> wrote:
> First, can you (or anyone) please suggest what to do with my classpath now when groovy-all's gone?

I still can't see a reasonable solution for that :( All the documentation I've found so far is

> http://groovy-lang.org/releasenotes/groovy-2.5.html

which alas does not help at all. Especially I can't see how “simply bumping the version number” could “be sufficient”?

Up to 2.4, indeed simply changing the version number did suffice: my build scripts did select the proper compiler at .../groovy{VERSION}/bin/groovyc, and to the run script was similarly added .../Extensions/groovy-all-{VERSION}-indy.jar to the classpath. Worked like a charm.

The build still works all right, but how on earth should I run the application? Without groovy on classpath it just reports that it can't load the app.Application class (which is quite understandable, for the class implementation uses Groovy, and java does not have an access to its JARs at all, so loading the class fails).

So far the only way I have found to test was to add a complete contents of groovy/lib to the classpath. That's darn inconvenient for testing at my side, and would get extremely inconvenient at the deployment site.

What's the proper way to launch an application written in Groovy from 2.5 up on a deployment site (where there's of course no Groovy installation at all)? Up to 2.4, simple

java -classpath '...groovy-all-{VERSION}-indy.jar...' app.Application

did suffice, all what was needed was to place the one groovy-all JAR for each version of groovy we build with[1] to the Extensions folder, and it worked perfectly.

What should I do now instead? I can see I could put all the JARs of all the groovys we use in there and add them all explicitly to the classpath; but it will be darn ugly; adding a new groovy release would get rather difficult, not speaking of switching betwixt different groovy versions for different applications.

Thanks a lot,
OC

[1] for some of our applications we use a fixed groovy version against which the app was extensively tested, lest we bump into some breaking change in a newer groovy. Thus, we build and run different applications with different groovy versions. Up to 2.4, no problem at all, with all the groovy-alls in the Extensions folder and the proper one in classpath of each run script worked like a charm.

Re: More Groovy 3 woes

[OCsite <oc...@ocs.cz>]

Daniel,

> On 16 May 2020, at 10:58, Daniel.Sun <su...@apache.org> wrote:
> The joint compilation issue should be fixed in Groovy 3.0.4, which will be
> released in a couple of days.
> 
> If you want to try in a hurry, here is link to SNAPSHOT:
> https://github.com/apache/groovy/actions/runs/106435124

great, thanks; I've suceeded to check quickly and my project is built completely! Great!

(Incidentally, seems the compiler now does not understand the --indy switch. I'd sugges — if it does not make any sense anymore —, to still recognise it and just emit a warning that the switch does not do anything anymore. That it prevents compilation is pretty bad for project backward compatibility.

Running's not that easy. First, can you (or anyone) please suggest what to do with my classpath now when groovy-all's gone? The only solution I've found to be able to run my application was to add all JARs from groovy/lib to classpath; that's darn inconvenient for testing and would be a proper hell for deployment :(

Aside of that it seems it runs more or less all right. Some of my ASTTs seem to be incompatible with the new stuff alas, but that I'll have to pursue in detail before I either simply fix it at my side or ask here for a help :)

Thanks again a big lot!
OC

Re: More Groovy 3 woes

["Daniel.Sun" <su...@apache.org>]

The joint compilation issue should be fixed in Groovy 3.0.4, which will be
released in a couple of days.

If you want to try in a hurry, here is link to SNAPSHOT:
https://github.com/apache/groovy/actions/runs/106435124


Cheers,
Daniel Sun



-----
Apache Groovy committer & PMC member 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html