On 06/21/2016 10:39 PM, Jochen Theodorou wrote:
On 21.06.2016 09:04, Mr Andersson wrote:
Gmaven or Gmaven 2 did not work for me either. Resulted in a bunch of
compilation issues which I started to correct, but then gave up on. I
shouldn't have to change my code to get on Groovy.
yeah, forget about those... gmavenplus is supposed to work. If that
one does not do the job, then there is a problem
[...]
Plus have you seen the size of this examples page?
https://github.com/groovy/GMavenPlus/wiki/Examples
Fifty ways to configure. I don't even know anything about what I need
when i start off, so that's just too much headache.
you wanted joint compilation, so go to
https://github.com/groovy/GMavenPlus/wiki/Examples#joint-compilation
and hopefully be done.
Did not work :(
The ant task for me is good enough.
well, then everything is almost fine ;)
[...]
command line is even more simple ;)
Not easy to integrate a command line argument for maven it seems. I am
not sure how you can add that to the classpath. I was trying really hard
on that but could not find any info, like with everything involving
searching for Java issues. Google sucks at this, or the Java folks
seriously do not ask or think enough about doing things the right way.
https://www.google.pl/search?q=adding+to+maven+classpath&oq=adding+to+maven+classpath&aqs=chrome..69i57j0l5.10311j0j7&sourceid=chrome&es_sm=93&ie=UTF-8
Yes, you are right.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<id>groovyc-compile</id>
<phase>compile</phase>
<configuration>
<target>
<taskdef name="groovyc"
classname="org.codehaus.groovy.ant.Groovyc">
<classpath refid="maven.compile.classpath"/>
</taskdef>
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>This seems to be enough and built successfully. Great! Even
simpler! If only I could pass a compilesStatic flag too. But I guess I
could put the classpath to a global config file for now. But Groovy
should consider adding such a flag alternatively provide a jar that has
this option turned on. It will bring back Groovy++ and that's defintely
desirable. I love Groovy and it's closeness to the java syntax and it's
much better interop with Java and have been resisting a switch to Scala
and Kotlin because you have to use ugly syntax to access from Java their
logic. With Groovy it is basically Java. Groovy adds so much to Java and
should really have an option to go static.
I think the maven structure is not really made for executing command
line commands... you could always use the ant runner to do that kind
of thing of course, but then why use maven at all.
In constract, pulling in Scala and Kotlin ( during the process
which I gave up on Groovy ) took seconds.
well, there are some maven people, here only very few
Groovy has been alive for over 10 years. It has to be a couple of
people wanting to integrate Groovy in a JEE environment by now.
maven works best if you follow the maven conventions and the very few
maven projects I had to do with really tried to follow that.
And I doubting the procedure is different for gradle.
give it a try. But it has its quirks too as well of course. For
example if you have files in src/main/java and in src/main/groovy, the
groovy plugin will not do joint compilation for the files in
src/main/java. You can easily change that by
sourceSets.main.java.srcDirs = [] sourceSets.main.groovy.srcDirs +=
["src/main/java"] or use a totally different folder.... or multiple
folders. ant is more direct in that you will always have to supply
that information anyway. if that is more easy or not, I don´t know.
But I have seen some pretty complex builds and most of them I really
would not like to do with ant I must say.
Relying on the Eclipse compiler is not a good thing as it has a
history of breaking and not being up to date with any other
compiler that one might wish to use.
Which is why the page suggests gmavenplus for maven... maybe that
should be more clear
Did not work with both. The ant task should be the one mentioned
because it will always succeed, unless you can figure how to add it
to the classpath.
Most important is that you got something working. Granted, it took too
long and longer than it should have, and that is the fault of our
documentation. Which brings me to the point of asking you what you
would suggest how we should change our documentation so the next one
will not have to do so much fighting.
Add the ant option at the top. Gmavenplus did not work for me when I
tried the join compilation option.
[...]
I am not sure what it means that you always compile all files. I
haven't tried it enough but besides a 15 seconds extra build time, i
don't see much difference in repetition.
It means, that if you change one class, you will compile all of them
and live with the build overhead. If you have several hundred files to
compile, this will add up during development and testing.
For intellij this doesn't seem to happen, no major build is happening,
maybe a slightly bigger one but barely noticable.
compared with eclipse groovy plugin: * stubs cannot compile as many
scenarios as the integrated approach of the eclipse groovy compiler
* not really integrated in maven, thus you always compile all files
I am working on a new compiler tool for Groovy, which is supposed to
have less of those disadvantages, for which I will then also look
for more proper maven integration (I am hoping here on the help of
gmaven plus). But that is still in the future and no fast project,
because my free time is limited
It should be simple, one plugin declaration with all configuration
right there, and work.
agreed.. though will only if you follow the conventions for maven,
because any different way will require additional configuration.. but
I guess that is clear already bye Jochen
