groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Champeau <cchamp...@apache.org>
Subject Re: Integrating Groovy with a Java EE application and Maven
Date Wed, 22 Jun 2016 08:30:18 GMT
You should really give Gradle a try. It's pretty straightforward.
Le 21 juin 2016 23:40, "Mr Andersson" <mr.andersson.002@gmail.com> a écrit :

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

Mime
View raw message