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, an
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 Grad
po (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>
27;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: *"user
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 use
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 nothi
y.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
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
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
> *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 exte
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
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 an
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 bui
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
> al
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 w
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
, 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:
> 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
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
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.
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
previ
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 poss
t; 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>"
&g
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
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/groov
25 matches
Mail list logo
