How to import BIRT code into eclipse

[eclipse-birt]

How to import BIRT code into eclipse

[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.

[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.

[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 8e9ce5f.

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 -DskipTests ran 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.

[wimjongman]

@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?

Yes. Eclipse has a special project, called Orbit [1], that was invented exactly for this purpose. The FAQ is here [2]. There is information on how to add libraries to the Orbit project.

[1] https://www.eclipse.org/orbit/
[2] https://wiki.eclipse.org/Orbit/FAQ#How_do_I_add_something_to_Orbit.3F

[patric-r]

https://wiki.eclipse.org/Orbit/Adding_Bundles_to_Orbit#Before_You_Do_Anything

This really looks like a very bureaucratic process just for making an ASL-licensed and in maven central available jar usuable during an eclipse build. Is this the only way to do it? if yes: Can anybody help?
An easiest as possible build process seems to be so much more valuable for the project than having 50 birt-dev mailing list posts about a new BIRT project logo which nobody might care about.

[wimjongman]

https://wiki.eclipse.org/Orbit/Adding_Bundles_to_Orbit#Before_You_Do_Anything

This really looks like a very bureaucratic process just for making an ASL-licensed and in maven central available jar usuable during an eclipse build. Is this the only way to do it?

Yes, it is the only way to do it. Protecting our consumers from copyright infringement comes with a price.

if yes: Can anybody help?

You can help. Looking at others to solve issues will just lead to a staring circle. Please step up if you can spare a couple of hours. I will guide you. You can start by sending a message to the Orbit mailing list.

An easiest as possible build process seems to be so much more valuable for the project than having 50 birt-dev mailing list posts about a new BIRT project logo which nobody might care about.

Judging by the posts, many find the logo important. Not you and me though, that is why we are on this ticket 😉

[patric-r]

@wimjongman question regarding your statement:
"Yes, it is the only way to do it. Protecting our consumers from copyright infringement comes with a price."

BIRT is using Apache FOP since years, isn't it?
What is the (legal) difference whether we use Orbit, Maven or whatever to integrate/use/package it?
The artifact delivered to the customer is exactly the same, containing the fop jar. Am I missing something?

[srbala]

@patric-r it's possible it might using older version, any new changes/version upgrade need approval from legal

[wimjongman]

@wimjongman question regarding your statement:
"Yes, it is the only way to do it. Protecting our consumers from copyright infringement comes with a price."

BIRT is using Apache FOP since years, isn't it?
What is the (legal) difference whether we use Orbit, Maven or whatever to integrate/use/package it?
The artifact delivered to the customer is exactly the same, containing the fop jar. Am I missing something?

There is no difference and we are already cleared to use Apache FOP. However, the process of getting FOP into Orbit remains the same and we have to jump through a couple of hoops to make sure that all the legal paperwork is in order.

[SteveSchafer-Innovent]

Just letting you know where I am on this. Based on Wim's suggestion I installed eclipse rcp 2020-06 and followed his steps in #628 (comment). I now have only one error where it's trying to unzip a pom.xml file in the maven-dependency-plugin in the birt-runtime-test project for some reason. I don't seem to have any problem with apache fop.

Description Resource Path Location Type
Error unpacking file: /disk1/home/innovent/git/birt-fork/birt/build/birt-packages/birt-runtime/pom.xml to: /disk1/home/innovent/git/birt-fork/birt/build/birt-packages/birt-runtime-test/target/birt-runtime
org.codehaus.plexus.archiver.ArchiverException: Error while expanding /disk1/home/innovent/git/birt-fork/birt/build/birt-packages/birt-runtime/pom.xml (org.apache.maven.plugins:maven-dependency-plugin:2.10:unpack:copy:process-test-resources)

org.apache.maven.plugin.MojoExecutionException: Error unpacking file: /disk1/home/innovent/git/birt-fork/birt/build/birt-packages/birt-runtime/pom.xml to: /disk1/home/innovent/git/birt-fork/birt/build/birt-packages/birt-runtime-test/target/birt-runtime
org.codehaus.plexus.archiver.ArchiverException: Error while expanding /disk1/home/innovent/git/birt-fork/birt/build/birt-packages/birt-runtime/pom.xml
at org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:323)
at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.unpackArtifact(UnpackMojo.java:127)
at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.doExecute(UnpackMojo.java:106)
at org.apache.maven.plugin.dependency.AbstractDependencyMojo.execute(AbstractDependencyMojo.java:167)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
at org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:332)
at org.eclipse.m2e.core.internal.embedder.MavenImpl.lambda$8(MavenImpl.java:1379)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:179)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:114)
at org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:1378)
at org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:54)
at com.ianbrandt.tools.m2e.mdp.core.MdpBuildParticipant.executeMojo(MdpBuildParticipant.java:133)
at com.ianbrandt.tools.m2e.mdp.core.MdpBuildParticipant.build(MdpBuildParticipant.java:67)
at org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:135)
at org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:169)
at org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)
at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$1(MavenBuilder.java:114)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:179)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:114)
at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$0(MavenBuilder.java:105)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:179)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:153)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:101)
at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:88)
at org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:197)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:832)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:220)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:263)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:316)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:319)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:371)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:392)
at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:154)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:244)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: org.codehaus.plexus.archiver.ArchiverException: Error while expanding /disk1/home/innovent/git/birt-fork/birt/build/birt-packages/birt-runtime/pom.xml
at org.codehaus.plexus.archiver.zip.AbstractZipUnArchiver.execute(AbstractZipUnArchiver.java:163)
at org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:129)
at org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:315)
... 36 more
Caused by: java.util.zip.ZipException: archive is not a ZIP archive
at org.apache.commons.compress.archivers.zip.ZipFile.positionAtEndOfCentralDirectoryRecord(ZipFile.java:806)
at org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:736)
at org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:481)
at org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:216)
at org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:192)
at org.codehaus.plexus.archiver.zip.AbstractZipUnArchiver.execute(AbstractZipUnArchiver.java:142)
... 38 more
pom.xml /birt-runtime-test line 31 Maven Build Problem

