Gradle sourceCompatibility has no effect to subprojects(转)
2016-01-13 11:11
316 查看
I have Java 6 and 7 installed on my machine. Gradle uses 1.7 (checked using
So I added the following line to my build file (on the root level, not in any closure):
(to be sure I also added the
To check whether the result was actually compatible with 1.6 I unzipped the resulting jar,
Afaik this means it is Java 1.7 Bytecode, which is wrong.
Any ideas why the
UPDATE: Yes, this is actually a multi-project build but I only checked one of the subprojects' build results. In this subproject's build file I made the mentioned changes to be sure they are actually applied. In addition, I added the following in the root project's build file (as @Vidya proposed as well):
But this didn't help either.
UPDATE 2: I checked the setting of sourceCompatibility with this snippet in the relevant build.gradle files:
It revealed that my sourceCompatibility is set to 1.7 although I tried to set it to 1.6. When I extracted the simplest subproject and built in on its own the sourceCompatibility is set correctly and the Java Byte code is compatible to 1.6. However, even this sub-project uses the wrong sourceCompatibility when used in the multi project build.
BTW: The plugins I use in some of the sub projects are:
UPDATE 3: I changed the built scripts to just use the java plugin (and thus just construct some jars) and removed the usage of the
I don't see how any of that would affect the sourceCompatibility setting.
http://stackoverflow.com/questions/21028438/gradle-sourcecompatibility-has-no-effect-to-subprojects
gradle -v). But I need to compile my code to be compatible with Java 1.6. As far as I understand the documentation I can use the
sourceCompatibilityproperty to do so (and indirectly the
targetCompatibilitywhich defaults to the
sourceCompatibility).
So I added the following line to my build file (on the root level, not in any closure):
sourceCompatibility = 1.6
(to be sure I also added the
targetCompatibility = 1.6in some trials, but that should not make a difference)
To check whether the result was actually compatible with 1.6 I unzipped the resulting jar,
cdinto the
WEB-INF/classesfolder and used
javap -verboseon the first
.classfile I encountered. But no matter whether I set the target compatibility or whether I used 1.5 instead of 1.6 or whether I specified it as string (
'1.6'), each time the result of javap was
minor version: 0 major version: 51
Afaik this means it is Java 1.7 Bytecode, which is wrong.
Any ideas why the
sourceCompatibility-setting doesn't work? Or is
javapnot the correct way to check the compatibility?
UPDATE: Yes, this is actually a multi-project build but I only checked one of the subprojects' build results. In this subproject's build file I made the mentioned changes to be sure they are actually applied. In addition, I added the following in the root project's build file (as @Vidya proposed as well):
allprojects { sourceCompatibility = 1.6 targetCompatibility = 1.6 }
But this didn't help either.
UPDATE 2: I checked the setting of sourceCompatibility with this snippet in the relevant build.gradle files:
compileJava.doFirst { println "source compatibility " + sourceCompatibility }
It revealed that my sourceCompatibility is set to 1.7 although I tried to set it to 1.6. When I extracted the simplest subproject and built in on its own the sourceCompatibility is set correctly and the Java Byte code is compatible to 1.6. However, even this sub-project uses the wrong sourceCompatibility when used in the multi project build.
BTW: The plugins I use in some of the sub projects are:
java,
war,
jetty,
gwt
UPDATE 3: I changed the built scripts to just use the java plugin (and thus just construct some jars) and removed the usage of the
war,
jettyand
gwtplugin. But still all the projects are set to sourceCompatibility 1.7 despite me setting it in the
allprojectssection and in some of the sub projects. All that is left now in the build scripts is the declaration of some decencies (maven, files and other sub projects), the declaration of the repositories to use, the declaration of some others tasks (that the build-task does not depend on, so it shouldn't be affected) and the configuration of the manifest file for the created jar files (I add a specification and an implementation version and title to the manifest file).
I don't see how any of that would affect the sourceCompatibility setting.
http://stackoverflow.com/questions/21028438/gradle-sourcecompatibility-has-no-effect-to-subprojects
相关文章推荐
- jquery中$("#afui").get(0)为什么要加get(0)呢?
- YUI Compressor 压缩 JavaScript 原理-《转载》
- Google Protocol Buffer 的使用和原理
- 网页加入HTML5时钟的快捷方式
- JS table form 序列化提交
- [转]设定version 更新js缓存
- FreeMarker常用标签介绍(Html,Jsp)
- 1823: [JSOI2010]满汉全席 2-SAT
- angular js模型
- css3 实现圆角边框的border-radius属性和实现阴影效果的box-shadow属性
- doT.js详细介绍
- javascript学习笔记
- extjs4 分页工具栏pagingtoolbar的每页显示数据combobox下拉框
- HTML常用标签及其全称
- js弹出框、对话框、提示框、弹窗总结
- CSS 样式修改 积累
- WOW.js – 让页面滚动更有趣
- TabHost(系统自带样式)
- 从$('li').filter(':even').css('background-color', 'red');说起
- jQuery EasyUI使用教程之添加排序