[equinox-dev] Reliable Testing For a Writable Folder

2019-12-23 Thread Ed Merks
While investigating https://bugs.eclipse.org/bugs/show_bug.cgi?id=558462 I tracked it down to the fact that testing a folder's writability, modifies the folder's timestamp if the folder is writable. There is very similar (copied) logic in all the following places:   org.eclipse.equinox.launche

[equinox-dev] Eclipse Native Launcher Help Needed

2020-01-13 Thread Ed Merks
Hi, I opened this enhancement request:   https://bugs.eclipse.org/bugs/show_bug.cgi?id=558832 Without something that would let an application (the installer) know the original value of the PATH before the native launcher has munged it, I don't think there is any way to determine which java wi

Re: [equinox-dev] How does Equinox infer systemCapabilities without .profile files?

2020-07-16 Thread Ed Merks
Mickael, It mostly starts here:   org.eclipse.osgi.storage.Storage.findVMProfile(Generation) For Java 9 and higher it ends up here:   org.eclipse.osgi.storage.Storage.calculateVMProfile(Version) While prototyping generating a profile I wrote some horrible code like this, using reflection to

Re: [equinox-dev] Sources for plugins

2020-11-23 Thread Ed Merks
Sravan, As far as I understand it, there exists no EPL/legal requirement to provide corresponding source bundles for *any *binary bundles.   It's of course very nice to have when you want to debug the use of a framework, but it's not an "OSS obligation," whatever that means.  The fact that al

Re: [equinox-dev] Marking org.eclipse.osgi.compatibility.state APIs as deprecated?

2021-01-08 Thread Ed Merks
What does it mean to deprecate "the API package org.eclipse.osgi.service.resolver"?  Does that affect the use of things like org.eclipse.osgi.service.resolver.VersionRange, org.eclipse.osgi.service.resolver.BundleDescription, and other things in that package?  These things are needed for stuff

Re: [equinox-dev] Marking org.eclipse.osgi.compatibility.state APIs as deprecated?

2021-01-08 Thread Ed Merks
entirely sure why that is API there, seems like an internal implementation detail to be able to set the BundleDescription which backs the implementation details of IPluginModel. Perhaps a more realistic consideration would be to move the API to PDE.   Tom - Original message -

Re: [equinox-dev] Marking org.eclipse.osgi.compatibility.state APIs as deprecated?

2021-01-08 Thread Ed Merks
e a political extremist; likely even an idiot.  But I'm an idiot who has a very hard time listening to an argument that starts with the premise: I don't think 'we' have to care much about 'them'.   That's not my Eclipse. On 08.01.2021 17:50, Mickael Istria wr

Re: [equinox-dev] Marking org.eclipse.osgi.compatibility.state APIs as deprecated?

2021-01-08 Thread Ed Merks
Thomas, Comments below On 08.01.2021 20:07, Thomas Watson wrote: I've certainly made fixes to this code long after Equinox has stopped using it and I don't mind maintaining fixes there when required.  I do care enough to not break existing projects that are using this API.  After all, I do us

Re: [equinox-dev] Classloader precedence of osgi.dev entries

2021-04-11 Thread Ed Merks
Christoph, As I understand it, this is primarily used for self-hosted launches.   The way I read it, it modifies/augments the bundle's actual classpath such that it works however the classpath normally works. If you do a self-hosted launch, you can see the -dev argument from the Properties..

[equinox-dev] Github site enhancements

2022-04-12 Thread Ed Merks
FYI, I updated the readme as displayed on this page https://github.com/eclipse-equinox to be more like this one https://github.com/eclipse-pde/ I.e., with instructions about issue reporting and a link for contribution details. Also, I added this section to the contribution page: https://g

[equinox-dev] Merge SimRel equinox.aggrcon into ep.aggregator

2022-06-09 Thread Ed Merks
Hi, I don't see any good reason to keep equinox.aggrcon separate from ep.aggrcon given it contributes the same repository and is always changed in lock-step by the same person. Does anyone object if I merged these two at the start of the 2022-09 cycle?  I'll interpret silence as agreement.  :

Re: [equinox-dev] Committer disagreement resolution guidelines

2022-06-20 Thread Ed Merks
It's not visible to me either...  Maybe the link is wrong... On 20.06.2022 11:59, Christoph Läubrich wrote: Hm.. it seems this is not visible because I'm not part of the group... that's really annoying... Am 20.06.22 um 11:51 schrieb Aleksandar Kurtakov: We have https://github.com/orgs/eclip

Re: [equinox-dev] Committer disagreement resolution guidelines

2022-06-20 Thread Ed Merks
Aleksandar Kurtakov: Link definitely is correct but seems to be "protected" in some way. As a project lead I can even start discussion among project leads. On Mon, Jun 20, 2022 at 1:02 PM Ed Merks <mailto:ed.me...@gmail.com>> wrote:     It's not visible to me either... 

Re: [equinox-dev] Security audit of the recent changes to Eclipse p2 (PGP signatures)

2022-08-11 Thread Ed Merks
Mikael, The draft is simple and looks fine. Thanks, Ed On 10.08.2022 12:23, Mikael Barbero wrote: Dear Equinox developers, The Eclipse Foundation is willing to fund a security audit of the recent changes to p2 to support detached signatures (made to replace classical jars signing). The Ec

Re: [equinox-dev] Security audit of the recent changes to Eclipse p2 (PGP signatures)

2023-03-02 Thread Ed Merks
signatures has been completed. A report is available for review upon request (limited to PMC members and committers). Mickael Istria and Ed Merks participated in the audit and have seen early and final versions of the report. There are some findings in th