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
Hi there,
> On 16 May 2020, at 2:41, Paul King wrote:
> I'd suggest creating an issue for this. We might be able to improve Groovy or
> if not we should assess whether the current doco around safe indexing
> explains possible interactions well enough.
GROOVY-9561
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
>
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.
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
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
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
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
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
>
> 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
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,
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
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
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
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
There's another thing I'd like to ask for a help with.
Some of my groovy sources are actually pre-processed (in a way remotely similar
to the well-known CPP, i.e., before groovyc is called, a temporary groovy
source is generated from one or more original sources; it's the generated temp
file
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
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
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
Groovy is all geared up to make it easy for you to do whatever
pre-processing you might like as an AST transform and in that scenario it
automatically corrects line numbering as needed (your AST transform may
have to play its part in making that work). So, in that scenario you'd move
whatever you
20 matches
Mail list logo