Problem encounter during the POM processing from travis build

[asellappen]

Problem summary :-

I am working for IBM to port ppc64le arch to the package fuse ,I am adding new travis.yml for auto build and test ,during this process i am using the below yml script ,

language: java
arch:
    - amd64
    - ppc64le

dist: bionic

script: 
 # - mvn -Pall -Dts.all clean install
   - mvn -Pamq clean install

jdk:
  - openjdk8
  - openjdk11
  - openjdk14

Issue:
failing travis job in intel and power arch with the below error.It look some problem with POM file ,Can you help to fix

[ERROR] [ERROR] Some problems were encountered while processing the POMs:
136[FATAL] Non-resolvable parent POM for org.jboss.fuse.bom:jboss-fuse-parent:6.3.0.redhat-SNAPSHOT: Could not find artifact io.fabric8.bom:fabric8-bom:pom:1.2.0.redhat-630267 in central (https://repo.maven.apache.org/maven2) and 'parent.relativePath' points at wrong local POM @ line 22, column 13

ref:https://travis-ci.com/github/asellappen/fuse/jobs/469799864

[gaughan]

Hi asellappen, 6.3 is an older version of Fuse, 7.x is the latest. Can you connect with us internally to discuss your plan or approach here?

[grgrzybek]

That's interesting... This is old version of Fuse (Fuse 6). Why would someone want "to port ppc64le arch" to Fuse? Fuse is Java application server based on OSGi, running on JDK.

[asellappen]

Thanks for taking up the issue.

sorry ,the default branch at github is 6.3.0redhat and have cloned from there to port ppc64le to my local.
now i have tried from master also and still seeing the same error.

The background for porting ppc64le is , I am working for IBM to port cpu arch ppc64le for open sources.

working to support for the IBM Power Little Endian (ppc64le) architecture for open source projects. The idea is to ensure that the builds on ppc architecture are continuously tested along with the Intel builds (amd64) as this is part of the ubuntu distro on that architecture as well and detecting (and fixing) any issues or failures early would help to ensure that we are always up to date.

This helps us simplify testing later when distributions are re-building and re-releasing,We typically build applications for customers and ISVs, and while we don't use this package directly, we do count on all of the packages in debian/ubuntu to build other packages. So we more likely have this as a second or third level dependency and couldn't tell you explicitly which features we use or our usage model.

hope this helps to clear your concerns.