Re: [platform-ui-dev] Policy of the Platform projects with regards to te

[Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>]

Hi,

By far the biggest performance problems I've seen in this space is the
reexporting who are in most regard the consequence of us using
Require-Bundle and afterwards splitting things up.

See https://dev.eclipse.org/mhonarc/lists/equinox-dev/msg08132.html

If there's really a problem with Import-Package we should make the
Equinox guys aware of it. Currently Require-Bundle vs Import-Package is
anyways a mood discussion because we are not versioning packages at all.

Tom

On 28.03.16 17:37, Stefan Xenos wrote:
>> 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
> <mailto: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
>     <mailto:bruno.do.medeiros@xxxxxxxxx>>
>     To:        platform-ui-dev@xxxxxxxxxxx
>     <mailto: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
>     <mailto: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 <mailto: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 <mailto: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
> 


-- 
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck