Re: Problem lading groovy-all for version 4.0.0

[Paul King]

Hi Jon, I would have thought that should work. Does adding "@pom" as per
the following help:

https://stackoverflow.com/questions/55575065/how-to-use-pom-type-dependency-in-gradle

Cheers, Paul.


<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sat, Mar 5, 2022 at 7:10 PM Kerridge, Jon 
wrote:

> Hi,
>
> I am wanting to move from Groovy 3 to 4.
>
> I am using Intellij, Gradle and openjdk 11
>
> I created a new gradle project for Java and Groovy.
>
> I modified the automatically generated build file to get groovy-all for
> version 4.0.0 as follows
>
>
>
> plugins
> *{ *id 'groovy'
> id 'java'
>
>
> *} *group 'org.example'
> version '1.0-SNAPSHOT'
>
> repositories
> *{ *mavenCentral()
>
>
> *} *dependencies
> *{ *implementation 'org.apache.groovy:groovy-all:4.0.0'
> testImplementation 'org.junit.jupiter:junit-jupiter-api:5.8.2'
> testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.8.2'
>
>
> *} *test
> *{ *useJUnitPlatform()
> *}*
>
>
>
> but it failed with
>
>    - Could not resolve org.apache.groovy:groovy-all:4.0.0 for
>Groovy4Test:main  (Groovy4Test is the project name)
>-
>
> If I replace ‘groovy-all’ with ‘groovy’ it works!
>
>
>
> I know I have been lazy in not working out the modules I require but I was
> just wanting to make the transition as easy as possible.
>
>
>
> What have I done wrong?
>
>
>
> Jon
>
>
>
> Jon Kerridge PhD FBCS FHEA CITP CEng
>
> Emeritus Professor of Computing
> School of Computing
> Edinburgh Napier University
> Merchiston Campus
>
> 10 Colinton Road
>
> Edinburgh
>
> EH10 5DT
>
>
>
> Email: j.kerri...@napier.ac.uk
>
>
>
> This message and its attachment(s) are intended for the addressee(s) only
> and should not be read, copied, disclosed, forwarded or relied upon by any
> person other than the intended addressee(s) without the permission of the
> sender. If you are not the intended addressee you must not take any action
> based on this message and its attachment(s) nor must you copy or show them
> to anyone. Please respond to the sender and ensure that this message and
> its attachment(s) are deleted.
>
> It is your responsibility to ensure that this message and its
> attachment(s) are scanned for viruses or other defects. Edinburgh Napier
> University does not accept liability for any loss or damage which may
> result from this message or its attachment(s), or for errors or omissions
> arising after it was sent. Email is not a secure medium. Emails entering
> Edinburgh Napier University's system are subject to routine monitoring and
> filtering by Edinburgh Napier University.
>
> Edinburgh Napier University is a registered Scottish charity. Registration
> number SC018373
>
> BSL users can contact us via contactSCOTLAND-BSL, the on-line British Sign
> Language interpreting service. Find out more on the contactSCOTLAND website.
>

Problem lading groovy-all for version 4.0.0

[Kerridge, Jon]

Hi,
I am wanting to move from Groovy 3 to 4.
I am using Intellij, Gradle and openjdk 11
I created a new gradle project for Java and Groovy.
I modified the automatically generated build file to get groovy-all for version 
4.0.0 as follows

plugins {
id 'groovy'
id 'java'
}

group 'org.example'
version '1.0-SNAPSHOT'

repositories {
mavenCentral()
}

dependencies {
implementation 'org.apache.groovy:groovy-all:4.0.0'
testImplementation 'org.junit.jupiter:junit-jupiter-api:5.8.2'
testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.8.2'
}

test {
useJUnitPlatform()
}

but it failed with

  *   Could not resolve org.apache.groovy:groovy-all:4.0.0 for Groovy4Test:main 
 (Groovy4Test is the project name)
  *
If I replace 'groovy-all' with 'groovy' it works!

I know I have been lazy in not working out the modules I require but I was just 
wanting to make the transition as easy as possible.

What have I done wrong?

Jon

Jon Kerridge PhD FBCS FHEA CITP CEng
Emeritus Professor of Computing
School of Computing
Edinburgh Napier University
Merchiston Campus
10 Colinton Road
Edinburgh
EH10 5DT

Email: j.kerri...@napier.ac.uk<mailto:j.kerri...@napier.ac.uk>


This message and its attachment(s) are intended for the addressee(s) only and 
should not be read, copied, disclosed, forwarded or relied upon by any person 
other than the intended addressee(s) without the permission of the sender. If 
you are not the intended addressee you must not take any action based on this 
message and its attachment(s) nor must you copy or show them to anyone. Please 
respond to the sender and ensure that this message and its attachment(s) are 
deleted.

It is your responsibility to ensure that this message and its attachment(s) are 
scanned for viruses or other defects. Edinburgh Napier University does not 
accept liability for any loss or damage which may result from this message or 
its attachment(s), or for errors or omissions arising after it was sent. Email 
is not a secure medium. Emails entering Edinburgh Napier University's system 
are subject to routine monitoring and filtering by Edinburgh Napier University.

Edinburgh Napier University is a registered Scottish charity. Registration 
number SC018373

BSL users can contact us via contactSCOTLAND-BSL, the on-line British Sign 
Language interpreting service. Find out more on the contactSCOTLAND website.

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

[o...@ocs.cz]

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

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

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

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

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

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

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

Thanks,
OC

> On 20. 5. 2020, at 10:19 PM, MG  wrote:
> 
> Hi Mauro,
> 
> I think I can shed some light at where OC is coming from. Basically, if you 
> have a project with very few dependencies and therefore few JARs, it is 
> without any doubt convenient to have just a single groovy-all- 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 

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?

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 
> <https://docs.gradle.org/current/userguide/xcode_plugin.html>
> 
> --
> Bob
> 
> On Mon, May 18, 2020 at 3:38 PM Andy Duncan  <mailto:a...@adjectivecolournoun.com>> wrote:
> Hi,
> 
> If you're bundling up Grooby applications for deployment on to servers,, I 
> would echo what others have said and look into Gradle, along with the Shadow 
> plugin [1]
> .  Having lived through the age of Ant and committing all of the binary 
> dependencies in my projects to source control, having a build system that can 
> bootstrap itself from nothing, manage all of the dependencies, _and_ package 
> only the classes my project actually needs into a single jar still seems a 
> bit like magic!
> 
> I've got a project [2] implementing AWS Lambda functions in Groovy that does 
> substantially the same thing.  The functions are packaged up into a single 
> file and deployed to AWS, but the same principle would apply for an 
> executable jar.  There's an example of doing that in the Shadow documentation.
> 
> I don't know how Xcode handles it, but IDEA has very good support for Gradle. 
>  It can import the project directly from the build.gradle file, and by 
> default defers to Gradle to do the building, so the result is exactly the 
> same as on a build server.
> 
> I hope this example helps, it really is so much easier than managing 
> pre-installed dependencies on a build server.
> 
> Andy
> 
> [1] https://imperceptiblethoughts.com/shadow/ 
> <https://imperceptiblethoughts.com/shadow/>
> [2] https://github.com/andyjduncan/serverless-dyndns 
> <https://github.com/andyjduncan/serverless-dyndns>
> On Mon, May 18, 2020 at 7:16 PM OCsite 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 wor

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 scri

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

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

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

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 sc

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 itse

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 makefil

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 
> <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 
>>> <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>" 
> mailto:users@groovy.apache.org>>
> Date: Monday, May 18, 2020 at 5:43 AM
> To: "users@groovy.apache.org <mailto: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 
>> <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 w

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

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

[OCsite]

Hi there,

> On 16 May 2020, at 14:17, OCsite  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: groovy-all

[Cédric Champeau]

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

Le jeu. 24 oct. 2019 à 09:47,  a écrit :

