oasp/oasp4j#551: added new BOM and structure

[hohwille]

Here is my PR for https://github.com/oasp/oasp4j/issues/551.

[hohwille]

Can someone help me out what travis is doing wrong here? I cleaned my local repo and can still not reproduce this. Maybe a broken maven version on travis side? I verified module order and it can not be the problem: https://github.com/hohwille/oasp4j/blob/83c31bdc5b52aad53dc4661398e76fab910049f3/boms/pom.xml#L16

[hohwille]

I resolved our merge conflict issue. Now we are back at our travis error. As it seems that travis error comes from the fact that we now have two BOMs and the one BOM depends on the other. Maven does resolve a BOM (POM with import scope) when building the reactor what happens before anything (the minimal BOM that is imported) has actually been installed. We could workaround this by hacking travis.yml so that these are pre-installed with "mvn install -N" but IMHO we should first discuss if there are cleaner solutions for this avoiding such hacks.

[hohwille]

I digged deeper and even cleaned my local m2 repo and started the build exactly like travis is doing (mvn install -DskipTests=true -Dmaven.javadoc.skip=true -B -V) but can not reproduce the error locally. My assumption is that the error is a bug present in maven 3.2.5 (used by travis) that is already fixed in my local version of maven. I can try to downgrade my local maven to 3.2.5 to verify.

[hohwille]

I also cannot reproduce the error with maven 3.2.5 locally. So travis does something rather strange here. Maybe a very odd settings.xml.

[hohwille]

So I ensured that the build order in maven should actually first build and install the minimal bom and then the regular one: https://github.com/hohwille/oasp4j/blob/83c31bdc5b52aad53dc4661398e76fab910049f3/boms/pom.xml#L16 For some strange reason however travis does not install the minimal bom and tries to download it for using it for the import in the regular bom. As this errors shows up even before the maven reactor is build it is hard to trace down the issue any further and the logs do not tell enough detail.

[hohwille]

Debugging travis does not work either: https://docs.travis-ci.com/user/running-build-in-debug-mode/ I used my correct API token and put in the proper job ID but I do get "permission denied".

[hohwille]

I usually like travis very much for its simplicity. In such situations you see the drawback of that approach.

[hohwille]

So actually travis ignores our .travis.yml config or what? Come on give me a chance.

[hohwille]

If someone has linux or win10 he could assist by running travis locally in docker and doing some debugging: https://docs.travis-ci.com/user/common-build-problems/#Troubleshooting-Locally-in-a-Docker-Image

[hohwille]

Any travis expert that can assist here? Travis is a complete mess in this case.

$ jdk_switcher use oraclejdk7
Switching to Oracle JDK7 (java-7-oracle), JAVA_HOME will be set to /usr/lib/jvm/java-7-oracle
update-java-alternatives: directory does not exist: /usr/lib/jvm/java-7-oracle

OK. As it seems trusty does not support jdk7 (anymore).

[hohwille]

Hardcoded setup in travis already causes the error: https://docs.travis-ci.com/user/languages/java/#Maven-Dependency-Management

[hohwille]

It really starts to get ridiculous...

[hohwille]

Okay. With ugly hacking I somehow made it. Do we want to upgrade to trusty and jdk8 with this PR (that should go into 2.6.1 bugfix release)? Or would I port this back to precise and jdk7 (if possible)?

[hohwille]

[ERROR] Plugin org.codehaus.mojo:flatten-maven-plugin:1.0.0 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.codehaus.mojo:flatten-maven-plugin:jar:1.0.0: Could not transfer artifact org.codehaus.mojo:flatten-maven-plugin:pom:1.0.0 from/to central (https://repo.maven.apache.org/maven2): Received fatal alert: protocol_version -> [Help 1]

What on earth is this now? I start hating travis. I Will revert my change (porting back to precise and jdk7) and do not further care about this for the bugfix release as we can control our changes accordingly.

[hohwille]

I did all I can and what is possible with my available time but for travis I have to give up at this state (what makes sense for 3.0.0 anyway). I would propose to merge this PR as is. Otherwise if you disagree, you need to take over my PR and continue on your own.

Please review and merge. Thanks.

[hohwille]

@AbhayChandel Thanks for your review feedback

1. that sounds like a bug in the template/archetype. Can you create an issue? Did you already investigate the reason why this happens. Seems strange... Excellent finding!
2. Git does not track folders. Hence, a folder can not be deleted centrally. You have to delete in manually on your disk. It would have been deleted by git if it was entirely empty but due to IDE artefacts that you most probably have locally in that folder (.project file from eclipse, etc.) it was not deleted. Nothing that I can do about.

[AbhayChandel]

I have fixed issue(#654 ) under PR #652. No need to be fixed in this PR. This PR can be merged now.