Since GMaven has been discontinued, I have been using Groovy-Eclipse Compiler plugin on my Maven projects. The version I used is 2.8.0-01 and I specifically used Groovy 2.1. I know 2.9.0-01-SNAPSHOT has been out for the longest time, but there's no ETA when it will be officially released.
My question here is... can I use safely use version 2.8.0-01 with Groovy 2.3.5 without potential side effects?
Thanks.
Since there is no groovy-eclipse-batch 2.3.5 you can not use it with any version of groovy-eclipse-compiler.
Probably there won't be a 2.3.5 of groovy-eclipse-batch ever, since groovy 2.3.6 has already been released. Once the 2.3.6 compiler is ported to greclipse, we will put out a release of the groovy-eclipse-batch artefact to maven central that is compatible with groovy-eclipsec-compiler 2.9.0 (which has recently been released)
Right now, the latest groovy-eclipse-batch you can use is 2.3.4-01 and it is compatible with the released version of groovy-eclipse-compiler 2.9.0-01.
For the latest released artefacts see:
http://search.maven.org/#search|ga|1|groovy-eclipse-batch
http://search.maven.org/#search|ga|1|groovy-eclipse-compiler
I don't think you can. Groovy-Eclipse adopts new versions of Groovy. In fact Groovy-Eclipe includes support for various versions of Groovy it supports. For each supported version of Groovy there will be a corresponding feature available from the update site. Groovy-Eclipse 2.9.0 has suppoort for Groovy 2.3.x and you'd have more luck with Groovy 2.3.5 with that version of Groovy-Eclipse.
There is some sort of a problem with Groovy 2.3.5 release, hence I'd recommend 2.3.6, which should be out now. Groovy-Eclipse support for Groovy 2.3.6 should be in very soon, hence I'd recommend to install Groovy-Eclipse from this update site at the end of the week: http://dist.springsource.org/snapshot/GRECLIPSE/e4.4
I was in the same situation as you with GMaven, switched to the Groovy-Eclipse, but note that there is a replacement for GMaven now, GMavenPlus, which works very much like the original GMaven, and I've switched back.
I was using 2.1, but wanted to upgrade to 2.3 because there were inconsistencies where groovyc would compile code using #CompileStatic while Groovy-Eclipse would give an error. The Groovy-Eclipse compiler had the advantage that it can compile Java and Groovy without stubs. The main advantage with GMavenPlus is that it compiles with the standard Groovy compiler of any version you want and also supports indy.
If Groovy-Eclipse is more important, the existing answers are all right. If using the version of Groovy you want and frequent upgrades is more important, then consider GMavenPlus.
Related
I am trying to configure PMD into a legacy application that needs to run in java 1.6 (this is mandatory). I am trying to find a version of pmd-plugin that was build at least again java 1.6. If I use maven-pmd-plugin it complains not being binary compatible with jre 1.6.
The problem is older version of PMD net.sourceforge.pmd seems to be ignored and maven-pmd-plugin:3.8 always run instead no matter the version I use.
Now I am trying with no lucky with this.
<dependency>
<groupId>net.sourceforge.pmd</groupId>
<artifactId>pmd</artifactId>
<version>5.0.0</version>
</dependency>
The latest PMD release to be compiled against Java 6 was PMD 5.4.6. (last of the 5.4.x branch). Ever since 5.5.0 PMD has required Java 7.
You can tell the Maven plugin to use whichever version of PMD you require by setting it's dependencies explicitly.
You can see the docs on how to do so here
Is Ant 1.9.4 compatible with Java 1.8?
The ant documentation is not very clear: it just says that it is compatible with a minimum version of Java 1.5.
How can I be sure that it is compatible with java 1.8?
Thank you!
This Ant Java Version Table indicates that ant 1.9.x needs a minimum version of 1.5. As Java takes great pains to maintain backwards compatibility, it would be extraordinary for an incompatibility to occur. Ant 1.10 requires Java 1.8.
We have been running 1.9.6 for many months with Java 8 without issue.
Taken from here
We recommend using 1.10.x unless you are required to use versions of Java prior to Java8 during the build process
To me this reads as not supported and might suddenly break.
I'm maintaining a parent pom for my team which will provide the latest compatible version of various maven plugins per the JDK that the project uses. Sometimes if a project utilizes an older version of Java (like 1.5) maven will fail due to a plugin requiring a newer version. Is there a way to get a map of a given plugin and see what the minimum java version is for said plugin? I was thinking there was some sort of report or something that would show me that, but I'm not seeing anything.
What about: https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/dist-tool-prerequisites.html Apart from that on every plugin page you can find the goals page which contains the information you need. One more thing if you are using not the most uptodate versions all older versions pages are available where you can look at which version which JDK versions uses. It shouldn't be problem to write some kind of script to programmatically extract the information of the older plugins. The above site contains the informations of the uptodate plugins.
Apart from that plugin version selection basead on JDK version is not a good idea. The plugins have only a minimum version for JDK they need to run with. Apart from that they run on all versions (already on JDK 9 with one exception)...Furthermore plugins might require a minimum Maven version to run with which is either Maven 2.2.1 or Maven 3.0+ which shouldn't a problem.
You should define your plugins versions simply based on problems you might have but i would recommend to keep uptodate with your plugins.
If you need running you build with JDK 6 for example, but you use Maven 3.3.X which needs JDK 7 to run you can achieve this by using toolchain to handle this situation.
In theory this shouldn't be an issue. Maven will use the Java version you run it with, so the plugin's dependency will be satisfied, independent of the project's language level. Just make sure your devs are using a current version.
Example: running Maven with Java 8 will satisfy the dependency of a Plugin that requires Java 8, independent of the project's source and target level.
(With dependencies it's more complicated, I am afraid, but since you are not actually coding against your plugins, you should be fine)
I have Spring Tool Suite 3.6.1, which is based on Eclipse 4.4.
I installed the version of Grails I need, but I noticed that the Groovy compiler is at 2.3, whereas I need it to be at 1.8.
I've gone to dist.springsource.org on the Eclipse Marketplace to look for the Compiler 1.8. I can install it, but it automatically uninstalls the existing Grails IDE. On top of that, it doesn't appear under Preferences - Groovy - Compiler and I don't seem to be able to select it.
What am I doing wrong? Do I need to use an earlier version of the Spring Tool Suite to access this particular compiler?
I'd recommend using the snapshot update site to get the latest groovy-eclipse: http://dist.springsource.org/snapshot/GRECLIPSE/e4.4/
That includes the 1.8 compiler and the latest groovy-eclipse 2.9.1 builds that work with it - the 2.9.0 release had trouble with groovy 1.8. (But 1.8 is getting quite old now so we may drop support in the not too distant future).
That snapshot build should also be compatible with grails-ide, not sure why it would be uninstalling grails-ide (but remember that grails-ide is different to the grails-runtime - have you definitely installed both from the dashboard extensions page or just the runtime?)
I'm writing testing library with my own junit runner. it extends BlockJUnit4ClassRunner which is available since 4.5 till... who knows. user of my library should be able to choose whatever junit version (with BlockJUnit4ClassRunner of course). and i don't know how to define dependency on junit (let's say current version is 4.10).
if i make [4.5, 4.10] provided, then i have to release new version with every junit release
i'm not sure if [4.5, ) is good a good practise because it implicitly chooses the newest version and build may not be repeatable
e.g. mockito uses ant and junit 4.10 only for compilation and have no maven dependency on it. i also don't know if it's a good practice.
how should i solve this dependency problem
In general, JUnit releases are backward compatible[*]. The developers take great care so that they are backward compatible. One option would be to declare a dependency on JUnit 4.5, and then the user can override that version in their pom (with version 4.10), and it should still work.
If you're doing the above and claiming that it works with all versions after 4.5, then you should be testing with all versions as well, which should be reasonably easy to do.
[*] Classes and methods are deprecated of course, but things should still work.
In case you always want to stick to the latest version of junit then use
<version>LATEST</version>
The above will always refer to the latest released or snapshot version of junit.
If you use
<version>RELEASE</version>
then it'll refer to the last released/non-snapshot version present in the repository.
Also there is no issue in declaring an open-ended version range which will include the latest version after x.y.z, i.e.
<version>[x.y.z,)</version>
But things turn sour when there may happen API level changes in the junit world that are incompatible with your artifact. In that sense, it's better to provide an exact version and mandate the client to follow the same.
The problem with the version markers LATEST and RELEASE they are only supported by Maven 2.2.1 and before but no longer for Maven 3. So the thing is to avoid them.
Furthermore if you define your dependency to JUnit as provided users can use a different version instead of the defined version.