> Hi,
>
> is there groovy maven dependency, that can be used in a java project
> without pulling in test ng?
>
> The test ng „gift“ is quite a nuisance, if junit tests are used. Even if
> junit is disabled for test ng, test ng still checks each and every junit
> test case (which takes roughly half a second on my box).
>
>
>
>
>
> Kind Regards,
>
> Arne
>

groovy-all

[arne.adams]

Hi,

is there groovy maven dependency, that can be used in a java project without
pulling in test ng?

The test ng "gift" is quite a nuisance, if junit tests are used. Even if
junit is disabled for test ng, test ng still checks each and every junit
test case (which takes roughly half a second on my box).

 

 

Kind Regards,

Arne

Re: What is the best replacement for running scripts using groovy-all?

[Mario Garcia]

BTW about @Grab, bear in mind that you can tell @Grab where to put/take its
dependencies from:

groovy -Dgrape.root=./lib my_script.groovy

So every project can have its dependencies in the project's structure.

Regards
Mario

El jue., 20 dic. 2018 a las 10:44, Paul Moore ()
escribió:

> I can understand that logic - there are quirks I've hit with the fat
> jar approach, but because I made the fat jar myself, I'm OK with just
> assuming it's a weirdness that I can either live with or investigate.
> But if it happened with a supplied jar, I'd feel that I should report
> the problem (even if I could work around it) in case it hit others,
> too. So that's an extra burden on the developers, as you say.
>
> Having an uber jar in the zip distribution would have solved my use
> case. Or even just a recipe in the documentation explaining how to
> build an uber jar for yourself. If the Gradle script I posted here
> earlier is of any help, feel free to use it.
>
> Paul
>
> On Thu, 20 Dec 2018 at 00:44, Paul King  wrote:
> >
> > We don't want to publish a fat jar to maven because it will cause
> problems that we will continually be asked about but perhaps having an uber
> jar within the zip distribution might be something we could look at. I
> suspect over time though that even that could be problematic.
> >
> > On Thu, Dec 20, 2018 at 8:46 AM MG  wrote:
> >>
> >> Hi,
> >>
> >> out of curiosity (and because having a fat jar again might be
> >> conventient at some point in the future in my work environment (also no
> >> internet access)):
> >>
> >> This solution proposed by Keith does not work
> >> https://github.com/gradle/gradle-groovy-all
> >> ?
> >>
> >> Cheers,
> >> mg
> >>
> >>
> >>
> >> Am 19.12.2018 um 23:33 schrieb Paul Moore:
> >> > On Wed, 19 Dec 2018 at 21:23, James Kleeh 
> wrote:
> >> >> Paul,
> >> >>
> >> >> The best solution is to use Maven or Gradle to create an all-in-one
> (fat) jar that you can ship and run with java -jar
> >> >>
> >> >> Gradle has a shadow plugin and Maven has a shade plugin to do just
> that.
> >> > Thanks. I'd come to the conclusion that Gradle was likely the solution
> >> > I should be looking at, and I've spent the evening trying to set up a
> >> > basic Gradle script that does what I want. After a lot of
> >> > experimentation, I came up with the following, which seems to do what
> >> > I want:
> >> >
> >> > -- start build.gradle --
> >> >
> >> > version = "0.1"
> >> >
> >> > configurations {
> >> >  deploy
> >> > }
> >> >
> >> > dependencies {
> >> >  deploy 'org.codehaus.groovy:groovy-all:2.5.4'
> >> > }
> >> >
> >> > repositories {
> >> >  jcenter()
> >> > }
> >> >
> >> > task copyDeps(type:Copy, group: "Custom", description: "Copies project
> >> > dependencies") {
> >> >  from configurations.deploy.collect { it.absolutePath }
> >> >  into "dest/lib"
> >> > }
> >> >
> >> > task copy(type: Copy, group: "Custom", description: "Copies sources to
> >> > the dest directory") {
> >> >  from "src"
> >> >  include "*.groovy"
> >> >  into "dest"
> >> > }
> >> >
> >> > task deploy(type:Zip, group: "Custom", description: "Build a
> deployment zip") {
> >> >  dependsOn copyDeps
> >> >  dependsOn copy
> >> >  from "dest"
> >> >  setArchiveName "${project.name}-${project.version}.zip"
> >> > }
> >> >
> >> > -- end build.gradle --
> >> >
> >> > It doesn't create a fat jar yet, but I can look into setting that up.
> >> > The various existing plugins seem to be dependent upon the
> >> > infrastructure set up by the java plugin, which I don't really
> >> > understand (or need, as far as I can tell) so they may not be of much
> >> > help. But I'm not sure what I need to do yet to write my own.
> >> > Something simple like
> >> >
> >> > task customFatJar(type: Jar) {
> >> >  dependsOn copyDeps
> >> >  baseName = 'all-in-one-jar'
> >> >  from "dest/lib"
> >> > }
> >> >
> >> > gives me an "all-in-one-jar.jar" that contains the dependency jars
> >> > directly included, rather than being unpacked. So there's more I need
> >> > to do here...
> >> >
> >> > Paul
> >> >
> >>
>

Re: What is the best replacement for running scripts using groovy-all?

[Paul Moore]

I can understand that logic - there are quirks I've hit with the fat
jar approach, but because I made the fat jar myself, I'm OK with just
assuming it's a weirdness that I can either live with or investigate.
But if it happened with a supplied jar, I'd feel that I should report
the problem (even if I could work around it) in case it hit others,
too. So that's an extra burden on the developers, as you say.

Having an uber jar in the zip distribution would have solved my use
case. Or even just a recipe in the documentation explaining how to
build an uber jar for yourself. If the Gradle script I posted here
earlier is of any help, feel free to use it.

Paul

On Thu, 20 Dec 2018 at 00:44, Paul King  wrote:
>
> We don't want to publish a fat jar to maven because it will cause problems 
> that we will continually be asked about but perhaps having an uber jar within 
> the zip distribution might be something we could look at. I suspect over time 
> though that even that could be problematic.
>
> On Thu, Dec 20, 2018 at 8:46 AM MG  wrote:
>>
>> Hi,
>>
>> out of curiosity (and because having a fat jar again might be
>> conventient at some point in the future in my work environment (also no
>> internet access)):
>>
>> This solution proposed by Keith does not work
>> https://github.com/gradle/gradle-groovy-all
>> ?
>>
>> Cheers,
>> mg
>>
>>
>>
>> Am 19.12.2018 um 23:33 schrieb Paul Moore:
>> > On Wed, 19 Dec 2018 at 21:23, James Kleeh  wrote:
>> >> Paul,
>> >>
>> >> The best solution is to use Maven or Gradle to create an all-in-one (fat) 
>> >> jar that you can ship and run with java -jar
>> >>
>> >> Gradle has a shadow plugin and Maven has a shade plugin to do just that.
>> > Thanks. I'd come to the conclusion that Gradle was likely the solution
>> > I should be looking at, and I've spent the evening trying to set up a
>> > basic Gradle script that does what I want. After a lot of
>> > experimentation, I came up with the following, which seems to do what
>> > I want:
>> >
>> > -- start build.gradle --
>> >
>> > version = "0.1"
>> >
>> > configurations {
>> >  deploy
>> > }
>> >
>> > dependencies {
>> >  deploy 'org.codehaus.groovy:groovy-all:2.5.4'
>> > }
>> >
>> > repositories {
>> >  jcenter()
>> > }
>> >
>> > task copyDeps(type:Copy, group: "Custom", description: "Copies project
>> > dependencies") {
>> >  from configurations.deploy.collect { it.absolutePath }
>> >  into "dest/lib"
>> > }
>> >
>> > task copy(type: Copy, group: "Custom", description: "Copies sources to
>> > the dest directory") {
>> >  from "src"
>> >  include "*.groovy"
>> >  into "dest"
>> > }
>> >
>> > task deploy(type:Zip, group: "Custom", description: "Build a deployment 
>> > zip") {
>> >  dependsOn copyDeps
>> >  dependsOn copy
>> >  from "dest"
>> >  setArchiveName "${project.name}-${project.version}.zip"
>> > }
>> >
>> > -- end build.gradle --
>> >
>> > It doesn't create a fat jar yet, but I can look into setting that up.
>> > The various existing plugins seem to be dependent upon the
>> > infrastructure set up by the java plugin, which I don't really
>> > understand (or need, as far as I can tell) so they may not be of much
>> > help. But I'm not sure what I need to do yet to write my own.
>> > Something simple like
>> >
>> > task customFatJar(type: Jar) {
>> >  dependsOn copyDeps
>> >  baseName = 'all-in-one-jar'
>> >  from "dest/lib"
>> > }
>> >
>> > gives me an "all-in-one-jar.jar" that contains the dependency jars
>> > directly included, rather than being unpacked. So there's more I need
>> > to do here...
>> >
>> > Paul
>> >
>>

