Also the usage page <https://github.com/groovy/GMavenPlus/wiki/Usage> has the two most common ways GMavenPlus is used.
-Keegan On Tue, Jun 21, 2016 at 8:31 AM, Winnebeck, Jason < jason.winneb...@windstream.com> wrote: > You are trying to do joint compilation so this is the only section you > need: > https://github.com/groovy/GMavenPlus/wiki/Examples#joint-compilation > > The only difference from pure Groovy compile and joint compilation is you > list the stub tasks to the goals. Basically all you do is add the > gmavenplus-plugin and Groovy as a dependency. > > Jason > > -----Original Message----- > From: Mr Andersson [mailto:mr.andersson....@gmail.com] > Sent: Tuesday, June 21, 2016 3:04 AM > To: users@groovy.apache.org > Subject: Re: Integrating Groovy with a Java EE application and Maven > > 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. > > I don't remember the exact errors, but there were some. > > I just tried again and it failed. I tried the join compilation but failed. > Files were not recognized. > > 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. > > The ant task for me is good enough. > > See comments below. > > On 06/19/2016 02:09 PM, Jochen Theodorou wrote: > > On 18.06.2016 20:12, Mr Andersson wrote: > >> I was able to get it to work, both as separate groovy and java > >> directories and as one directory ( basically a groovy directory with > >> mixed ). > >> > >> It is interesting how complex this task was. It would appear as if > >> the Groovy community should have figured this out by now. > > > > From the project side we support an ant task, command line and a > > programmatic way to do joint compilation. The task is complex because > > the build tools and the scenarios are. Gradle has much better support > > for Groovy because we use it for our own build, but most of all, > > because the Gradle people care. > > > >> I finally ( after 10 hours ) was able to get it to work, using only ANT. > >> The question is why Gmaven, GMaven2 Eclipse maven, and what not is > >> even mentioned when it is as simple as an ANT task. > > > > 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 > > > > >> 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. > > And I doubting the procedure is different for gradle. > > > >> 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. > > > > >> The solution ( note that I change some other things as well, like I > >> don't use src/main/java but just src ): > >> > >> <properties> > >> <java.version>1.8</java.version> > >> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> > >> <org.springframework.version>4.0.6.RELEASE</org.springframework.version> > >> > >> <skipTests>true</skipTests> > >> <maven.test.skip>true</maven.test.skip> > >> > >> <myproject.src>${basedir}/src</myproject.src> > >> <myproject.test>${basedir}/test</myproject.test> > >> > <myproject.srcOutput>${project.build.directory}/WEB-INF/classes</myproject.srcOutput> > >> > <myproject.testOutput>${project.build.directory}/WEB-INF/classes</myproject.testOutput> > >> </properties> > >> > >> > >> <sourceDirectory>${myproject.src}</sourceDirectory> > >> <testSourceDirectory>${myproject.src}</testSourceDirectory> > >> > >> <!-- This is an important part, especially in development mode, where we > >> treat the compiled output the same as when served through a container, > >> we place in a /WEB-INF/classes/ directory, \ rather than the default > >> /classes/ allowing us to have consistent resources lookup through out > >> all environments --> > >> <outputDirectory>${myproject.srcOutput}</outputDirectory> > >> <testOutputDirectory>${myproject.srcOutput}</testOutputDirectory > >> > >> > >> <plugin> > >> <inherited>true</inherited> > >> <groupId>org.apache.maven.plugins</groupId> > >> <artifactId>maven-compiler-plugin</artifactId> > >> <version>3.5.1</version> > >> <configuration> > >> <source>${java.version}</source> > >> <target>${java.version}</target> > >> > >> <!-- See: > >> > http://stackoverflow.com/questions/17944108/maven-compiler-plugin-always-detecting-a-set-of-sources-as-stale > >> > >> --> <useIncrementalCompilation>false</useIncrementalCompilation> > >> </configuration> > >> > >> <executions> > >> <execution> > >> <id>default-compile</id> > >> <phase>none</phase> > >> </execution> > >> </executions> > >> </plugin> <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> > >> > >> <mkdir dir="${myproject.src}"/> > >> <mkdir dir="${myproject.srcOutput}"/> > >> <groovyc destdir="${myproject.srcOutput}" > >> srcdir="${myproject.src}" listfiles="true"> > >> <classpath refid="maven.compile.classpath"/> > >> <src> > >> <pathelement path="${myproject.src}" /> > >> </src> > >> > >> <javac source="1.8" target="1.8" debug="on" > >> encoding="UTF-8"/> > >> </groovyc> > >> > >> </target> > >> </configuration> > >> <goals> > >> <goal>run</goal> > >> </goals> > >> </execution> > >> </executions> > >> </plugin> > > > > I see, good to have that here. Now what are the main cons with this? > > > > compared with gmaven plus: > > * not really integrated in maven, thus you always compile all files > > 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. > > > > > 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 > > > > bye Jochen > > > > It should be simple, one plugin declaration with all configuration right > there, and work. > > ---------------------------------------------------------------------- > This email message and any attachments are for the sole use of the > intended recipient(s). Any unauthorized review, use, disclosure or > distribution is prohibited. If you are not the intended recipient, please > contact the sender by reply email and destroy all copies of the original > message and any attachments. >
