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

[MG]

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

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?

[OCsite]

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  wrote:
> 
> 
> On Tue, May 19, 2020 at 8:32 PM OCsite mailto:o...@ocs.cz>> 
> wrote:
> Paul,
> 
>> On 19 May 2020, at 7:09, Paul King > <mailto:pa...@asert.com.au>> wrote:
>> On Tue, May 19, 2020 at 2:58 AM Corum, Michael > <mailto:mco...@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 mailto:o...@ocs.cz>>
>> Reply-To: "users@groovy.apache.org <mailto:users@groovy.apache.org>" 
>> mailto:users@groovy.apache.org>>
>> Date: Monday, May 18, 2020 at 11:47 AM
>> To: "users@groovy.apache.org <mailto:users@groovy.apache.org>" 
>> mailto:users@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 > <mailto:mauro...@tiscali.it>> wrote:
&

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

[Paul King]

On Tue, May 19, 2020 at 8:32 PM OCsite  wrote:

> Paul,
>
> On 19 May 2020, at 7:09, Paul King  wrote:
> On Tue, May 19, 2020 at 2:58 AM Corum, Michael  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 
>> *Reply-To: *"users@groovy.apache.org" 
>> *Date: *Monday, May 18, 2020 at 11:47 AM
>> *To: *"users@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  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. Embeddi

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

[OCsite]

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

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

[Andy Duncan]

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

[OCsite]

Paul,

> On 19 May 2020, at 7:09, Paul King  wrote:
> On Tue, May 19, 2020 at 2:58 AM Corum, Michael  <mailto:mco...@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 mailto:o...@ocs.cz>>
> Reply-To: "users@groovy.apache.org <mailto:users@groovy.apache.org>" 
> mailto:users@groovy.apache.org>>
> Date: Monday, May 18, 2020 at 11:47 AM
> To: "users@groovy.apache.org <mailto:users@groovy.apache.org>" 
> mailto:users@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  <mailto:mauro...@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 framework

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

[Mauro Molinari]

  
  
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?

[Jochen Theodorou]

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?

[Paul King]

On Tue, May 19, 2020 at 2:58 AM Corum, Michael  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 
> *Reply-To: *"users@groovy.apache.org" 
> *Date: *Monday, May 18, 2020 at 11:47 AM
> *To: *"users@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  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 le

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

[OCsite]

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  wrote:
> 
> 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  > 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 mailto:o...@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 > > wrote:
>> 
>> The 

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

[sigzero]

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 
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  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  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  wrote:
>>
>>>
>>> On 18 May 2020, at 18:12, Mauro Molinari  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 

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

[Andy Duncan]

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  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  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  wrote:
>
>>
>> On 18 May 2020, at 18:12, Mauro Molinari  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 

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

[Tamás Cservenák]

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  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  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  wrote:
>
>>
>> On 18 May 2020, at 18:12, Mauro Molinari  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".
>>
>> 

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

[OCsite]

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  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 mailto:o...@ocs.cz>> 
> wrote:
> 
>> On 18 May 2020, at 18:12, Mauro Molinari > > 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 

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

[Tamás Cservenák]

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  wrote:

>
> On 18 May 2020, at 18:12, Mauro Molinari  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 

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

[Corum, Michael]

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 
Reply-To: "users@groovy.apache.org" 
Date: Monday, May 18, 2020 at 11:47 AM
To: "users@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 
mailto:mauro...@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 
agai

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

[OCsite]

> On 18 May 2020, at 18:12, Mauro Molinari  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 

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

[Mauro Molinari]

  
  
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]

Thanks again, but...

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

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

[Mauro Molinari]

  
  
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]

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  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 
> 
> 
>> On May 18, 2020, at 8:43 AM, OCsite mailto:o...@ocs.cz>> wrote:
>> 
>> Hi there,
>> 
>>> On 16 May 2020, at 14:17, OCsite mailto:o...@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: How to test and deploy without groovy-all? (was: More Groovy 3 woes)

[OCsite]

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  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  wrote:
> 
> I use Maven to do my build-test-deploy, and I am currently researching 
> converting to Gradle.
> Here is my maven dependency…
>  
> 
>   org.codehaus.groovy
>   groovy-all
>   2.5.9
>   provided
>   pom
> 
>  
> 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 mailto:o...@ocs.cz>>
> Reply-To: "users@groovy.apache.org " 
> mailto:users@groovy.apache.org>>
> Date: Monday, May 18, 2020 at 5:43 AM
> To: "users@groovy.apache.org " 
> mailto:users@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 mailto:o...@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 
> 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 

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

[Keith Suderman]

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  wrote:
> 
> Hi there,
> 
>> On 16 May 2020, at 14:17, OCsite mailto:o...@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.