Re: [platform-dev] Migration of Eclipse TLP to GitHub complete

[Alex Blewitt]

Congratulations everyone on a successful transition to GitHub 

Sent from my iPhone 

> On 15 Apr 2022, at 07:59, Wim Jongman  wrote:
> 
> 
> Woot! Thank you so much!
> 
>> On Fri, 15 Apr 2022 at 13:21, Sravan K Lakkimsetti  
>> wrote:
>> Hi,
>> 
>>  
>> 
>> Thanks to enormous effort from Michael Istria in experimenting, identifying 
>> tasks on exactly what needs be done and migrating most of the repositories, 
>> we are now able to migrate all source code repositories from Eclipse TLP.
>> 
>> Thanks Michael for the effort. Special thanks to Alexander Kurtakov and 
>> Eclipse foundation(Frederic Gurr, Matt Ward, and team) for supporting 
>> eclipse platform team in this process.
>> 
>>  
>> 
>> As we have migrated Eclipse TLP projects to GitHub, please use GitHub issues 
>> of appropriate repositories to raise bugs/enhancements
>> 
>> Here are organisations used by Eclipse TLP
>> 
>> https://github.com/eclipse-equinox/  for OSGi runtime
>> https://github.com/eclipse-platform/ for common 
>> workspace/UI/workbench/IDE
>> https://github.com/eclipse-jdt/ for Java 
>> Development Tools
>> https://github.com/eclipse-pde/   for plugin 
>> development   
>>  
>> 
>> Thanks and Regards,
>> Sravan
>> 
>> Sravan Kumar Lakkimsetti
>> 
>> Eclipse Platform Co-lead
>> IBM India Pvt Ltd,
>> Embassy Golf Links Business Park, C Block,
>> Off Indiranagar-Kormangla Inner Ring Road,
>> Bangalore - 560071, India
>> 
>>  
>> 
>> ___
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To unsubscribe from this list, visit 
>> https://www.eclipse.org/mailman/listinfo/platform-dev
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Vote to stop bug auto-closing in all Eclipse platform projects

[Alex Blewitt]

+1

Sent from my iPhone 

