search

eclipse-birt / birt

Eclipse BIRT™ The open source reporting and data visualization project.
http://www.eclipse.org/birt
Eclipse Public License 2.0
451 stars 389 forks source link

How to import BIRT code into eclipse #628

Closed SteveSchafer-Innovent closed 2 years ago

SteveSchafer-Innovent commented 3 years ago

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.

wimjongman commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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

wimjongman commented 3 years ago

@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 commented 3 years ago

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 https://github.com/eclipse/birt/issues/628#issuecomment-826648253. 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 commented 3 years ago

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

https://github.com/eclipse/jetty.project/pull/6404

patric-r commented 3 years ago

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

patric-r commented 3 years ago

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

wimjongman commented 3 years ago

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

patric-r commented 3 years ago

Which branch for what project? BIRT or Jetty?

wimjongman commented 3 years ago

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

patric-r commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

https://github.com/eclipse/birt/issues/628#issuecomment-826648253

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 commented 3 years ago

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

wimjongman commented 3 years ago

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

patric-r commented 2 years ago

What I did:

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

This sounds similar to what I got in April: https://github.com/eclipse/birt/issues/628#issuecomment-818264575

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

wimjongman commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@wimjongman any ideas?

wimjongman commented 2 years ago

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 commented 2 years ago

birt1 sure @wimjongman

wimjongman commented 2 years ago

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

wimjongman commented 2 years ago

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

image

patric-r commented 2 years ago

@wimjongman

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

image

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

wimjongman commented 2 years ago

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

patric-r commented 2 years ago

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

image

wimjongman commented 2 years ago

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

wimjongman commented 2 years ago

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 commented 2 years ago

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

image

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 commented 2 years ago

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

image

patric-r commented 2 years ago

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:

image

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

wimjongman commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

mvn package -DskipTests

wimjongman commented 2 years ago

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

 ../build/birt-packages/

directory

wimjongman commented 2 years ago

build failing again after merge with master

merks commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

wimjongman commented 2 years ago

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 commented 2 years ago

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

image

ruspl-afed commented 2 years ago

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

ruspl-afed commented 2 years ago

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 commented 2 years ago

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

wimjongman commented 2 years ago

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:

image

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

image

image