Che: Consider Adding Default Profiles for Maven Build

[l0rd]

OpenJDK is not currently supported to build Che.

Is there a technical reason for that? Would it be hard to support it?

Without OpenJDK support it's not possible to build Che on CentOS or RHEL platform with Red Hat supported packages only.

[snjeza]

I have built che on Fedora 24 using OpenJDK 1.0.0_102.

[ibuziuk]

@l0rd @snjeza I have tried to build the whole che against openjdk version "1.8.0_91" on Ubuntu 16.04. Basically, after using --fail-at-end flag I have failures in three plugins:

• Che Plugin :: SVN :: Server ........................ FAILURE
• Che Plugin :: Maven :: Extension Maven Server ...... FAILURE
• Che Plugin :: Maven :: Maven Server Impl ........... FAILURE

All seems to be server related

[ibuziuk]

@l0rd @snjeza hmmm.... I have the very same failure against oracle "1.8.0_91"

[snjeza]

I have used

mvn -DskipTests=true -Dfindbugs.skip=true -Dskip-validate-sources clean install

[benoitf]

could you list failure errors ?

[snjeza]

There aren't any failure errors if we skip the tests. When I include them, I get the same errors as you get. In my opinion, they aren't related to OpenJDK.

[ibuziuk]

I'm doing -X right now, will let you know once finished

[ibuziuk]

@benoitf agree with @snjeza it looks like there is just a bunch of failing tests:

• che-plugin-svn-ext-server

Tests run: 7, Failures: 0, Errors: 7, Skipped: 0, Time elapsed: 0.728 sec <<< FAILURE! - in org.eclipse.che.plugin.svn.server.SubversionApiITest

Tests run: 6, Failures: 0, Errors: 6, Skipped: 0, Time elapsed: 0.518 sec <<< FAILURE! - in org.eclipse.che.plugin.svn.server.SubversionProjectImporterTest

all due to ERROR: /bin/bash: svnadmin: command not found

Probably, someone removed the command without amending the tests ?

• maven-server-impl

7 test failures in org.eclipse.che.maven.server.ProjectResolverTest due to NPE in setUp()

 <![CDATA[java.lang.NullPointerException
    at java.io.File.<init>(File.java:277)
    at org.eclipse.che.maven.server.ProjectResolverTest.setUp(ProjectResolverTest.java:61)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
    at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564)
    at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213)
    at org.testng.internal.Invoker.invokeMethod(Invoker.java:653)
    at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
    at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
    at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
    at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
    at org.testng.TestRunner.privateRun(TestRunner.java:767)
    at org.testng.TestRunner.run(TestRunner.java:617)
    at org.testng.SuiteRunner.runTest(SuiteRunner.java:348)
    at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:343)
    at org.testng.SuiteRunner.privateRun(SuiteRunner.java:305)
    at org.testng.SuiteRunner.run(SuiteRunner.java:254)
    at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
    at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
    at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
    at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
    at org.testng.TestNG.run(TestNG.java:1057)
    at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:115)
    at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(TestNGDirectoryTestSuite.java:205)
    at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:108)
    at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:111)
    at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
    at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
    at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)

None of the errors related to JDK

[snjeza]

@ibuziuk You have to install subversion.
When I use OpenJDK, I get two test failures. When using OracleJDK I get four test failures.

[ibuziuk]

@snjeza thanks for the pointer - I will give it a go tomorrow. Seems to be that Oracle JDK is more prone to the tests failures :-)

[l0rd]

@ibuziuk I had a similar issue with maven plugin and I solved it setting
M2_HOME

On Wed, Sep 28, 2016 at 11:58 PM, Ilya Buziuk [email protected]
wrote:

@snjeza https://github.com/snjeza thanks for the pointer - I will give
it a go tomorrow. Seems to be that Oracle JDK is more prone to the tests
failures :-)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/eclipse/che/issues/2594#issuecomment-250313215, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAlC75RdNk-iEll4eKceavR_IKLDxwh2ks5quuMZgaJpZM4KGmg9
.

[snjeza]

Seems to be that Oracle JDK is more prone to the tests failures :-)

OpenJDK runs 7914 and OraclJDK 7981 tests.

[ibuziuk]

After installing svn and setting M2_HOME I was able to build che via "mvn clean verify"
@TylerJewell probably it makes sense to update the "Development Workflow" with info about necessity of installing subversion for che plugin-svn tests ? Also, WDYT about creating a separate 'fast-and-dirty' profile disabled by default with the following system properties enabled:

    -DskipTests=true
    -Dfindbugs.skip=true
    -Dskip-validate-sources
    -Dmdep.analyze.skip=true
    -Dlicense.skip=true
    -Dgwt.compiler.localWorkers=2 -T 1C

[TylerJewell]

In the development workflow, we do indicate that different plugins may have different requirements that have to be installed for tests to be completed. I am hoping that we can avoid the exercise of trying to maintain a long list of what is needed for each module, as I think it can be a pain over time.

I am +1 to having the default profile skip tests, skip findbugs, skip source validation, etc. And then having engineers enable those checks with a different profile. I think @benoitf was thinking about how to do this. One of the first steps he took was to fix some issues with skip tests. https://github.com/eclipse/che/pull/2696.

[ibuziuk]

@TylerJewell @benoitf what about having the following profile enabled by default:

        <profile>
            <id>fast-and-dirty</id>
            <activation>
                <activeByDefault>true</activeByDefault>
            </activation>
            <properties>
                <findbugs.skip>true</findbugs.skip>
                <gwt.compiler.localWorkers>2 -T 1C</gwt.compiler.localWorkers>
                <license.skip>true</license.skip>
                <mdep.analyze.skip>true</mdep.analyze.skip>
                <skip-validate-sources>true</skip-validate-sources>
                <skipTests>true</skipTests>
            </properties>
        </profile>

and when an engineer needs to do a full build, this profile would be simply disabled via :

mvn clean verify -P !fast-and-dirty

[skabashnyuk]

-1. Low quality profile by default is not an option.

[benoitf]

For me, I'm not a fan to disable any validation by default else developers will contribute with many errors (including license, findbugs, etc)

but to have a profile that allow to skip yes.

[ibuziuk]

@skabashnyuk @benoitf I sort of agree that is why I propose to disable this "fast-and-dirty" profile by default

[benoitf]

but

<activation>
                <activeByDefault>true</activeByDefault>
</activation>

means it's activated by default

[skabashnyuk]

@ibuziuk What kind of problem you are trying to solve?

[TylerJewell]

I want this as default option so that average developer can build all of Che with basic syntax.

What is the syntax to run maven with a specific profile? You provided the syntax for removing a profile.

[benoitf]

average developer can still compile Che with "mvn clean install" without avoiding license check, findbugs, etc.

[ibuziuk]

@benoitf yes, because @TylerJewell said earlier:

I am +1 to having the default profile skip tests, skip findbugs, skip source validation, etc. And then having engineers enable those checks with a different profile.

@skabashnyuk the problem is that there is a line in "Development Workflow":

Oracle Java 1.8 -- compilation with openjdk is not yet supported

And OpenJDK compatible build is one of the most important requirements for Red Hat. Basically, it seems to be that Che Build is openJDK compatible OOTB

[TylerJewell]

So proposal is fast and dirty has to be activated but make the default profile include everything but unit tests?

[ibuziuk]

@TylerJewell if the profile enabled by default it would be vanilla

mvn clean install
if not:

mvn clean install -Pfast-and-dirty

[skabashnyuk]

I don't see how OpenJDK compatible build related to Low quality profile. Can you elaborate?

[benoitf]

@TylerJewell I think the problem that you want to solve is not solved with these properties

because "average developer issue" will be for example : "user has not patch tool installed" or "user has not npm installed" which is not linked to checks/tests

I think what is more useful is : "skip dashboard" module if npm is not installed when building from root pom

[ibuziuk]

@skabashnyuk I do believe this profile thing is just a side discussion in order to make the process of building Che as easy as possible without necessity of installing additional software. The main thing is that doc explicitly says that OpenJDK in not supported for the build purposes

[skabashnyuk]

ok. Can we focused particularly on OpenJDK in this issue? As far as I understand you have major issues in ProjectResolverTest? right?

[ibuziuk]

@skabashnyuk nope, after setting M2_HOME there is no test failures

[TylerJewell]

