How to import BIRT code into eclipse

[SteveSchafer-Innovent]

I have not been successful at importing the BIRT code into eclipse without there being errors. I've tried several methods of importing, including importing existing project at the root level, importing existing project for each individual project, and importing existing maven project at the root level, with varying results. I'd like to know if anyone has been able to get the code imported without any errors and specifically how to do it.

[patric-r]

+1

Same here. Ideally we would have a document describing how to set up a correct and working build environment within eclipse. Building BIRT within Eclipse is an important prerequisite of doing changes, fixing bugs and issuing PRs (I'm wondering if the main developers are building BIRT solely with maven?).

IMHO, this is much more important than other things currently discussed (e.g. having a new logo/website).

[ruspl-afed]

@Flugtiger mentioned oomph setup script. I don't know if he still plans to submit it but this would be very helpful.

[patric-r]

A working oomph script would be helpful.

@ruspl-afed How does your BIRT development environment currently look like?

[ruspl-afed]

What I did:

(should be covered by oomph) 1) imported all project as "General" from cloned repo 2) switched target to /org.eclipse.birt.target/org.eclipse.birt.target.target 3) switched workspace preference "Missed API Baseline" to warning

(plan to contribute it after tests will be fixed for master)

4) added lifycycle mapping ignorance to /org.eclipse.birt.report.viewer/pom.xml 5) changed VM to 1.8 for nl fragments

[patric-r]

Thanks. Which Java version/Eclipse SDK release needs to be currently used? (Having all those information in a single document would be really helpful to the community)

[ruspl-afed]

Java 8 is important at the moment, but there is a plan to upgrade to Java 11. I'm using the latest released Eclipse for Committers package for development. The dependencies are specified in the target.

[SteveSchafer-Innovent]

Here's what I did.

1. general / import existing project - select root of cloned repo. If I do not check "Search for nested projects", I get a tree view which doesn't show packages and no errors. If I check "Search for nested projects", it tells me a couple of projects cannot be imported because they already exist. Then I end up with a lot of projects and 154 errors, a lot of which are lifecycle errors.
2. I changed the lifecycle error to a warning in the workspace because I didn't want to make any changes to the repo.
3. That gets me down to 143 errors, most of which are about projects that cannot be built until their prerequisites are built. The others are various packages and/or classes that cannot be resolved. Then after a few minutes (while I'm typing this), it decides to rebuild on its own and then I have 53 errors, most of which are "Access restriction ... is not API ...", which I can change to warnings. After that I'm down to 17 errors which is about as low as I've been able to get it.

I think that at least some of the unresolved classes and packages may be due misconfigured java build path (e.g. no source folder), java packages no longer supported (javax.xml.bind), and J2SE-1.5 execution environment. All of these can be fixed in due course.

I do have one really weird error where it's obviously trying to unzip a pom.xml file. It seems to be caused by an unpack goal in the maven-dependency-plugin in birt-runtime-test. No idea why it's doing that.

I also have "An API baseline has not been set for the current workspace". I've tried setting it to org.eclipse.birt.target.target but that gives me "There is a possible API baseline mismatch since none of the workspace projects is in the baseline", so that probably wan't the right thing to do.
Anyway sorry for the long-winded comment but if anyone sees anything I'm obviously doing wrong, please let me know.

[ruspl-afed]

I also have "An API baseline has not been set for the current workspace". I've tried setting it to org.eclipse.birt.target.target but that gives me "There is a possible API baseline mismatch since none of the workspace projects is in the baseline", so that probably wan't the right thing to do.

We don't have API baseline defined yet, but we need to create one that points to the latest officially released BIRT. @wimjongman do we know the git tag and the p2 repo URL of the latest official BIRT release?

[patric-r]

I still cannot get it to work. I used the most recent eclipse-for-commiters package, like @ruspl-afed said. I did it like @SteveSchafer-Innovent said, using "search nested projects" on the git repo.

I have more than 20000 compile errors (e.g. org.eclipse.emf cannot be resolved - although I installled EMF, com.lowagie cannot be resolved - but when I click on the imports, the source file is opened. This really looks like a configuration error. Any help is appreciated.

IMHO, if BIRT want to encourage other developers, the project really needs a document how to setup a proper build/development environment. Currently, it is very frustrating.

[wimjongman]

We don't have API baseline defined yet, but we need to create one that points to the latest officially released BIRT. @wimjongman do we know the git tag and the p2 repo URL of the latest official BIRT release?

I see this release directory R-R1-4.8.0-201806261756. There is no tag for it but I expect it is commit 8e9ce5f6a29cc01ca41dee4dd6c17d3a34f19944.

So tag BIRT_4_8_0_Release_201806261756 must be made out of commit 8e9ce5f

[wimjongman]

I don't have the authority to do that. I expect this can only be done by project leads.

[ruspl-afed]

I have more than 20000 compile errors (e.g. org.eclipse.emf cannot be resolved - although I installled EMF, com.lowagie cannot be resolved - but when I click on the imports, the source file is opened. This really looks like a configuration error. Any help is appreciated.

What target do you use? Please try with

/org.eclipse.birt.target/org.eclipse.birt.target.target

[patric-r]

@ruspl-afed Thanks,

I opened /org.eclipse.birt.target/org.eclipse.birt.target.target and clicked on "Set as Active Target Platform".

This dropped the error count down to 1052. Good! Most of them are maven errors of the following group (all nested projects seem to be affected):

• "Plugin execution not covered by lifecycle configuration: org.apache.maven.plugins:maven-antrun-plugin:1.8:run (execution: generate.property.files, phase: compile)" errors
• Plugin execution not covered by lifecycle configuration: org.eclipse.tycho:tycho-packaging-plugin:1.0.0:build-qualifier (execution: default-build-qualifier, phase: validate)
• Plugin execution not covered by lifecycle configuration: org.eclipse.tycho:tycho-packaging-plugin:1.0.0:build-qualifier-aggregator (execution: default-build-qualifier-aggregator, phase: validate)
• Plugin execution not covered by lifecycle configuration: org.eclipse.tycho:tycho-packaging-plugin:1.0.0:validate-id (execution: default-validate-id, phase: validate)
• Plugin execution not covered by lifecycle configuration: org.eclipse.tycho:tycho-packaging-plugin:1.0.0:validate-version (execution: default-validate-version, phase: validate)

Any hints are appreciated.

[wimjongman]

If you open the problems view, you can select the "..lifecycle.." error.

It enables you to download a couple of extra plugins. If that does not solve it, it also enables you to silence the errors in the preferences. Eclipse is running its own compile anyway.

[patric-r]

Thank you so much, @wimjongman !

I used quick fix->Discover new m2e connectors to resolve most dependencies:

Down to 89 errors.

But not all of them:

• Plugin execution not covered by lifecycle configuration: org.apache.maven.plugins:maven-antrun-plugin:1.8:run (execution: generate.property.files, phase: compile)

When using Quick fix, it shows me: No marketplace entries found to handle Execution generate.property.files, in /org.eclipse.birt.report.engine.emitter.config.nl/pom.xml in Eclipse. Please see Help for more information.

In addition to the maven errors, I have a few others:

• Java compiler level does not match the version of the installed Java project facet.
• An API baseline has not been set for the current workspace.
• The import org.eclipse.birt.chart.viewer cannot be resolved (org.eclipse.birt.chart.viewer/WebContent/drill)
• SampleHelper cannot be resolved (org.eclipse.birt.chart.viewer/WebContent)
• The method accept(File, String) of type new FilenameFilter(){} must override a superclass method (birt-runtime-test/src/test/java/org/eclipse/birt/sdk)

[wimjongman]

Can you start to write a "getting started" document that explains all steps?

[patric-r]

@wimjongman I can try to do this but at first I would need to have a working development environment in order to document all steps. It would be nice if you (or someone else) would assist me to solve the remaining issues.

[ruspl-afed]

Plugin execution not covered by lifecycle configuration: org.apache.maven.plugins:maven-antrun-plugin:1.8:run (execution: generate.property.files, phase: compile)

please choose "Ignore" Quick Fix for this

An API baseline has not been set for the current workspace.

Since we don't have baseline defined at the moment let's set this error to warning in preferences

As for java version related problem I fixed a number of them in master, but perhaps not all

[patric-r]

Instead of ignoring, why can't we fix the root cause of those issues?

What about the other issues?

[wimjongman]

Go to the root of the git repo and run the build. This might resolve some of the compile issues.

mvn clean verify -DskipTests

[ruspl-afed]

Instead of ignoring, why can't we fix the root cause of those issues?

To fix the root cause we will need to implement a maven to eclipse lifecycle mapping for this maven plugin. I think this is out of scope for this project.

What about the other issues?

Please update us with the list of issues you still have after building the latest master with

mvn clean verify -DskipTests

as @wimjongman suggested

[patric-r]

mvn clean verify -DskipTests fails very strangely with many errors.... First of them is:

[ERROR] C:\Users\github\git\birt\viewer\org.eclipse.birt.axis.overlay\src\org\eclipse\birt\axis\utility\UTF8Encoder.java:[1]
[ERROR]         /*
[ERROR]         ^
[ERROR] The type java.lang.Object cannot be resolved. It is indirectly referenced from required .class files

[wimjongman]

Yes, it needs to be run with JDK 8. I am working on a > JDK8 (JDK11) build and I am one failing test away from success.

Please try to run the same with branch prepare_for_java11

[patric-r]

@wimjongman Thanks, running maven with a JDK 8 worked. The command mvn clean verify -DskipTestsran without any errors.

However, the situation didn't change in eclipse. Even after refreshing and doing a clean build, I still have 89 errors.

[wimjongman]

What errors are left?

[wimjongman]

We just released a new build. Please update BIRT and check the remaining errors. BIRT build must now be done with JDK11+

[patric-r]

@wimjongman mvn verify goal with JDK 11 works after pulling the newest changes. However, eclipse now shows ~5800 errors again.

Now we are back on all those "package org.w3c.dom is accessible from more than one module: , java.xml" errors.

Aren't you getting those errors in your eclipse?

[wimjongman]

Please try Project/Clean.. Clean all projects.

[patric-r]

I already did this. I refreshed maven configuration, I closed the projects and re-opened it, ran clean all - the result is the same.

[wimjongman]

Ok, let me try on a fresh workspace.

[patric-r]

By the way, the error makes perfectly sense for me, as org.eclipse.birt.report.data.oda.xml/buildXML.xml defines a dependency to xml-apis which is also providing those classes, causing a conflict (with the classes of the same name from the JDK) as BIRT seems to not use an explicit java module (hence "unnamed") yet

The interesting question is why you don't get those errors.

[ruspl-afed]

it could be because come projects are not part of pom-based build for some reason

[wimjongman]

Did you activate the target platform in the preferences/PDE/Target platform?

[patric-r]

Yes. I even clicked now on "Reload Target Platform" but this didn't change anything.

[wimjongman]

ok, I see your problems myself now. I'm looking into it.

[wimjongman]

I am still fighting this.

The issue: "package org.w3c.dom is accessible from more than one module" is now clear to me. In java 11 there can only be one package on the classpath. Some packages are passed by the JVM and by the Manifest simultaneously.

It means that we have to juggle the build path properties while at the same time making Tycho happy.

[srbala]

Is version 4.9 release will require minimum JDK 1.8, will work and compile with JDK 11?

[wimjongman]

Yes. We just released a patch so that it compiles with JDK11. Some bundles needed to move to JDK11 for that. So strictly speaking we are not 100% compatible with JDK8 anymore.

[patric-r]

@wimjongman going back to the topic: First of all, thanks for your commits.

Just to clarify: You're still on this issue, right? Please let me know as soon as you're finished. I'll be happy to test this again.

[wimjongman]

Yes, I am on this. In fact, you can help right now by activating branch https://github.com/eclipse/birt/tree/How_to_import_BIRT_code_into_eclipse_%23628

1. Open a clean workspace
2. Switch to the branch ^^
3. Import the projectSet.psf found in the root
4. Switch to "Top level elements/Working sets" in the Package Explorer kebab menu “⋮”
5. Activate the target platform found in the BBuild/...target project

Let me known which errors you still find.

[srbala]

Some bundles needed to move to JDK11 for that. So strictly speaking we are not 100% compatible with JDK8 anymore.

@wimjongman Both JDK8 and JDK11 are in LTS. JDK8 is supported 2024 and beyond https://adoptopenjdk.net/support.html. It would be nice and better keep JDK8 support.

Builds can have profiles for JDK8 vs JDK11

[wimjongman]

Eclipse 2020-09 and above need JDK11+. People who will hack on BIRT will see the errors that are the topic of this issue.

[srbala]

Just one more clarification. So, BIRT runtime will be compatble with JDK8 and IDE tooling will require JDK 11+?

[wimjongman]

In the short term, BIRT runtime will not be compatible with JDK8.

[patric-r]

@wimjongman I executed all the steps you described. I have only 2 java compile errors left:

PDFTranscoder cannot be resolved to a type  PDFRendererImpl.java    /org.eclipse.birt.chart.device.pdf/src/org/eclipse/birt/chart/device/pdf    line 127    Java Problem

The import org.apache.fop cannot be resolved    PDFRendererImpl.java    /org.eclipse.birt.chart.device.pdf/src/org/eclipse/birt/chart/device/pdf    line 30 Java Problem

Additionally, I still get 78 maven errors (within eclipse!), most of them are:

Plugin execution not covered by lifecycle configuration: org.apache.maven.plugins:maven-antrun-plugin:3.0.0:run (execution: generate.property.files, phase: compile)

[wimjongman]

The java compile errors are caused by a missing fopxx.jar in that project. By running the mvn build the file is copied to that location. You can also add it manually.

mvn errors must be resolved by installing additional mvn plugins and/or ignoring them.

[patric-r]

@wimjongman What makes this jar special compared to all other dependent jars which work out of the box?

I don't know much about the eclipse plugin build ecosystem but IMHO we should either make the build pure eclipse, or we should make it pure maven. I consider a mix of both worlds (e.g. run this maven phase/goal first then eclipse compile succeeds) unneccessarly complex and intransparent.

It is an hurdle for all developers willing to contribute.

[wimjongman]

Note that I am only involved in building/coding BIRT for 4 weeks. There must be a historic reason but I don't know it. Probably the fop cannot be distributed with Eclipse or there is no p2 repository serving it. The reason it is not pushed into the repo is maybe because of licensing (just a wild guess).

If fop was consumable by p2/Tycho then it should come from a recent build of the Eclipse orbit project (which does not contain it). https://download.eclipse.org/tools/orbit/downloads/drops/R20210223232630/

You can help by finding a p2 repo that serves our required version of fop. If you can't find it then ask the Eclipse Orbit project if they can include our required version of fop OR figure out if we can include it in our git repo.

Make sure to create an issue for it.

[srbala]

we should either make the build pure eclipse, or we should make it pure maven. I consider a mix of both worlds (e.g. run this maven phase/goal first then eclipse compile succeeds) unneccessarly complex and intransparent.

@patric-r @wimjongman Future direction would import project into eclipse as maven project. In some of our projects which uses the jar files which are not in p2 are resloved using manual jar install from local file. Updating Readme.md with necessary steps to setup local environment would be nice too.

[patric-r]

@wimjongman I was unable to find a p2 repo with Apache FOP 2.3. I don't know anything about the process but wouldn't it be possible to add Apache FOP 2.3 to an official eclipse p2 repo?

@srbala Agreed, if this is possible for Eclipse Product/Plugin development, e.g. that you can still run/debug the BIRT product within Eclipse.