Re: [platform-dev] Build from source problem

Here you are seeing compilation failure in SWT. In SWT we have org.eclipse.swt as plugin and org.eclipse.swt. as fragment. In this case I am suspecting fragment is not getting loaded during the compilation of org.eclipse.swt.tests. if you have a x86_64 machine, can you please try building on that

Re: [platform-dev] Extensibility of the application model

> PDE to properly descibe/support this I don't think this is part of PDE but should be part of the "model-editor"/E4 support as it does not really has a meaning outside this scope. > by 4.20 as this feature is optional I think there is no need to rush as nothing hurts if users are just

Re: [platform-dev] Track SWT allocations

Indeed this should be enabled by default, really useful! Am 15.04.21 um 20:17 schrieb Wim Jongman: Hi Christophe, This is triggered when the widget is garbage collected (but was not disposed). Just set the property as described in the N It works really nice.

Re: [platform-dev] Build from source problem

export MAVEN_OPTS=-Xmx6G Didn't help (unless, of course, the lack of quotes doesn't affect the build) Part of the output: $ export MAVEN_OPTS=-Xmx6G $ mvn clean verify -DskipTests=true .. [INFO]

Re: [platform-dev] Track SWT allocations

Christoph* On Thu, Apr 15, 2021 at 8:17 PM Wim Jongman wrote: > Hi Christophe, > > > This is triggered when the widget is garbage collected (but was not > disposed). Just set the property as described in the N It works really > nice. > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=569752 >

Re: [platform-dev] Track SWT allocations

Hi Christophe, This is triggered when the widget is garbage collected (but was not disposed). Just set the property as described in the N It works really nice. https://bugs.eclipse.org/bugs/show_bug.cgi?id=569752 Cheers, Wim On Thu, Apr 15, 2021 at 5:16 PM Christoph Läubrich wrote: >

Re: [platform-dev] Track SWT allocations

That's it, thanks Laurent. is there any description how this works? I put for example in one of my views: new Font(parent.getDisplay(), parent.getFont().getFontData()); and get "not properly disposed" but at a time where the view is already opened, so is this triggered by garbage

Re: [platform-dev] Track SWT allocations