@skabashnyuk - the title is mislabeled. We do support openjdk - we just have to update the docs. The issue has transformed into one where we are trying to make it possible for any basic developer to do a maven clean install, and for it to reasonably work.

@benoitf - if we skip tests, that should cover most of the issues. The only exception is the dashboard module where you need to have additional sofrware installed. Is this correct?

[skabashnyuk]

AFAIK some plugins like SVN(not sure) or maven may require additional tools installed.

[ibuziuk]

@skabashnyuk I installed only svn via sudo apt-get install subversion. No additional tools, I guess

[TylerJewell]

I think the SVN plugin only requires tools to be installed for unit tests. The basic module itself doesn't require those additional tools. So let's do this.

@ibuziuk - let's:
1: Name the profile build-simple.
2: Have the profile be the default profile
3: Have it skip unit tests AND skip building the dashboard module
4: But leave in the other checks like license compiance, findbugs, etc.

I'll then update the development workflow docs to indicate that this profile is activated by default, and to run unit tests or to build hte dashboard there is different syntax, but you must also install other software.

[ibuziuk]

@TylerJewell sounds good to me ;-)

[skabashnyuk]

Disagree to have it by default globally. It can be done in specific places like SVN plugin or so

[TylerJewell]

Has to be global - cannot skip building dashboard module from within the dashboard module, for example. Also, I am ok to have unit tests skipped - to add skipping unit tests in single modules, that could take a long time to discover all locations?

[benoitf]

@TylerJewell no because you may require "patch" or "npm tool" as well for updating some source code, etc.

your build-simple profile will be no help there (skiping findbugs is not helping the user if patch tool or npm is not installed) and I never saw an issue on users having issues with these plugins.

I think it might be better to "educate" the average developer

mvn clean install : say that there are some required tools missing, how to install them, profile that can help him and not failing in a submodule.

or "skip dashboard" module if npm is not installed when building from root pom or explain how to setup
"skip modules requiring patch tools" or explain how to install it.
etc

but not disabling findbugs or license checks, etc that are not raising any reported issues.

[benoitf]

cannot skip building dashboard module from within the dashboard module, for example.

we can. Module itself can not launch some stuff if some requirements are not defined

here again it would be better to not "skip" but use docker to build it for example.
if native tool is there then it can be used.

I think the "skip all" will have more worst side effect. Users complaining why when they change source code of a module it's not taken into account, etc.

Also why would want to launch a build of che at root level if at the end, you skip half of it.

if you're at the root it means you want to build everything, else you go in assembly folder if you only want to build this module

[TylerJewell]

Ok, so the proposal then would be:

1. No disabling of any license, test, compliance checks, and;
2. For each module that has unit tests or compilation dependent upon 3rd party resources, have that compilation be done in a specialized docker container, and:
3. Have the module check to see if docker is installed, and if not, skip the test / compilation with a message that docker is required. If docker is installed, then complete the compilation using a docker container.

[benoitf]

yes I agree it would be better if build work for everyone even when missing some tools.

we could still use profile to disable some parts (dev may skip some stuff) but by default it should be able to build and test everything whatever your Operating System or tools you've on your computer

about #3, as docker is required to run che, we could say that it's a requirement to build it as well, no ?
Because it might be strange to build it locally and not having docker installed because you won't be able to run it.

[ibuziuk]

@benoitf but one can still launch Che without docker on embedded tomcat

[TylerJewell]

Yes, I mostly agree. Except that we will eventually support different kinds of non-docker machines within Che. So - it will not always be required.

[benoitf]

@ibuziuk well for now when you'll create a workspace it will boot the workspace with docker.
I'm not even sure you can start che master if docker is not running. (Tomcat assembly)

[benoitf]

@ibuziuk will this issue be closed or it's still open for further improvements on build ?

[ibuziuk]

@benoitf I think it would be better to close this one and open a new for the @TylerJewell 's proposal:

1. No disabling of any license, test, compliance checks, and;
2. For each module that has unit tests or compilation dependent upon 3rd party resources, have that compilation be done in a specialized docker container, and:
3. Have the module check to see if docker is installed, and if not, skip the test / compilation with a message that docker is required. If docker is installed, then complete the compilation using a docker container.

[benoitf]

ok