[wimjongman]

This one is waiting on the release of the jetty p2 repository:

jetty/jetty.project#6404

[patric-r]

@wimjongman that PR has now finally being merged into jetty.

[patric-r]

@wimjongman any updates on this?
IMHO solving this issue is the key of getting more PR / contributions from the community.

[wimjongman]

Is that really the case? Did you import the branch and looked at it? I would like your feedback in that case.

[patric-r]

Which branch for what project? BIRT or Jetty?

[wimjongman]

https://github.com/eclipse/birt/tree/How_to_import_BIRT_code_into_eclipse_%23628

[patric-r]

Ah, I wasn't aware about this branch nor that the work is completed - I always thought that the jetty issue blocks any progress.

Which steps needs to be executed in order to use this branch to get a working development environment (e.g. which java and eclipse SDK version do I need, any further prerequisites etc.)?

[patric-r]

Which steps needs to be executed in order to use this branch to get a working development environment (e.g. which java and eclipse SDK version do I need, any further prerequisites etc.)?

@wimjongman a kind reminder to the above, please

[wimjongman]

Hey @patric-r, I already described this in an earlier comment:

#628 (comment)

You need to have an Eclipse with PDE installed. When you use the Eclipse installer, you can select an Eclipse flavor with PDE inside.

Then just follow the instructions in the ^^ comment.

[patric-r]

@wimjongman Yes, but it still lacks the info which java and eclipse SDK version we need ;)

[wimjongman]

Always the latest Eclipse. Lowest Java is 11 but anything 11-17 is fine.

[patric-r]

What I did:

• Downloaded "eclipse for commiters 2012-09", unzipped and started it using a Java 11 SDK
• Imported branch How_to_import_BIRT_code_into_eclipse_#628 using import -> Projects from git (with smart import)
• During import "marketplace solutions available: org.eclipse.wst.common.modulecore.ModuleCoreNature" popup showed up. It seems that PDE is not sufficient? Clicked on "show solutions" and installed "Eclipse Java Enterprise Java and Web developer Tools" and restarted eclipse
  -> eclipse rebuilt the project - result: 16768 errors left.
  error 1 of 16768: The import org.apache.batik.transcoder cannot be resolved

Root cause is most probably that eclipse shows errors for every pom.xml file, e.g.:

• Plugin execution not covered by lifecycle configuration: org.eclipse.tycho:tycho-compiler-plugin:2.4.0:compile (execution: default-compile, phase: compile)
  * Plugin execution not covered by lifecycle configuration: org.apache.maven.plugins:maven-antrun-plugin:3.0.0:run (execution: generate.property.files, phase: compile)
• Plugin execution not covered by lifecycle configuration: org.eclipse.tycho:tycho-packaging-plugin:2.4.0:build-qualifier (execution: default-build-qualifier, phase: validate)

This sounds similar to what I got in April: #628 (comment)

What am I doing wrong / I am missing, @wimjongman?

[wimjongman]

What target do you use? Please activate this target definition:

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

(Open the file, in the toolbar of the editor you can set as target platform)

[patric-r]

Thanks, did this now.

Errors increased to ~70000.
pom.xml are still failing, e.g. with:

Plugin execution not covered by lifecycle configuration: org.eclipse.tycho:target-platform-configuration:2.4.0:target-platform (execution: default-target-platform, phase: initialize)

[patric-r]

@wimjongman any ideas?

[wimjongman]

Can you paste a screenshot of your whole IDE window? Make sure the package explorer is visible and a project is visible with all its text.

[patric-r]

sure @wimjongman

[wimjongman]

Thanks. There is an issue with the target platform. Some bundles cannot be resolved.

[wimjongman]

Pff, this is quite a battle, but finally, I have a healthy WS again. I will commit a new target platform ASAP.

[patric-r]

@wimjongman

Thanks for your effort
I pulled your changes and clicked on "reload target platform".
It is now looking much better:
1544 errors left:

What needs to be done in order to fix the remaining (especially the pom / maven) issues?

[wimjongman]

Can you press CTRL+1 on the "plugin execution" and take one of the proposed actions?

[patric-r]

Did this and I chose "Discover m2e connectors".
However, it can't resolve everything:

[wimjongman]

Press CTRL+1 and select ignore. Since we build outside the IDE there is no dire need for it.

[wimjongman]

I have added additional dependencies to the target file. In the same location, I have created a birtrun launch configuration. You can use that to launch the designer.

[patric-r]

@wimjongman
Pulled your recent changes and reload target platform.
Java errors increased a little bit and we now have an API baseline error:

Regarding ignoring the pom.xml:
Is there a way to mass apply this change (ideally by committing a preference file or something)?
The quick fix 'select all' only allows me to select 7 pom.xml at a time so I would have to do this many times.
In order to ease future development, it would be nice to have a better solution, ideally it should work out of the box.

[wimjongman]

Yes, it should work out of the box. This can be changed in the preferences and I think it has been changed in master by @SteveSchafer-Innovent

[patric-r]

Okay, good to know that this is already fixed in the master branch.
For now, I changed the preference like you proposed and as expected, the maven errors are now gone:

How to fix the remaining errors (especially the API baseline error which appeared after your recent change)?

[wimjongman]

The "baseline workflow" is a method to prevent undocumented API changes.

How does it work:

1. Download the previous BIRT release (download the all-in-one from here
2. Unzip this in a known location e.g. ~user/eclipse/baselines/
3. Goto preferences/plugin development/API Baseline and add the unzipped directory there

Now Eclipse can compare 4.8 to 4.9 and warn us for undocumented API changes.

[patric-r]

So the "baseline" is a method to ensure that certain projects are API compatible to a specific, e.g. older eclipse release (different to the eclipse SDK which we are using for development) to ensure BIRT will run on those releases as well?

With "all-in-one" you mean birt-report-designer-all-in-one-4.8.0-20190521-win32.win32.x86_64.zip?

Is this something every contributor needs to do in order to properly compile, change and test a working copy of birt?

[wimjongman]

So the "baseline" is a method to ensure that certain projects are API compatible to a specific, e.g. older eclipse release (different to the eclipse SDK which we are using for development) to ensure BIRT will run on those releases as well?

Not so much to an older Eclipse release but more to an older BIRT release. If we want BIRT to run against the API of an older Eclipse release then we have to build against that version. The current target platform runs against the latest Eclipse version. This means that we now can use new Eclipse API that would prevent BIRT from running on older Eclipse releases.

However, I have no intention to support older Eclipse releases. For that, we have BIRT 4.8.

The other reason is that any new BIRT API is properly documented with a "@SInCE" tag. If this is not the case then the baseline will complain. Try adding a new API (e.g. public method) to a project that uses the baseline and you will see an error appearing.

With "all-in-one" you mean birt-report-designer-all-in-one-4.8.0-20190521-win32.win32.x86_64.zip?

Yes,

Is this something every contributor needs to do in order to properly compile, change and test a working copy of birth?

The error is an error for Eclipse but it does not prevent running BIRT. The error can also be switched off in the preferences. Also, the lifecycle errors that you got are just logical errors as far as Eclipse is concerned. It does not hinder the execution of BIRT from within Eclipse.

[wimjongman]

With my latest push also the build is working again. Run maven with a java11 SDK. On the command line:

mvn package -DskipTests

[wimjongman]

After the build, you will find the created products in the

 ../build/birt-packages/ 

directory

[wimjongman]

build failing again after merge with master

[merks]

I've tried to write Oomph setup in the current state, as observed above, it's hard to even do this manually.

For /org.eclipse.birt.chart.device.pdf/META-INF/MANIFEST.MF lib/fop-2.3.jar is missing.
For /org.eclipse.birt.build/META-INF/MANIFEST.MF lib/dom4j-1.6.1.jar is missing.

You can't really build with compliance set to Java 11 because it complains about APIs being visible from multiple different modules.

You need a Java 8, JDK, and you need to tools.jar on the classpath or the com.sun.jdi* things don't resolve

For /org.eclipse.birt.data.oda.pojo.ui/META-INF/MANIFEST.MF the Fragment-Host doesn't resolve, it should probably be Fragment-Host: org.eclipse.birt.data.oda.pojo;bundle-version="[2.1.0,5.0.0)" instead.

For org.eclipse.birt.report.debug.internal.ui.launcher.util.ReportLauncherUtils.getEclipseHome() it should probably be like this

	public static IPath getEclipseHome() {
		return new Path(TargetPlatform.getLocation());
	}

For org.eclipse.birt.report.viewer.mock.ServletContextSimulator it should implement more 'newer' methods.

And of course all the Maven errors should be disabled, at least for now...

There's also the issue of Jetty dependencies and where to get those. The ones proved by the platform/SimRel aren't all the ones that are needed...

Given that things are in a state of flux and are quite badly broken, it's not really so feasible to automate the setup process at the moment.

I fixed some of the problems above via the setup, but others I had to fix manually. In the end, I do have an error-free workspace...

[ruspl-afed]

Thank you so much Ed @merks for investing your time. I was creating setup in parallel, but may be I can continue from your variant. Do you plan to create a PR?

[merks]

I'm familiar with the Gerrit workflow but I don't know how to do this with forks and pull requests. I'll just attach the work in progress here as a zip. It's mostly just boiler plate and the JRE task isn't much good because it only works with Java 8 right now...

BIRT.setup.zip

[wimjongman]

Sorry about this Ed. I just pushed a big stabilization change that I did not realize you were not seeing.

[wimjongman]

This one was fixed. Thanks all for pushing this. An important step forward.

Please use the new installer link and follow the instructions. The link is also available from the README.MD:

https://www.eclipse.org/setups/installer/?url=https://raw.githubusercontent.com/eclipse/birt/master/build/org.eclipse.birt.releng/BIRTConfiguration.setup&show=true

[patric-r]

When using this installer, I still get 21 java errors, "Access Restriction" (dom4j):

[ruspl-afed]

Strange, I thougt it was fixed by the latest manifest adjustments
Let me see if I can rebase #678

[ruspl-afed]

When using this installer, I still get 21 java errors, "Access Restriction" (dom4j):

I just merged #678 , please try to update sources from master branch without re-installing

[patric-r]

@ruspl-afed Yes, this fixed the problem! All java errors are now gone.
Congratulations and thanks!

However, I had several UI freezes (maybe because of the M2?).
And every time I restart the eclipse (clean shutdown) eclipse is going to rebuild BIRT. Why?

Next questions:

• How to run the junit tests?
• How to run the report designer?

[wimjongman]

I also saw the UI freezes.

For the report designer to run you have to create a run configuration. There is already one run configuration available, you can run from there:

For the unit test to run you also have to create a run configuration. You can start finding the classes that are name AllTests and run these as JUnit plugins tests. This will create a run configuration that you will have to tweak in the Run Configuration dialog