From my fuzzy memories (which might be fuzzier than Scotts), the standalone runtime occurred around 3.7 time frame. Might have been earlier. One of the other contributing factors to keeping the legacy method was that was what Actuate was using in iServer and iHub for integration.
With that said, I second Scott's assessment. Whichever is easier. The point of the reboot is to get rid of the cruft, and package things in a better way for wider community adoption and support.
-John
-------- Original message --------
From: Scott Rosenbaum <scottr@xxxxxxxxxxxxxxxxxxxxx>
Date: 3/24/21 2:42 PM (GMT-06:00)
To: For developers on the BIRT project <birt-dev@xxxxxxxxxxx>
Subject: Re: [birt-dev] Unit tests
My vote is for what-ever is easiest, or whatever someone is willing to do the work to do.
My guess as we move forward is we are going to come to a lot of, "this isn't the best way to do this..." moments.
For right now, I think we have to do the minimum we can to get it working, and file issues for what needs to be done. Then we can start looking at priorities.
Fixing the build is certainly important, but I think there are some security issues (known old libraries with security vulnerabilities) that we should address first. But that is just one opinion.
It is good to have a way of working "without OSGi running". Many
Eclipse components like EMF or Xtext support so-called "standalone
setup" mode. But the way _how_ it is implemented there is much more,
well, elegant.
What a can see inside BIRT implementation regarding wrapping
platform looks a bit awkward. And tests show that Runtime-OSGI is
broken.
The way to fix the current state is:
1) avoid putting jars inside jars & fulfill Runtime-OSGI with
the "library" jars it needs
or
2) disable Runtime-OSGI test for a while that will be a step to
remove "-DskipTests" from our pipeline
We need to decide how to go forward.
Regards,
AF
24.03.2021 17:30, Scott Rosenbaum
пишет:
Alex,
I can't point you to any documentation, but I can give you
a bit of history from my fuzzy memories. First off, the goal
of the runtime was to have a way to distribute BIRT free from
the UI. The project wanted people to be able to include BIRT
in their applications, but we did not want them to have to
include all the UI components. So the Runtime is just those
components required to Design (design engine API), Run, and
Render reports with out any of the UI components present. When
this was first created, it was tightly bundled with the whole
eclipse platform, and required the engine to first start up
the platform in order for the Report Engine to work.
Once the project got going, there was a lot of demand from
our users to create something that was not dependent on the
Platform. "We just want to drop the jars in the lib directory
and run reports" was a common request.
So we modified the runtime to not be dependent on the
platform, which is now the modern runtime. But what about
users that have implemented BIRT using the 'old' way of doing
things with all the platform code, plugins directory, etc. We
didn't want to force them to change their code, or we wanted
to let them just drop in their plugins. We also had customers
that were deploying their reports within an RCP client. So
that is what led to the Runtime-OSGI. It is simply a backwards
compatible version of the Runtime.
Do we need to keep it? I don't know, my guess is no, but I
would leave that up to the community.
I was able to workaround this particular failure by adding
more bundles to birt-runtime-osgi, and then more and more.
And then I improved class loader creation a bit to consider
more than one folder ... but then finally I was blocked by
classes from Tidy.jar that archived inside
org.eclipse.birt.report.engine bundle.
Perhaps someone can point me to a document that explains
what is the specific goal of "birt-runtime-osgi" and why
BIRT needs wrapper layer around Eclipse Platform
Regards,
AF
24.03.2021 16:29, Steve Schafer пишет:
When using mvn package without -DskipTests
it gets class-not-found errors. Is this the correct way
to run the unit tests?