Re: What is the best replacement for running scripts using groovy-all?

[Paul King]

We don't want to publish a fat jar to maven because it will cause problems
that we will continually be asked about but perhaps having an uber jar
within the zip distribution might be something we could look at. I suspect
over time though that even that could be problematic.

On Thu, Dec 20, 2018 at 8:46 AM MG  wrote:

> Hi,
>
> out of curiosity (and because having a fat jar again might be
> conventient at some point in the future in my work environment (also no
> internet access)):
>
> This solution proposed by Keith does not work
> https://github.com/gradle/gradle-groovy-all
> ?
>
> Cheers,
> mg
>
>
>
> Am 19.12.2018 um 23:33 schrieb Paul Moore:
> > On Wed, 19 Dec 2018 at 21:23, James Kleeh  wrote:
> >> Paul,
> >>
> >> The best solution is to use Maven or Gradle to create an all-in-one
> (fat) jar that you can ship and run with java -jar
> >>
> >> Gradle has a shadow plugin and Maven has a shade plugin to do just that.
> > Thanks. I'd come to the conclusion that Gradle was likely the solution
> > I should be looking at, and I've spent the evening trying to set up a
> > basic Gradle script that does what I want. After a lot of
> > experimentation, I came up with the following, which seems to do what
> > I want:
> >
> > -- start build.gradle --
> >
> > version = "0.1"
> >
> > configurations {
> >  deploy
> > }
> >
> > dependencies {
> >  deploy 'org.codehaus.groovy:groovy-all:2.5.4'
> > }
> >
> > repositories {
> >  jcenter()
> > }
> >
> > task copyDeps(type:Copy, group: "Custom", description: "Copies project
> > dependencies") {
> >  from configurations.deploy.collect { it.absolutePath }
> >  into "dest/lib"
> > }
> >
> > task copy(type: Copy, group: "Custom", description: "Copies sources to
> > the dest directory") {
> >  from "src"
> >  include "*.groovy"
> >  into "dest"
> > }
> >
> > task deploy(type:Zip, group: "Custom", description: "Build a deployment
> zip") {
> >  dependsOn copyDeps
> >  dependsOn copy
> >  from "dest"
> >  setArchiveName "${project.name}-${project.version}.zip"
> > }
> >
> > -- end build.gradle --
> >
> > It doesn't create a fat jar yet, but I can look into setting that up.
> > The various existing plugins seem to be dependent upon the
> > infrastructure set up by the java plugin, which I don't really
> > understand (or need, as far as I can tell) so they may not be of much
> > help. But I'm not sure what I need to do yet to write my own.
> > Something simple like
> >
> > task customFatJar(type: Jar) {
> >  dependsOn copyDeps
> >  baseName = 'all-in-one-jar'
> >  from "dest/lib"
> > }
> >
> > gives me an "all-in-one-jar.jar" that contains the dependency jars
> > directly included, rather than being unpacked. So there's more I need
> > to do here...
> >
> > Paul
> >
>
>

Re: What is the best replacement for running scripts using groovy-all?

[Remko Popma]

You may be interested in the Gradle application plugin. This creates a 
distribution zip file with all the dependencies and some starter scripts. 
https://docs.gradle.org/current/userguide/application_plugin.html

The only customization would be to add your custom script to the bin/ directory 
where the starter scripts live. 


Remko.
(Shameless plug) Every java main() method deserves http://picocli.info

> On Dec 20, 2018, at 8:00, Paul Moore  wrote:
> 
>> On Wed, 19 Dec 2018 at 22:46, MG  wrote:
>> 
>> Hi,
>> 
>> out of curiosity (and because having a fat jar again might be
>> conventient at some point in the future in my work environment (also no
>> internet access)):
>> 
>> This solution proposed by Keith does not work
>> https://github.com/gradle/gradle-groovy-all
>> ?
> 
> See https://github.com/gradle/gradle-groovy-all/issues/1
> 
> Basically, yes it does, but only for groovy.ui.GroovyMain (which is
> fine) and they don't support usage for anything other than Gradle's
> purposes and they are looking to discontinue it once Gradle no longer
> needs it (which isn't quite as fine ;-))
> 
> In addition, by not going with that solution, I've learned a lot about
> Gradle and how to use it to solve my problem, which is much better, as
> not only do I have a solution, I also learned something new :-) By the
> way - my Gradle solution also doesn't work for groovy.ui.Console, but
> that's fine as I say above (and it's a chance to learn more, working
> out why :-))
> 
> Paul

Re: What is the best replacement for running scripts using groovy-all?

[Paul Moore]

On Wed, 19 Dec 2018 at 22:46, MG  wrote:
>
> Hi,
>
> out of curiosity (and because having a fat jar again might be
> conventient at some point in the future in my work environment (also no
> internet access)):
>
> This solution proposed by Keith does not work
> https://github.com/gradle/gradle-groovy-all
> ?

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

Basically, yes it does, but only for groovy.ui.GroovyMain (which is
fine) and they don't support usage for anything other than Gradle's
purposes and they are looking to discontinue it once Gradle no longer
needs it (which isn't quite as fine ;-))

In addition, by not going with that solution, I've learned a lot about
Gradle and how to use it to solve my problem, which is much better, as
not only do I have a solution, I also learned something new :-) By the
way - my Gradle solution also doesn't work for groovy.ui.Console, but
that's fine as I say above (and it's a chance to learn more, working
out why :-))

Paul

Re: What is the best replacement for running scripts using groovy-all?

[MG]

Hi,

out of curiosity (and because having a fat jar again might be 
conventient at some point in the future in my work environment (also no 
internet access)):


This solution proposed by Keith does not work
https://github.com/gradle/gradle-groovy-all
?

Cheers,
mg



Am 19.12.2018 um 23:33 schrieb Paul Moore:

On Wed, 19 Dec 2018 at 21:23, James Kleeh  wrote:

Paul,

The best solution is to use Maven or Gradle to create an all-in-one (fat) jar 
that you can ship and run with java -jar

Gradle has a shadow plugin and Maven has a shade plugin to do just that.

Thanks. I'd come to the conclusion that Gradle was likely the solution
I should be looking at, and I've spent the evening trying to set up a
basic Gradle script that does what I want. After a lot of
experimentation, I came up with the following, which seems to do what
I want:

-- start build.gradle --

version = "0.1"

configurations {
 deploy
}

dependencies {
 deploy 'org.codehaus.groovy:groovy-all:2.5.4'
}

repositories {
 jcenter()
}

task copyDeps(type:Copy, group: "Custom", description: "Copies project
dependencies") {
 from configurations.deploy.collect { it.absolutePath }
 into "dest/lib"
}

task copy(type: Copy, group: "Custom", description: "Copies sources to
the dest directory") {
 from "src"
 include "*.groovy"
 into "dest"
}

task deploy(type:Zip, group: "Custom", description: "Build a deployment zip") {
 dependsOn copyDeps
 dependsOn copy
 from "dest"
 setArchiveName "${project.name}-${project.version}.zip"
}

-- end build.gradle --

It doesn't create a fat jar yet, but I can look into setting that up.
The various existing plugins seem to be dependent upon the
infrastructure set up by the java plugin, which I don't really
understand (or need, as far as I can tell) so they may not be of much
help. But I'm not sure what I need to do yet to write my own.
Something simple like

task customFatJar(type: Jar) {
 dependsOn copyDeps
 baseName = 'all-in-one-jar'
 from "dest/lib"
}

gives me an "all-in-one-jar.jar" that contains the dependency jars
directly included, rather than being unpacked. So there's more I need
to do here...

Paul

Re: What is the best replacement for running scripts using groovy-all?

[Paul Moore]

On Wed, 19 Dec 2018 at 22:33, Paul Moore  wrote:

> Something simple like
>
> task customFatJar(type: Jar) {
> dependsOn copyDeps
> baseName = 'all-in-one-jar'
> from "dest/lib"
> }
>
> gives me an "all-in-one-jar.jar" that contains the dependency jars
> directly included, rather than being unpacked. So there's more I need
> to do here...

Actually, I found the following on the web, which seems to work:

task customFatJar(type: Jar) {
dependsOn copyDeps
baseName = 'all-in-one-jar'
from {
configurations.deploy.collect {
it.isDirectory() ? it : zipTree(it)
}
}
}

I'm not at all sure *why* it works, but it does :-)

Paul

Re: What is the best replacement for running scripts using groovy-all?

[Paul Moore]

On Wed, 19 Dec 2018 at 21:23, James Kleeh  wrote:
>
> Paul,
>
> The best solution is to use Maven or Gradle to create an all-in-one (fat) jar 
> that you can ship and run with java -jar
>
> Gradle has a shadow plugin and Maven has a shade plugin to do just that.

Thanks. I'd come to the conclusion that Gradle was likely the solution
I should be looking at, and I've spent the evening trying to set up a
basic Gradle script that does what I want. After a lot of
experimentation, I came up with the following, which seems to do what
I want:

-- start build.gradle --

version = "0.1"

configurations {
deploy
}

dependencies {
deploy 'org.codehaus.groovy:groovy-all:2.5.4'
}

repositories {
jcenter()
}

task copyDeps(type:Copy, group: "Custom", description: "Copies project
dependencies") {
from configurations.deploy.collect { it.absolutePath }
into "dest/lib"
}

task copy(type: Copy, group: "Custom", description: "Copies sources to
the dest directory") {
from "src"
include "*.groovy"
into "dest"
}

task deploy(type:Zip, group: "Custom", description: "Build a deployment zip") {
dependsOn copyDeps
dependsOn copy
from "dest"
setArchiveName "${project.name}-${project.version}.zip"
}

-- end build.gradle --

It doesn't create a fat jar yet, but I can look into setting that up.
The various existing plugins seem to be dependent upon the
infrastructure set up by the java plugin, which I don't really
understand (or need, as far as I can tell) so they may not be of much
help. But I'm not sure what I need to do yet to write my own.
Something simple like

task customFatJar(type: Jar) {
dependsOn copyDeps
baseName = 'all-in-one-jar'
from "dest/lib"
}

gives me an "all-in-one-jar.jar" that contains the dependency jars
directly included, rather than being unpacked. So there's more I need
to do here...

Paul

Re: What is the best replacement for running scripts using groovy-all?

[Nelson, Erick]

Grab caches it files by default in your user home directory in .groovy/grapes

Just zip up that dir and copy it to the server you want it on, and extract it. 

Sent from my iPhone

> On Dec 19, 2018, at 1:24 PM, James Kleeh  wrote:
> 
> Paul,
> 
> The best solution is to use Maven or Gradle to create an all-in-one (fat) jar 
> that you can ship and run with java -jar
> 
> Gradle has a shadow plugin and Maven has a shade plugin to do just that.
> 
> James
> 
>> On Dec 19, 2018, at 4:19 PM, Paul Moore  wrote:
>> 
>> On Wed, 19 Dec 2018 at 20:18, Søren Berg Glasius  wrote:
>>> 
>>> Hi Paul,
>>> 
>>> This is where The @Grab anotation comes in handy: 
>>> http://docs.groovy-lang.org/latest/html/documentation/grape.html
>>> 
>>> It wil automatically download your dependencies and it works in Groovy 
>>> scripts too.
>> 
>> Thanks - yes, I've seen @Grab, and used it while testing. But the
>> problem is that it puts the dependency files "somewhere", but not
>> alongside the script. I need to ship the script and its dependencies
>> to another machine with no web access, so I need better control over
>> where the dependencies end up. (I could probably hunt out where the
>> files downloaded by @Grab went, but it would be a completely manual
>> task to locate them all and copy them, and mistakes would happen - so
>> I'd prefer something automated.
>> 
>> Paul
> 

Re: What is the best replacement for running scripts using groovy-all?

[James Kleeh]

Paul,

The best solution is to use Maven or Gradle to create an all-in-one (fat) jar 
that you can ship and run with java -jar

Gradle has a shadow plugin and Maven has a shade plugin to do just that.

James

> On Dec 19, 2018, at 4:19 PM, Paul Moore  wrote:
> 
> On Wed, 19 Dec 2018 at 20:18, Søren Berg Glasius  wrote:
>> 
>> Hi Paul,
>> 
>> This is where The @Grab anotation comes in handy: 
>> http://docs.groovy-lang.org/latest/html/documentation/grape.html
>> 
>> It wil automatically download your dependencies and it works in Groovy 
>> scripts too.
> 
> Thanks - yes, I've seen @Grab, and used it while testing. But the
> problem is that it puts the dependency files "somewhere", but not
> alongside the script. I need to ship the script and its dependencies
> to another machine with no web access, so I need better control over
> where the dependencies end up. (I could probably hunt out where the
> files downloaded by @Grab went, but it would be a completely manual
> task to locate them all and copy them, and mistakes would happen - so
> I'd prefer something automated.
> 
> Paul

Re: What is the best replacement for running scripts using groovy-all?

[Paul Moore]

On Wed, 19 Dec 2018 at 20:18, Søren Berg Glasius  wrote:
>
> Hi Paul,
>
> This is where The @Grab anotation comes in handy: 
> http://docs.groovy-lang.org/latest/html/documentation/grape.html
>
> It wil automatically download your dependencies and it works in Groovy 
> scripts too.

Thanks - yes, I've seen @Grab, and used it while testing. But the
problem is that it puts the dependency files "somewhere", but not
alongside the script. I need to ship the script and its dependencies
to another machine with no web access, so I need better control over
where the dependencies end up. (I could probably hunt out where the
files downloaded by @Grab went, but it would be a completely manual
task to locate them all and copy them, and mistakes would happen - so
I'd prefer something automated.

Paul

Re: What is the best replacement for running scripts using groovy-all?

[Søren Berg Glasius]

Hi Paul,

This is where The @Grab anotation comes in handy:
http://docs.groovy-lang.org/latest/html/documentation/grape.html

It wil automatically download your dependencies and it works in Groovy
scripts too.

Best regards / Med venlig hilsen,
Søren Berg Glasius

Hedevej 1, Gl. Rye, 8680 Ry, Denmark
Mobile: +45 40 44 91 88, Skype: sbglasius
--- Press ESC once to quit - twice to save the changes.


On Wed, 19 Dec 2018 at 20:27, Paul Moore  wrote:

> On Wed, 19 Dec 2018 at 08:56, Paul Moore  wrote:
> >
> > On Wed, 19 Dec 2018 at 00:03, Keith Suderman  wrote:
> > >
> > > Option 4) Use the Maven Assembly plugin or the Shade plugin to build
> your own groovy-all Jar file.  Or just use
> https://github.com/gradle/gradle-groovy-all
> >
> > Thanks. Are there any "beginner guide" style instructions on how to
> > use the Maven Assembly plugin or Shade plugin that you can point me
> > to? As I say, I don't use Maven, so the instructions for the plugins
> > use a lot of terms and ideas I'm not familiar with. I can (and
> > probably will!) use the gradle-groovy-all but I'd like to learn a bit
> > more about the Java ecosystem (I'm mostly a Python programmer, but I
> > use Groovy as an alternative for environments where JVM-based tools
> > are a better fit than Python-based ones). I find that starting Groovy
> > *without* a Java/JVM background, there's a lot of assumed knowledge
> > it's quite hard to pick up (unless you're willing to learn Java at the
> > same time ;-))
>
> I've been digging around with this some more, and I've come to the
> conclusion that it's not that important to me in fact to have a single
> groovy-all jar for my deployment. But what I *do* need is a simple way
> to collect together everything I need to run my script(s) and ship
> them to the target machine(s). So my starting point is one or more
> .groovy files. I do *not* want to compile these - I want to ship the
> source script to the server, so that minor changes can be made in
> place using just a text editor. And with them, I want a directory full
> of supporting jar files.
>
> Having created and tested the scripts, I need to collect together all
> of the jar files I used to run them. Obviously, the first thing I need
> is the Groovy jars. Ideally I'd try to strip out unneeded jars (my
> code is to be run on a server with no GUI, so I suspect the
> groovy-swing jar could be skipped, for example). But that's probably
> way more trouble than it's worth, so I'm OK with skipping that step.
> Other dependencies, I've tended to collect from various places (for
> development, I can use @Grab annotations in the source, but my server
> doesn't have Internet access, so that won't work for the deployed
> version).
>
> From what I gather with Java projects, dependencies get managed by a
> tool like Maven or Gradle or by the IDE. But it's very hard for me to
> understand the documentation for these tools, as they are typically
> looking at the problem from the point of view of "compile and build a
> binary from the sources" rather than "collect dependencies into one
> place, but don't compile anything". One problem I'm struggling with is
> that with my background, what I'm trying to do is "obviously" the
> right approach, but I get the feeling that it's very different from
> the Java/Groovy way of doing things, so I keep missing the point of
> people's explanations.
>
> Essentially, what I want is a project structure like this:
>
> MyProject
> script1.groovy
> script2.groovy
> script3.groovy
> script4.groovy
> dependencies.txt
> target
> lib
>
> dependencies.txt can be anything but what it contains should be a list
> of dependencies - something like
>
> org.codehaus.groovy:groovy-all:pom:2.5.4
> javax.mail:mail:jar:1.4.4
> org.apache.commons:commons-csv:jar:1.6
>
> Running "some command" should then copy all the jars needed (based on
> those dependencies) to target/lib. Ideally, copy *.groovy to target as
> well, so I can just zip up the target directory, ship it to the
> destination machine, where I can unzip it and run it with whatever JVM
> is present there.
>
> Am I missing something fundamental which makes this impossible to
> achieve with Java, or is it just that my Google skills have failed me?
> Or is it that Java projects simply aren't normally of this form?
>
> Paul
>

Re: What is the best replacement for running scripts using groovy-all?

[Paul Moore]

On Wed, 19 Dec 2018 at 08:56, Paul Moore  wrote:
>
> On Wed, 19 Dec 2018 at 00:03, Keith Suderman  wrote:
> >
> > Option 4) Use the Maven Assembly plugin or the Shade plugin to build your 
> > own groovy-all Jar file.  Or just use 
> > https://github.com/gradle/gradle-groovy-all
>
> Thanks. Are there any "beginner guide" style instructions on how to
> use the Maven Assembly plugin or Shade plugin that you can point me
> to? As I say, I don't use Maven, so the instructions for the plugins
> use a lot of terms and ideas I'm not familiar with. I can (and
> probably will!) use the gradle-groovy-all but I'd like to learn a bit
> more about the Java ecosystem (I'm mostly a Python programmer, but I
> use Groovy as an alternative for environments where JVM-based tools
> are a better fit than Python-based ones). I find that starting Groovy
> *without* a Java/JVM background, there's a lot of assumed knowledge
> it's quite hard to pick up (unless you're willing to learn Java at the
> same time ;-))

I've been digging around with this some more, and I've come to the
conclusion that it's not that important to me in fact to have a single
groovy-all jar for my deployment. But what I *do* need is a simple way
to collect together everything I need to run my script(s) and ship
them to the target machine(s). So my starting point is one or more
.groovy files. I do *not* want to compile these - I want to ship the
source script to the server, so that minor changes can be made in
place using just a text editor. And with them, I want a directory full
of supporting jar files.

Having created and tested the scripts, I need to collect together all
of the jar files I used to run them. Obviously, the first thing I need
is the Groovy jars. Ideally I'd try to strip out unneeded jars (my
code is to be run on a server with no GUI, so I suspect the
groovy-swing jar could be skipped, for example). But that's probably
way more trouble than it's worth, so I'm OK with skipping that step.
Other dependencies, I've tended to collect from various places (for
development, I can use @Grab annotations in the source, but my server
doesn't have Internet access, so that won't work for the deployed
version).

>From what I gather with Java projects, dependencies get managed by a
tool like Maven or Gradle or by the IDE. But it's very hard for me to
understand the documentation for these tools, as they are typically
looking at the problem from the point of view of "compile and build a
binary from the sources" rather than "collect dependencies into one
place, but don't compile anything". One problem I'm struggling with is
that with my background, what I'm trying to do is "obviously" the
right approach, but I get the feeling that it's very different from
the Java/Groovy way of doing things, so I keep missing the point of
people's explanations.

Essentially, what I want is a project structure like this:

MyProject
script1.groovy
script2.groovy
script3.groovy
script4.groovy
dependencies.txt
target
lib

dependencies.txt can be anything but what it contains should be a list
of dependencies - something like

org.codehaus.groovy:groovy-all:pom:2.5.4
javax.mail:mail:jar:1.4.4
org.apache.commons:commons-csv:jar:1.6

Running "some command" should then copy all the jars needed (based on
those dependencies) to target/lib. Ideally, copy *.groovy to target as
well, so I can just zip up the target directory, ship it to the
destination machine, where I can unzip it and run it with whatever JVM
is present there.

Am I missing something fundamental which makes this impossible to
achieve with Java, or is it just that my Google skills have failed me?
Or is it that Java projects simply aren't normally of this form?

Paul

Re: What is the best replacement for running scripts using groovy-all?

[Keith Suderman]

Option 4) Use the Maven Assembly plugin or the Shade plugin to build your own 
groovy-all Jar file.  Or just use https://github.com/gradle/gradle-groovy-all 
<https://github.com/gradle/gradle-groovy-all>

- Keith


> On Dec 17, 2018, at 3:49 AM, Paul Moore  <mailto:p.f.mo...@gmail.com>> wrote:
> 
> I use Groovy as a scripting language for small tasks, running on
> application servers that do not have very good scripting tools
> available, and to which I only have limited access. Prior to Groovy
> 2.5, I've used the groovy-all jar as a low-impact, easy to deploy
> scripting option. I run scripts as
> 
>java -cp .../groovy-all-2.4.x.jar;. groovy.ui.Main myscript.groovy
> 
> The advantages of this approach are:
> 
> 1. One-off deployment of a single binary file to the server, with all
> subsequent script deployments being text files (the actual scripts).
> 2. Works with whatever Java is present on the server.
> 3. Doesn't need to rely on any particular directory structure on the server.
> 4. Doesn't need source code to be held elsewhere (it's a
> run-from-source solution rather than a compiled binary).
> 
> Since Groovy 2.5, the -all jar has been discontinued - the release
> notes explain why, although the reasons don't really apply to me
> (getting something as modern as Java 1.9 on the machines I work with
> would be a miracle!) But they don't really offer a good replacement
> for my use case.
> 
> What's the best option for a situation like mine? Things I've considered are:
> 
> 1. Deploy the full Groovy lib directory and use "-cp
> groovy-2.5.x/lib/*;.". Probably the best option, but either requires
> copying the full lib directory around or hard-coding its path (at the
> moment, I can just dump a copy of the -all jar in the directory
> alongside my script).
> 2. Use the full install and the supplied bat file wrapper. As well as
> the same problem of hard coded paths/copying directories, I find bat
> file wrappers extremely problematic - as bat files don't nest, you
> have to remember to say "call groovy.bat ..." when running from a
> batch script - which frequently gets forgotten.
> 3. Compile my scripts with the needed Groovy jars embedded. This means
> every script needs to be deployed as a binary, and source needs
> managing. Also minor changes involve a full build-deploy cycle.
> 
> Ideally, I'd like a simple means of creating the old -all jar file.
> Even if it comes with warnings and limitations, that would be fine for
> me (at least, assuming the limitations aren't any worse than they were
> in 2.4.x). However, I'm *not* a Java developer, so unfortunately I
> don't know how to translate the comment from the release notes stating
> "We also provided a convenience "all" jar by jarjar’ing the core and
> "module" jars" into instructions for how I could create the -all jar
> file for myself. And the comment "we do provide an "all" pom" doesn't
> mean much to me either - I understand it's something to do with maven,
> but as I don't use tools like maven,. that's not much help to me...
> 
> If anyone can offer any suggestions, I'd be most grateful.
> 
> Paul

Re: Availability of 2.5.0 groovy-all in Maven Central

[Daniel.Sun]

Pls search "required JUST since Groovy 2.5.0"


Cheers,
Daniel.Sun




-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

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

Re: Availability of 2.5.0 groovy-all in Maven Central

[Daniel.Sun]

Hi Robert,

 Pls open http://groovy-lang.org/download.html and search "".

 Thanks for your reminding me, I will refine the doco too later :-)

Cheers,
Daniel.Sun




-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

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

Re: Availability of 2.5.0 groovy-all in Maven Central

[Robert Stagner]

Thanks, Daniel.  This certainly helps.

When you stated "I've refine doco" what are you referring to?  I'm assuming
the documentation.  I reviewed the documentation, specifically,
http://docs.groovy-lang.org/latest/html/documentation/#_maven_integration,
and I do not see a reference to the pom statement.  Am I
missing something here?

On Sun, Jun 3, 2018 at 8:16 PM Daniel.Sun  wrote:

> Here is the twitter to summarize the change:
> https://twitter.com/daniel_sun/status/1003474637697642496
>
>
> Cheers,
> Daniel.Sun
>
>
>
>
> -
> Daniel Sun
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>

Re: Availability of 2.5.0 groovy-all in Maven Central

[Daniel.Sun]

Here is the twitter to summarize the change:
https://twitter.com/daniel_sun/status/1003474637697642496


Cheers,
Daniel.Sun




-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

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

Re: Availability of 2.5.0 groovy-all in Maven Central

[Daniel.Sun]

OK.

I've refine the doco on the Download page of groovy-lang.org
site(http://groovy-lang.org/download.html):

```
org.codehaus.groovy
groovy-all
x.y.z
pom 
```
(`pom ` is added)

BTW, gradle is so smart that `compile
'org.codehaus.groovy:groovy-all:x.y.z'` always works well(Note: DON'T
specify `ext: 'pom'`)

Cheers,
Daniel.Sun




-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

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

Re: Availability of 2.5.0 groovy-all in Maven Central

[Robert Stagner]

Daniel,

Like the others, I ran into a similar error

Failure to find org.codehaus.groovy:groovy-all:jar:2.5.0 in
https://repo.maven.apache.org/maven2 was cached in the local repository,
resolution will not be reattempted until the update interval of central has
elapsed or updates are forced -> [Help 1]

I am also using IntelliJ IDEA.  And, like you I receive the error from the
command line.  Once I include pom it worked.

On Sun, Jun 3, 2018 at 7:21 PM Daniel.Sun  wrote:

> Hi Keith,
>
> I'll add the `pom` to the doco on "Download" page.
>
> P.S. I'm using IntelliJ IDEA. Even if I don't add `pom`,
> it
> works well too. But if I run via command line, I'll get same error as
> yours.
>
> Cheers,
> Daniel.Sun
>
>
>
>
> -
> Daniel Sun
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>

Re: Availability of 2.5.0 groovy-all in Maven Central

[Daniel.Sun]

Hi Keith,

I'll add the `pom` to the doco on "Download" page.

P.S. I'm using IntelliJ IDEA. Even if I don't add `pom`, it
works well too. But if I run via command line, I'll get same error as yours.

Cheers,
Daniel.Sun




-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

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

Re: Availability of 2.5.0 groovy-all in Maven Central

[Keith Suderman]

Daniel beat me to it.  I tried using the Groovy Eclipse compiler (2.5.0-01) and 
I need to explicitly set the type to 'pom' or I get a not found message for 
groovy-all:jar:2.5.0

- Keith


> On Jun 3, 2018, at 9:47 PM, Daniel.Sun  wrote:
> 
> Please add `pom` and try again, here is the complete pom file:
> 
> ```
> 
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
>4.0.0
> 
>me.sunlan
>try-groovy-via-mvn
>1.0-SNAPSHOT
> 
>    
>
>org.codehaus.groovy
>groovy-all
>2.5.0
>pom
>
>
> 
> ```
> 
> and here is result of `mvn dependency:tree`:
> ```
> [INFO] me.sunlan:try-groovy-via-mvn:jar:1.0-SNAPSHOT
> [INFO] \- org.codehaus.groovy:groovy-all:pom:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy:jar:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy-ant:jar:2.5.0:compile
> [INFO]|  +- org.apache.ant:ant:jar:1.9.9:compile
> [INFO]|  +- org.apache.ant:ant-junit:jar:1.9.9:runtime
> [INFO]|  +- org.apache.ant:ant-launcher:jar:1.9.9:compile
> [INFO]|  \- org.apache.ant:ant-antlr:jar:1.9.9:runtime
> [INFO]+- org.codehaus.groovy:groovy-bsf:jar:2.5.0:compile
> [INFO]|  +- bsf:bsf:jar:2.4.0:compile
> [INFO]|  \- commons-logging:commons-logging:jar:1.2:compile
> [INFO]+- org.codehaus.groovy:groovy-cli-picocli:jar:2.5.0:compile
> [INFO]|  \- info.picocli:picocli:jar:3.0.2:compile
> [INFO]+- org.codehaus.groovy:groovy-console:jar:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy-datetime:jar:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy-docgenerator:jar:2.5.0:compile
> [INFO]|  \- com.thoughtworks.qdox:qdox:jar:1.12.1:compile
> [INFO]+- org.codehaus.groovy:groovy-groovydoc:jar:2.5.0:compile
> [INFO]|  \- org.codehaus.groovy:groovy-dateutil:jar:2.5.0:runtime
> [INFO]+- org.codehaus.groovy:groovy-groovysh:jar:2.5.0:compile
> [INFO]|  \- jline:jline:jar:2.14.6:compile
> [INFO]+- org.codehaus.groovy:groovy-jmx:jar:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy-json:jar:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy-jsr223:jar:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy-macro:jar:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy-nio:jar:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy-servlet:jar:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy-sql:jar:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy-swing:jar:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy-templates:jar:2.5.0:compile
> [INFO]+- org.codehaus.groovy:groovy-test:jar:2.5.0:compile
> [INFO]|  \- junit:junit:jar:4.12:compile
> [INFO]| \- org.hamcrest:hamcrest-core:jar:1.3:compile
> [INFO]+- org.codehaus.groovy:groovy-test-junit5:jar:2.5.0:compile
> [INFO]|  +- org.junit.platform:junit-platform-launcher:jar:1.2.0:compile
> [INFO]|  |  +- org.apiguardian:apiguardian-api:jar:1.0.0:compile
> [INFO]|  |  \-
> org.junit.platform:junit-platform-engine:jar:1.2.0:compile
> [INFO]|  | +-
> org.junit.platform:junit-platform-commons:jar:1.2.0:compile
> [INFO]|  | \- org.opentest4j:opentest4j:jar:1.1.0:compile
> [INFO]|  \- org.junit.jupiter:junit-jupiter-engine:jar:5.2.0:runtime
> [INFO]| \- org.junit.jupiter:junit-jupiter-api:jar:5.2.0:runtime
> [INFO]+- org.codehaus.groovy:groovy-testng:jar:2.5.0:compile
> [INFO]|  \- org.testng:testng:jar:6.9.10:runtime
> [INFO]| \- com.beust:jcommander:jar:1.48:runtime
> [INFO]\- org.codehaus.groovy:groovy-xml:jar:2.5.0:compile
> [INFO]
> 
> [INFO] BUILD SUCCESS
> [INFO]
> 
> [INFO] Total time: 02:47 min
> [INFO] Finished at: 2018-06-04T09:42:43+08:00
> [INFO] Final Memory: 17M/216M
> [INFO]
> 
> ```
> 
> No matter it works or not, please let me know.
> 
> Cheers,
> Daniel.Sun
> 
> 
> 
> -
> Daniel Sun
> 
> Apache Groovy committer
> 
> Blog: http://blog.sunlan.me 
> 
> Twitter: @daniel_sun 
> 
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html



--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu

Re: Availability of 2.5.0 groovy-all in Maven Central

[Daniel.Sun]

Please add `pom` and try again, here is the complete pom file:

```

http://maven.apache.org/POM/4.0.0;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0

me.sunlan
try-groovy-via-mvn
1.0-SNAPSHOT



org.codehaus.groovy
        groovy-all
2.5.0
pom



```

and here is result of `mvn dependency:tree`:
```
[INFO] me.sunlan:try-groovy-via-mvn:jar:1.0-SNAPSHOT
[INFO] \- org.codehaus.groovy:groovy-all:pom:2.5.0:compile
[INFO]+- org.codehaus.groovy:groovy:jar:2.5.0:compile
[INFO]+- org.codehaus.groovy:groovy-ant:jar:2.5.0:compile
[INFO]|  +- org.apache.ant:ant:jar:1.9.9:compile
[INFO]|  +- org.apache.ant:ant-junit:jar:1.9.9:runtime
[INFO]|  +- org.apache.ant:ant-launcher:jar:1.9.9:compile
[INFO]|  \- org.apache.ant:ant-antlr:jar:1.9.9:runtime
[INFO]+- org.codehaus.groovy:groovy-bsf:jar:2.5.0:compile
[INFO]|  +- bsf:bsf:jar:2.4.0:compile
[INFO]|  \- commons-logging:commons-logging:jar:1.2:compile
[INFO]+- org.codehaus.groovy:groovy-cli-picocli:jar:2.5.0:compile
[INFO]|  \- info.picocli:picocli:jar:3.0.2:compile
[INFO]+- org.codehaus.groovy:groovy-console:jar:2.5.0:compile
[INFO]+- org.codehaus.groovy:groovy-datetime:jar:2.5.0:compile
[INFO]+- org.codehaus.groovy:groovy-docgenerator:jar:2.5.0:compile
[INFO]|  \- com.thoughtworks.qdox:qdox:jar:1.12.1:compile
[INFO]+- org.codehaus.groovy:groovy-groovydoc:jar:2.5.0:compile
[INFO]|  \- org.codehaus.groovy:groovy-dateutil:jar:2.5.0:runtime
[INFO]+- org.codehaus.groovy:groovy-groovysh:jar:2.5.0:compile
[INFO]|  \- jline:jline:jar:2.14.6:compile
[INFO]+- org.codehaus.groovy:groovy-jmx:jar:2.5.0:compile
[INFO]+- org.codehaus.groovy:groovy-json:jar:2.5.0:compile
[INFO]+- org.codehaus.groovy:groovy-jsr223:jar:2.5.0:compile
[INFO]+- org.codehaus.groovy:groovy-macro:jar:2.5.0:compile
[INFO]+- org.codehaus.groovy:groovy-nio:jar:2.5.0:compile
[INFO]+- org.codehaus.groovy:groovy-servlet:jar:2.5.0:compile
[INFO]+- org.codehaus.groovy:groovy-sql:jar:2.5.0:compile
[INFO]+- org.codehaus.groovy:groovy-swing:jar:2.5.0:compile
[INFO]+- org.codehaus.groovy:groovy-templates:jar:2.5.0:compile
[INFO]+- org.codehaus.groovy:groovy-test:jar:2.5.0:compile
[INFO]|  \- junit:junit:jar:4.12:compile
[INFO]| \- org.hamcrest:hamcrest-core:jar:1.3:compile
[INFO]+- org.codehaus.groovy:groovy-test-junit5:jar:2.5.0:compile
[INFO]|  +- org.junit.platform:junit-platform-launcher:jar:1.2.0:compile
[INFO]|  |  +- org.apiguardian:apiguardian-api:jar:1.0.0:compile
[INFO]|  |  \-
org.junit.platform:junit-platform-engine:jar:1.2.0:compile
[INFO]|  | +-
org.junit.platform:junit-platform-commons:jar:1.2.0:compile
[INFO]|  | \- org.opentest4j:opentest4j:jar:1.1.0:compile
[INFO]|  \- org.junit.jupiter:junit-jupiter-engine:jar:5.2.0:runtime
[INFO]| \- org.junit.jupiter:junit-jupiter-api:jar:5.2.0:runtime
[INFO]+- org.codehaus.groovy:groovy-testng:jar:2.5.0:compile
[INFO]|  \- org.testng:testng:jar:6.9.10:runtime
[INFO]| \- com.beust:jcommander:jar:1.48:runtime
[INFO]\- org.codehaus.groovy:groovy-xml:jar:2.5.0:compile
[INFO]

[INFO] BUILD SUCCESS
[INFO]

[INFO] Total time: 02:47 min
[INFO] Finished at: 2018-06-04T09:42:43+08:00
[INFO] Final Memory: 17M/216M
[INFO]

```

No matter it works or not, please let me know.

Cheers,
Daniel.Sun



-
Daniel Sun

Apache Groovy committer

Blog: http://blog.sunlan.me 

Twitter: @daniel_sun 

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

Re: Availability of 2.5.0 groovy-all in Maven Central

[Mike Thomsen]

I'm running Maven 3.5.0 and it didn't resolve when I tried that POM:

[ERROR] Failed to execute goal on project try-groovy-via-mvn: Could not
resolve dependencies for project
me.sunlan:try-groovy-via-mvn:jar:1.0-SNAPSHOT: Failure to find
org.codehaus.groovy:groovy-all:jar:2.5.0 in
https://repo.maven.apache.org/maven2 was cached in the local repository,
resolution will not be reattempted until the update interval of central has
elapsed or updates are forced -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException

On Sun, Jun 3, 2018 at 8:34 PM Daniel.Sun  wrote:

> The original picture:
> 
>
> Cheers,
> Daniel.Sun
>
>
>
>
> -
> Daniel Sun
>
> Apache Groovy committer
>
> Blog: http://blog.sunlan.me
>
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>

Re: Availability of 2.5.0 groovy-all in Maven Central

[Daniel.Sun]

The original picture:
 

Cheers,
Daniel.Sun




-
Daniel Sun

Apache Groovy committer

Blog: http://blog.sunlan.me 

Twitter: @daniel_sun 

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

Re: Availability of 2.5.0 groovy-all in Maven Central

[Daniel.Sun]

Hi Robert,

   I'm using "Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-04T03:39:06+08:00)", and the following pom file works well, please
give it a try.

```

http://maven.apache.org/POM/4.0.0;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0

me.sunlan
try-groovy-via-mvn
1.0-SNAPSHOT



org.codehaus.groovy
groovy-all
2.5.0



```

<http://groovy.329449.n5.nabble.com/file/t340716/trygroovy250viamvn.png> 

Cheers,
Daniel.Sun




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

Re: Availability of 2.5.0 groovy-all in Maven Central

[Robert Stagner]

Daniel,

How should this be addressed in the POM file, for those of us using Maven
to grab groovy-all?

I tried the simple coordinates like


org.codehaus.groovy
groovy-all
2.5.0


but that did not work for me.

On Sun, Jun 3, 2018 at 8:13 AM Daniel.Sun  wrote:

> Hi Mike,
>
> FYI, http://groovy-lang.org/download.html
>
> ```
> The core plus all the modules. Also includes jarjar'ed versions of Antlr,
> ASM, Commons-CLI. In order to cater to the module system of Java 9+, only
> the individual jar files of the core and all modules will be provided since
> Groovy 2.5.0, i.e. the fat jar file groovy-all-x.y.z.jar will not be
> available. Optional dependencies are marked as optional. You may need to
> include some of the optional dependencies to use some features of Groovy,
> e.g. AntBuilder, GroovyMBeans...
> ```
>
> In short, fat jar file(i.e. groovy-all.jar) has not been provided since
> Groovy 2.5.0, but you still can use `compile
> 'org.codehaus.groovy:groovy-all:x.y.z'` to get all the individual jar
> files.
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>

Re: Availability of 2.5.0 groovy-all in Maven Central

[Daniel.Sun]

Hi Mike,

FYI, http://groovy-lang.org/download.html

```
The core plus all the modules. Also includes jarjar'ed versions of Antlr,
ASM, Commons-CLI. In order to cater to the module system of Java 9+, only
the individual jar files of the core and all modules will be provided since
Groovy 2.5.0, i.e. the fat jar file groovy-all-x.y.z.jar will not be
available. Optional dependencies are marked as optional. You may need to
include some of the optional dependencies to use some features of Groovy,
e.g. AntBuilder, GroovyMBeans...
```

In short, fat jar file(i.e. groovy-all.jar) has not been provided since
Groovy 2.5.0, but you still can use `compile
'org.codehaus.groovy:groovy-all:x.y.z'` to get all the individual jar files.

Cheers,
Daniel.Sun




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

Re: Availability of 2.5.0 groovy-all in Maven Central

[Andres Almiray]

I believe groovy-all.jar is no more. Instead we get a super POM groovy-all.pom 
that describes all individual modules. 

Sent from my primitive Tricorder

> On 3 Jun 2018, at 16:10, Mike Thomsen  wrote:
> 
> Any release date for when the groovy-all artifact will be accessible from 
> Maven Central? When I tried to upgrade to 2.5.0 and looked there, it showed 
> that the jar was not available yet.
> 
> Thanks,
> 
> Mike

Re: Why does Groovy's CliBuilder depend on apache commons-cli, which isn't included in groovy-all?

[Paul King]

The groovy-all jar doesn't bundle Groovy's optional dependencies such as:
ant, junit, bsf, commons-logging, log4j, jline, testng, xstream,
commons-cli, jansi, ivy, etc. It includes all of Groovy's modules and
embeds a small set of required dependencies for its own internal purposes
like asm and antlr and commons-cli.

This lets you write scripts or classes which also use those dependencies
directly or indirectly, e.g. hibernate uses antlr, spring uses asm and
importantly they might be different versions and that's okay.

The embedded commons-cli is used for the command-line tools (groovy,
groovyc, groovysh, groovyConsole etc.). There are other technical reasons
like classloader issues related to the approach we have taken but mostly
it's a separation of concerns issue. We might change what cli handling
package we use internally and we might supply different modules which offer
different CliBuilder implementations which might have different
dependencies. We don't want to tie all these things together. Technically,
you can use the groovyjarjarcommonscli package if you want direct access to
the commons-cli library though it's not recommended and it's not possible
via CliBuilder - it is specifically designed not to use the internal one.
In the future with JDK9/10+ we will likely not make such embedded packages
visible at all.

Long story short, add the commons-cli dependency to your project and/or
classpath. That's the correct approach.

Cheers, Paul.


On Fri, Mar 30, 2018 at 1:02 AM, Nick <oinksoc...@letterboxes.org> wrote:

> Hello,
>
> I asked a question on stack overflow, I wonder if anyone here knows the
> answer?
>
> https://stackoverflow.com/questions/49452422/why-does-groovy
> s-clibuilder-depend-on-apache-commons-cli-which-isnt-included
>
> To quote it:
>
> > I've been attempting to use the Groovy CliBuilder, as described here:
> >
> > http://docs.groovy-lang.org/2.4.7/html/gapi/groovy/util/CliBuilder.html
> >
> > However, it depends on classes missing from groovy-all-2.4.7,
> specifically those in Apache's commons-cli library.
> >
> > Ok, so I could add that dependency. But I find there is what looks like
> a version of the Apache CliBuilder class bundled in groovy-all in the
> groovyjarjarcommonscli package!
> >
> > Firstly, why bundle that at all?
> >
> > Secondly, why not use it to back Groovy's CliBuilder implementation?
> >
> > Thirdly, can I rely groovyjarjarcommonscli being there for use in the
> future?
>
>
> Thanks!
>
> Nick
>
>

Why does Groovy's CliBuilder depend on apache commons-cli, which isn't included in groovy-all?

[Nick]

Hello,

I asked a question on stack overflow, I wonder if anyone here knows the 
answer?


https://stackoverflow.com/questions/49452422/why-does-groovys-clibuilder-depend-on-apache-commons-cli-which-isnt-included

To quote it:

> I've been attempting to use the Groovy CliBuilder, as described here:
>
> http://docs.groovy-lang.org/2.4.7/html/gapi/groovy/util/CliBuilder.html
>
> However, it depends on classes missing from groovy-all-2.4.7, 
specifically those in Apache's commons-cli library.

>
> Ok, so I could add that dependency. But I find there is what looks 
like a version of the Apache CliBuilder class bundled in groovy-all in 
the groovyjarjarcommonscli package!

>
> Firstly, why bundle that at all?
>
> Secondly, why not use it to back Groovy's CliBuilder implementation?
>
> Thirdly, can I rely groovyjarjarcommonscli being there for use in the 
future?



Thanks!

Nick

groovy vs groovy-all in dependencies

[Schalk Cronjé]

Hi all,

In http://groovy-lang.org/download.html there is a section about adding 
dependencies, which distinguishes between use of groovy and groovy-all. 
There are many long-time users, including myself, who use groovy-all, 
because it is very convenient, yet it is probably not the best solution 
in many cases. I am wondering whether we should just extend that section 
with some recommendation when to use which dependency.



Maybe the section should also highlight what to do when both groovy-all 
and groovy appears in the graph of transitive dependencies.



What do you think?

-- Schalk

Trying to understand why groovydoc task needs groovy-all in Gradle 2.13 / 2.14

[Mario Garcia]

I'm trying to execute a project using gradle 2.13 / 2.14 and it fails when
executing groovydoc saying:

groovydoc doesn't support the "noTimestamp" attribute

Checking gradle documentation it's saying you should be using groovy-all,
but sometimes I may not want to use the whole groovy-all jar.

Does anyone know why is this ? Is this a Gradle bug, it's something that
changed in groovydoc ?

Mario