|Status:||Removed||Start date:||May 08, 2017|
|Sprint:||gCube Release 4.5.0 - gCore|
|Wiki Updates:||Version Control System:|
|Type:||Common Apps||Building System:|
The last build fails: http://eticsbuild2.research-infrastructures.eu/BuildReport/bdownload/AllBuilds/org.gcube.4-5-0/BUILD_5/reports/reportModuleDetail-org.gcube.common.tscharts-datamodel.html due to the wrong source version in the maven confgiuration.
The solution is :
- to force the target version to 1.8 and source to 1.7 (as suggested in the wiki documentation : https://wiki.gcube-system.org/gcube/Developing_gCube_Maven_Components#Java_Version).
- to remove target from the maven configuration (target will be provided in automatic way).
I assign to @email@example.com because Daniele Strollo is missig from Assignee.
Thank you Maria.
#3 Updated by Maria Di Girolamo over 2 years ago
The last build fails (http://eticsbuild2.research-infrastructures.eu/BuildReport/bdownload/AllBuilds/org.gcube.4-5-0-gcore/BUILD_29/reports/reportModuleDetail-org.gcube.common.tscharts-datamodel.html) :
"[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project tschartdatamodel: Fatal error compiling: invalid target release: 1.8 -> [Help 1]
Please, could you replace the 1.8 version with the 1.7 version :
#5 Updated by Maria Di Girolamo over 2 years ago
This configuration continues fails due to the same error as reported in my previous comment.
I apologize but this configuration will be not integrated in this release, because today the release must be closed.
I'm going to integrate the previous version for this component and execute a local build.
The new configuration will be integrated in the next release.
@firstname.lastname@example.org , @email@example.com , @firstname.lastname@example.org (as release/subsystem/deployer and infrastructure ) what do you think about this decision? Is it possible post-poned the integration of the new configuration for this component? ( I note that no dependant component exist, so integration for it to the previous version should not be a problem for it)
#6 Updated by Gabriele Giammatteo over 2 years ago
the difference between the configurations 1-1-1 and 1-1-1-1 seems to be exactly in the fact that 1-1-1-1 sets the compiler target to 1.8 in the pom.xml while in 1-1-1 it was set to 1.7, so it is correct to use version 1-1-1 in the gCore release (Java 7-based).
Probably, the confusion comes also from the fact that a bad versioning has been chosen. In fact, since the new configuration (1-1-1-1) has a change in the code (pom.xml) we should have incremented the version to 1.1.2. As convention, age number is incremented only for changes in the ETICS fields of the configuration when the source code is the same.
However, for me have two different version is not the best solution. If the code compiles fine both with Java 7 and Java 8, why do we explicitly set the target version in the pom.xml? It forces use to release two different versions of the component for the gCore and Smartgears releases, while if the pom.xml would not set explicitly the target, we could use the same version for both releases (and the target is inherited from the build environment)...