[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-ui-dev] Policy of the Platform projects with regards to tests accessing non-public members
|
I was just asking you because of your huge experience. ;-)
I never heard anybody saying to prefer Require-Bundle over Import-Package. If you search for it, you always get the same answer to prefer Import-Package. Bnd even ignores Require-Bundle from looking into the docs. And I remember an article where it was said that Require-Bundle was introduced because of one party wanting it, where osgi purists not wanting it.
I suppose performance issues could occur when you have big applications with a lot of plugins that export a lot of packages. But I would like to see some benchmarks before making decisions. Would be really interesting to hear from people that are saying to always use Require-Bundle.
Am 28.03.2016 21:48 schrieb "Daniel Megert" <
daniel_megert@xxxxxxxxxx>:
> @Dani
> Do you have any benchmarks that compare those two dependency approaches?
You ask the wrong person - I did not
make any performance related statements.
Dani
From:
Dirk Fauth <dirk.fauth@xxxxxxxxx>
To:
"Eclipse Platform
UI component developers list." <platform-ui-dev@xxxxxxxxxxx>
Date:
28.03.2016 21:28
Subject:
Re: [platform-ui-dev]
Policy of the Platform projects with regards to tests accessing non-public
members
Sent by:
platform-ui-dev-bounces@xxxxxxxxxxx
I don't know about performance issues with Require-Bundle.
Haven't looked at it from that point. If Require-Bundle is better in performance than preferring
ALWAYS one approach is wrong. Using Require-Bundle wouldn't be dynamic
which means you can not exchange implementations. For example you can not
exchange the logging implementation when using Require-Bundle, this only
works with Import-Package. Probably a good rule could be to use Import-Package
for third-party libraries that should be exchangeable and Require-Bundle
for application bundles that are not intended to be exchanged?
@Dani
Do you have any benchmarks that compare those two dependency approaches?
Am 28.03.2016 17:37 schrieb "Stefan Xenos" <sxenos@xxxxxxxxx>:
> The Require-Bundle stuff introduces more
> problems than it tries to solve.
You know, that's a funny thing. At EclipseCon I attended
a couple talks where people said you should never use Require-Bundle and
a couple talks where people said you should always use it.
The argument against Require-Bundle was that you can get
class name conflicts if you put identical jar files in two plugins with
different names.
The argument against Require-Package was that it was much
slower than Require-Bundle and slowed down startup time for large numbers
of plugins.
If the performance claims are true (I haven't confirmed
them), I have to say the argument in favor of Require-Bundle sounds much
stronger. The name conflicts only occur if you don't use a consistent naming
scheme so are largely only a theoretical problem (and even if it shows
up, it can be fixed by applying a consistent naming scheme). But the performance
problems were seen by end users in the real world and have no workaround.
- Stefan
On Mon, Mar 28, 2016, 6:03 AM Daniel Megert <daniel_megert@xxxxxxxxxx>
wrote:
Sorry to chime in late.
Existing plug-ins should not be converted to fragments as mentioned before.
The ugly thing using a fragment is that it would have packages in it with
no *.test.*in
the name (in order to access the hidden members). If the amount of hidden
members that you use is not high, you should consider to simply put the
tests into the existing test bundle and use org.eclipse.text.tests.Accessorto
access the hidden members.
Dani
From: Bruno
Medeiros <bruno.do.medeiros@xxxxxxxxx>
To: platform-ui-dev@xxxxxxxxxxx
Date: 08.03.2016
15:21
Subject: [platform-ui-dev]
Policy of the Platform projects with regards to tests accessing non-public
members
Sent by: platform-ui-dev-bounces@xxxxxxxxxxx
[Reposting from the IDE-Dev mailing list]
Hi,
I've started recently my first attempt at a big functionality patch for
an Eclipse Platform project. Previously I've only submitted very small,
trivial patches.
Whilst beginning to write tests for this functionality, I've noticed that
nearly all platform.ui and platform.text *test* plugins are separate plugins,
and not plugin-fragments of the plugin being tested. This makes it impossible
for the test code to directly access non-public members of the plugin being
tested (see https://rcpquickstart.wordpress.com/2007/06/20/unit-testing-plug-ins-with-fragments/).
This severely limits the usefulness/potential of what the tests can do,
so I'm wondering, is this some official code policy of the Platform projects,
is there some limitation prevent them from being converted to fragment
bundles, or did simply no one got around to doing it?
Would then a patch to change a test bundle to a fragment be accepted? The
tests I'm writing need access to non-public plugin members. (of org.eclipse.core.filebuffers
, if you're wondering)
--
Bruno Medeiros
https://twitter.com/brunodomedeiros_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev