Release #8661

Release #8213: gCube Release 4.5.0 - gCore

Release #8391: org.gcube.common.4-5-0-gcore


Added by Maria Di Girolamo over 2 years ago. Updated over 2 years ago.

Status:RemovedStart date:May 08, 2017
Priority:ImmediateDue date:
Assignee:Francesco Mangiacrapa
Sprint:gCube Release 4.5.0 - gCore
Wiki Updates: Version Control System:
Type:Common Apps Building System:


The last build fails: 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 :
- to remove target from the maven configuration (target will be provided in automatic way).

I assign to because Daniele Strollo is missig from Assignee.

Thank you Maria.

Related issues

Copied from gCube - Release #8417: org.gcube.common.ts-charts-datamodel.1-1-1-1 Released May 08, 2017


#1 Updated by Maria Di Girolamo over 2 years ago

  • Copied from Release #8417: org.gcube.common.ts-charts-datamodel.1-1-1-1 added

#2 Updated by Maria Di Girolamo over 2 years ago

  • Parent task changed from #8213 to #8391

#3 Updated by Maria Di Girolamo over 2 years ago

The last build fails ( :
"[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 :

#4 Updated by Maria Di Girolamo over 2 years ago

  • Priority changed from Normal to Immediate
  • Status changed from Under Integration to Build Issue

#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. , , (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)...

#7 Updated by Maria Di Girolamo over 2 years ago

  • Status changed from Build Issue to Removed

Thank you, Gabriele for your clarification.

Also available in: Atom PDF