User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
Thank you for this explanation, Scott
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?