You should really give Gradle a try. It's pretty straightforward. Le 21 juin 2016 23:40, "Mr Andersson" <[email protected]> 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 > >
