Bug 567979 - 3 ways to build are at least 1 too many
Summary: 3 ways to build are at least 1 too many
Status: ASSIGNED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.18   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: JDT-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-18 16:16 EDT by Carsten Hammer CLA
Modified: 2020-11-06 01:48 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Carsten Hammer CLA 2020-10-18 16:16:53 EDT
Currently jdt.ui uses 3 ways to build afaik

1) ant based build for integration build
2) maven tycho based build for gerrit
3) eclipse jdt based build for development within eclipse

All 3 builds work different.
While I can argue that I cannot get rid of 2 and 3 because of technical reasons for keeping 1 I see no valid arguments.

The integration build is missing at the moment complete jdt.ui part and 
performance tests are off for some time (a year?). Can you point me to documentation about the build?

If I try to run one of the test.xml ant scripts checked out I find that I am missing a "library.xml" file that is not part of the git checkout. Where is this file?

Imho at the moment I think there is room for improvement regarding the build architecture:

a) everybody should be able to repeat all builds and tests locally without special infrastructure (with the exception of the platform hardware of course)
b) failures should be as transparent as possible (regarding what you have to do to solve it - if a file has to be prepared the build should tell you that) 
c) every build if local or not should create the same results. Because of some tests not being part of suites these tests are seen and executed working in eclipse but not part of the build
Comment 1 Alexander Kurtakov CLA 2020-11-05 15:24:51 EST
(In reply to Carsten Hammer from comment #0)
> Currently jdt.ui uses 3 ways to build afaik
> 
> 1) ant based build for integration build
> 2) maven tycho based build for gerrit
> 3) eclipse jdt based build for development within eclipse
> 
> All 3 builds work different.
> While I can argue that I cannot get rid of 2 and 3 because of technical
> reasons for keeping 1 I see no valid arguments.

1 is not building it's launching prebuild via maven test bundles against Eclipse SDK (prebuild via maven) and this launching is done via ant.

> 
> The integration build is missing at the moment complete jdt.ui part
I honestly have no idea what does ^ means.

> and 
> performance tests are off for some time (a year?). 

Actually they are run:
https://ci.eclipse.org/releng/job/ep418I-perf-lin64/
https://ci.eclipse.org/releng/job/ep418I-perf-lin64-baseline/
https://ci.eclipse.org/releng/job/ep418ILR-perf-lin64/
https://ci.eclipse.org/releng/job/ep418ILR-perf-lin64-baseline/
But the comparison page is not generated and published. 
See bug 562424 . 

> Can you point me to
> documentation about the build?

https://wiki.eclipse.org/Performance/Automated_Tests 
Unfortunately there is a lot of garbage in both documentation and scripts. 
As one can see in https://git.eclipse.org/c/platform/eclipse.platform.releng.buildtools.git/log/ efforts to make sense of things is ongoing on as time permits basis. It would be nice if we get more people interested in this area and helping us get a better and more consistent build.

> 
> If I try to run one of the test.xml ant scripts checked out I find that I am
> missing a "library.xml" file that is not part of the git checkout. Where is
> this file?

I really dislike the whole 'test framework' https://wiki.eclipse.org/Platform-releng/Eclipse_Test_Framework but it allows us to run the tests against real prebuilt product post build so we can do it on win/mac/linux and with different JVMs. I would be really happy if someone provides us with better way to achieve that.

> 
> Imho at the moment I think there is room for improvement regarding the build
> architecture:
> 
> a) everybody should be able to repeat all builds and tests locally without
> special infrastructure (with the exception of the platform hardware of
> course)
> b) failures should be as transparent as possible (regarding what you have to
> do to solve it - if a file has to be prepared the build should tell you
> that) 
> c) every build if local or not should create the same results. Because of
> some tests not being part of suites these tests are seen and executed
> working in eclipse but not part of the build
Comment 2 Carsten Hammer CLA 2020-11-05 15:33:17 EST
(In reply to Alexander Kurtakov from comment #1)

> > 
> > The integration build is missing at the moment complete jdt.ui part
> I honestly have no idea what does ^ means.

It means there are several modules in jdt.ui that are not build at all. They are excluded from the build while still part of the git checkout.

One of these projects I have added (together with a new one) in https://git.eclipse.org/r/c/jdt/eclipse.jdt.ui/+/167738

https://git.eclipse.org/r/c/jdt/eclipse.jdt.ui/+/167738/10/pom.xml
Comment 3 Sravan Kumar Lakkimsetti CLA 2020-11-06 01:48:55 EST
(In reply to Carsten Hammer from comment #0)
> Currently jdt.ui uses 3 ways to build afaik
> 
> 1) ant based build for integration build
> 2) maven tycho based build for gerrit
> 3) eclipse jdt based build for development within eclipse
> 
> All 3 builds work different.
> While I can argue that I cannot get rid of 2 and 3 because of technical
> reasons for keeping 1 I see no valid arguments.

We use tycho for integration build as well as for gerrit validation. This internally uses ecj for compilation. There are some parts built with ant but we use maven tools to invoke ant.  

in gerrit validation we use a build-individual-bundles profile to trigger build in that particular repository. we also use api-check profile to check if there are any bundles that require version increment. 

In integration build we don't use above mentioned profiles and also we skip tests using -DskipTests=true. 

If you want to run the above in local eclipse you can use m2e plugin and run maven build on pom.xml. You can actually run this on individual bundles. You can run from command line as well using
mvn clean verify -Pbuild-individual-bundles -DskipTests=true

 
> 
> The integration build is missing at the moment complete jdt.ui part
There are some parts in jdt.ui that are not built as part of integration build or gerrit validation build specifically AST view and JE view. These are built separately by JDT UI team when required.

> and 
> performance tests are off for some time (a year?). Can you point me to
> documentation about the build?
> 

We are struggling with publishing of performance test results here. We will definitely need some help here. Here is some of the documentation we have https://wiki.eclipse.org/Performance/Automated_Tests. Please note we don't have access to derby now. So we put the results in a results file now.

> If I try to run one of the test.xml ant scripts checked out I find that I am
> missing a "library.xml" file that is not part of the git checkout. Where is
> this file?

Regarding test run there is some documentation available in these links
https://wiki.eclipse.org/Platform-releng/Eclipse_Test_Framework
https://wiki.eclipse.org/Platform-releng/Automated_Testing
https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/eclipse.platform.releng.tychoeclipsebuilder/eclipse-junit-tests/src/main/scripts/library.xml

To run automated tests you use the following method also
1. get https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/production/testScripts/hudsonBootstrap/getEBuilder.xml
2. use ant to run this in following format
    ant -f getEBuilder.xml -Djava.io.tmpdir=<tmp dir> -Djvm=<path to java> -DbuildId=<build id> -DeclipseStream=<stream like 4.18> -DEBUILDER_HASH=<EBUILDER_HASH> -DdownloadURL=http://download.eclipse.org/eclipse/downloads/drops4/${buildId} -Dosgi.os=<linux|macosx|win32> -Dosgi.ws=<gtk|cocoa|win32> -Dosgi.arch=<arch> -DtestSuite=<test suite target>

EBUILDER_HASH and stream can be obtained from http://download.eclipse.org/eclipse/downloads/drops4/${buildId}/buildproperties.shsource

You'll need to set WORKSPACE property before running the above script

test suite targets can be obtained from https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/production/testScripts/configuration/sdk.tests/testScripts/test.xml

> 
> Imho at the moment I think there is room for improvement regarding the build
> architecture:
> 
> a) everybody should be able to repeat all builds and tests locally without
> special infrastructure (with the exception of the platform hardware of
> course)

Integration build can be done using the following
1. Install maven with default java as jdk 11
2. setup maven tool chains similar to https://build.eclipse.org/common/maven-toolchains.xml Only java 8 and above are required.
3. clone https://git.eclipse.org/r/platform/eclipse.platform.releng.aggregator.git with submodules
4. Pull latest source in all submodules
5. run mvn clean verify -DskipTests=true -Pbree-libs

if you want to build a single bundle 
cd <bundle location>
mvn clean verify -Pbree-libs -Pbuild-individual-bundles


> b) failures should be as transparent as possible (regarding what you have to
> do to solve it - if a file has to be prepared the build should tell you
> that) 
> c) every build if local or not should create the same results. Because of
> some tests not being part of suites these tests are seen and executed
> working in eclipse but not part of the build

tests have a issue as we use tycho for gerrit verification and ant for automated tests

for automated tests https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/production/testScripts/configuration/sdk.tests/testScripts/test.xml needs to be updated for new bundles. Most of the times this is what is missing.