Hi Christoph, I think it is org.eclipse.swt.graphics.Resource.reportNonDisposed (see https://www.eclipse.org/eclipse/news/4.19/platform_isv.php) Regards, Laurent Le jeu. 15 avr. 2021 à 16:48, Christoph Läubrich a écrit : > I think I read in recent release notes that there is a new >

[platform-dev] Track SWT allocations

I think I read in recent release notes that there is a new system-property to allow for tracking of resource allocation (or missing de-allocations?) but can't find it anymore. Any tips? ___ platform-dev mailing list platform-dev@eclipse.org To

Re: [platform-dev] canonical way to handle optional dependencies

Thanks Tom. That is a very interesting option too. Is there a way from the main bundle to know if the fragment is available? In CDT's case "NoLeak" uses "UILeaker". Thanks Jonah ~~~ Jonah Graham Kichwa Coders www.kichwacoders.com On Thu, 15 Apr 2021 at 09:56, Tom Schindl via platform-dev <

Re: [platform-dev] canonical way to handle optional dependencies

Hi, An option to ban the offending guy from the codebase would be to move the offending class to a fragment. Let's say we have MyBundle + my.class.UILeaker - methodA(String) - methodB(String) - leakMethod(Shell) We could refactor it to: ---8<--- MyBundle +

Re: [platform-dev] canonical way to handle optional dependencies

It would be an option - but seems to me to be too much work. I also don't particularly like the idea of having org.eclipse.ui.* packages floating about the ecosystem that aren't the real ones. Thanks Jonah ~~~ Jonah Graham Kichwa Coders www.kichwacoders.com On Thu, 15 Apr 2021 at 09:16,

Re: [platform-dev] canonical way to handle optional dependencies

On 15 Apr 2021, at 14:05, Jonah Graham wrote: > > Most of the dependencies on the UI are relatively easy to resolve. However > one area is in the API - the API includes references to > org.eclipse.ui.dialogs.IOverwriteQuery, and in the headless case these > references are null. The problem

Re: [platform-dev] canonical way to handle optional dependencies

Wouldn't it be an option to simply supply a "cli-only" bundle that supplies the missing interfaces with dummy implementations? Am 15.04.21 um 15:04 schrieb Jonah Graham: On Thu, 15 Apr 2021 at 08:38, Christoph Läubrich > wrote: I think there is no "one fits

Re: [platform-dev] canonical way to handle optional dependencies

Thank you Wim for confirming I was on the right path and for the suggestion to wrap it all in a static method and class. Jonah ~~~ Jonah Graham Kichwa Coders www.kichwacoders.com On Thu, 15 Apr 2021 at 08:55, Wim Jongman wrote: > Yes, those are two good options. AFAIK there is no additional

Re: [platform-dev] canonical way to handle optional dependencies

On Thu, 15 Apr 2021 at 08:38, Christoph Läubrich wrote: > I think there is no "one fits all". Optional dependency are really > problematic to handle right and should be avoided as they often mean > your bundle/services are not well shaped. > Thanks - I do agree. > If you describe your case it

Re: [platform-dev] canonical way to handle optional dependencies

Yes, those are two good options. AFAIK there is no additional magic that you miss. I would wrap the dependency checking in a static class. e.g use if(DepBundleChecker.isAvailable()){ .. do something ..} instead of catching class loading exceptions. It's a bit more elegant but it stays a pita.

Re: [platform-dev] Build from source problem

I see one definite problem. MAVEN_OPTS=-Xmx2048m Is definitely not sufficient. To build eclipse you’ll need 6GB. Log is indicating problem with GC. In our regular builds we use export MAVEN_OPTS="-Xmx6G". use higher Xmx value and try to build again. Thanks Sravan From: Kirill

Re: [platform-dev] canonical way to handle optional dependencies

I think there is no "one fits all". Optional dependency are really problematic to handle right and should be avoided as they often mean your bundle/services are not well shaped. If you describe your case it might be possible to give some more advice. Am 15.04.21 um 13:38 schrieb Jonah Graham:

Re: [platform-dev] Build from source problem

Hello! I apologize for the long answer, I did not notice that the moderators tipped off my previous letter The sequence of commands literally looked like this: $ cd eclipse.platform.releng.aggregator /eclipse.platform.releng.aggregator$ export MAVEN_OPTS=-Xmx2048m

[platform-dev] canonical way to handle optional dependencies

Hello, (Not sure this is on topic for the list - but not sure where to ask.) What is the canonical way to check if an optional dependency is available? I know of a couple of methods: 1. wrapping code in try/catch and catching something wide like Throwable or NoClassDefFoundError 2. checking

Re: [platform-dev] Extensibility of the application model

Hi, I tend to disagree that we only want to contribute static data, if we use a service approach, we could eg in future add Predicate-Support (eg only merge that feature if you starting on locale-xyz, ...). I think we should provide ONE extension story and not multiple who are not really

Re: [platform-dev] Extensibility of the application model

Hi, Thanks Dirk for bringing the thread; and thanks Dirk for clarifying how a MANIFEST header is much more interesting than a service. That is IMO per se a good reason to stick to MANIFEST header and not "regress" to an OSGi service. So my concern is not any more about the technical aspects, but

Re: [platform-dev] Extensibility of the application model

What if we will reserve a default location inside OSGI-INF (say, OSGI-INF/e4/fragment.e4xmi) and then implement a header in the MANIFEST.MF just to override the default. Similary like it was done for  "Bundle-Localization:" Regards, AF 4/15/2021 9:24 AM, Christoph Läubrich пишет: First of

Re: [platform-dev] Extensibility of the application model

First of all, as mentioned before, DS is an implementation detail! Actually extensions can be registered by anything else (Activators, CDI, BluePrint, Remote Service API...) and are just services. The disadvantage of a service when we are talking about static meta-data like a fragement.xml

[platform-dev] Extensibility of the application model

Hi all, I have recently contributed a new way to extend the application model via fragment and processor that avoids the usage of the extension point. A model processor can be registered via DS, a model fragment can now be registered via a Manifest header. Mickael and Tom have now mentioned on