> On 17 Feb 2022, at 08:58, Andrey Loskutov  wrote:
> 
> Hi all,
> 
> this is a follow up on PMC response 
> https://www.eclipse.org/lists/platform-dev/msg03319.html
> 
> As of today, this bug auto-closing is not active only for JDT project.
> 
> The proposal is to switch "off" bug auto-closing for the all Eclipse platform 
> projects, including Platform, JDT, PDE und Equinox.
> I don't think if we need an additional vote for PDE & Equinox, because the 
> only active committers there are same as on the Eclipse platform.
> 
> Therefore I would like to start voting to stop auto-closing bugs in bugzilla, 
> github, gitlab (or whatever else bug trackers we might use in the future) for 
> all Eclipse platform development.
> 
> I think it is enough to post your +1 / 0 / -1 as a reply on this mailing list.
> Everyone is welcome to vote but binding votes are committers`votes.
> I would propose to conclude the vote by the end of the next week (25 
> February).
> 
> Kind regards,
> Andrey Loskutov
> 
> Спасение утопающих - дело рук самих утопающих
> 
> https://www.eclipse.org/user/aloskutov
> 
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Fwd: [Bug 305081] [api] IInstallableUnit#getFilter is marked noReference

[Alex Blewitt]

I agree. It’s happened to many bugs I raised over the years even when they are 
provably still valid, and it gives a really bad impression to end users for 
limited gain.

Alex

Sent from my iPhone 

> On 10 Feb 2022, at 06:49, Christoph Läubrich  wrote:
> 
> +1 for disabling this.
> 
>> Am 10.02.22 um 07:45 schrieb Andrey Loskutov:
>> Yes, please.
>> I believe PMC once decided it would be a great idea to have less bugs open, 
>> so I would ask PMC to discuss the success of this practice once again, we 
>> should be able to reiterate on our processes.
>> I've complained https://www.eclipse.org/lists/jdt-dev/msg01419.html already 
>> (no result), Stephan too (before he silently quit) 
>> https://www.eclipse.org/lists/eclipse-pmc/msg03833.html, I know other 
>> committers not happy with this practice, and we receive constant feedback 
>> from users that this *is* a bad practice.
>> It doesn't help anyone, just creates bad impression for remaining few users 
>> who take time to fill bug reports.
>> Am 10. Februar 2022 07:23:49 MEZ schrieb Ed Merks :
>>> Can we please turn off this "Genie" that does this to open bugs? I've
>>> asked about this before and I really don't like it.  This time I want to
>>> really make it stop.  I think such a behavior creates a really bad
>>> impression, i.e., that we manage bugs so poorly that we need a bot that
>>> times them out automatically because we just can't be bothered to manage
>>> this properly.  Yes, of course I know there is much time involved in
>>> triage, but that's exactly the point.  I triaged all the p2 bugs some
>>> time ago to reduce it to the ones that are open so these are legitimate
>>> issues that should not be auto-closed...
>>> 
>>> Regards,
>>> Ed
>> --
>> Kind regards,
>> Andrey Loskutov
>> https://www.eclipse.org/user/aloskutov
>> Спасение утопающих - дело рук самих утопающих
>> ___
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To unsubscribe from this list, visit 
>> https://www.eclipse.org/mailman/listinfo/platform-dev
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Eclipse/SWT source repositories?

[Alex Blewitt]

https://git.eclipse.org/c/

Alex

Sent from my iPhone 

> On 9 Dec 2021, at 12:22, Thomas Singer  wrote:
> 
> Hi,
> 
> Where can I find the source code repositories for Eclipse, especially for 
> org.eclipse.swt/swt.binaries? The eclipse.org website is extremely confusing 
> and even Google did not help me.
> 
> Thanks in advance.
> 
> -- 
> Best regards,
> Thomas Singer
> =
> syntevo GmbH
> www.syntevo.com
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] org.eclipse.jdt.core.compiler.problem.invalidJavadoc=error settings in platform code

[Alex Blewitt]

Not that it answers your question directly, but you can use “git update-index 
—assume-unchanged” to make it appear that you haven’t changed the file and so 
not to be considered as a diff when pulling.

I have a wrapper script called “git forget” because it’s easier to type.

https://github.com/alblue/scripts/blob/main/git-forget

Sent from my iPhone 

> On 18 Aug 2021, at 18:28, Christoph Läubrich  wrote:
> 
> One thing I always wonder, most projects in platform use a project specific 
> setting
> 
> org.eclipse.jdt.core.compiler.problem.invalidJavadoc=error
> 
> but with this settings enabled there are hundreds of errors and the workspace 
> is nearly unusable.
> 
> So my first task is always to change the error to warning to at least get a 
> valid build.
> 
> I can understand that one want to have valid javadoc, but enabling this and 
> not fixing the errors seems strange to me. So how is this to be handeled? I 
> really don't like to change/reset settings each time I pull the changes from 
> the repo...
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Source Tarball Eclipse 4.17.0

[Alex Blewitt]

My recollection of running that job in the past is that it puts the binaries a 
few levels above in the binaries project so that it’s in the right place for 
the subsequent eclipse build.

Alex

Sent from my iPhone 

> On 18 Jun 2021, at 08:32, Kirill Kotovich  wrote:
> 
> I ran the following command but no new files appeared after the build.
> 
> main@ws801:~/swt$ ant -f
> ./eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.e2k/build.xml
> build_libraries
> 
> init_build:
> 
> build_local:
>   [exec] Cairo found, compiling SWT support for the cairo graphics library.
>   [exec] libjawt.so found, the SWT/AWT integration library will be compiled.
>   [exec] Building SWT/GTK+ for Architectures: linux e2k
>   [exec] *** Warning: Cannot compile Webkit2 Extension because
> 'pkg-config --exists webkit2gtk-web-extension-4.0' check failed.
> Please install webkitgtk4-devel.ARCH on your system.
>   [exec] Building GTK3 bindings:
> 
>   [exec] rm -f *.o *.so
>   [exec] GTK3 Build succeeded
> [delete] Deleting directory
> /home/main/swt/eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.e2k/tmpdir
> 
> refresh_fragment:
> 
> BUILD SUCCESSFUL
> Total time: 1 minute 28 seconds
> main@ws801:~/swt$ ls
> /home/main/swt/eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.e2k
> about_files   fragment.properties  
> libswt-pi3-gtk-4936r26.so
> about.htmllibswt-atk-gtk-4936r26.so
> libswt-webkit-gtk-4936r26.so
> build.properties  libswt-awt-gtk-4936r26.soMETA-INF
> build.sha1libswt-cairo-gtk-4936r26.so  mvnBuildSwtJar.sh
> build.xml libswt-glx-gtk-4936r26.sopom.xml
> forceQualifierUpdate.txt  libswt-gtk-4936r26.sowebkitextensions4936r26
> 
> пт, 18 июн. 2021 г. в 07:10, Sravan K Lakkimsetti :
>> Hi,
>> We will need build native fragment for e2k platform. This will require some 
>> trials.
>> Clone eclipse.platform.swt and clipse.platform.swt.binaries repos
>> Duplicate 
>> eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.x86_64 as 
>> eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.
>> Update build.xml with the platform architecture
>> Run ant target “build_libraries” in build.xml (completes in less than 10 
>> minutes)
>>   ant -f /build.xml build_libraries
>> At minimum you’ll need gtk3 development libraries and jdk to be installed. I 
>> don’t remember off hand on other libraries, but the error messages form ant 
>> command should give you clues on other dev libraries to be installed.
>> Once built you’ll need to commit the newly built libraries and then start 
>> full maven build.
>> Thanks
>> Sravan
>> From: Kirill Kotovich 
>> Sent: 18 June 2021 02:19
>> To: Eclipse platform general developers list. 
>> Subject: [EXTERNAL] Re: [platform-dev] Source Tarball Eclipse 4.17.0
>> Sounds interesting. I understand correctly that to build SWT on Linux it is 
>> enough to clone "eclipse.platform.swt/bundles/org.eclipse.swt", rename 
>> ".classpath_gtk" to ".classpath" and run "mvn verify" in the root of the 
>> project? These articles pushed me to this conclusion:
>> https://wiki.eclipse.org/SWT/Developer_Guide
>> https://github.com/eclipse/eclipse.platform.swt/tree/master/bundles/org.eclipse.swt
>> чт, 17 июн. 2021 г. в 06:57, Sravan K Lakkimsetti :
>> The problem here is non availability of swt native fragment for e2k 
>> platform. We need to create native fragment for e2k platform for this to 
>> work. If are interested you can try creating fragments for swt and launcher.
>> Thanks
>> Sravan
>> -Original Message-
>> From: Kirill Kotovich 
>> Sent: 17 June 2021 01:25
>> To: Eclipse platform general developers list. 
>> Subject: [EXTERNAL] Re: [platform-dev] Source Tarball Eclipse 4.17.0
>> Thank you, everything was found. I was confused by the lack of the 
>> "org.eclipse.releng.tychoeclipsebuilder" directory in the project root, and 
>> searching for the required packages in the 
>> "eclipse.platform.releng.tychoeclipsebuilder" directory failed due to my 
>> carelessness.
>> Can you help with another problem? Building Eclipse 4.17 on Windows and 
>> Ubuntu for amd64 was successful, but trying to build Eclipse 4.17 on Linux 
>> on an unsupported e2k platform failed with the following
>> errors:
>> 
>> [ERROR] Failed to execute goal
>> org.eclipse.tycho:tycho-compiler-plugin:2.0.0:compile
>> (default-compile) on project org.eclipse.swt.tests: Compilation
>> failure: Compilation failure:
>> [ERROR] 
>> /home/main/eclipse.platform.releng.aggregator/eclipse.platform.swt/tests/org.eclipse.swt.tests/JUnit
>> Tests/org/eclipse/swt/tests/junit/Test_org_eclipse_swt_custom_BidiSegmentListener.java:[22]
>> [ERROR] import org.eclipse.swt.SWT;
>> [ERROR] ^^^
>> [ERROR] The import org.eclipse.swt.SWT cannot be resolved [ERROR] 
>> 

Re: [platform-dev] Source Tarball Eclipse 4.17.0

[Alex Blewitt]

It looks like in the mail two dashes - - have combined to form an mdash — which 
might explain why your command didn't work. 

Alex

Sent from my iPhone 

> On 11 Jun 2021, at 19:35, Kirill Kotovich  wrote:
> 
> I lied. With Eclipse IDE managed to clone with submodules
> 
> пт, 11 июн. 2021 г. в 21:05, Kirill Kotovich :
>> 
>> When trying to run the command:
>> "git clone -b R4_17_maintenance –recurse-submodules
>> https://git.eclipse.org/r/platform/eclipse.platform.releng.aggregator.git;
>> 
>> An error is displayed in the terminal:
>> "fatal: the repository «–recurse-submodules» does not exist"
>> 
>> It also failed to clone through the Eclipse IDE
>> 
>> --
>> With gratitude,
>> 
>> Kirill
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

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

[Alex Blewitt]

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 is that if it is part of the API (ie method argument, return value) 
then the class has to be loaded in order to call that method, even with a null 
value. If you attempt to call this method then it will attempt to load the ui 
class and when it’s not found it will raise a ClassNotFound error (or similar).

In order to fix it you’ll need to change the API to take a more generic object 
(like Object) which will allow you to call the method with a null value, and 
you can pass through the untyped value to where it needs to be used, casting it 
at the point of use (or using a reflective call that obscure the types).

You may find the right evolution path is to create a second method with the 
same signature but using Object in place, migrating the code paths to that 
method, and leaving a call path from the old to the new. You can then mark the 
old API as deprecated and invite callers to move over to the new call.

Using the same method name has both advantages and disadvantages; if you are 
calling with null then you’ll need to disambiguate by casting to Object but 
might facilitate changeover when you delete the old method; if you use a new 
name then callers will have to change source code to take advantage of the 
changed api but will likely be easier to determine if code has been moved from 
old to new patterns.

In either case it is a new method signature which won’t be source compatible 
for old callers, so it’s probably a major version bump when you remove the old 
call path.

Alex
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Workspace location, properties and declarative services

[Alex Blewitt]

> On 23 Mar 2021, at 08:56, Lars Vogel  wrote:
> 
> Hi Alex,
> 
> What about sending out an event via the EventAdmin service once the
> workspace location changes?  We currently have the UI events in e4 via
> the IEventBroker for example for the application start.

The problem is that events published via EventBroker are ephemeral. If an event 
has been published and then your bundle currently runs, you don’t have a way of 
picking that up. The EGit integration looks at startup whether the Platform is 
running or not, and takes different actions based on the assumption that it’s 
been triggered before/after the event has been released. For services which 
must be started I think relying on EventAdmin is not the best trigger.

If Eclipse supported the config admin service, you could replace the OSGi 
Location services that get published with a dynamic config policy, and then 
have the workspace service depend on a configuration policy being set. As it 
stands, the Location services are a minimal service wrapper around such 
configuration with some supporting methods.

Alex

___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Workspace location, properties and declarative services

[Alex Blewitt]

I’m trying to migrate the Workspace initialisation from an Activator start() 
method to a Declarative Service in 
https://git.eclipse.org/r/c/platform/eclipse.platform.resources/+/178145 


Although this works if the workspace location has been set with a -data flag, 
it doesn’t work if the user decides to change the location later on. That’s 
because the IDEApplication prompts the user for a location in the 
org.eclipse.ui.ide bundle, which in turn, has a dependency on the 
org.eclipse.core.resources bundle that defines the workspace.

The following happens at startup:

* Equinox publishes an org.eclipse.services.datalocation.Location of type 
osgi.instance.area

https://github.com/eclipse/rt.equinox.framework/blob/1c00fefd63ceff66a96d66f578a30a5677864877/bundles/org.eclipse.osgi/container/src/org/eclipse/osgi/internal/framework/SystemBundleActivator.java#L178
 


* IDEApplication prompts the user for a dialog, and then sets the instance 
location:

https://github.com/eclipse/eclipse.platform.ui/blob/b65540939ac72f0c57a7b2ed32235fcfc9471361/bundles/org.eclipse.ui.ide.application/src/org/eclipse/ui/internal/ide/application/IDEApplication.java#L313
 


* This is ultimately accessible from 
Workspace->LocalMetaArea->Activator.installLocation

https://github.com/eclipse/rt.equinox.bundles/blob/e4e1bb43f2b17f84b39c6361e938bd9ae7e6e086/bundles/org.eclipse.equinox.common/src/org/eclipse/core/internal/runtime/Activator.java#L55
 

 

The problem is that because the Location is published at startup, whether or 
not it has been set, it’s not trivial to configure to DS to set up a dependency 
to arrive when the value has been changed. It’s also not clear what should 
happen to configurations that use ResourcesPlugin but don’t use the 
IDEApplication.

The problem is that if we launch the Workspace with no dependencies, it will 
default to and initially set up) the default value, unless @noDefault is 
specified, in which case it will likely error out. 

We could set up a dependency such that the Workspace only is launched when an 
osgi.instance.area Location is published, but Equinox will do this 
automatically unless the @noDefault is given.

Finally, we could publish a service/placeholder/Location in IDEApplication, 
which could be used to trigger the creation of the Workspace by DS.

Ultimately I think the only way of solving it is to either set the URL of the 
workspace as a service property of the location when it’s published, and when 
the URL is updated then update the service properties accordingly. Thus we 
could have the creation of the workspace dependent upon a service being 
published:

{org.eclipse.osgi.service.datalocation.Location}={type=osgi.instance.area}
=>
{org.eclipse.osgi.service.datalocation.Location}={type=osgi.instance.area,url=/path/to/workspace}

We could then set up the DS component for the Workspace to listen to a service 
filter that has the URL set as a property.

https://github.com/eclipse/rt.equinox.framework/blob/1c00fefd63ceff66a96d66f578a30a5677864877/bundles/org.eclipse.osgi/supplement/src/org/eclipse/osgi/service/datalocation/Location.java#L37
 


Thoughts?

Alex___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Has the time come?

[Alex Blewitt]

I think the move to GitHub would be a way of getting more users interested in 
contributing; however, I think for that to work we need to be able to do builds 
on GitHub as well (or report test failures there).

I’m not sure how or whether GitHub actions could be used for the builds, but 
the open jdk team has some great workflows for interacting with comments.

A bigger problem is that it is not trivial to set up or run builds/tests. I 
think we would need to address that first.

Alex

Sent from my iPhone 

> On 10 Mar 2021, at 14:56, Wim Jongman  wrote:
> 
> 
> Maybe we can skip adding features completely for one or two releases and have 
> all hands focusing entirely on the releng process. 
> 
>> On Wed, Mar 10, 2021 at 3:42 PM Christoph Läubrich  
>> wrote:
>> +1 for move to github, we should take the opportunity to merge several 
>> repos, this cluttering of code is just a mess.
>> 
>> 
>> Am 10.03.21 um 15:37 schrieb Wim Jongman:
>> > Hi,
>> > 
>> > Can we discuss the move to GitHub again?
>> > 
>> > Cons:
>> > * No Gerrit -> best review system ever
>> > 
>> > Pros:
>> > * All the developers are there.
>> > * No Gerrit -> easy entry for new devs
>> > 
>> > Cheers,
>> > 
>> > Wim
>> ___
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To unsubscribe from this list, visit 
>> https://www.eclipse.org/mailman/listinfo/platform-dev
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Cannot Windows SWT native libraries due to problems with

[Alex Blewitt]

I believe there’s two downloads; one with the LTS And one with the latest 
jdk/jre, And if you don’t install a different jdk then it will default to using 
the one that eclipse itself is using.

Alex

Sent from my iPhone 

> On 22 Feb 2021, at 23:10, Stefan Kowski  wrote:
> 
> I installed Eclipse Committer 2020-12 to make changes to the Windows SWT
> GDI+ native library.
> 
> After running the build.xml in project
> "org.eclipse.swt.win32.win32.x86_64" with target "build_libraries", I
> get an error message:
> 
> "Buildfile:
> C:\Users\StefanKowski\git\eclipse.platform.swt.binaries\bundles\org.eclipse.swt.win32.win32.x86_64\build.xml
> init_fragment:
> Java 15 has removed Nashorn, you must provide an engine for running
> JavaScript yourself. GraalVM JavaScript currently is the preferred option.
> 
> BUILD FAILED"
> 
> Eclipse comes von JDK 15 bundled, do I have to install an external JDK (11)?
> 
> Regards
> Stefan
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Using newly built SWT native libraries in Eclipse SDK unit tests

[Alex Blewitt]

It looks like the version of your SWT and the version of the Eclipse SDK you’re 
using don’t match.

SWT loads the native library based on an explicit version number, so that it 
can be clear that it matches up the two.

If you use the version of the Eclipse SDK and SWT from the same release, you 
should be OK. Otherwise you may find you have subtle differences between the 
two.

You can check out the version of SWT from the Git repo using the tag associated 
with your platform’s release to make sure you have the same number.

Trying to use a different numbered release by changing the number is unlikely 
to work and will fail in surprising ways.

Alex

> On 22 Feb 2021, at 20:55, Stefan Kowski  wrote:
> 
> Hi,
> 
> I made some changes in the Windows SWT GDI+ native libraries, using
> org.eclipse.swt.win32.win32.x86_64.source_3.115.100.v20201202-1103.jar
> as starting point.
> 
> After the build, I have the new DLL files swt-gdip-win32-4940r23.dll and
> swt-win32-4940r23.dll.
> 
> I copied them to C:\Users\StefanKowski\.swt\lib\win32\x86_64.
> 
> I also installed the Eclipse SDK (eclipse-SDK-4.18-win32-x86_64.zip).
> 
> When I run an example, e.g. ControlExample.java, the native libraries
> cannot be found:
> 
> Exception in thread "main" java.lang.UnsatisfiedLinkError: Could not
> load SWT library. Reasons:
>no swt-win32-4942r22 in java.library.path:
> C:\SDE\eclipse-jee-2020.12\eclipse\plugins...
>no swt-win32 in java.library.path:
> C:\SDE\eclipse-jee-2020.12\eclipse\plugins
>Can't load library:
> C:\Users\StefanKowski\.swt\lib\win32\x86_64\swt-win32-4942r22.dll
>Can't load library:
> C:\Users\StefanKowski\.swt\lib\win32\x86_64\swt-win32.dll
> 
> How can I change the version number to "440r23" for using my self-built
> versions? It may work with renaming the files, but I think there is a
> proper configuration
> 
> Regards
> Stefan
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/platform-dev

___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Parallel Builds

[Alex Blewitt]

IIRC the parallel builds works if you have independent projects. So if you have 
B->A and C->A, then you can build A, then build B in parallel.

If you have C->B->A then there won’t be any parallelisation.

ISTR that B is blocked until A is built completely, even if parts of B could go 
ahead from a pure Java perspective, because we build projects in atomic units.

Alex

Sent from my iPhone 

> On 22 Jan 2021, at 12:34, Wim Jongman  wrote:
> 
> 
> Cool.
> 
> I am new to this too. I have activated it (set to 5 (5 jobs?). But a full 
> java build takes just as long and I do not see multiple build jobs.
> 
> I have a 270 project workspace. For normal 99% work, the incremental build is 
> working fine. It is slow (or rather, it takes a long time) when a full 
> rebuild needs to take place, which is somewhat annoying. It occurs mostly 
> when adding/removing dependencies. 
> 
> 
> 
>> On Fri, Jan 22, 2021 at 1:25 PM Mickael Istria  wrote:
>>> On Fri, Jan 22, 2021 at 1:04 PM Alex Blewitt  wrote:
>>> Can we update the default to ‘true’ or ‘max processors’ or ‘half 
>>> processors’ or similar, so we can enable it out of the box for every 
>>> project build type? If not, what’s stoppping us from doing so?
>> 
>> 
>> When this feature was introduced some years ago, there were some 
>> communication about it asking for people to try it and give feedback. Based 
>> on this feedback, we could then decide to change default or not. We didn't 
>> receive any substantial feedback and my first impression back then is that 
>> because JDT being a bit greedy in scheduling rules, changing default in the 
>> IDE didn't make a difference back then. So it has remained as it.
>> If enough people are willing to try it in their workspace, verify it works 
>> as expected, that it creates a performance gain, report any bug they face; 
>> then we could decide to change the default based on that feedback.
>> ___
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To unsubscribe from this list, visit 
>> https://www.eclipse.org/mailman/listinfo/platform-dev
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Gerrit Spam

[Alex Blewitt]

This is added by the Gerrit Trigger.

https://plugins.jenkins.io/gerrit-trigger/ 


There’s a ’silent’ mode, which presumably suppresses that message, but I don’t 
know if it also suppresses the build succeed/failed messages either.

Alex

> On 25 Jan 2021, at 13:30, Wim Jongman  wrote:
> 
> Hi,
> 
> I can do without the "Build started" messages from Gerrit.
> 
> Do I have supporters for this? Otherwise, I don't want to waste the 
> webmaster's time asking for a solution.
> 
> Cheers,
> 
> Wim
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/platform-dev

___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Deprecating Bugzilla and Gerrrit?

[Alex Blewitt]

A mail sent out by Denis suggests that Bugzilla and Gerrit are not long for 
this (eclipse) world, and that we will all be able to use GitHub or GitLab:

https://www.eclipse.org/lists/eclipse.org-committers/msg01247.html

I think this means we lose access to the last couple of decades of bug 
references and won’t be able to do per commit review and testing any more.

Alex

Sent from my iPhone ___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Running multiple instances of eclipse in MacOS

[Alex Blewitt]

If you run the app from the command line you can launch a second instance. You 
have to use the name of the executable and the -data argument to launch it.

/path/to/Eclipse.app/Contents/MacOS/eclipse -data /path/to/workspace

You can also use open -n for an app:

open -n /path/to/Eclipse.app

If you want to have a double clickable app then you can always install two 
Eclipse instances using the Oomph installer.

Alex

Sent from my iPhone 

> On 7 Dec 2020, at 20:55, Gayan Perera  wrote:
> 
> 
> Hi Friends,
> Do you have any workarounds to get multiple instances on the same eclipse 
> installation for different workspaces on MacOS. Or may be a plugin that i can 
> use ?
> 
> Best regards,
> Gayan.
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] MacOS .dmg vs .tar.gz

[Alex Blewitt]

In that case, can we get the Oomph installer to publish the .tar.gz as .tgz
instead? For the case where it's hosted on an external download server, it
gives a better experience. Perhaps bug 568788 should be moved to the Oomph
queue instead?

On Tue, Oct 13, 2020 at 6:11 PM Jonah Graham  wrote:

> Hello folks,
>
> The Eclipse Platform delivers Mac packages as only DMG files. This is what
> EPP does too. The Oomph Eclipse Installer publishes both .tar.gz and .dmg
> files, but only the dmg is linked from eclipse.org/download.
>
> I am not familiar with MacOSX, so this question may be unreasonable.
>
> Is it possible to publish both .tar.gz and .dmg for MacOSX?
>
> Thanks,
> Jonah
>
>
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] MacOS .dmg vs .tar.gz

[Alex Blewitt]

> On 13 Nov 2020, at 11:42, Ed Merks  wrote:
> Alex,
> 
> I wonder how notarization plays into this picture?  I was under the 
> impression that only the *.dmg is notarized and that notarization is 
> important...
> 
Notarising is important, sure :) Notarisation happens at an app level though 
rather than DMG as far as macOS is concerned.

However, it may be that the Eclipse build process does the notarisation step as 
part of building the DMG, so it could be hat the .tar.gz isn’t notarized while 
the content of the dmg is. I can verify this and confirm.
> I find the whole discussion very odd given the platform has just removed its 
> *.tar.gz going forward but now "we" want EPP packages to have them, though to 
> rename them to something else.
> 
I’m happy to get rid of the .tar.gz so it’s not something that I was asking EPP 
to provide directly. This thread was arguing for the publishing of the .tar.gz 
links which are apparently being built still using EPP.

I am personally happy with the idea of only building the .dmg; others on this 
thread have a different opinion.
> Why is the platform moving away from this while the EPP is moving sideways 
> back toward it?   Has any user ever asked for a *.tar.gz?   Something is 
> wrong with the overall big picture…
There are a couple of people on this thread who have. Provably there’s no 
benefit of using .tar.gz (other than personal preference) so I agree that it’s 
a big picture issue, and I wasn’t trying to fight or revert that.

All I was saying in https://bugs.eclipse.org/bugs/show_bug.cgi?id=568788 
 was that if we are 
continuing to produce the gzipp’d tar files, then we should use the .tgz 
extension instead of .tar.gz.

If we’re not producing the targz files then feel free to close as wontfix :)

Alex

___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] MacOS .dmg vs .tar.gz

[Alex Blewitt]

> On 11 Nov 2020, at 18:02, Liviu Ionescu  wrote:
> 
> 
> 
>> On 11 Nov 2020, at 19:56, Alex Blewitt  wrote:
>> 
>> No, as it doesn’t provide an easy means to drag and drop it to the 
>> Applications folder.
> 
> This assumes you have a single Eclipse instance in your system.
> 
> Totally inaccurate. 

Of course I have a few copies of Eclipse lying around – it is, after all, the 
platform general developers list. But that doesn’t mean end users will. In 
fact, when you drag-and-drop on macOS to the /Applications folder, it will ask 
you if you want to replace the existing one – which is the right answer for 99% 
of the Eclipse userbase who just want to write code.

> In embedded development you may very well have a one Eclipse for each target 
> platform, or even for each project, thus the recommended way is to install as 
> many Eclipses as you want in your home folder.

In general Eclipse users on macOS do not do this; nor do other users on other 
platforms. The fact that you can do so is of course one of the benefits of open 
source in that users can do what they want.

> Actually installing Eclipse in /Applications should be discouraged.

That is the standard location for installing apps on macOS. And, to close off 
this argument (for I feel that there is nothing more that needs to be said) the 
same pattern is true of the other main Eclipse competitor in the IDE space:

https://www.jetbrains.com/idea/download/download-thanks.html?platform=mac=IIC
 
<https://www.jetbrains.com/idea/download/download-thanks.html?platform=mac=IIC>



Alex___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] MacOS .dmg vs .tar.gz

[Alex Blewitt]

On 11 Nov 2020, at 17:52, Liviu Ionescu  wrote:
> 
>> On 11 Nov 2020, at 19:11, Alex Blewitt  wrote:
>> 
>> Because it’s a strictly worse experience
> 
> By what criteria? Can you accept that this is a subjective matter and others 
> may think differently?

If and only if you believe the dialogs that I captured in my prior mail were 
identical.

> Isn't the Eclipse.app extracted from the archive as functional as the one 
> extracted from the .dmg?

No, as it doesn’t provide an easy means to drag and drop it to the Applications 
folder.

> Who cares about 'kMDItemWhereFrom'?

Clearly not you :-)

> The thousands and thousands of users of my project never did, why should they 
> do it?

The millions of Eclipse users don’t care about tar.gz files, so why should we 
do it?

Alex
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] MacOS .dmg vs .tar.gz

[Alex Blewitt]

> On 11 Nov 2020, at 16:54, Liviu Ionescu  wrote:
> 
>> On 11 Nov 2020, at 18:46, Alex Blewitt  wrote:
>> 
>> On macOS, the .dmg approach is strictly better experience than the .tar.gz 
>> approach, so continuing to use this makes sense to me.
> 
> The point was not to remove the link to the .dmg, but, since the .tar.gz file 
> is already available, why hide it and not give the choice to the user?

Because it’s a strictly worse experience, and there’s no point in providing 
both of them?

Alex
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] MacOS .dmg vs .tar.gz

[Alex Blewitt]

How was the dmg created? Can you mount it and see if the quarantine bits are in 
the dmg itself? If you downloaded it from a tgz, then created a dmg from that, 
you’d bake in the quarantine flags into the dmg itself. 

If you can give me the exact url you downloaded I can verify it for you. But I 
have not noticed this behaviour on the Eclipse Platform DMGs so it’s not an 
issue with either Eclipse or DMGs themselves.

Alex

Sent from my iPhone 

> On 6 Nov 2020, at 22:18, Liviu Ionescu  wrote:
> 
> 
> 
>> On 7 Nov 2020, at 00:05, Jonah Graham  wrote:
>> 
>> Hi Liviu,
>> 
>> Is that different to how 2020-09 R is?
> 
> I first noticed the quarantine attribute on a 2020-09 R Eclipse CPP that I 
> used to test my new version of Embed CDT, and I was quite confused; then I 
> tested the two files from the same folder, to be sure the comparison makes 
> sense.
> 
>> How about compared to the eclipse Platform's M2: 
>> https://download.eclipse.org/eclipse/downloads/drops4/I20201106-0710/
> 
> I'm not sure I understood your request, but I downloaded 
> eclipse-SDK-I20201106-0710-macosx-cocoa-x86_64.dmg from there, copied the 
> Eclipse.app to ~/tmp and its content is also quarantined; same as before.
> 
> 
> Regards,
> 
> Liviu
> 
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] ant properties provided via org.eclipse.ant.core.antProperties, working as intended?

[Alex Blewitt]

Have a look at https://github.com/eclipse/eclipse.platform  
ant/org.eclipse.ant.launching/src/org/eclipse/ant/internal/launching/launchConfigurations/RemoteAntRuntimeProcess.java

That might not be the exact file but it will be somewhere around there. 

Alex 

Sent from my iPhone 

> On 1 Nov 2020, at 22:39, Homer, Tony  wrote:
> 
> 
> I wrote a plugin which provides an org.eclipse.ant.core.antProperties 
> extension.  The property it provides shows up in the Ant properties editor 
> along with the eclipse-provided ant properties.  However, when I execute an 
> ant target (via the Eclipse ant view) that references the property, the 
> property is not accessible.  Similarly, the eclipse-provided ant property, 
> eclipse.home, is not accessible.  If I define a property (ant.foo with value 
> “foo”) in the Ant properties page, it is accessible.  Ant built-ins (such as 
> ant.home) are accessible. 
>  
> Here is an example antfile + output from Eclipse console that demonstrates 
> this.
>  
> ant.xml contents:
> 
> 
> 
> 
> 
> 
> 
> 
>  
> console output:
> Buildfile: 
> /home/tony/spinny_mount/development/test/runtime-test/AntTest/ant.xml
> echo-ant.tmpdir:
>  [echo] ant.foo: foo
>  [echo] ant.home: 
> /home/tony/spinny_mount/development/iss/workspace_nda_clean/.metadata/.plugins/org.eclipse.pde.core/.bundle_pool/plugins/org.apache.ant_1.10.8.v20200515-1239
>  [echo] eclipse.home: ${eclipse.home}
>  [echo] ant.tmpdir: ${ant.tmpdir}
> BUILD SUCCESSFUL
> Total time: 200 milliseconds
>  
> Is this a bug or am I attempting to use the feature incorrectly?
>  
> Additional background for context: I am attempting to mitigate CVE-2020-11979 
> in an Eclipse product.  Please refer to the advisory from Apache Ant:
> https://lists.apache.org/thread.html/rc3c8ef9724b5b1e171529b47f4b35cb7920edfb6e917fa21eb6c64ea%40%3Cdev.ant.apache.org%3E
> Eclipse currently includes Ant 1.10.8 which is affected by CVE-2020-11979, 
> but even if updated to use 1.10.9, the advisory recommends that the directory 
> be explicitly created with the correct permissions and the ant.tmpdir 
> property be set so that ant will use it.
> My mitigation plan is to create a temp folder with the recommended 
> permissions, then set the ant.tmpdir property using the 
> org.eclipse.ant.core.antProperties extension point.  I wrote a plugin which 
> successfully sets ant.tmpdir to the desired value, but when I attempt to 
> access the value in an antfile in eclipse, exercising the relevant target 
> shows that the property is not available to ant.
>  
> Is there some way other than via the org.eclipse.ant.core.antProperties 
> extension point to have Eclipse pass the ant.tmpdir property to Ant?
>  
> FWIW, I tried to step further into the code to see how the set of arguments 
> is passed to Ant, but I couldn’t find my way to the class which performs the 
> actual Ant invocation.  It appears that there may be an extra class loader 
> which loads Ant and some of the inner eclipse ant wrapping implementation, 
> maybe for security reasons?  In any case, I haven’t been able to puzzle out 
> how the set of properties in the Ant property editor get passed to Ant.  
> Because of this, I can’t tell if this is a bug or user error.  If someone can 
> guide me in how to troubleshoot more effectively or identify the right place 
> to look and how to configure my Eclipse environment so that I can set a 
> breakpoint there, I’d be interested in delving further.
>  
> Thanks!
> Tony Homer
>  
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Commit messages

[Alex Blewitt]

> On 24 Oct 2020, at 13:12, Wim Jongman  wrote:
> 
> Andrey recently pointed out on a couple of commits that commit messages could 
> be better. I agree with that.

Do you have specific or generic types of advice of what could be made better 
about the commit messages?

Alex

Sent from my iPhone
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Accidental push to eclipse.platform.debug

[Alex Blewitt]

Thanks all :)

I kicked off a mini build on top of master in platform.debug and it went 
through successfully, so I will leave the commit as is, and ensure that I don’t 
make the same mistake in the future …

https://git.eclipse.org/r/c/platform/eclipse.platform.debug/+/171022 
<https://git.eclipse.org/r/c/platform/eclipse.platform.debug/+/171022>

Alex

> On 20 Oct 2020, at 18:00, Sravan K Lakkimsetti  
> wrote:
> 
> We build using https://ci.eclipse.org/releng/view/Builds/job/I-build-4.18/ 
> <https://ci.eclipse.org/releng/view/Builds/job/I-build-4.18/> it is scheduled 
> for 6PM daily.
> For test purposes you can build SDK using 
> https://ci.eclipse.org/platform/job/eclipse-aggregator-master/ 
> <https://ci.eclipse.org/platform/job/eclipse-aggregator-master/> this will do 
> a full sdk build. But no signing of jars or notarization. Unfortunately this 
> won’t catch version update issues. Useful when you want to verify integration 
> in SDK.
>  
> Thanks
> Sravan
>  
>  
> From: Alex Blewitt  
> Sent: 20 October 2020 22:06
> To: Eclipse platform general developers list. 
> Subject: [EXTERNAL] Re: [platform-dev] Accidental push to 
> eclipse.platform.debug
>  
>> On 20 Oct 2020, at 17:30, Mickael Istria > <mailto:mist...@redhat.com>> wrote:
>>  
>>  
>>  
>> On Tue, Oct 20, 2020 at 6:23 PM Alex Blewitt > <mailto:alex.blew...@gmail.com>> wrote:
>>> I accidentally pushed to master in the platform debug repository in a 
>>> change that I thought I’d configured for Gerrit:
>>> https://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=5c202200d26fa8f0fb07c46d3f92f5e4338b2f32
>>>  
>>> <https://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=5c202200d26fa8f0fb07c46d3f92f5e4338b2f32>
>>> What’s the process for resolving this commit? Should I commit a revert 
>>> backing out the change and go through the Gerrit review?
>>  
>> If it's a desirable change, let's just keep it ;)
>> If not (ie it introduces regression or test issues), I think it's OK if you 
>> just push directly a revert commit.
>  
> OK … I had built it and then done a git pull, so I’d changed the base. I’m 
> concerned that I may have inadvertently broken the build, particularly if it 
> needed version updates in the manifest etc.
>  
> Do you know where the master build branch is? I couldn’t see it obviously on 
> ci.eclipse.org <http://ci.eclipse.org/>.
> 
> 
>> Gerrit is highly recommended and brings a lot of quality assessment, but 
>> committers are free to bypass it when it seems to be the best path forward 
>> (eg if it prevents from upcoming build failures).
>  
> If the build is broken, I’ll need to push a revert.
>  
> Alex
> 
> ___
> platform-dev mailing list
> platform-dev@eclipse.org <mailto:platform-dev@eclipse.org>
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/platform-dev 
> <https://www.eclipse.org/mailman/listinfo/platform-dev>
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Accidental push to eclipse.platform.debug

[Alex Blewitt]

> On 20 Oct 2020, at 17:30, Mickael Istria  wrote:
> 
> 
> 
> On Tue, Oct 20, 2020 at 6:23 PM Alex Blewitt  <mailto:alex.blew...@gmail.com>> wrote:
> I accidentally pushed to master in the platform debug repository in a change 
> that I thought I’d configured for Gerrit:
> https://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=5c202200d26fa8f0fb07c46d3f92f5e4338b2f32
>  
> <https://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=5c202200d26fa8f0fb07c46d3f92f5e4338b2f32>
> What’s the process for resolving this commit? Should I commit a revert 
> backing out the change and go through the Gerrit review?
> 
> If it's a desirable change, let's just keep it ;)
> If not (ie it introduces regression or test issues), I think it's OK if you 
> just push directly a revert commit.

OK … I had built it and then done a git pull, so I’d changed the base. I’m 
concerned that I may have inadvertently broken the build, particularly if it 
needed version updates in the manifest etc.

Do you know where the master build branch is? I couldn’t see it obviously on 
ci.eclipse.org <http://ci.eclipse.org/>.

> Gerrit is highly recommended and brings a lot of quality assessment, but 
> committers are free to bypass it when it seems to be the best path forward 
> (eg if it prevents from upcoming build failures).

If the build is broken, I’ll need to push a revert.

Alex___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Accidental push to eclipse.platform.debug

[Alex Blewitt]

I accidentally pushed to master in the platform debug repository in a change 
that I thought I’d configured for Gerrit:

https://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=5c202200d26fa8f0fb07c46d3f92f5e4338b2f32
 


What’s the process for resolving this commit? Should I commit a revert backing 
out the change and go through the Gerrit review?

Amongst other things, I’d not configured the Signed-Off-By in the commit either 
:-/

Alex___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] MacOS .dmg vs .tar.gz

[Alex Blewitt]

> On 14 Oct 2020, at 12:41, Liviu Ionescu  wrote:
> 
>> On 14 Oct 2020, at 14:31, Alex Blewitt  wrote:
>> 
>> The quarantine bit is added when people download the archive via the 
>> browser. It does not apply to those downloading with another tool eg 
>> curl/wget.
> 
> Right, as long as you have a proper URL, not something like:
> 
> https://www.eclipse.org/downloads/download.php?file=/embed-cdt/packages/2020-09/eclipse-embedcdt-2020-09-R-macosx.cocoa.x86_64.tar.gz

You can add =1 to the end of the URL to be automatically redirected:

Without:
% curl --head 
"https://www.eclipse.org/downloads/download.php?file=/embed-cdt/packages/2020-09/eclipse-embedcdt-2020-09-R-macosx.cocoa.x86_64.tar.gz;
 | egrep 'HTTP|Location' 
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
HTTP/1.1 200 OK

With:
% curl --head 
"https://www.eclipse.org/downloads/download.php?file=/embed-cdt/packages/2020-09/eclipse-embedcdt-2020-09-R-macosx.cocoa.x86_64.tar.gz=1;
 | egrep 'HTTP|Location'
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:--  0:00:01 --:--:-- 0
HTTP/1.1 302 Found
Location: 
https://ftp.halifax.rwth-aachen.de/eclipse/embed-cdt/packages/2020-09/eclipse-embedcdt-2020-09-R-macosx.cocoa.x86_64.tar.gz

>> It’s possible that your users are accustomed to downloading with one of 
>> those tools, or are expanding archives with a brew-installed tar (which 
>> might not support the propagation of the quarantine bit).
> 
> Although I don't exclude these use cases, I seriously doubt that someone 
> would prefer to do this, instead of simply downloading via the browser and 
> removing the quarantine bit, as recommended in the Download page.

My expectation is that users won’t read and follow directions :)

Alex___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] MacOS .dmg vs .tar.gz

[Alex Blewitt]

The quarantine bit is added when people download the archive via the browser. 
It does not apply to those downloading with another tool eg curl/wget.

It’s possible that your users are accustomed to downloading with one of those 
tools, or are expanding archives with a brew-installed tar (which might not 
support the propagation of the quarantine bit).

This has been the default since macOS 10.5 so it’s not a new issue.

Alex

Sent from my iPhone 

> On 14 Oct 2020, at 10:25, Liviu Ionescu  wrote:
> 
> 
> 
>> On 14 Oct 2020, at 09:56, Ed Merks  wrote:
>> 
>> the web pages don't present this to the user because it's just not very 
>> usable for an end-user given all the protections in place on MacOS.
> 
> This is a bit weird, I have difficulties to understand why, according to 
> multiple opinions, archives are considered 'not very usable', while for three 
> years all my GNU MCU Eclipse macOS releases were plain archives and tens of 
> thousands of users had no problems to install them.
> 
> And nobody ever complained for having to remove the quarantine extended 
> attribute added by the browser after download.
> 
> For those who missed my previous message, here is how the new Download page 
> looks like:
> 
> https://projects.eclipse.org/projects/iot.embed-cdt/downloads
> 
> It is a simple and clear notice, hard to miss.
> 
> 
> Regards,
> 
> Liviu
> 
> 
> 
> 
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Creating a whiteboard pattern for IResourceChangeListener

[Alex Blewitt]

Sorry, should perhaps have filed that first.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=564876

> On 2 Jul 2020, at 17:21, Lars Vogel  wrote:
> 
> Hi Alex,
> 
> Sounds great to me. Thanks for working on this.
> 
> Let's continue this discussion via a bug report.
> 
> Best regards
> 
> Alex Blewitt mailto:alex.blew...@gmail.com>> schrieb 
> am Do., 2. Juli 2020, 17:58:
> Hi everyone,
> 
> I’ve proposed a change at 
> https://git.eclipse.org/r/c/platform/eclipse.platform.resources/+/165750 
> <https://git.eclipse.org/r/c/platform/eclipse.platform.resources/+/165750> to 
> provide a way of registering IResourceChangeListener instances via an OSGi 
> service rather than an explicit call to IWorkspace.
> 
> There’s lots of calls in projects that look something like:
> 
> ResourcesPlugin.getWorkspace().addResourceChangeListener(resourceChangeListener);
> 
> This has an ordering dependency that the workspace needs to be running before 
> this registration occurs. Of course, if the workspace doesn’t exist at this 
> point we aren’t going to be receiving any events but we’d like to be able to 
> start them in either order.
> 
> If we use the OSGi whiteboard pattern, we can turn it on its head and do:
> 
> context.registerService(resourceChangeListener, 
> IResourceChangeListener.class);
> 
> (We do something similar in many places for DebugOptions.)
> 
> Now we have decoupled the start order dependency, and with the change above 
> we’ll now pick up the binding when the resources plugin is available, and 
> will automatically deregister when either service goes away.
> 
> We can also use this to register the listeners via DS:
> 
> 
> http://www.osgi.org/xmlns/scr/v1.4.0 
> <http://www.osgi.org/xmlns/scr/v1.4.0>" immediate="true" 
> name="ExampleResourceListener">
>
>
>interface="org.eclipse.core.resources.IResourceChangeListener"/>
>
>
>
> 
> The additional properties on the service will allow a subset of the event 
> types to be passed in (in this case, 1 == POST_BUILD). There is a minor 
> disadvantage in that this is an integer rather than a compile-time constant 
> reference, though if the registration in code is used you can have a 
> Dictionary including IResourceChangeEvent.POST_BUILD as the key in the 
> dictionary.
> 
> This approach of having a whiteboard pattern (either DS or ServiceTracker) 
> for listeners could be replayed on other listener types as well; but from 
> what I can tell, the IResourceChangeListener is the most popular in hooking 
> together the world.
> 
> Arguably it might be more ‘OSGi’ to attempt migrating the 
> IResourceChangeEvent to an OSGi EventAdmin topic, but that would require more 
> invasive dependency and code changes than exists at the moment. Having 
> everything in DS means that we can start the components lazily and avoid the 
> use of Activators, which will certainly help with the start-up times.
> 
> Thoughts?
> 
> Alex
> ___
> platform-dev mailing list
> platform-dev@eclipse.org <mailto:platform-dev@eclipse.org>
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/platform-dev 
> <https://www.eclipse.org/mailman/listinfo/platform-dev>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/platform-dev

___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Creating a whiteboard pattern for IResourceChangeListener

[Alex Blewitt]

Hi everyone,

I’ve proposed a change at 
https://git.eclipse.org/r/c/platform/eclipse.platform.resources/+/165750 
 to 
provide a way of registering IResourceChangeListener instances via an OSGi 
service rather than an explicit call to IWorkspace.

There’s lots of calls in projects that look something like:

ResourcesPlugin.getWorkspace().addResourceChangeListener(resourceChangeListener);

This has an ordering dependency that the workspace needs to be running before 
this registration occurs. Of course, if the workspace doesn’t exist at this 
point we aren’t going to be receiving any events but we’d like to be able to 
start them in either order.

If we use the OSGi whiteboard pattern, we can turn it on its head and do:

context.registerService(resourceChangeListener, IResourceChangeListener.class);

(We do something similar in many places for DebugOptions.)

Now we have decoupled the start order dependency, and with the change above 
we’ll now pick up the binding when the resources plugin is available, and will 
automatically deregister when either service goes away.

We can also use this to register the listeners via DS:


http://www.osgi.org/xmlns/scr/v1.4.0; 
immediate="true" name="ExampleResourceListener">
   
   
  
   
   
   

The additional properties on the service will allow a subset of the event types 
to be passed in (in this case, 1 == POST_BUILD). There is a minor disadvantage 
in that this is an integer rather than a compile-time constant reference, 
though if the registration in code is used you can have a Dictionary including 
IResourceChangeEvent.POST_BUILD as the key in the dictionary.

This approach of having a whiteboard pattern (either DS or ServiceTracker) for 
listeners could be replayed on other listener types as well; but from what I 
can tell, the IResourceChangeListener is the most popular in hooking together 
the world.

Arguably it might be more ‘OSGi’ to attempt migrating the IResourceChangeEvent 
to an OSGi EventAdmin topic, but that would require more invasive dependency 
and code changes than exists at the moment. Having everything in DS means that 
we can start the components lazily and avoid the use of Activators, which will 
certainly help with the start-up times.

Thoughts?

Alex___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev