Issue #1447 without osgi layer

[claesrosell]

No description provided.

[merks]

That looks like a lot of work!

[claesrosell]

With this latest rebase against master I should be able to test the builds against Linux and Windows. Probably there will be runtime issues but hopefully not. It would be nice with at least one unit test for the webviewer.

[speckyspooky]

I cross the fingers that your changes will be stable, according to Ed it seems to be more like a small change and needed time to get it running.
If it is stable we and after the merge to the master I can do my specific designer tests for the special image tests (backgraound & svg) and alos ome special Excel-file tests with the diagonals and so on.

[merks]

Yes, I'm eagerly awaiting this being merged so that we can iron out any wrinkles that may remain.

[speckyspooky]

It's a little bit like "christmas time"

[claesrosell]

I have tested the "all in one" builds for Linux and Windows and the WebViewer works for them.

@wimjongman , this is a architectural change in some regard. Before we had two different solutions. One that used the OSGI default HTTP-service and one that started a dedicated server. The dedicated server was a mix of an OSGI web-bundle and programmatically configured WebAppContext. Only the second solution was used.

This commit replaces both solutions with a solution that is more "Jetty". To work in an OSGI environment some classloader configuration needs to be done + some stuff to for bundleresourse scheme to work.

[wimjongman]

Looks great. Thanks Claes!

[bvfalcon]

@claesrosell i it possible to replace such short-living repositories with long-living, at least on releasing?
Now in BIRT release 4.14.0 stands short-living non-existent eclipse platform. After replacing with long-living eclipse platform repository project does not assemble. Version 4.14.0 cannot be modified, also with minor changes.
The same thing can acquire with future release 4.15.0 -- now in master stands also short-living repository

[merks]

Are you doing your own builds against older tags/branches?

This file is generated and many of the locations are moving targets that might later cause build failure. This is the only one that is literally deleted though. So I suppose you are asking that all the locations refer to permanent stable locations before the final release commit?

[bvfalcon]

Are you doing your own builds against older tags/branches?
So I suppose you are asking that all the locations refer to permanent stable locations before the final release commit?

On both questions -- yes :)

Git-tags are very useful to create branches and usually are used for it -- fix bugs and customize something. May be this is the meaning of git-tags, I don't know. But in this case tag 4.14.0 contains link to non-existing eclipse platform repository (possible, night-build). The nearest release eclipse repository (4.30) does not contains some artifacts, which are used in BIRT config files (org.mortbay.jasper.apache-el as example). Therefore, it is impossible now to fix bugs in 4.14.0 and make a fork for it.

I think, it is very difficult to fix this problem for 4.14.0, but this problem can be prevented for future releases. May be with usage of maven-enforcer rules or something similar.

[merks]

Generally anything you change and for which a new build will be done will be on the master branch. There are no maintenance releases from the project. Note that the bundle org.mortbay.jasper.apache-el you mention comes from Orbit, not from the Platform.

Effectively all of these are moving targets, that you're asking us to lock down for you so that you can do builds using those.

      <repository location="https://download.eclipse.org/cbi/updates/license"/>
      <repository location="https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/nightly/latest"/>
      <repository location="https://download.eclipse.org/oomph/simrel-orbit-legacy/milestone/latest"/>
      <repository location="https://download.eclipse.org/tools/orbit/simrel/maven-jetty/release/latest"/>
      <repository location="https://download.eclipse.org/datatools/updates/milestone/latest"/>
      <repository location="https://download.eclipse.org/modeling/emf/emf/builds/milestone/latest"/>
      <repository location="https://download.eclipse.org/tools/gef/classic/releases/latest"/>
      <repository location="https://download.eclipse.org/webtools/repository/latest"/>
      <repository location="https://download.eclipse.org/justj/epp/release/latest"/>
      <repository location="https://download.eclipse.org/justj/jres/17/updates/release/latest"/>
      <repository location="https://download.eclipse.org/eclipse/updates/4.31-I-builds"/

What you're asking for it a fair bit of overhead during the release process and then isn't something the project team itself uses. So yes it's possible to do, but it's yet more work for us (me)...