Re: [platform-dev] How to build SWT jars from sources?

[Ed Merks via platform-dev]

Yes, that seems like the most focused place

https://github.com/eclipse-platform/eclipse.platform.swt/discussions

Unfortunately Hannes just started vacation, so help might be in short 
supply.


I imagine you just need to clone SWT including the LFS parts of the 
repository and redirect your scripts to that folder location. Good luck!


On 23.02.2024 14:31, Thomas Singer via platform-dev wrote:

What would be the SWT discussion list?

How to build the SWT jars using ANT?


___
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] How to build SWT jars from sources?

[Ed Merks via platform-dev]

It's probably better to ask on one of the discussions list.

The binaries are in the SWT repository 
https://github.com/eclipse-platform/eclipse.platform.swt/tree/master/binaries 
but you need to enable the LFS support for those be be checkout out as 
they are in the workspace with the Oomph setup:



On 23.02.2024 09:17, Thomas Singer via platform-dev wrote:

Hi Jonas,

Thanks for answering. The linked comment writes about building the 
native fragments which is not what I want. I need to build the SWT 
jars which until recently used the prebuilt native fragments from 
org.eclipse.swt.binaries.
___
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] Add Upstream REPO

[Ed Merks via platform-dev]

This all appears to be completely general questions about git and 
nothing specific to do with the Eclipse Platform, so likely best asked 
elsewhere such as stackoverflow.


If you must ask questions (related to the Eclipse Platform) it's better 
to use discussions not the mailing list


https://github.com/eclipse-platform/.github/discussions

We all get too much email already...

On 06.12.2023 10:50, java joe via platform-dev wrote:
Im following the directions in; 
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/configuring-a-remote-repository-for-a-fork


QUESTION:  in number 3 below, WHAT would be the 
|*ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git
*IS that the main trunk? As in; 
https://github.com/eclipse-platform/eclipse.platform.git


ANY HELP GREATLY appreciated.  Im trying to update my fork to the 
trunk and not doing so hot..

|

1.

Open Terminal.

2.

List the current configured remote repository for your fork.

|$ git remote -v > origin
https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch) > origin
https://github.com/YOUR_USERNAME/YOUR_FORK.git (push) |
3.

Specify a new remote /upstream/ repository that will be synced
with the fork.

|git remote add upstream
https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git |
4.

Verify the new upstream repository you've specified for your fork.

|$ git remote -v > origin
https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch) > origin
https://github.com/YOUR_USERNAME/YOUR_FORK.git (push) > upstream
https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (fetch)
> upstream
https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (push) |


___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, 
visithttps://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] Problems installing Platform using Oomph

[Ed Merks via platform-dev]

It's fixed by this:

https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/pull/1429

This job promoted the changes:

https://ci.eclipse.org/oomph/job/setup-archiver/

So the server should very soon yield the changes for the installer to 
work properly.


Locally you should do a pull on all the git repositories, especially of 
course the aggregator repository, to see this change when you do Help -> 
Perform Setup Tasks...


Thanks for reporting!  And sorry for the inconvenience.


On 09.10.2023 12:58, John MOULE via platform-dev wrote:

Hi,

I'm using Oomph installer to install Eclipse SDK with Platform 
project. But I get the following error:


ERROR: org.eclipse.equinox.p2.metadata.repository code=1000 No 
repository found at 
https://download.eclipse.org/webtools/CI/3.31.0/I-latest/repository.


(details attached)

I've tried using "Latest Release (4.29 - 2023-09)" and "Latest (4.30 - 
2023-12)", but get the same results.

Windows 10, JDK 17.0.5

Am I missing something or is this a known issue?

Cheers John

___
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 and Equinox 4.29 (2023-09) GA is available

[Ed Merks via platform-dev]

All the update sites are sound and have the correct content.

The only problem is that this link does not exist because someone 
overlooked creating it:


https://projects.eclipse.org/projects/eclipse/releases/4.29.0

As a result, this mostly-generated page cannot point to it:

https://projects.eclipse.org/releases/2023-09

But these sites have the correct content:

https://download.eclipse.org/eclipse/updates/4.29/
https://download.eclipse.org/releases/2023-09/

Also, all the links in Rahul's email are correct and have the 4.29 
content for the 2023-09 release.


I don't know anything about Homebrew or what the discussion there is about.

In any case, release records on projects.eclipse.org are not relevant 
with respect to the actual released content which is correct as it is 
now and is not in need of fixing.



On 14.09.2023 18:33, Jan Westerkamp via platform-dev wrote:

Hi Ed,

does this mean only the organisational things and the site needs a fix 
or does this mean a patch release (i.e. 4.29.1 with updated release 
notes etc.) is required to fix this?
So does this need to be fixed before the Homebrew issue can be fixed 
(the existing version only references an invalid version number 
"4.28.0,2023-09", but should download 2023-09)?


If not, then the Homebrew side can be fixed now and does not need an 
additional fix later, which would create inconvenience because 
additional configs and plugins need to maintained by the users again.


Best,
Jan

Am 14.09.23 um 14:33 schrieb Ed Merks via platform-dev:


It looks like the Eclipse project forgot to create a release record 
for 4.29:


https://projects.eclipse.org/projects/eclipse/governance

I did ask folks to review their release records, and to create new 
ones where appropriate, well ahead of when Wayne created the PMI page 
on this issue:


https://github.com/merks/simrel-maven/issues/9


On 14.09.2023 14:25, Jan Westerkamp via platform-dev wrote:

Great news!

But I wonder about the deviation of the contained project version 
numbers included in Eclipse 2023-09 
(https://projects.eclipse.org/releases/2023-09):


- Eclipse Project 4.28.0 
(https://projects.eclipse.org/projects/eclipse/releases/4.28.0)
- Eclipse Packaging 4.29.0 
(https://projects.eclipse.org/projects/technology.packaging/releases/4.29.0)


This originated the following issue for the Homebrew packages:

https://github.com/Homebrew/homebrew-cask/issues/155163

Is this deviation intended or a bug?

Best,
Jan

Am 13.09.23 um 16:00 schrieb Rahul Mohanan via platform-dev:


Hello Everyone,

We are pleased to announce that 2023-09 is available for download 
and updates.


    Eclipse downloads:

https://download.eclipse.org/eclipse/downloads/drops4/R-4.29-202309031000/ 



    New and Noteworthy:

https://www.eclipse.org/eclipse/news/4.29/

    Update existing (non-production) installs:

https://download.eclipse.org/eclipse/updates/4.29/

    Specific repository good for building against:

https://download.eclipse.org/eclipse/updates/4.29/R-4.29-202309031000/

    Equinox specific downloads:

https://download.eclipse.org/equinox/drops/R-4.29-202309031000/

Thank you to everyone who made this checkpoint possible.

Thanks and Regards,

/Rahul Mohanan/

Eclipse SDK Team


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




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


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




___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, 
visithttps://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 and Equinox 4.29 (2023-09) GA is available

[Ed Merks via platform-dev]

It looks like the Eclipse project forgot to create a release record for 
4.29:


https://projects.eclipse.org/projects/eclipse/governance

I did ask folks to review their release records, and to create new ones 
where appropriate, well ahead of when Wayne created the PMI page on this 
issue:


https://github.com/merks/simrel-maven/issues/9


On 14.09.2023 14:25, Jan Westerkamp via platform-dev wrote:

Great news!

But I wonder about the deviation of the contained project version 
numbers included in Eclipse 2023-09 
(https://projects.eclipse.org/releases/2023-09):


- Eclipse Project 4.28.0 
(https://projects.eclipse.org/projects/eclipse/releases/4.28.0)
- Eclipse Packaging 4.29.0 
(https://projects.eclipse.org/projects/technology.packaging/releases/4.29.0)


This originated the following issue for the Homebrew packages:

https://github.com/Homebrew/homebrew-cask/issues/155163

Is this deviation intended or a bug?

Best,
Jan

Am 13.09.23 um 16:00 schrieb Rahul Mohanan via platform-dev:


Hello Everyone,

We are pleased to announce that 2023-09 is available for download and 
updates.


    Eclipse downloads:

https://download.eclipse.org/eclipse/downloads/drops4/R-4.29-202309031000/ 



    New and Noteworthy:

https://www.eclipse.org/eclipse/news/4.29/

    Update existing (non-production) installs:

https://download.eclipse.org/eclipse/updates/4.29/

    Specific repository good for building against:

https://download.eclipse.org/eclipse/updates/4.29/R-4.29-202309031000/

    Equinox specific downloads:

https://download.eclipse.org/equinox/drops/R-4.29-202309031000/

Thank you to everyone who made this checkpoint possible.

Thanks and Regards,

/Rahul Mohanan/

Eclipse SDK Team


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




___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, 
visithttps://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] Process for a security/bugfix release for the Eclipse Platform

[Ed Merks via platform-dev]

Marta,

Note that all the opinions I express are *my own*.   I *do not *speak 
for the Platform.


My opinions reflect the reality of the great many projects supported by 
a handful of committers (or even a single committer) doing everything on 
a for-free basis.   While the focus here right now may be on the 
Platform's set of projects, that focus will (must?) eventually broaden 
to include all of SimRel (and effectively all Eclipse Projects and all 
their dependencies) because security problems can come from anywhere and 
from any Project.  I would hope that most projects could produce a new 
build on short noticed, but I know that even that's unfortunately (and 
shockingly)  not the case.   Certainly the Platform is more than capable 
of producing a build on a moment's notice, and such a build (p2 update 
site) could be termed an "emergency release", but I think you probably 
are using that term to mean something much more.


In any case, please don't get me wrong. I fully share the Foundation's 
concerns about loss of reputation and the Foundation's goal of being an 
industry leader.  The reality though is that the Foundation has a budget 
while Projects don't.


I believe that probably I speak for most of the Platform committers when 
I say that I prefer this discussion on a GitHub issue or GitHub  
discussion.  Likely no one wants a long disconnected set of email 
threads on such a topic, and after the fact, someone will likely want a 
single location with a cohesive thread of discussion rather than a 
disjointed mailing list archive.  I wonder if the focus on the Platform 
is a bit of the case of looking for a lost set of keys under the 
streetlight because the lighting is best for finding lost things there.  
It's just as likely that the keys will be lost in some dark corner, or 
deep in the grass.  But I suppose one has to start looking somewhere.  
This issue is also very likely of interest to the IDE Working Group, 
which also has a budget...


Regards,
Ed

On 24.07.2023 09:25, Marta Rybczynska wrote:

Hello Ed and others,
The policy of EF reflects the reality in the industry. 90 days is the 
typical time security researchers agree to wait. However, this is not 
set in stone. It might happen that a researcher says they have a 
presentation accepted on a conference and they will present the 
vulnerability at that specific date. Or, a researcher who is following 
a different calendar, like 30 days. Or if there is an active 
exploitation of a vulnerability.


In such cases, if the project does not have a way to produce an 
emergency release in such cases, this could be bad for their users 
(and their reputation...). This is the risk I note in this case (EF 
policy is secondary here).


Also, this is also always a  project's call to decide to do a security 
release or not. Usually, for a minor vulnerability, it is OK to wait. 
For a major one, it's another story.


It might be useful to start a discussion about cross-project security 
releases (we call it coordinated disclosure in the security world, 
btw), do I read it correctly that you prefer a GitHub issue instead of 
a mailing list post?


Kind regards,
Marta

On Wed, Jul 19, 2023 at 9:31 AM Ed Merks via platform-dev 
 wrote:


Marta,

I notice this interesting blog has relevant background details:


https://newsroom.eclipse.org/eclipse-newsletter/2023/may/reporting-and-managing-security-issues-eclipse-foundation-projects

With respect to timing, I see this in the policy:

https://www.eclipse.org/security/policy/#timing

With respect to distribution of a resolution, I do not see the use
of, nor definition of, the term "security release" but rather only
the following, where it simply mentions using "normal distribution
channels" at a minimum:

https://www.eclipse.org/security/policy/#distribution

In general, all changes are normally made available for
distribution within a day via integration builds, and, as you've
noted, releases are normally made available for distribution on a
quarterly basis.

Also highly relevant, is that the simultaneous release, the mostly
widely used distribution channel, is also normally available
quarterly.  SimRel integration (staging) builds are available
daily with new content available as  contributed by the
participating projects:

https://ci.eclipse.org/simrel/

Asking for special out-of-band "security releases" is asking for a
lot from the Platform project.  Too much in my *personal opinion*,
but everyone is entitled to an option.  Moreover,  I assume this
same policy, and expectation, applies uniformly for all projects
where that expectation is probably significantly less realistic. 
It would seem better to me to try to work (as much as possible)
within the bounds of the existing processes and normal
distribution channels.

General cross-cutting 

Re: [platform-dev] Process for a security/bugfix release for the Eclipse Platform

[Ed Merks via platform-dev]

Marta,

I notice this interesting blog has relevant background details:

https://newsroom.eclipse.org/eclipse-newsletter/2023/may/reporting-and-managing-security-issues-eclipse-foundation-projects

With respect to timing, I see this in the policy:

https://www.eclipse.org/security/policy/#timing

With respect to distribution of a resolution, I do not see the use of, 
nor definition of, the term "security release" but rather only the 
following, where it simply mentions using "normal distribution channels" 
at a minimum:


https://www.eclipse.org/security/policy/#distribution

In general, all changes are normally made available for distribution 
within a day via integration builds, and, as you've noted, releases are 
normally made available for distribution on a quarterly basis.


Also highly relevant, is that the simultaneous release, the mostly 
widely used distribution channel, is also normally available quarterly.  
SimRel integration (staging) builds are available daily with new content 
available as  contributed by the participating projects:


https://ci.eclipse.org/simrel/

Asking for special out-of-band "security releases" is asking for a lot 
from the Platform project.  Too much in my *personal opinion*, but 
everyone is entitled to an option.  Moreover, I assume this same policy, 
and expectation, applies uniformly for all projects where that 
expectation is probably significantly less realistic.  It would seem 
better to me to try to work (as much as possible) within the bounds of 
the existing processes and normal distribution channels.


General cross-cutting discussions or issues can be hosted here:

https://github.com/eclipse-platform/.github/discussions
https://github.com/eclipse-platform/.github/issues

This related discussion is already underway:

https://github.com/eclipse-platform/.github/discussions/129

Regards,
Ed

On 18.07.2023 18:03, Marta Rybczynska via platform-dev wrote:

Hello,
Eclipse platform has been releasing every three month for some time. 
I've been recently working on clarifying security processes and I 
could not find a description how the Eclipse Platform handles a 
security release.


Would a security fix need to wait for next 3-month release? This could 
be in conflict with the 90 days vulnerability release policy. Consider 
this scenario:
- A vulnerability is reported two weeks before the release and the 
team needs some time to prepare a fix.

- The fix is ready one month after the release
- 90 days will come two weeks BEFORE the next release
Releasing a vulnerability information to the public without a release 
fixing it is against best practices and it would be beneficial to 
avoid it.


Do you consider running a separate bugfix release?

Could you please point me to documentation/discussions on how you do 
handle or would handle such a situation?


Thanks in advance,
Marta

___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, 
visithttps://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] Please don't forget to make 4.25 visible in the composite and so so as soon as possible

[Ed Merks]

Sravan,

I was waiting for the webdev team to announce the website updates, but 
probably I shouldn't have.  Normally they do that:


https://www.eclipse.org/lists/epp-dev/msg06610.html

I was also refreshing the pages to see when they were up-to-date and 
when that was the case, then I composed my email for cross projects.  
But then I noticed the platform 4.25 site wasn't up-to-date.


Anyway, all this follows strict schedule where the update sites are made 
available 1/2 hour before the 10:00AM EST/EDT, so in the future you 
should do it similarly on schedule rather than waiting...


I typically commit the catalog changes *many *hours ahead of time.  
Then, right after the release, I regenerate it again, which is how I 
noticed the platform site was not complete...


Cheers,
Ed

On 14.09.2022 16:38, Sravan K Lakkimsetti wrote:

Hi Ed,

We are waiting for your mail on availability of Simrel. We are supposed to make 
the platform visible after your mail. Can we send the availability mail now?

Thanks
Sravan


-Original Message-
From: platform-dev  On Behalf Of Ed Merks
Sent: 14 September 2022 19:59
To: Eclipse platform general developers list.
Subject: [EXTERNAL] [platform-dev] Please don't forget to make 4.25 visible in 
the composite and so so as soon as possible

The composite at
https://download.eclipse.org/justj/?file=eclipse/updates/4.25  still contains 
only the categories and not the release:

 
    
      
      
      
    
    
      
    


It's good the size is ignored, because it's wrong.)

___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, 
visithttps://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, 
visithttps://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] Please don't forget to make 4.25 visible in the composite and so so as soon as possible

[Ed Merks]

The composite at 
https://download.eclipse.org/justj/?file=eclipse/updates/4.25 still 
contains only the categories and not the release:



type='org.eclipse.equinox.internal.p2.metadata.repository.CompositeMetadataRepository' 
version='1.0.0'>

  
    
    
    
  
  
    
  


It's good the size is ignored, because it's wrong.)

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

[platform-dev] RC2 Was Not Contributed to SimRel

[Ed Merks]

Hi,

I was testing using the platform's latest SimRel contribution repo as an 
API baseline for 4.25, and running into API errors. As a result, I just 
happened to notice that my assumption that the latest platform 
contribution to SimRel would be RC2 was wrong because in fact it was 
still RC1.


The following review was never completed:

https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/195540

We had a similar issue for RC1.

We really need to improve the process such that this doesn't happen 
again or we might end up wondering why we shipped bugs for 2022-09 that 
we thought were fixed...


Regards,
Ed

___
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] Master branch is open for 4.26 development

[Ed Merks]

A *huge *thanks to you, Sravan and Alex, for all the essential releng 
work toward closing the 4.25 stream and opening the 4.26!!


On 02.09.2022 22:23, Samantha Dawley wrote:

Hello,

We are pleased to announce that the master branch is open for 4.26 
development.


You can subscribe to the build schedule here 
.


Best Regards,
Samantha Dawley
Red Hat Eclipse Team



___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, 
visithttps://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] Adding new version of JNA library in orbit

[Ed Merks]

The platform is  pulling that directly from Maven:



The generate maven dependency resolves to a much newer version:



The versions are available here( with 5.21.1 being the latest):


https://repo1.maven.org/maven2/net/java/dev/jna/jna/


The version would need to be changed here:


https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/67bf36e6dcd414163905a05e72c30c66a5b5b164/eclipse.platform.releng.prereqs.sdk/eclipse-sdk-prereqs.target#L178-L189


So it's best to open an issue in that repository


https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues




On 31.08.2022 01:29, Muhammad Umair Sair wrote:

Hi,

I am facing issue on Linux with NativeLibrary. When HTTPS proxy is 
set, I am getting errors on terminal error stream with consistency 
from org.eclipse.equinox.internal.security.linux.unlockSecretService(..) 
and following call in this method gets stuck forever.


Pointer secretService = 
fLibSecret.secret_service_get_sync(SecretServiceFlags.SECRET_SERVICE_LOAD_COLLECTIONS,

Pointer.NULL, gerror);

On investigation, I found that its a race condition between finalizer 
and NativeLibrary.getInstance(..). On second time call to get secret-1 
library, the object from weak reference is gone/GCed in 
NativeLibrary.libraries but the NativeLibrary object itself is not 
finalized/GCed yet, so it gets ref.get()==null and goes for reloading 
the library which causes following errors in console. The reason is 
that the older library was not unloaded yet and we loaded it again.


~
(java:3835014): GLib-GObject-WARNING **: 02:47:42.753: cannot register 
existing type 'SecretService'


(java:3835014): GLib-GObject-WARNING **: 02:47:42.753: cannot add 
private field to invalid (non-instantiatable) type ''


(java:3835014): GLib-GObject-CRITICAL **: 02:47:42.753: 
g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE 
(instance_type)' failed


(java:3835014): GLib-GObject-CRITICAL **: 02:47:42.753: 
g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE 
(instance_type)' failed


(java:3835014): GLib-GObject-WARNING **: 02:47:42.753: cannot register 
existing type 'SecretBackend'


(java:3835014): GLib-GObject-CRITICAL **: 02:47:42.753: 
g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE 
(interface_type)' failed


(java:3835014): GLib-GObject-CRITICAL **: 02:47:42.753: 
g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE 
(interface_type)' failed


(java:3835014): GLib-CRITICAL **: 02:47:42.753: g_once_init_leave: 
assertion 'result != 0' failed


(java:3835014): GLib-GObject-CRITICAL **: 02:47:42.753: 
g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE 
(instance_type)' failed

~~

I was looking at jna project and they have moved away from using 
finalizers [1] and it is available is version 5.12.


Can we add latest jna version in orbit for 2022-09?

[1] https://github.com/java-native-access/jna/pull/1402

Thanks,
Umair Sair

___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, 
visithttps://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] The Platform's 2022-09 M3 Contribution

[Ed Merks]

FYI,

I expected to see the platform's 2022-09 M3 contribution in SimRel by 
now, but it wasn't present so I added it.


https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/195254

Oops, sorry I see the commit comment was wrong; copied from the last time.

Regards,
Ed

___
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] [pde-dev] PDE and GitHub

[Ed Merks]

Thanks guys, that was the information I was looking for!

FYI, EGit has this cool plugin, which is independent from Mylyn, that 
could be reused to do all kinds of very nice Github integration.  I've 
been playing with it a bit already.  E.g., I wanted to be able to create 
a remote to a fork if one has a fork for the clone...


On 16.07.2022 11:45, Christoph Läubrich wrote:
Please don't complicate that too much, the data is all there so 
instead of duplicate it better enhance the tools than enhancing the 
usual developer or require complex commit_hooks (this has not worked 
well for gerrit either) ...


One don't needs the GH API for that, as "fetch PR" do not needs the 
github API either... it all should be recoverable from the git-data + 
some filling into a template that makes up a full link.


So if we have found out that the commit is part of 'origin/pull/123' 
it should not be so hard to display a link


https://github.com//pull/123

...

Am 16.07.22 um 11:38 schrieb Hannes Wellmann:
Like the others I'm in favor to not require an issue for each 
non-trivial PR. There are good reasons to create an issue, e.g. you 
don't want to work on it (now) or want to discuss the solution first. 
But if one already has implemented a (draft) solution a requirement 
to create a dedicated issue just feels like extra ceremony that 
causes noise and extra work.

Regarding Ed's remark:
As Christoph showed you can find the PR of a commit via the GitHub UI.
Besides that we could use an enhanced merge-procedure to 
automatically append the link to the PR (and maybe the reviewers 
etc.) just like it was done in Gerrit [1].
This was already suggested on other mailing lists and I asked about 
that at the community meeting in June. Jonah Graham pointed there to 
the GitHub UI way mentioned by Christoph.
While the GH-UI offers a way to find the PR, embedding a link in the 
commit message is probably the most universal way that does not 
require more magic in EGit or at other places.
In the end such magic probably would require to log-in to GitHub 
within Eclipse because for most interactions with the GH API one 
needs an authentication. I think we should avoid that if possible. 
Not everybody has a GH account and for me it would feel odd to have 
to enter a log-in to my local Eclipse.

Greetings
Hannes
[1] - 
https://github.com/eclipse-pde/eclipse.pde/commit/15d4491246a0bc3eb19f874a4cd2774a1bdc2269

*Gesendet:* Samstag, 16. Juli 2022 um 11:13 Uhr
*Von:* "Christoph Läubrich" 
*An:* platform-dev@eclipse.org
*Betreff:* Re: [platform-dev] [pde-dev] PDE and GitHub
Hi Ed,

I think I noted it somewhere else already:

1) the PR that merged the commit is recorded and github also shows that
information as you already found out
2) the magic is described here [1] there is even a script for that [2])
3) But EGit currently do not offer anything to make this "magic" visible
in the UI

[1]https://stackoverflow.com/questions/17818167/find-a-pull-request-on-github-where-a-commit-was-originally-created 
<https://stackoverflow.com/questions/17818167/find-a-pull-request-on-github-where-a-commit-was-originally-created> 

[2] http://joey.aghion.com/find-the-github-pull-request-for-a-commit/ 
<http://joey.aghion.com/find-the-github-pull-request-for-a-commit/>


Am 16.07.22 um 10:55 schrieb Ed Merks:
 > Of course making everyone efficient is an important goal!   I 
think it's

 > also an important goal to preserve historical information, especially
 > around discussions with respect to design decisions.  From that 
point of
 > view,  I wonder, does each PR-only commit really have a link back 
to the PR?

 >
 > I look at this commit and I see no such link(s):
 >
 > I don't see such a link from here either.:
 >
 > 
https://github.com/eclipse-pde/eclipse.pde/commit/36b87ff2d4a4192fc9baa1fafa970a966464f506 
<https://github.com/eclipse-pde/eclipse.pde/commit/36b87ff2d4a4192fc9baa1fafa970a966464f506> 


 >
 > Contrast that to this commit which has links:
 >
 > And from here one can navigate those links:
 >
 > 
https://github.com/eclipse-pde/eclipse.pde/commit/c9e687a44805f1fb26e422d25a1982f74291bffd 
<https://github.com/eclipse-pde/eclipse.pde/commit/c9e687a44805f1fb26e422d25a1982f74291bffd> 


 >
 > So it seems to me that yes a PR is much like an Issue, but without 
links
 > to one or both in the commit itself, it's just a commit and one 
cannot

 > find out any historical information discussions and design decisions
 > that were made relative to that commit.  I expect that information is
 > useful and has gone missing.  Or did I overlook something that such
 > links at least to the PR are implicitly navigable somewhere?
 >
 > On 15.07.2022 12:53, Mickael Istria wrote:
 >> Hi Vikas,
 >>
 >> Like Lars, I'm also unsure adding more tickets and bureaucracy as a
 >> requirement will help the committers in bei

Re: [platform-dev] [pde-dev] PDE and GitHub

[Ed Merks]

Of course making everyone efficient is an important goal!   I think it's 
also an important goal to preserve historical information, especially 
around discussions with respect to design decisions.  From that point of 
view,  I wonder, does each PR-only commit really have a link back to the PR?


I look at this commit and I see no such link(s):

I don't see such a link from here either.:

https://github.com/eclipse-pde/eclipse.pde/commit/36b87ff2d4a4192fc9baa1fafa970a966464f506

Contrast that to this commit which has links:

And from here one can navigate those links:

https://github.com/eclipse-pde/eclipse.pde/commit/c9e687a44805f1fb26e422d25a1982f74291bffd

So it seems to me that yes a PR is much like an Issue, but without links 
to one or both in the commit itself, it's just a commit and one cannot 
find out any historical information discussions and design decisions 
that were made relative to that commit.  I expect that information is 
useful and has gone missing.  Or did I overlook something that such 
links at least to the PR are implicitly navigable somewhere?


On 15.07.2022 12:53, Mickael Istria wrote:

Hi Vikas,

Like Lars, I'm also unsure adding more tickets and bureaucracy as a 
requirement will help the committers in being more efficient.
Can you please explain the current problems that you or others face 
with tracking in the current state? Maybe we can find some tricks (eg 
GitHub queries) to satisfy you needs without requiring an issue for 
every PR if the contributor didn't reporting an issue a-priori was useful.


Cheers

___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, 
visithttps://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] Merge equinox.aggrcon into ep.aggrcon

[Ed Merks]

FYI,

I've completed the merge of equinox.aggrcon into ep.aggrcon and deleted 
equinox.aggrcon:


https://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?id=ec821e3df25d9cba7372336ff7fefaa7c86166c0

I've confirmed that the new staging site contains the same number of IUs 
as before:


  https://download.eclipse.org/staging/2022-09/

Cheers,
Ed

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

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

[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.  :-P


Regards,
Ed


___
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 push to github g...@github.com:eclipse-platform/eclipse.platform.ui.git

[Ed Merks]

Marcus,

I got a notification like this:

This issue of not being able to assign a reviewer came up recently too.  
I'm not sure how that's being resolved.  But I do think committers will 
generally be notified so hopefully one of them adds themself.


Do you see this part?

I suppose you could add a comment with @vogella to send a more directed 
notification...




On 18.05.2022 14:40, Hoepfner, Marcus via platform-dev wrote:


Thanks.

I have created a fork and a PR now on 
https://github.com/eclipse-platform/eclipse.platform.ui.


Unfortunately I cannot add Reviewers to the PR.

Guess that’s because I’m not contributor in platform.ui?

*From: *platform-dev  on behalf of 
Ed Merks 

*Date: *Wednesday, 18. May 2022 at 13:44
*To: *platform-dev@eclipse.org 
*Subject: *Re: [platform-dev] Cannot push to github 
g...@github.com:eclipse-platform/eclipse.platform.ui.git


The more detailed instructions are here:

https://github.com/eclipse-platform/.github/blob/main/CONTRIBUTING.md#recommended-workflow 
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Feclipse-platform%2F.github%2Fblob%2Fmain%2FCONTRIBUTING.md%23recommended-workflow=05%7C01%7Cmarcus.hoepfner%40sap.com%7Cf356323367b24210870308da38c3943a%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637884710710591194%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=C3vSCssFqZuIEXEj1HAlfSuTEHRinGL78KZcpz4DN5A%3D=0>


Yes, you should use a fork with pull requests.

I generally clone the "real" repository and create an additional 
remote that points at my fork:


I leave master hooked up to origin/master and create a local branch 
that I push to my fork remote.  When I'm done I check out master again 
and can always pull from the real original clone (so no need to 
manually sync my fork with the original).


On 18.05.2022 13:36, Hoepfner, Marcus via platform-dev wrote:

Hi,

did not follow all the discussion how to contribute after moved to
github.

Do I need to fork or can I push to new branch in
g...@github.com:eclipse-platform/eclipse.platform.ui.git?

How do I become contributer in that repo?

I want to develop a feature, not about a bug fix.


https://github.com/eclipse-platform/eclipse.platform.ui/blob/master/CONTRIBUTING.md

<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Feclipse-platform%2Feclipse.platform.ui%2Fblob%2Fmaster%2FCONTRIBUTING.md=05%7C01%7Cmarcus.hoepfner%40sap.com%7Cf356323367b24210870308da38c3943a%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637884710710591194%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=s7ZHGjmKsVBd2n2DegCe7D3EDJEi3i0laMEFFo%2BtyEg%3D=0>
does not really say a lot and points to a wiki page which is
talking about gerrit.

Thanks, Marcus



___

platform-dev mailing list

platform-dev@eclipse.org

To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/platform-dev  
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.eclipse.org%2Fmailman%2Flistinfo%2Fplatform-dev=05%7C01%7Cmarcus.hoepfner%40sap.com%7Cf356323367b24210870308da38c3943a%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637884710710591194%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=GRLR1xduQjl2nTX46%2B5u216YgJaQz6YYC5tD3cVP96I%3D=0>


___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, 
visithttps://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 push to github g...@github.com:eclipse-platform/eclipse.platform.ui.git

[Ed Merks]

The more detailed instructions are here:

https://github.com/eclipse-platform/.github/blob/main/CONTRIBUTING.md#recommended-workflow

Yes, you should use a fork with pull requests.

I generally clone the "real" repository and create an additional remote 
that points at my fork:


I leave master hooked up to origin/master and create a local branch that 
I push to my fork remote.  When I'm done I check out master again and 
can always pull from the real original clone (so no need to manually 
sync my fork with the original).



On 18.05.2022 13:36, Hoepfner, Marcus via platform-dev wrote:


Hi,

did not follow all the discussion how to contribute after moved to github.

Do I need to fork or can I push to new branch in 
g...@github.com:eclipse-platform/eclipse.platform.ui.git?


How do I become contributer in that repo?

I want to develop a feature, not about a bug fix.

https://github.com/eclipse-platform/eclipse.platform.ui/blob/master/CONTRIBUTING.md 
does not really say a lot and points to a wiki page which is talking 
about gerrit.


Thanks, Marcus


___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, 
visithttps://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] Dedicated "issues" repository

[Ed Merks]

The organization readme says

" If you are unsure, you can open an issue 
 against this 
repository and the issue will then be moved as best by maintainers."


That links to this:

https://github.com/eclipse-platform/.github/issues


On 16.04.2022 13:29, Wim Jongman wrote:

Hi,

It would be great if the issues could be filed on the organization 
level but since this is not possible:


Did someone already suggest creating dedicated "issue" repositories as 
the place to store issues?


e,g, https://github.com/eclipse-platform/issues

Issues can be referenced from each individual repo/pr.

Cheers,

Wim

___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, 
visithttps://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.platform.ui Git repository now on GitHub

[Ed Merks]

There is a new comment here suggesting it's not quite done:

https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1151#note_679407

I did already migrate the setup, but the pull request defaulted to the 
wrong (current default R1_0) branch, though I could change that manually...


I guess I wasn't patient enough.  Sorry.

On 11.04.2022 16:51, Mickael Istria wrote:
eclipse.platform.ui Git repository is now moved to GitHub: 
https://github.com/eclipse-platform/eclipse.platform.ui
If you see this message, perform GitHub migration by (assuming the 
legacy Gerrit repo is called `upstream`)

$ git reset --hard HEAD
$ git remote set upstream 
g...@github.com:eclipse-platform/eclipse.platform.ui.git

$ git pull upstream master

--
Mickael Istria
Eclipse IDE  developer, for Red 
Hat Developers 


___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, 
visithttps://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] Customizing Github Organization Pages

[Ed Merks]

Mickael,

Perhaps a picture would help me understand what you're referring to, if 
it's not already one of the things for which I had a screen capture.


My assumption is that if it requires an admin page with admin access for 
the organization then only the foundation staff can admin it and they 
will do so via a helpdesk request.


Regards,
Ed

On 31.03.2022 15:57, Mickael Istria wrote:

Hi Ed,

While contributing a .github/README.md file seems like regular 
Git/GitHub stuff that any committer can tackle, I do not see the links 
to configure the organization (eg set links, names and so on). Are 
those supposed to be accessible to committers? to project leads? Or do 
we need to open an helpdesk ticket to get them modified?
If you don't know, I can open an helpdesk ticket to ask; I'm pretty 
sure that if we're insistent and annoying enough (and I know we can 
be!) the Foundation staff will consider just letting us access more 
organization and repo settings ;)


___
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] Intended Bug-Tracker for Platform-projects hosted on GitHub

[Ed Merks]

Firstly, I want to apologize for my 'whim' comment, which is indeed 
overly general without context.   I was specifically referring to 
https://github.com/eclipse-platform/eclipse.platform/issues/7 where the 
idea was to merge eclipse.platform and eclipse.platform.team and where I 
could see no basis for that decision, making it feel like a whim.


Your comments below are super constructive and basically outlines a 
strategy for a plan.  I think this excellent content should go in an 
issue, e.g., #7 , where it can guide the decision making process because 
you perfectly outline the factors to be considered which we shouldn't 
lose in this endless email thread!  Maybe some other folks will also 
have some additional considerations that should be taken into account.


With "just" 15 repos, it should not be too difficult to at least outline 
plan for which ones we'd like to combine, guided by informed choices.  
E.g., I was super happy with 
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/24 
which gathered all the migration information in one place.  We could do 
the same thing again for this merge topic, I hope...


On 31.03.2022 11:19, Aleksandar Kurtakov wrote:



On Thu, Mar 31, 2022 at 10:54 AM Ed Merks  wrote:

I think the broader generalized message here is "please let's make
decisions as group".

Merging repos now feels like a whim.  I'd personally like to see a
documented strategy of which repos we will have when we reach the
end point.  Why only these? Why not more, like what we have now?
Why not have just one?

I'm not arguing for nor against merging.  I would just really
appreciate understanding the strategy and seeing a plan so that we
committers could comment on a cohesive them.  This affects us all
and we should all be included...


So this is not a whim but rather a long going effort started years ago:
* https://www.eclipse.org/lists//eclipse-pmc/msg03054.html - merging 
projects was just the first step. The artificial separation between UI 
and UA for example was a nightmare at organizational level which we 
fixed but it stayed at code level.
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=475932 as an example 
that made it possible for version checks to work (it can't detect 
multi repos) so releng was freed from one more case where we had to 
jump in.


So let me explain what my vision is. There are certain questions which 
drive it:
1. Is the current state of XYZ creating extra work which we can 
reduce? E.g. few more commits for each new stream, separately 
maintained Jenkinsfiles, build scripts update, non functional version 
checks and etc. that could all be reduced
2. Will such a change make it better or harder for committers and 
potential contributors in the long run? E.g. repositories to clone, 
ease to setup new development machine, finding your way in the code.
3. Will such a change make it better or harder for the releng team in 
the long run? E.g. build automation, using more standard tools, giving 
better reports/feedback to developers for their daily work
4. Do we have a deadline? E.g. service will be terminated, lower level 
dependency will no longer be part of the next version of OS and etc.
5. Do we have any limitations that prevent us from doing that change 
now? E.g. too slow build times destroying CI feedback


So can I say that there is a strategy based on ^^  - Yes and no.
So the current strategy is to look up for cases which will have "Yes" 
as an answer to 1-3 and after that analyze 4. and 5.
If there is a deadline act fast so we are ahead of the deadline (I 
still remember the time when we had no builds for certain period as 
all scripts and etc. were run by committer account with cron jobs on 
machines not being accessible and the stress from that) so I'm 100% 
convinced that at the first point a change is "inevitable" it should 
be acted upon.
Last comes 5. - quite often it requires some reorganization and even 
further changes to make it work. Merging all  platform repos would not 
work right now as it will make CI response time totally unbearable but 
this doesn't prevent doing steps in that direction.

E.g. merging platform.team into platform:
* releng will simplify as even on the next cycle we will save time and 
more automation will kick in as there would be less limitations 
imposed by git repos boundaries
* both build in less than 10 minutes on CI and big chunk of of time is 
actually spent in downloading dependencies (huge overlap for both 
repos) so combined build would probably be not more than 2-3 mins 
slower than building them separately
* committers will have to clone one less repo next time they setup new 
machine, short time inconvenience could be having to change local 
scripts/setups
* is our setup harder or easier to understand with such a change - 
https://git.eclipse.org/c/platform/eclipse.platform.team.git/tree/ 
shows and expla

Re: [platform-dev] Intended Bug-Tracker for Platform-projects hosted on GitHub

[Ed Merks]

See, you too are hoping that your opinion matters and that your opinion 
is included in the decision making process.  I expect we all would like 
that very much.


-1000 for merging in the absence of a cohesive plan that the committers 
agree is a good strategy for our project


On 31.03.2022 09:53, Christoph Läubrich wrote:

Am 31.03.22 um 09:42 schrieb Aleksandar Kurtakov:



On Thu, Mar 31, 2022 at 10:35 AM S A 
> wrote:


    Please first finish the GitHub moves and let that settle for a month
    (or better, a fe months). There are enough new problems and
    disruptive changes already.


The thing is in order to fix very old problems and some new we have 
to change things or we are going to add even more bandaid and make it 
even harder to fix later (as it has happened so many times).


+100

later is just another term for "probably never" in 
software-development ;-)

___
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

[Ed Merks]

Do you have a link to the issue?  Auto-closing continues...

On 04.03.2022 10:14, Andrey Loskutov wrote:

Hi all,

this is an update on current state.
I consider voting is done now, the results are (sorry if I've missed anyone) 
19:10 for stop current practice.
I think the result is clear and as proposed before, I will continue with 
creating a ticket for the foundation to disable auto-closing bugs for the 
platform.

+1 to stop closing
An Lo
Jö Ku
Th Si
Sa Si
Ch Lä
Al Fe
Si An
Ha We
JF Ma
St Wa
Ed Me
Al Bl
Li Io
Se Za
Ro Th
Ni Ne
Vi Ch
La Sh
Ka Th

-1 to stop closing
Mi Is
Al Ku
Wi Jo
Mi Wi
Th Wa
Ma Bo
Jo Gr
La Vo
Sr La
Ad Po

Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov



Gesendet: Donnerstag, 17. Februar 2022 um 09:58 Uhr
Von: "Andrey Loskutov" 
An: "platform-dev" 
Betreff: [platform-dev] Vote to stop bug auto-closing in all Eclipse platform 
projects

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

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

[platform-dev] The 4.24 IBuild is Inconsistent

[Ed Merks]

My Tycho builds fails like this last night:

[ERROR] Cannot resolve target definition:
[ERROR]   Software being installed: org.eclipse.sdk.feature.group 
4.24.0.v20220312-2252
[ERROR]   Missing requirement: org.eclipse.core.net.win32.x86_64 
1.1.600.v20220312-1450 requires 'org.eclipse.equinox.p2.iu; 
org.eclipse.core.net.win32 0.0.0' but it could not be found
[ERROR]   Cannot satisfy dependency: org.eclipse.platform.feature.group 
4.24.0.v20220312-1800 depends on: org.eclipse.equinox.p2.iu; 
org.eclipse.core.net.win32.x86_64 
[1.1.600.v20220312-1450,1.1.600.v20220312-1450]
[ERROR]   Cannot satisfy dependency: org.eclipse.sdk.feature.group 
4.24.0.v20220312-2252 depends on: org.eclipse.equinox.p2.iu; 
org.eclipse.platform.feature.group [4.24.0.v20220312-1800,4.24.0.v20220312-1800]

I think that's because this bug introduced a new bundle/fragment

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

But that fragment is not included by /org.eclipse.platform-feature/feature.xml 
which needs this addition:

   

I think that's why org.eclipse.core.net.win32 is s not in the repository.

I'd normally contribute the fix to Gerrit, but that doesn't work for this 
migrated repository.  Is the new process for how to contribute documented 
somewhere?


___
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

[Ed Merks]

Yes, this is indeed an option for the working group to consider. Let's 
see how targeted development works out so that we can expand on such 
success stories...


On 22.02.2022 11:44, Thomas Singer wrote:
Eventually the free ride might come to an end... 


Maybe offering some kind of support contract for companies (for fixing 
their reported bugs) would be an option?



___
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

[Ed Merks]

Comment below.

On 22.02.2022 09:27, Liviu Ionescu wrote:



On 22 Feb 2022, at 10:42, Karsten Thoms  wrote:

... but that’s just reality due to lack of resources.

According to the Annual Eclipse Foundation Community Report, in 2021 the 
Foundation burnt 7.6 M$, so I would not blame the lack of resources.

Probably the word "burnt" is not really the best choice of words.


The question is how many of the 7.6 went to developers maintaining the Eclipse 
platform.
Funding development on one or more of the hundreds of projects hosted at 
Eclipse is not the role of the Foundation.  The Eclipse IDE Working 
Group is looking to do some targeted development work on some aspects of 
the Platform via its much more limited budget.  Its budget has also 
helped develop the improvements to mature PGP signing implementation in p2.


And generally how to find a solution to fix the bugs, not whether to auto-close 
them or not.


More people and organizations who consume things for free need to 
contribute more time and/or more money.  Eventually the free ride might 
come to an end...


I only raise this issue because I maintain lists and I manage what's in 
those lists, within my own personal resource capacity. I don't want a 
robot to remove things from my lists.  How others manage other parts is 
up to them.  But if more people spent a few hours a month looking at 
lists, that would sure help a lot.  If we don't plan to fix something 
ever, let's close it immediately not after 2 years...





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] Vote to stop bug auto-closing in all Eclipse platform projects

[Ed Merks]

+1

On 17.02.2022 09: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

[platform-dev] The p2 gerrit builds are failing right at the start

[Ed Merks]

This build fails

https://ci.eclipse.org/equinox/job/p2/job/44%252F190744%252F2/1/console

It's kicked off from here:

https://git.eclipse.org/r/c/equinox/rt.equinox.p2/+/190744

Is this an infrastructure problem or is this maybe his something related 
to migrating the eclipse.platform.releng to github?


Here's the failing part right at the start...

+ mvn clean verify --batch-mode --fail-at-end 
-Dmaven.repo.local=/home/jenkins/agent/workspace/p2_44_190744_2/.m2/repository 
-Pbuild-individual-bundles -Pbree-libs -Papi-check -DskipTests=false 
-Dcompare-version-with-baselines.skip=false 
-Dmaven.test.error.ignore=true -Dmaven.test.failure.ignore=true 
-Dproject.build.sourceEncoding=UTF-8 Apache Maven 3.8.3 
(ff8e977a158738155dc465c6a97ffaf31982d739) Maven home: 
/opt/tools/apache-maven/latest Java version: 11.0.2, vendor: Oracle 
Corporation, runtime: /opt/tools/java/openjdk/jdk-11/11.0.2+9 Default 
locale: en_US, platform encoding: UTF-8 OS name: "linux", version: 
"5.14.14-200.fc34.x86_64", arch: "amd64", family: "unix" [INFO] Scanning 
for projects... [INFO] Resolving target definition 
file:/home/jenkins/agent/workspace/p2_44_190744_2/.m2/repository/org/eclipse/eclipse-sdk-prereqs/4.23.0-SNAPSHOT/eclipse-sdk-prereqs-4.23.0-SNAPSHOT.target 
for environments=[linux/gtk/x86_64, linux/gtk/ppc64le, 
linux/gtk/aarch64, win32/win32/x86_64, macosx/cocoa/x86_64, 
macosx/cocoa/aarch64], include source mode=honor, execution 
environment=StandardEEResolutionHints [executionEnvironment=OSGi profile 
'JavaSE-11' { source level: 11, target level: 11}], remote p2 repository 
options=org.eclipse.tycho.p2.remote.RemoteAgent@2caa9666... [ERROR] 
org.eclipse.equinox.frameworkadmin.equinox: Failed to resolve target 
definition 
file:/home/jenkins/agent/workspace/p2_44_190744_2/.m2/repository/org/eclipse/eclipse-sdk-prereqs/4.23.0-SNAPSHOT/eclipse-sdk-prereqs-4.23.0-SNAPSHOT.target: 
Could not find "com.google.gson/2.8.8.v20211029-0838" in the 
repositories of the current location
___
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

[Ed Merks]

I do keep lists:

   
https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=NEW_status=ASSIGNED_status=REOPENED_status=RESOLVED=Modeling=releng=doc=website=Core=Doc=Edit=Mapping=Tools=Xcore=XML%2FXMI_id=21197880=resolution%2Cbug_id=EMF_format=advanced=---=FIXED

   
https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=REOPENED_status=FIXED=Modeling=Core_id=21197881=bug_id%20DESC=MDT.XSD_format=advanced

   
https://bugs.eclipse.org/bugs/buglist.cgi?Bugzilla_restrictlogin=on_status=UNCONFIRMED_status=FIXED_status=NEW_status=ASSIGNED_status=REOPENED=Tools=Docs=Dynamic%20Working%20Sets=P2%20Management=Preferences%20Management=Project%20Configuration=Release%20Engineering=Setup=Targlets=Tools=Utilities=Version%20Management_id=21197882=bug_id%20DESC=Oomph_format=advanced

   
https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=REOPENED=Eclipse%20Project=p2_id=21192801=bug_id%20DESC=Equinox_format=advanced

   
https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=REOPENED_status=RESOLVED=Technology=General_id=21197883=Justj_format=advanced

And while you might not keep lists, auto closing issues reminds not just 
you that attention is needed but it reminds the users that you don't 
keep a list.  And it might will tell the users that you don't really 
care about backlogs of issues enough to track them.    Whatever isn't 
dealt with in a few days or weeks will linger for the robot's auto-close 
lifetime by which point the reporter hopefully doesn't care anymore 
either. Of course the problem is not that we nor you don't care, we're 
all just super busy.  But what impression do we want to give the users?  
That we're so busy we need a robot to help us?



On 10.02.2022 11:28, Mickael Istria wrote:
FWIW, I personally like the "reminder" about old bugs I once cared 
about and then have forgotten about, and that often allows me to take 
a decision of whether I'm fine seeing them closed (sometimes marking 
them as resolved or not important any more), or whether I need to 
reopen them with more context.
I almost never do active triaging of those bugs by looking at a bug 
list. The only triaging I do happens by reacting to these 
notifications. Remove the notifications, and I'll personally be doing 
less triaging as a result (for the very little it counts in practice).


If I had to vote, I'd vote -0 for the removal of autoclose, which 
means I don't mind overall about the decision, but if it were only me 
I would keep the autoclose.


___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, 
visithttps://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

[Ed Merks]

Please consider the opinions of your committers and contributors as at 
least relatively important.   We're explaining to you what is important 
to us and why we feel that way.  We don't really so much appreciate our 
opinions being dismissed as not important to you.   We have higher 
expectations from our PMC leads.


If the disease is "lack of triage", we feel that unfortunately the "auto 
triage close cure" is even worse than that disease. We're asking you to 
please stop sending the patients home with a robot.   We might not do a 
good job curing the patients and we could and should definitely discuss 
how to improve our cure rate and our patient satisfaction statistics, 
but in the meanwhile please stop making the problem worse with a robot.  
And please don't characterize what we say as "just not important" 
because that's just plain disrespectful.


On 10.02.2022 10:52, Aleksandar Kurtakov wrote:



On Thu, Feb 10, 2022 at 11:43 AM Rolf Theunissen 
 wrote:


I fully agree. In fact, I consider any bug that is closed and
marked as 'stalebug' as open.

Also, back in the day there seemed to be a different triage
process, and correct me if I am wrong, but it seems that bugs that
are marked as being triaged are not auto-closed. At least some
very old bugs do not get auto-closed.
I know that it is hard to manage the huge back-log of issues. But
there seems also hardly any focus on new incoming bugs, they are
ignored until they are finally automatically closed, which gives a
really bad impression on the overall quality of the projects.


You nailed it! It's pointless discussion whether bugs are autoclosed 
or not aka stay open without anyone looking into it or being closed 
without anyone looking into it. What's important is who will triage 
and fix bugs, look into gerrits and etc.? I'm very interested in the 
later discussion and until we improve on it, discussing the former is 
just non-important to me.



Rolf

Op do 10 feb. 2022 om 08:23 schreef 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://

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

[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



 Forwarded Message 
Subject: 	[Bug 305081] [api] IInstallableUnit#getFilter is marked 
noReference

Date:   Thu, 10 Feb 2022 06:16:14 +
From:   bugzilla-dae...@eclipse.org
To: ed.me...@gmail.com



https://bugs.eclipse.org/bugs/show_bug.cgi?id=305081
Product/Component: Equinox / p2


Eclipse Genie  changed:

What |Removed |Added

Resolution|--- |WONTFIX
Status|NEW |CLOSED
Whiteboard| |stalebug

--- Comment #3 from Eclipse Genie  ---
This bug hasn't had any activity in quite some time. Maybe the problem got
resolved, was a duplicate of something else, or became less pressing for 
some

reason - or maybe it's still relevant but just hasn't been looked at yet. As
such, we're closing this bug.

If you have further information on the current state of the bug, please 
add it

and reopen this bug. The information can be, for example, that the problem
still occurs, that you still want the feature, that more information is 
needed,

or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.

--
You are receiving this mail because:
You are on the CC list for the bug.
You are watching the assignee of the bug.
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] CI Bot not Working?

[Ed Merks]

Hi,

Since at least last Friday, CI Bot doesn't get automatically added, so 
Gerrit builds don't kick off anymore.  E.g.,


https://git.eclipse.org/r/c/equinox/rt.equinox.p2/+/190518

Is this a general problem others have noticed too or it it specific to p2?

Regards,
Ed

___
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] PGP Signing Question?

[Ed Merks]

Mickael,

Thanks.

More comments below.

On 03.01.2022 13:18, Mickael Istria wrote:



On Mon, Jan 3, 2022 at 11:55 AM Ed Merks  wrote:

Is there a bug here?  I don't think we can expect the users to
grant trust on the basis of some hexadecimal numbers...


Actually, they can grant trust based on  those numbers because users 
should verify those signers are trusted, eg by checking whether the 
ids are matching some verified keys in some external PGP services.

But indeed, the UI is still rough and still needs to be improved.
I've opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=578024 to 
track this issue.    Minimally the help for the dialog should describe 
how to find such external PGP services and in our case specifically how 
to verify that this is an Eclipse project's key. We can discuss the 
details there.  I can try to help iron out the wrinkles...


Where/what is the best way for asking question and for discussing
the implementation details? I posted on platform-dev because the
entire platform is affected by these design decisions, but perhaps
I should restrict this to p2-dev or elsewhere?


Bugs against p2 are the best channel IMO.


So, for example, if I have the question "is it guaranteed that two 
different org.bouncycastle.openpgp.PGPPublicKey instances might have the 
same org.bouncycastle.openpgp.PGPPublicKey.getKeyID() values" that 
should be a p2 Bugzilla?  I wouldn't ask that on platform-dev but I 
would have thought to ask on p2-dev rather than open a question 
Bugzilla.  I see no reason to assume that the getKeyID values are 
unique, though I suppose the chances of collisions are vanishingly small 
(and downstream utility class seem to assume this).



I expect there is a concern about the size of many such the
duplicates keys, but with both jar and *.xz compression that isn't
really so much a problem.  I.e., 1000 copies of the key has
minimal impact on the size compressed artifacts as seen here where
the artifacts.xml has 1000 copies of the key:


OK, I probably made a wrong estimation back then, and maybe adding the 
signer key to each artifact would be preferable.


And even the

org.eclipse.equinox.p2.tests.engine.CertificateCheckerTest.testPGPSignedArtifactUntrustedKey()
test works that way...


Yes, this is supposed to work with key as artifact property. The 
metrics you shared seem to highlight it would be a better approach, so 
please open a bug to Platform/Releng so we can try to improve that.
I've opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=578023 to 
track this issue.


___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, 
visithttps://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] PGP Signing Question?

[Ed Merks]

Hi,

I've been investigating the new PGP signing support.  To test it, I 
install the Eclipse Test Framework from the 4.23 I-Builds because that 
includes several bundles that are PGP signed:


As a result of this action, the following dialog pops up asking me if I 
trust "these signers":


There is no information in the name column.  I believe it's populated by 
org.eclipse.equinox.internal.p2.ui.dialogs.TrustCertificateDialog.createUpperDialogArea(Composite) 
like this:


        java.util.List users = new ArrayList<>();
        pgp.getUserIDs().forEachRemaining(users::add);
        return String.join(",", users); //$NON-NLS-1

Looking at the implementation, I don't see how a PGPPublicKey ever ends 
up with associated "user IDs".    (And the Details... button is only 
enabled for a selected X509Certificate.)


Is there a bug here?  I don't think we can expect the users to grant 
trust on the basis of some hexadecimal numbers...


--

Where/what is the best way for asking question and for discussing the 
implementation details? I posted on platform-dev because the entire 
platform is affected by these design decisions, but perhaps I should 
restrict this to p2-dev or elsewhere?


For example, the fact that the keys are stored as repository properties, 
rather than as properties on the artifacts, seems quite problematic and 
will tend to break downstream applications. We've already seen that this 
breaks mirroring because mirroring doesn't mirror repository properties 
nor should it in general do so.  It also breaks the installer (i.e., in 
general the use of p2 agents with a shared p2 bundle pool).  It will no 
doubt impact the aggregator as well.  Every consumer will need to know 
to "copy and merge" this specific repository property (but not any other 
repository properties) when copying/mirroring artifacts.


I expect there is a concern about the size of many such the duplicates 
keys, but with both jar and *.xz compression that isn't really so much a 
problem.  I.e., 1000 copies of the key has minimal impact on the size 
compressed artifacts as seen here where the artifacts.xml has 1000 
copies of the key:


-rw-r--r-- 1 merks 197609  823870 Jan  3 11:31 artifacts.original.xml
-rw-r--r-- 1 merks 197609  119252 Jan  3 11:32 artifacts.original.xml.jar
-rw-r--r-- 1 merks 197609   89796 Jan  3 11:37 artifacts.original.xml.xz
-rw-r--r-- 1 merks 197609 1264772 Jan  3 11:14 artifacts.xml
-rw-r--r-- 1 merks 197609  122441 Jan  3 11:33 artifacts.xml.jar
-rw-r--r-- 1 merks 197609   90008 Jan  3 11:38 artifacts.xml.xz

The implementation sort of already assumes/supports it as an artifact 
key in 
org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.findKey(long, 
IArtifactDescriptor)  like this:


    // in case keys from artifact were not imported yet in 
keystore, add them

    PGPSignatureVerifier.KNOWN_KEYS
.addKeys(artifact.getProperty(PGPSignatureVerifier.PGP_SIGNER_KEYS_PROPERTY_NAME));
    return PGPSignatureVerifier.KNOWN_KEYS.getKey(id);

And even the 
org.eclipse.equinox.p2.tests.engine.CertificateCheckerTest.testPGPSignedArtifactUntrustedKey() 
test works that way...


Regards,
Ed
___
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] Getting the solution of a P2 resolve operation including missing requirements

[Ed Merks]

Christoph,

Certainly quite a number of things things in Oomph could be generally 
contributed to p2...


The problem is that this is also not without yet more additional effort 
and I am only one person who "must" keep 4 project afloat and on the 
train...


Also, if such additions are then generally used, they must be supported 
as API, which makes it less easy to change for my own purposes, e.g., 
when I recently added support for ignoring negative requirements.   No 
doubt you've noticed that you cannot do so much interesting and useful 
stuff with p2 without "internal" "APIs", so everyone doing interesting 
p2 things ends up using various internal things...


Also, if Oomph relies on some feature being in a new/recent version of 
p2 then those things cannot work with older versions of p2 where this 
addition isn't present.


Regards,
Ed

On 02.01.2022 08:26, Christoph Läubrich wrote:

Thanks Ed,

thanks for sharing this, looking at the effort taken into this Util 
methods I wonder if it would make sense to contribute those to P2 so 
they are generally available?


With some testing I have now chosen an incremental approach instead 
that generates some intermediate IUs that are later removed from the 
set of resolved units by extracting the missing requirements from the 
explanation [1].


That has the advantage for my use case that I don't need to modify the 
IUs back as they are used later on to resolve other stuff as well.
Now I get a all resolvable items and a list of unresolved requirements 
as well.


[1] https://github.com/eclipse/tycho/pull/468

Am 31.12.21 um 10:26 schrieb Ed Merks:

Christoph,

The approach that we took with using p2 to implement Targlet support 
is to transform all the metadata such that resolution meets our needs:


https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/plugins/org.eclipse.oomph.p2.core/src/org/eclipse/oomph/p2/core/P2Util.java#n223 



For the specific case you describe, making all the requirements 
optional and greedy ensures that all requirements that can be 
resolved are resolved but failures to resolve a requirement do not 
fail the overall resolution.


This does not get you two sets of things though.  You'd still need to 
check afterwards if any non-optional requirement is unsatisfied to 
get your second list.   But that's iterating over all the resolved 
IU's requirements and querying each against the other resolved IUs to 
collect that list of unresolved requirements...


Regards,
Ed


On 30.12.2021 20:09, Christoph Läubrich wrote:
I'm currently investigate if it is already possible to get a result 
from the Projector.invokeSolver call even if the result is not 
resolvable.


What I want to archive is to resolve a state as if all missing 
requirements are there (and just reported as such).


For example I have a bundle that is missing an import package, then 
I get the error:


Software being installed: tycho.bundle 1.0.0.qualifier
 Missing requirement: tycho.bundle 1.0.0.qualifier requires 
'java.package; my.missing.package 0.0.0' but it could not be found


I now wanted to get two "sets":

1) all resolved items as if the package was not missing
2) all missing requirements (in this case the missing package)

What I could think of is to do this in an incremental way, eg. first 
try to resolve, then get the missing items and create a new resolver 
run with a dummy unit providing the missing item and thus keep track 
of all these dummy items in a list.


I just wanted to make sure that I'm not missing an existing function 
that already do this.

___
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

___
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] Getting the solution of a P2 resolve operation including missing requirements

[Ed Merks]

Christoph,

The approach that we took with using p2 to implement Targlet support is 
to transform all the metadata such that resolution meets our needs:


https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/plugins/org.eclipse.oomph.p2.core/src/org/eclipse/oomph/p2/core/P2Util.java#n223

For the specific case you describe, making all the requirements optional 
and greedy ensures that all requirements that can be resolved are 
resolved but failures to resolve a requirement do not fail the overall 
resolution.


This does not get you two sets of things though.  You'd still need to 
check afterwards if any non-optional requirement is unsatisfied to get 
your second list.   But that's iterating over all the resolved IU's 
requirements and querying each against the other resolved IUs to collect 
that list of unresolved requirements...


Regards,
Ed


On 30.12.2021 20:09, Christoph Läubrich wrote:
I'm currently investigate if it is already possible to get a result 
from the Projector.invokeSolver call even if the result is not 
resolvable.


What I want to archive is to resolve a state as if all missing 
requirements are there (and just reported as such).


For example I have a bundle that is missing an import package, then I 
get the error:


Software being installed: tycho.bundle 1.0.0.qualifier
 Missing requirement: tycho.bundle 1.0.0.qualifier requires 
'java.package; my.missing.package 0.0.0' but it could not be found


I now wanted to get two "sets":

1) all resolved items as if the package was not missing
2) all missing requirements (in this case the missing package)

What I could think of is to do this in an incremental way, eg. first 
try to resolve, then get the missing items and create a new resolver 
run with a dummy unit providing the missing item and thus keep track 
of all these dummy items in a list.


I just wanted to make sure that I'm not missing an existing function 
that already do this.

___
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] Unsigned Content?

[Ed Merks]

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

On 17.12.2021 09:44, Mickael Istria wrote:



On Fri, Dec 17, 2021 at 9:11 AM Ed Merks  wrote:

Here is what happens when the installer tries to install
org.mockito.mockito-core into a Platform SDK IDE:

java.lang.NullPointerException
    at

org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.buildPGPTrustore(CertificateChecker.java:311)
    at

org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker$1.get(CertificateChecker.java:63)
    at

org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker$1.get(CertificateChecker.java:1)
    at

org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.checkCertificates(CertificateChecker.java:126)
    at

org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.start(CertificateChecker.java:83)
    at

org.eclipse.equinox.internal.p2.engine.phases.CheckTrust.completePhase(CheckTrust.java:63)
    at
org.eclipse.equinox.internal.p2.engine.Phase.postPerform(Phase.java:254)
    at
org.eclipse.equinox.internal.p2.engine.Phase.perform(Phase.java:105)
    at
org.eclipse.equinox.internal.p2.engine.PhaseSet.perform(PhaseSet.java:50)
    at
org.eclipse.equinox.internal.p2.engine.Engine.perform(Engine.java:80)
    at
org.eclipse.equinox.internal.p2.engine.Engine.perform(Engine.java:48)
    at

org.eclipse.equinox.internal.provisional.p2.director.PlanExecutionHelper.executePlan(PlanExecutionHelper.java:46)
    at

org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl$3.commit(ProfileTransactionImpl.java:549)
    at

org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl.commit(ProfileTransactionImpl.java:345)
    at
org.eclipse.oomph.setup.p2.impl.P2TaskImpl.perform(P2TaskImpl.java:905)
    at

org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.doPerformNeededSetupTasks(SetupTaskPerformer.java:3851)
    at

org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performNeededSetupTasks(SetupTaskPerformer.java:3779)
    at

org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performTriggeredSetupTasks(SetupTaskPerformer.java:3760)
    at

org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.perform(SetupTaskPerformer.java:3638)
    at
org.eclipse.oomph.setup.ui.wizards.ProgressPage$9.run(ProgressPage.java:600)
    at

org.eclipse.oomph.setup.ui.wizards.ProgressPage$11$1.run(ProgressPage.java:727)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

Why?  Because

org.eclipse.equinox.internal.p2.engine.phases.CheckTrust.completePhase(IProgressMonitor,
IProfile, Map) knows the profile, but the
certificate checker doesn't know to check that profile but rather
checks the self profile.  I imagine the p2 director will have such
problems too, or perhaps it will not fail but also might not
actually check the correct profile...


Such feedback is really welcome. Can you please open a dedicated bug 
for this issue and add me as CC ?


I wonder though if n projects have to duplicate the effort n times
if that will be n times the work.


The effort of consuming upstream artifacts from Maven is equivalent to 
the effort of consuming artifacts from Orbit. So there is no extra 
effort involved for consumers, they just change a version in their 
.target and that's all.
"Downstream" projects can also directly consume bundles provided by 
their "upstream" ones in a plain p2 way. For example, a project that 
need mockito can just take Mockito from Platform instead of Orbit, 
without playing with Maven dependencies. It's actually already a 
common and efficient: may target files don't reference Orbit and pick 
the libs that's provided by their "upstream".


Also, might we end up with n versions of each such bundle?


We already do have N versions of several libs, split across multiple 
repositories (eg some older projects don't rebuild against latest 
Orbit and still include older libs). p2 -during SimRel aggregation or 
installation on user end- does take care of picking the best and tries 
to avoid multiple versions when this can be avoided.
Consuming libs from Maven instead of Orbit doesn't really change the 
problem/solution in the end.



___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, 
visithttps://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] Unsigned Content?

[Ed Merks]

Comments below.

On 17.12.2021 07:46, Aleksandar Kurtakov wrote:



On Fri, Dec 17, 2021 at 8:01 AM Ed Merks  wrote:

Has the platform decided to bypass Orbit to produce IUs directly from
some other sources?   I'm not sure how the multiple versions of
such IUs
on the release train will be (or even can be) coordinated across
projects if the general new approach is that each project produces
such
things purely for its own purpose from whatever sources it deems fit.

Also, the artifacts are not signed, which is the reason that I
noticed:


https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.23-I-builds/index.html

Note that once an unsigned version of some specific artifact ID is
out
there is the wild (in someone's bundle pool), it's extremely hard to
stamp it out unless a new version with a new artifact ID is
created to
supersede it.

Perhaps the platform has decided that PGP signatures are now
deemed to
be fully secure and fully feature complete such that signatures are
obsolete?  This is not the expectation I have based Planning Council
discussions.


Platform is not contributing these to release train so no issue for 
release train for now!
That appears to be the case given these particular IUs are not on the 
current train.
The feature org.eclipse.test relies on PGP on purpose as this is our 
proof and example how PGP works and is on par with jarsigner as far as 
signing requirements for third party dependencies are considered 
https://github.com/eclipse-cbi/best-practices/blob/main/software-supply-chain/osssc-best-practices.md#securing-third-party-artifacts 
.


A proof of concept is arguably useful.

Here is what happens when the installer tries to install 
org.mockito.mockito-core into a Platform SDK IDE:


java.lang.NullPointerException
    at 
org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.buildPGPTrustore(CertificateChecker.java:311)
    at 
org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker$1.get(CertificateChecker.java:63)
    at 
org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker$1.get(CertificateChecker.java:1)
    at 
org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.checkCertificates(CertificateChecker.java:126)
    at 
org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.start(CertificateChecker.java:83)
    at 
org.eclipse.equinox.internal.p2.engine.phases.CheckTrust.completePhase(CheckTrust.java:63)
    at 
org.eclipse.equinox.internal.p2.engine.Phase.postPerform(Phase.java:254)

    at org.eclipse.equinox.internal.p2.engine.Phase.perform(Phase.java:105)
    at 
org.eclipse.equinox.internal.p2.engine.PhaseSet.perform(PhaseSet.java:50)
    at 
org.eclipse.equinox.internal.p2.engine.Engine.perform(Engine.java:80)
    at 
org.eclipse.equinox.internal.p2.engine.Engine.perform(Engine.java:48)
    at 
org.eclipse.equinox.internal.provisional.p2.director.PlanExecutionHelper.executePlan(PlanExecutionHelper.java:46)
    at 
org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl$3.commit(ProfileTransactionImpl.java:549)
    at 
org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl.commit(ProfileTransactionImpl.java:345)
    at 
org.eclipse.oomph.setup.p2.impl.P2TaskImpl.perform(P2TaskImpl.java:905)
    at 
org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.doPerformNeededSetupTasks(SetupTaskPerformer.java:3851)
    at 
org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performNeededSetupTasks(SetupTaskPerformer.java:3779)
    at 
org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performTriggeredSetupTasks(SetupTaskPerformer.java:3760)
    at 
org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.perform(SetupTaskPerformer.java:3638)
    at 
org.eclipse.oomph.setup.ui.wizards.ProgressPage$9.run(ProgressPage.java:600)
    at 
org.eclipse.oomph.setup.ui.wizards.ProgressPage$11$1.run(ProgressPage.java:727)

    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

Why?  Because 
org.eclipse.equinox.internal.p2.engine.phases.CheckTrust.completePhase(IProgressMonitor, 
IProfile, Map) knows the profile, but the certificate 
checker doesn't know to check that profile but rather checks the self 
profile.  I imagine the p2 director will have such problems too, or 
perhaps it will not fail but also might not actually check the correct 
profile...
Updating mockito and friends to newer versions so they work with 
latest Java versions is a task we couldn't have completed if we had 
gone through Orbit as this literally doubles the work involved.
I sympathize fully with the endless work of getting things done 
primarily for the benefit of others.  I wonder though if n projects have 
to duplicate the effort n times if that will be n times the work.  Also, 
might we end up with n versions of each such bundle? That's not a 
problem for the platform, but it's problem for SimRel

[platform-dev] Unsigned Content?

[Ed Merks]

Has the platform decided to bypass Orbit to produce IUs directly from 
some other sources?   I'm not sure how the multiple versions of such IUs 
on the release train will be (or even can be) coordinated across 
projects if the general new approach is that each project produces such 
things purely for its own purpose from whatever sources it deems fit.


Also, the artifacts are not signed, which is the reason that I noticed:

https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.23-I-builds/index.html

Note that once an unsigned version of some specific artifact ID is out 
there is the wild (in someone's bundle pool), it's extremely hard to 
stamp it out unless a new version with a new artifact ID is created to 
supersede it.


Perhaps the platform has decided that PGP signatures are now deemed to 
be fully secure and fully feature complete such that signatures are 
obsolete?  This is not the expectation I have based Planning Council 
discussions.


___
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?

[Ed Merks]

Thomas,

You could use the following approach so that you have an IDE with *all 
*the projects in the platform SDK automatically created.  You can use 
this simple link to get started:


https://www.eclipse.org/setups/installer/?url=https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/interim/PlatformSDKConfiguration.setup=true

Or, if you want more detailed documentation for how that works, there is 
this:


https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning

Of course this is overkill for your specific question because you only 
need SWT:



On 09.12.2021 13:21, 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.
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] API Errors for SWT

[Ed Merks]

After pulling today I see these errors:

I wonder how this slipped through the cracks?  Even if I fix the first 
error the others remain.  I guess those are then normally filtered?
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Gerrit Verification for eclipse.platform.releng

[Ed Merks]

Hi,

The build to verify

https://git.eclipse.org/r/c/platform/eclipse.platform.releng/+/185693

fails like this:

https://ci.eclipse.org/platform/job/eclipse.platform.releng/job/93%252F185693%252F3/1/

But my impression is that this isn't a result of my changes but rather 
that this test cannot pass for a Gerrit verification build.  E.g., 
"buildId property must be specified for testComparatorLogSize test" is a 
failure caused by the build job configuration:


        String buildId = System.getProperty("buildId");
        assertNotNull("buildId property must be specified for 
testComparatorLogSize test", buildId);


So I think to proceed I need to bypass the verification build.

Please correct me if that is a wrong assumption.

Regards,
Ed

___
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

[Ed Merks]

Christoph,

Comments below.

On 19.08.2021 09:03, Christoph Läubrich wrote:

Hi Ed,

I used the oompf setup and regularly do "Search For Updates" and 
"Perform Setup Tasks" is this the right way to keep up to date?
The latter is more correct.  E.g., it would take into account any 
changes to the setup that might introduce new requirements that would 
not be picked up simply by updating existing requirements.


As an example the bundle 'org.eclipse.equinox.p2.artifact.repository' 
without the change in settings I get an error in ChecksumUtilities:


Description    Resource    Path    Location    Type
Javadoc: Description expected after this reference 
ChecksumUtilities.java 
/org.eclipse.equinox.p2.artifact.repository/src/org/eclipse/equinox/internal/p2/artifact/processors/checksum 
line 39    Java Problem


The quickfix suggest me to configure problem severity where the 
"Malformed Javadoc comments" are set to "Error", if i turn this into 
"warning" the marker change to warning, so I assume this is the 
relevant setting here.


That's strange though because I don't see errors for that file at that line:


And the project specific preferences say this:

While the global ones say this:

If I recall correctly if for any specific preference it's not present in 
the *.prefs, that one will default to the global one.


Nothing here appears to validate the @param nor to care that there is a 
missing comment even if it did...


Regards,
Ed



Maybe there needs something to be configured on the preferences as well?


Am 19.08.21 um 07:32 schrieb Ed Merks:

Christoph,

I have the entire SDK in a workspace without errors:

This is of course using the Oomph setups for these projects.

https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning

Perhaps you're doing something differently from others?  What's an 
example of an error that you see?


If I break some Javadoc in a project with this set to error, it does 
result in an error:



Regards,
Ed


On 18.08.2021 19: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



___
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] Outlook for p2 repo of the 4.20 release

[Ed Merks]

Sravan,

Great.  Locally I've regenerated the catalog and have I tested 
installing the Eclipse SDK 4.20 product from it, along with JustJ Java 
16.01.  It all works very well.  So I'm all set for Wednesday...


Thanks,
Ed

On 14.06.2021 17:13, Sravan K Lakkimsetti wrote:


The repository is ready now. Can you please check?

Thanks
Sravan

-Original Message-
From: Ed Merks 
Sent: 14 June 2021 13:09
To: Eclipse platform general developers list. 
Subject: [EXTERNAL] [platform-dev] Outlook for p2 repo of the 4.20 release

When should we expect to see the equivalent of the following 4.19 
repository corresponding to the 4.19 release for the 4.20 release?


https://download.eclipse.org/justj/?file=eclipse/updates/4.19/R-4.19-202103031800 
<https://download.eclipse.org/justj/?file=eclipse/updates/4.19/R-4.19-202103031800>


This is still repo is still empty:

https://download.eclipse.org/justj/?file=eclipse/updates/4.20 
<https://download.eclipse.org/justj/?file=eclipse/updates/4.20>


I need the final fixed URL to make the final updates to the setup 
catalogs before the release on Wednesday. Of course the mirrors need 
this in advance too...


Regards,
Ed


___
platform-dev mailing list
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] Outlook for p2 repo of the 4.20 release

[Ed Merks]

When should we expect to see the equivalent of the following 4.19 
repository corresponding to the 4.19 release for the 4.20 release?


https://download.eclipse.org/justj/?file=eclipse/updates/4.19/R-4.19-202103031800

This is still repo is still empty:

https://download.eclipse.org/justj/?file=eclipse/updates/4.20

I need the final fixed URL to make the final updates to the setup 
catalogs before the release on Wednesday.  Of course the mirrors need 
this in advance too...


Regards,
Ed


___
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] recommended way placing the workspace relative to the location of the launcher

[Ed Merks]

Yes, I think you just can't be sure where absolute locations will be 
stored both in the workspace and even in the installation (configuration 
folder) once it has been launched in a non-readonly location...



On 27.05.2021 19:01, Jonah Graham wrote:


The help has a bunch of options, but none that covers your use case as 
far as I can see - 
https://help.eclipse.org/2021-03/topic/org.eclipse.platform.doc.isv/reference/misc/runtime-options.html?cp=2_1_5_0 
 



That said, I did see this commit come through 
https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/179406 
 
and it may add a new option from 2021-06 of @launcher.dir, but that 
seems so far only implemented to resolve (and allow relocation of) 
the install area, rather than the workspace.


Also, do you have a special use case? because AFAIK workspaces are not 
relocatable. Certainly JDT / CDT put absolute paths in the workspace 
metadata.


HTH,
Jonah


~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com 


On Thu, 27 May 2021 at 12:49, Christoph Läubrich 
mailto:lae...@laeubi-soft.de>> wrote:


I want to place an Eclipse-Install + its workspace on an USB
drive, of
course, depending on the computer where I do plug this into the drive
letter / path might change. At best I could have a Layout similar to
what the eclipse-installer produces:

/eclipse
/ws

If I use the simple approach:

-Dosgi.instance.area=../ws

this is placed in the current working(!) directory but not
relative to
the /eclipse folder...

What I have tired so far (without success):

- @config.dir/
- reference:


___
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] [cross-project-issues-dev] Signed content

[Ed Merks]

Sravan,

Don't worry!  You were simply being honest about how you felt and given 
there was indeed no intent behind the unsigned artifacts it's perfectly 
understandable that you should find my comments upsetting and therefore 
offensive.   Am I am sorry for that.


Yes, signing jars produced by others, especially externally, is not 
completely ideal either.  I know the platform is working on alternatives 
to that and of course that's something we'll need to consider and 
discuss in the near future as an alternative.


Regards,
Ed


On 03.05.2021 10:20, Sravan K Lakkimsetti wrote:


Hi Ed,

I am sorry If I offended you with my earlier mail. Let me clarify my 
stance on signing.


Any bundle that is built by Eclipse project has to be signed. To me 
this is non-negotiable.


The discussion is on the orbit bundles that gets built by fetching 
from maven central. By signing these we are actually creating new 
bundle which can diverge(technically) from the source(maven central). 
In this case the vendor will not responsible(as we modified the 
bundle) from problems we encounter in the bundle. This is something I 
want to find a solution for. We had discussions but there is no 
concrete solution in this matter.


I hope I clarified my position in this matter.

Thanks

Sravan

*From:*Ed Merks 
*Sent:* 03 May 2021 11:57
*To:* Eclipse platform general developers list. 
; Cross project issues 
; Eclipse Planning Council 
; eclipse-ide...@eclipse.org
*Subject:* [EXTERNAL] Re: [cross-project-issues-dev] [platform-dev] 
Signed content


Sravan, I flushed the cache on the job's workspace and reran it from 
scratch. https://ci.eclipse.org/oomph/job/repository-analyzer/ 
<https://ci.eclipse.org/oomph/job/repository-analyzer/> This time it 
did not find unsigned jars from the platform's builds nor in the 
SimRel aggregation. So most likely


Sravan,

I flushed the cache on the job's workspace and reran it from scratch.

https://ci.eclipse.org/oomph/job/repository-analyzer/ 
<https://ci.eclipse.org/oomph/job/repository-analyzer/>


This time it did not find unsigned jars from the platform's builds nor 
in the SimRel aggregation.  So most likely there was some build at 
some time in which these were not signed, and those were cached the 
first time they were visible. There's no way to track down such 
artifact history when the IU IDs are identical; and these IUs have no 
qualifier in the version...


Sorry for the false alarm.  The platform never has made such mistakes 
in the past, so the basic assumption was that this therefore was a 
deliberate choice, especially given the ongoing discussions about not 
signing things like Jetty in particular.  Sorry for jumping to 
conclusions.


I feel better with your statement that such a change would not be made 
unilaterally and without notice.


Regards,
Ed

On 02.05.2021 14:11, Sravan K Lakkimsetti wrote:

I don’t this mail is in good intentions. This is really offending
and upsetting.

This was not reported with the repository analysers either in
platform

<https://download.eclipse.org/eclipse/downloads/drops4/I20210429-1800/buildlogs/reporeports/index.html>
or simrel
<https://download.eclipse.org/staging/2021-06/buildInfo/reporeports/>.


Here is the output of jarsigner when I ran on
org.eclipse.jetty.util.ajax


C:\Users\SRAVANLAKKIMSETTI\Downloads>"c:\EclipseTest\JAVA\jdk-11.0.10+9\bin\jarsigner.exe"
-verify org.eclipse.jetty.util.ajax_10.0.2.jar

jar verified.

We do have a test in platform to verify unsigned content in the
repository. That test will fail if any bundle is reported as
unsigned. This is based on the repository analyser report
generated during the build. We have been using this for quite some
time. I myself has stopped simrel contribution multiple times the
moment I notice a problem with signing.

I don’t see a problem when the jarsigner returns as success.

-Sravan

*From:*Ed Merks  <mailto:ed.me...@gmail.com>
*Sent:* 02 May 2021 13:41
*To:* Eclipse platform general developers list.
 <mailto:platform-dev@eclipse.org>;
Cross project issues 
<mailto:cross-project-issues-...@eclipse.org>; Eclipse Planning
Council 
<mailto:eclipse.org-planning-coun...@eclipse.org>;
eclipse-ide...@eclipse.org <mailto:eclipse-ide...@eclipse.org>
*Subject:* [EXTERNAL] [platform-dev] Signed content

Hi, I am assume from observation that the platform team has
decided to change its signing policy to not physically sign some
jars anymore:

https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.20-I-builds/index.html

<https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.20-I-builds/index.html>



Hi,

I am assume from observation that the platform team has decided to
change

Re: [platform-dev] Signed content

[Ed Merks]

Sravan,

I flushed the cache on the job's workspace and reran it from scratch.

  https://ci.eclipse.org/oomph/job/repository-analyzer/

This time it did not find unsigned jars from the platform's builds nor 
in the SimRel aggregation.  So most likely there was some build at some 
time in which these were not signed, and those were cached the first 
time they were visible.  There's no way to track down such artifact 
history when the IU IDs are identical; and these IUs have no qualifier 
in the version...


Sorry for the false alarm.  The platform never has made such mistakes in 
the past, so the basic assumption was that this therefore was a 
deliberate choice, especially given the ongoing discussions about not 
signing things like Jetty in particular. Sorry for jumping to conclusions.


I feel better with your statement that such a change would not be made 
unilaterally and without notice.


Regards,
Ed

On 02.05.2021 14:11, Sravan K Lakkimsetti wrote:


I don’t this mail is in good intentions. This is really offending and 
upsetting.


This was not reported with the repository analysers either in platform 
<https://download.eclipse.org/eclipse/downloads/drops4/I20210429-1800/buildlogs/reporeports/index.html> 
or simrel 
<https://download.eclipse.org/staging/2021-06/buildInfo/reporeports/>.


Here is the output of jarsigner when I ran on org.eclipse.jetty.util.ajax

C:\Users\SRAVANLAKKIMSETTI\Downloads>"c:\EclipseTest\JAVA\jdk-11.0.10+9\bin\jarsigner.exe" 
-verify org.eclipse.jetty.util.ajax_10.0.2.jar


jar verified.

We do have a test in platform to verify unsigned content in the 
repository. That test will fail if any bundle is reported as unsigned. 
This is based on the repository analyser report generated during the 
build. We have been using this for quite some time. I myself has 
stopped simrel contribution multiple times the moment I notice a 
problem with signing.


I don’t see a problem when the jarsigner returns as success.

-Sravan

*From:*Ed Merks 
*Sent:* 02 May 2021 13:41
*To:* Eclipse platform general developers list. 
; Cross project issues 
; Eclipse Planning Council 
; eclipse-ide...@eclipse.org

*Subject:* [EXTERNAL] [platform-dev] Signed content

Hi, I am assume from observation that the platform team has decided to 
change its signing policy to not physically sign some jars anymore: 
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.20-I-builds/index.html 
<https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.20-I-builds/index.html> 



Hi,

I am assume from observation that the platform team has decided to 
change its signing policy to not physically sign some jars anymore:


https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.20-I-builds/index.html 
<https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.20-I-builds/index.html>


This of course propagates to SimRel:

https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/staging/2021-06/index.html 
<https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/staging/2021-06/index.html>


I don't recall a Planning Council policy decision to drop/change the 
need for signed jars.  I don't know the full impact this has on the 
installer nor on consumers.   The installer at least appears to 
happily install such things and the IDE presents such things to the 
user as if they are signed:


Slowly I get the feeling that SimRel is a no longer process where we 
all work together as a team.  Rather it feels as if the platform team 
can and does unilaterally make decisions for everyone else.


Regards,
Ed



___
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] Signed content

[Ed Merks]

Hi,

I am assume from observation that the platform team has decided to 
change its signing policy to not physically sign some jars anymore:


https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.20-I-builds/index.html

This of course propagates to SimRel:

https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/staging/2021-06/index.html

I don't recall a Planning Council policy decision to drop/change the 
need for signed jars.  I don't know the full impact this has on the 
installer nor on consumers.   The installer at least appears to happily 
install such things and the IDE presents such things to the user as if 
they are signed:


Slowly I get the feeling that SimRel is a no longer process where we all 
work together as a team.  Rather it feels as if the platform team can 
and does unilaterally make decisions for everyone else.


Regards,
Ed


___
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?

[Ed Merks]

On 29.03.2021 08:24, Christoph Läubrich wrote:
I think I recently read about that's it is possible to have a "button" 
in a html page that links to an Oomph setup file and simply creates 
the IDE+checkouts and so on. I think that should be the very first 
thing any project that wishes to attract developers should setup. 


Yes, this page has a link with such a button:

https://www.eclipse.org/setups/installer/?url=https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/interim/PlatformSDKConfiguration.setup=true

I.e., like this for those who don't follow links:

The actual link URL on the button is this:

eclipse+installer:https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/interim/PlatformSDKConfiguration.setup 



Most people use the installer in a disposable way, but of course one 
must keep it around more permanently and register it as a link handler 
to make direct use of such a single-click link.  That's why I provide a 
generic page through which to indirect the configuration link such that 
the user has documentation about different ways to use the configuration 
link.


The embedded documentation in the Configuration itself is also included 
on this indirection page.  In this case that documentation has a link to 
the tutorial documentation that I wrote specifically for the overall 
platform's configuration to make it easy for anyone to get started in 
order contribute to any part of the platform or all parts of the platform:


https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning

So mostly one just needs a Project setup (I've already written ones for 
all the platform projects, so that's done), and a Configuration (which 
essentially just selects which Product Version to install and which 
Project Streams to provision):


https://wiki.eclipse.org/Eclipse_Oomph_Authoring#Automation_and_Specialization_with_Configurations

___
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

[Ed Merks]

It sounds like a very sensitive area where even subtle changes in 
behavior (timing of events) are likely to be disruptive downstream...


What will be the net benefit from such a change from an end-user point 
of view as well as from and downstream developer point of view?  I.e., 
will something be faster or more flexible?  Will the platform be 
easier/cheaper to maintain?


I see this is related to the following bug.  There it talks about 
simplifying what the activator does:


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

Of course simplification is also a worthwhile goal...


On 22.03.2021 23:38, Alex Blewitt wrote:
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
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 

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

[Ed Merks]

On 18.03.2021 09:51, Mickael Istria wrote:
But I think Oomph cannot be the silver-bullet of attracting new 
contributors: Oomph is still an Eclipse specific technology and 
workflow newcomers will need to learn and read about in order to 
become efficient.


I'm not sure many of us are convinced that GitHub itself is a magic 
bullet despite anecdotes to the contrary.


The point of Oomph is that it's fully automated, with defaults such that 
one can just hit next, next, finish.  I don't think it's possible to 
have fewer manual tasks nor less reading for a motivated but lazy 
(time-constrained) user:


https://www.eclipse.org/setups/installer/?url=https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/interim/PlatformSDKConfiguration.setup=true

The premise that this not a silver-bullet because it is Eclipse-specific 
is questionable at best.  Surely no one will be contributing to any part 
of the platform without using Eclipse, or am I missing something?


My sense continues to be that the platform team's own "not invented 
here, or not invented by us" aversion is the primary problem of a missed 
opportunity here.  Folks just don't feel a need or desire to promote 
something that's simple and works well, nor to contribute to 
improvements if it doesn't 100% suit the ideals.  Instead I see notes 
about "one click cloning a repo" being really cool when we have "one 
click provision an entirely functional IDE  ready for contribution" 
already available for a long time.  Why is that I wonder?


Oomph is to provisioning what Gerrit is to Code Review: maybe the best 
tool around, but that almost know one beyond a few dozen of people 
who've been working on Eclipse stuff for years will care to learn.


What's to learn?  Most users are already familiar with using it via the 
installer.  In any case, by implication, apparently what people really 
care to do is learn how to install and then use Eclipse (the right one 
with PDE) as well as EGit to clone the correct URLs.  Then they know to 
magically import the correct and only appropriate projects into the 
workspace from that clone, without reading anything.   Then these highly 
motivated users know to set up a  proper API baseline from their 
ethereal knowledge. When faced with the sea of red errors, they continue 
to try to figure out (without reading anything), how to make them go 
away before they can make their first attempt at a contribution.  (Oh 
yes, and don't forget to copy/renamed the SWT .classpath file manually, 
without having read something to describe that tiny but fundamental step.)


This whole premise seems beyond questionable to me.   Instead, let's 
focus on moving to GitHub as a magic bullet, with no technical 
discussion about the merit of that because it's a social decision not a 
technical decision and the conclusion is foregone...



___
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?

[Ed Merks]

I preface everything I say on this thread with the observation that "I 
am completely uniformed on the details"...  All this squash-merge, 
force-push means very little to me so I'm admittedly highly ignorant...


I continue to get the sense that decisions are being made on what feels 
like a knee-jerk basis.  I don't intend to offend anyone with that 
comment, so please don't take offense.  It just seems we keep seeing 
anecdotes and factoids floating by.


Rolf's suggestion of gathering facts and making decisions based on a 
full set of confirmed facts would be ideal for such an important 
decision.  Perhaps a table with the important considerations as the rows 
and github versus gitlab as the columns to get a feeling of the pos and 
cons.   Having used gitlab for several customer projects it's doesn't 
feel all that different from github to me.  It has a bit of a "the 
latest cool new thing' feeling to it, so it makes me wonder why all the 
cool kids aren't flocking too it...


In terms of this specific latest detail, wouldn't Eclipse have 100% 
control over any limits on gitlab.eclipse.org?



On 16.03.2021 12:35, Lars Vogel wrote:

That would be a bad restriction for the for project. Some projects use
actions already like Windowbuilder and Wild Web Developer, AFAIK they
have not seen issues with time limitations yet. Link for
windowbuilder: https://github.com/eclipse/windowbuilder

On the plus side, every fork would get the same amount of free
minutes, so contributors which fork the repo to send PR would be able
to use this action validation on their side.

On Tue, Mar 16, 2021 at 12:31 PM Sebastian Zarnekow
 wrote:

I may be wrong but I think the Eclipse foundation would fall under the category 
GitHub Free for Organizations so as a total it would get 2000 mins for *all* 
its repositories according to 
https://docs.github.com/en/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-actions
 - as I said, I may be wrong about this, but that's what I understood.



On Tue, Mar 16, 2021 at 12:10 PM Lars Vogel  wrote:

https://github.com/pricing

2,000 Actions minutes/month Free for public repositories so we would
get ~ 33 hours of free and fast build time per month and repo. Not
sufficient for our daily aggregator build but really nice for
validation builds and sufficient for most platform repo activities
AFAICS.


On Tue, Mar 16, 2021 at 12:00 PM Sebastian Zarnekow
 wrote:

As far as I know, there are usage limits for organizations when it comes to 
Github runners / actions - even for open source projects. Can you please share 
the source of your information, Lars?

On Tue, Mar 16, 2021 at 11:42 AM Lars Vogel  wrote:

Moving to Github would allow us to use Github actions for build
verification (using Maven), which can be easily configured to be cross
platform and cross Java versions and are free for Open Source projects
and run on the Github infrastructure which seems better in terms of
scalability and availability compared to the Eclipse foundation
infrastructure.

So if we have to move to a new hosting platform, +1 for Github from me.

On Tue, Mar 16, 2021 at 11:06 AM Mickael Istria  wrote:



On Tue, Mar 16, 2021 at 10:54 AM Sebastian Zarnekow 
 wrote:

Looking at the https://github.com/eclipse/lemminx-maven/pull/205 I don't see 
the comments *on* the previous commit that became obsolete due to a force push. 
I can still see them as outdated in the linear conversation though. This is 
also the case on Gitlab though. So the force-push habit (which is inherently 
necessary if FF-only merges are allowed) has an impact on the way we can 
associate comments with versions of a patch-set.


Indeed, it's slightly more complicated. But the data is here: the comments keep 
reference to the commit, so even after a force-push, it's still possible to 
find out which version of the commit the comment applies to, and to get access 
to the content of that former commit.
But the `... forced-push ...` line could probably be improved with a link to 
show a diff of the commits, and ideally this diff link would show data in the 
context of the PR, eg be capable of showing comments.
I'm going to open a feature request to GitHub about it and will keep you in 
touch if this improves at some point.
However, I agree that if we want to make things simpler via GitHub, we probably need to 
enable workflows that do not involve force-push, and instead rely on GitHub capability to 
"squash and merge" and let committers use it if they feel it's better than 
asking submitter for a force-push.
--
Mickael Istria
Eclipse IDE developer, for Red Hat Developers
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev



--
Eclipse Platform project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer 

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

[Ed Merks]

Given past trends (twists and turns), I would be slightly concerned that 
the long term trend might be that we should all use GitLab and that the 
Foundation will want to support only one thing and rather two, to save 
resource.  Of course that could be a misguided thought, but resource 
savings do often seem to be a driving factor...


In any case, I think Rolf's suggestion to consider carefully the pros 
and cons of the workflows are a very good suggestion.  My feeling is 
that the current decision making process seems somewhat spontaneous and 
anecdotal.



On 16.03.2021 09:23, Rolf Theunissen wrote:

Dirk, All,

Please at this concern to the wiki page.

Besides the legal consideration, is there a difference in the intended 
workflow on GitHub or GitLab? IMHO the discussion should first be 
about the envisioned workflow, the differences between that envisioned 
workflow and the current workflow, and how the change would impact the 
current way of working (and current committers). Then it can be 
evaluated how the workflow can be executed on the different 
platforms/tools. With that a motivated choice for one of the platforms 
can be made. After that, a migration and/or improvement plan can be 
made, both for the way of working as well as moving the code & build 
tools.


Rolf

Op ma 15 mrt. 2021 om 20:22 schreef Dirk Fauth via platform-dev 
mailto:platform-dev@eclipse.org>>:


Is there a decision made with regards to GitHub vs GitLab? As far
as I understood there are legal constraints to consider. That is
why the foundation prefers GitLab.

Wim Jongman mailto:wim.jong...@gmail.com>>
schrieb am Mo., 15. März 2021, 20:03:

Hi,

Before this stalls again, do we have a team?

I see Rolf, Mickael, Sravan, and myself on the wiki page.

What is the first step? I am happy to execute it. Shall I
attempt to port the platform website to Git?

https://wiki.eclipse.org/Platform-releng/Migration_To_GitHub
<https://wiki.eclipse.org/Platform-releng/Migration_To_GitHub>


Cheers,

Wim



On Thu, Mar 11, 2021 at 5:50 PM Wim Jongman
mailto:wim.jong...@gmail.com>> wrote:

I think the move to GitLab is for projects that stay on
the foundation infra.

On Thu, Mar 11, 2021 at 5:05 PM Jonah Graham
mailto:jo...@kichwacoders.com>>
wrote:



    On Thu, 11 Mar 2021 at 11:00, Ed Merks
mailto:ed.me...@gmail.com>> wrote:

I'm not sure if anyone mentioned the "forced"
migration to gitlab?

Does it make sense to migrate anything to github
if it will subsequently need to be migrated to
gitlab anyway?

I'm just asking...


This is news to me. I have not heard anything about
leaving github.


On 11.03.2021 16:55, Wim Jongman wrote:



On Wed, Mar 10, 2021 at 5:27 PM Mickael Istria
mailto:mist...@redhat.com>>
wrote:

 I'd advise starting by evaluating for
instance migration of PDE to GitHub:


How about starting with the websites. In 99% of
the cases, the websites don't need to dance with
Gerrit, but ATM is required.

The websites are ideal for casual contributions,
especially with the 5-minute deployments that the
webmasters have built, there is instant
gratification.

It would also help us. We can update websites
super fast with the GH workflow.





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

___
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 <mailto:platform-dev@eclipse.org>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listin

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

[Ed Merks]

I'm not sure if anyone mentioned the "forced" migration to gitlab?

Does it make sense to migrate anything to github if it will subsequently 
need to be migrated to gitlab anyway?


I'm just asking...


On 11.03.2021 16:55, Wim Jongman wrote:



On Wed, Mar 10, 2021 at 5:27 PM Mickael Istria > wrote:


 I'd advise starting by evaluating for instance migration of PDE
to GitHub:


How about starting with the websites. In 99% of the cases, the 
websites don't need to dance with Gerrit, but ATM is required.


The websites are ideal for casual contributions, especially with the 
5-minute deployments that the webmasters have built, there is instant 
gratification.


It would also help us. We can update websites super fast with the GH 
workflow.






___
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] I-Builds repo is not current

[Ed Merks]

The compositeContent.jar looks like this:




type='org.eclipse.equinox.internal.p2.metadata.repository.CompositeMetadataRepository' 
version='1'>

  
    
    
    
  
  
    location='https://download.eclipse.org/eclipse/updates/4.19-I-builds/'/>

  


So it appears to be the same and update-to-date.

And the timestamp indicates it's been this way since 16.12.2020:

https://download.eclipse.org/justj/?file=eclipse/updates/I-builds/


On 06.01.2021 17:37, Gayan Perera wrote:

Hi Wim,

I use
https://download.eclipse.org/eclipse/updates/4.19-I-builds/ 
 which 
works fine for me.


Best regards,
Gayan.

On Wed, 6 Jan 2021 at 15:31, Wim Jongman > wrote:


Hi,

Until recently I was  updating from the i-build update site. It
does not contain the 4.19 i-builds.

Did this recently change or did I find an issue?

https://download.eclipse.org/eclipse/updates/I-builds/


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] Deprecating Bugzilla and Gerrrit?

[Ed Merks]

Yes, I did not mean to suggest that you/we should not have or continue 
to have the discussion here about the impact on the platform.


But of course the impact is much broader than the platform, so I'm 
highly likely to rapidly degrade into a very long, tangential, and 
poisonous rant about the four projects, the three builds, and the dozens 
of build jobs that I manage for free, as a one-man traveling show, 
purely for the entertainment and gratification of others.  As such, I am 
just beside myself with eagerness to revisit it all in order save 
someone else some time and to live a world based purely on the latest 
greatness of consolidation.



On 18.12.2020 10:42, Mickael Istria wrote:



On Fri, Dec 18, 2020 at 10:34 AM Ed Merks <mailto:ed.me...@gmail.com>> wrote:


I've already sent a note to the board raising the topic of
"Disruptive Infrastructure Changes".

There's just so much wrong about this and about the way this was
announced that it's hard to remain completely professional.  So
I'll refrain from ranting and saying things I'll no doubt regret
later.


Thanks Ed for voicing concerns to the EF in committers' name.
I think we can and should keep chatting here about the suggested 
change for Eclipse project specifically, identify the technical needs 
other infrastructures wouldn't meet and the induced change cost, 
operational cost, risk vs the things that seem affordable or 
profitable in the infra change. I think this discussion in beneficial 
for the Eclipse project itself, but will also help EF in identifying 
what specific parts of the infra change are actually more challenging 
for committers so the plans can adapt accordingly.


___
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] Deprecating Bugzilla and Gerrrit?

[Ed Merks]

I've already sent a note to the board raising the topic of "Disruptive 
Infrastructure Changes".


There's just so much wrong about this and about the way this was 
announced that it's hard to remain completely professional.  So I'll 
refrain from ranting and saying things I'll no doubt regret later.



On 18.12.2020 10:14, Mickael Istria wrote:



On Fri, Dec 18, 2020 at 10:01 AM Thomas Wolf > wrote:


Yes, we can. However: triggering CI builds will be different; and
I fear
changes in the builds will be required to get them triggered properly.
Reporting build results may also work differently. In any case the
GerritTrigger won't work.


Indeed, projects would have to add some Jenkinsfile and recreate jobs 
in CI as "multi-branch pipeline". It's an effort, but if you ask me, 
the result is better, more "configuration-as-code" which makes 
maintenance easier and more easily distributed.


I'm not keen on having to donate more of my volunteer time to
revamp CI
builds and their integration with a git server.


Yes, that's something I think our Committer Representative need to 
mention. The amount of effort it's asking the community to do seem 
significantly higher to the amount of effort leaving some Gerrit 
server alive.


One crucial shortcoming of the PR model of Gitlab/Github is that
there
is no support for PRs depending on other PRs. On Gerrit, I very often
have whole sequences of changes that depend on each other. This,
and the
ability to group changes by topic, are two crucial features of Gerrit.


Ack.

Apart from that, Gitlab has a "squash on merge" feature for
merging PRs
(or merge requests, as they call it), which makes it easier to
deal with
clean-up commits in a PR (no need for amending and force pushing).


GitHub too, has "Squash and Merge" and "Rebase and Merge" actions, and 
repo admin can set one of them as default.


Asking contributors to amend and force push means the main benefit of
using a PR model falls away, namely that contributors just know
how to
contribute since "everybody" knows the PR model from Github.


That was my first fear when I started working on GitHub projects, but 
actually contributors we got on those projects are OK squashing or 
amending their contributions. It hasn't been a concrete problem so 
far. We just need to explain, just like we often need to explain to 
push to "refs/for/master", keep Change-Id and so on with Gerrit.


___
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

[Ed Merks]

I continue to think there are some wires badly crossed somewhere.

The conclusion that a *.tar.gz is equally functional to a *.dmg and that 
everyone should be perfectly happy with a *.tar.gz (perhaps re-suffixed) 
kind of suggests that all the effort invested in producing a *.dmg and 
notarizing the darned thing is/was pretty much completely pointless and 
mostly misguided.  I find that hard to believe.


You're testing on recent release of MacOs?


On 13.11.2020 13:00, Liviu Ionescu wrote:



On 13 Nov 2020, at 13: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...

The tests were performed using the binaries available in M2:

https://download.eclipse.org/technology/epp/downloads/release/2020-12/M2/

As you can see, there are both .dmg and .tar.gz.

I don't know how/if the binaries were notarized, or if there is something wrong 
with the notarization process, but the Eclipse.app extracted from the .tar.gz 
is equally functional as the one extracted from the .dmg.


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.  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?

The GNU MCU/ARM Eclipse (now Embedded CDT) users always used .tar.gz files, 
since I never produced .dmg files.


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] SWT - supported Linux versions

[Ed Merks]

It would seem that if one includes an "overall version" like 4.18 in 
general then every MANIFEST.MF changes each release (because that number 
changes each release) and hence every version of every manifest 
changes.  Or would SWT's MANIFEST be just a special case?


On 15.10.2020 17:20, Aleksandar Kurtakov wrote:



On Thu, Oct 15, 2020 at 6:13 PM Gregor Schmid > wrote:



Hi all,

the number 4.940 in version.txt has only just become meaningless - see
the recent discussion about "Inconsistent version change in SWT 4.18"
and the associated closed bug report

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

In that discussion Tom mentioned the Manifest file as an alternative
and I'm investigating that. Thanks Aleksandar, for moving that
forward.

So I'm also curious about the Implementation-Version in the Manifest
file. Does that have a well-defined meaning? 



It should be the version as specified in the OSGi manifest - 
https://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/bundles/org.eclipse.swt/META-INF/MANIFEST.MF 
. I notice that it is wrong with my patch so I have to look further at 
what needs fixing.


Is it documented
somewhere? Is it reliable?


It's 100% reliable as we have tools that verify that OSGi metadata is 
good and bumped when a change happens.



If not, wouldn't it be a good idea to have both "4.18" and "2020-12"
added to the Manifest file and/or as constants at some well-defined
location like the Library class or the version.txt file?


I wouldn't mind having eclipse sdk version (4.18) in the manifest too. 
It is the best place according to me for such metadata. Just have to 
play with the build system to make sure it's fetched from the main 
build and not hardcoded to prevent shipping wrong content.



My suggestion to use a map to deduct the user-visible version from
whatever inconsistent version number is embedded in the code was
actually a joke. If that's the only way, so be it, but from a software
engineering standpoint I still vote for something predictable :-).

Best regards,
    Greg

Thomas Singer mailto:ts-...@syntevo.com>> writes:

> Hi Aleksandar,
>
> Do you mean
>
>> Manifest-Version: 1.0
>> Ant-Version: Apache Ant 1.10.9
>> Created-By: 11.0.2+9 (Oracle Corporation)
>> SWT-OS: linux
>> SWT-WS: gtk
>> SWT-Arch: x86_64
>> Implementation-Version: 3.113.0
>
> Should I find there something like "4.16"? The version.txt still
shows
> "version 4.940". It's all a little bit confusing.
>
> --
> Best regards,
> Thomas Singer
>
>
>
> On 2020-10-15 16:04, Aleksandar Kurtakov wrote:
>> Thomas, would you please look at
>>

https://ci.eclipse.org/platform/job/eclipse.platform.swt-Gerrit/1815/artifact/eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.x86_64/target/swt-I20201015-1352-gtk-linux-x86_64.zip
>> and the swt.jar/manifest.mf in it. If this works for you I'll
push and it
>> will be available starting tomorrow build.
>>
>> On Thu, Oct 15, 2020 at 4:06 PM Aleksandar Kurtakov
mailto:akurt...@redhat.com>>
>> wrote:
>>
>>>
>>>
>>> On Thu, Oct 15, 2020 at 3:28 PM Thomas Singer
mailto:ts-...@syntevo.com>> wrote:
>>>
 Hi Aleksander,

 Thanks for the link. Now the problem remains how to map
between the
 content of the version.txt inside the org.eclipse*.jar to the
 Eclipse/SWT version. For example, my version.txt contains the
 information "version 4.940". Which is the corresponding
Eclipse/SWT
 version?

>>>
>>> Frankly, this questions I can't easily answer. I've opened
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=567906 to use
>>> Implementation-Version in the manifest for that.
>>>

 --
 Best regards,
 Thomas Singer


 On 2020-10-15 13:38, Aleksandar Kurtakov wrote:
> On Thu, Oct 15, 2020 at 2:27 PM Thomas Singer
mailto:ts-...@syntevo.com>>
 wrote:
>
>> Hi all,
>>
>> How can I find out which Eclipse/SWT release is supposed to
support
>> which platforms, especially which Linux versions? Thanks in
advance.
>>
>
> https://www.eclipse.org/swt/faq.php#gtkstartup - lists the
mapping
 between
> gtk and swt versions.
>
>
>>
>> Cheers,
>> Tom
>> ___
>> 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

[Ed Merks]

Jonah,

The platform, like the installer, also produces *.tar.gz for the MacOS, 
e.g.,


https://download.eclipse.org/eclipse/downloads/drops4/S-4.18M1a-202010120320/eclipse-SDK-4.18M1a-macosx-cocoa-x86_64.tar.gz

But, like the installer, 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.


I'm happy that the platform provides the *.tar.gz as well because it's 
useful for scripts.  E.g., the JustJ JRE generation script uses the 
*.tar.gz for MacOS.  I hope that it will always continue to do so...


Regards,
Ed

On 13.10.2020 19:10, 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] Recent API Removal breaks clients

[Ed Merks]

Peter,

Comments below.

On 19.09.2020 11:51, Peter Kriens wrote:

So what is the purpose of version numbers if you start lying about their 
semantics?


The concern is that the cure (major version increments) is as disruptive 
and painful as the disease (deleting/breaking API). Assuming an API has 
been deprecated for a long time and that the clients have all had 
sufficient time to stop using it and have done so, the only remaining 
diseased part is in the bundle providing that "API.".    Here the 
disease can be excised easily by a single committer.   But, if we now 
also increment the major version number, the resulting symptoms are 
exactly the same as the disease: all clients are broken and all clients 
will yet again have to revisit all their code to bump the upper bound of 
all their bundles.   This approach guarantees that the entire downstream 
client base stops working after each and every deletion.


Surely in this light, this is not a feasible strategy for the platform's 
gigantic downstream ecoystem...




I agree that it semantic version does take an effort to get started with but 
from extensive experience I can promise you that this is a one time effort and 
pays off handsomely in much more control over the process.
If it were just within one project or the downstream consumer base is 
small, that of course makes good sense.   But with the platform as just 
the tip of the iceberg, I don't believe we should realistically expect 
the entire ecosystem to be quite so enamored with this approach.


However, having versions but then not using their semantics is probably the 
worst of both worlds.
It's all about balance.  However factually and technically correct you 
are (and you definitely are),  the practical reality of a huge, 
poorly-maintained, downstream ecosystem guarantees that this approach 
will wipe out...


Kind regards,

Peter Kriens




On 18 Sep 2020, at 17:28, Lars Vogel  wrote:


Why is API removed from Eclipse without bumping the major version number?

I tried this once and we got furious feedback from the community that
is worse than anything else (see cross if you want to). People
maintain a max version and increasing the major version breaks them
completely So the PMC decided that planned deletions do not justify
major bumps.

Best regards, Lars

On Fri, Sep 18, 2020 at 5:11 PM Jonah Graham  wrote:

Sorry to rehash old questions - but I wasn't active when this was first 
discussed. CDT has recently taken on this policy (but not used it yet):

Why is API removed from Eclipse without bumping the major version number? i.e the 
"In general, removing a deprecated API does NOT cause the increase of the major 
version segment." in https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process

Thanks
Jonah

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Fri, 18 Sep 2020 at 09:43, Aleksandar Kurtakov  wrote:



On Fri, Sep 18, 2020 at 12:30 PM Aleksandar Kurtakov  
wrote:



On Fri, Sep 18, 2020 at 11:27 AM Wim Jongman  wrote:



Should we not support older versions of Eclipse?


There is 2 years notice period so I would say do not support versions older 
than 2 years.


We provide LTS so it is not possible for everyone. It would also not catch the 
API break in the i-build.


API is deprecated for at least 2 years before being removed so if a project has 
deprecations free build with the 2 years old version it will work fine with the 
latest release.




1. The person that proposes the API change makes an impact analysis by searching 
all the Eclipse repositories, removal is abandoned if used > x%
2. Removal of API is sent to the mailing list of the project that uses the API 
so that we can fix things in time, especially when the project is in 
maintenance mode.


1. and 2. are not realistic if we go that path why don't we add Spring Tools or 
JBoss Tools which are one of the widely used plugins out there. Why not add 
Pydev too? Requiring to subscribe to project list to notify is a bit too much 
for me. There is a reason we have cross-project list. Effectively this proposal 
is to never ever change anything and let Eclipse Platform collapse under its 
own weight where we keep shipping multiple ways to do things - each with its 
own oddities.


Yes, we should add them as well. It is also about the thousands of consumers 
that we don't know.

And I really don't think that leaving three lines in Platform will cause 
Eclipse to collapse under its own weight. Java has never removed a deprecated 
method or an API class. AFAICT, they are fine :)


That ^^ is no longer true for Java too. 
https://www.oracle.com/java/technologies/javase/jdk-11-relnote.html#Removed and 
continues in newer versions.


I just can't resist sending this link here 
https://www.eclipse.org/lists/cdt-dev/msg34634.html .
Java  and the overall software world are changing on an ever increasing pace - no matter 
whether we accept it, like it or not. Thus LTS (the old 10+ years) is gone - no 

Re: [platform-dev] Recent API Removal breaks clients

[Ed Merks]

Wim,

I empathize with these concerns.  To prevent such problems, EMF's builds 
and test against a great many target platforms:


  https://ci.eclipse.org/emf/job/all-target-platforms/

This job builds the latest source and runs all the tests against helios 
and higher.  This was of course a lot of work to implement and is 
significant work to maintain; EMF takes Long Term Support very seriously.


Every time yet another thing is deprecated I cringe.  I maintain warning 
free code so I notice!  And then the threat of removal always looms on 
the horizon.   So when IProgressMonitorWithBlocking was deprecated, I 
notice, and then I notice too that it's in EMF's API, so the threat of 
removal means that I must break APIs should that come to pass.  But I 
don't break EMF's APIs, and I don't want break EMF's APIs.  Do I have a 
choice?  Does my opinion matter?  Not so much.


In this case, when I point out that if I were to actually try to remove 
my uses, that I would break behavior because the platform as a whole has 
not altered the code to make implementing IProgressMonitorWithBlocking 
redundant, I'm told that will happen later in the next release cycle.


  https://bugs.eclipse.org/bugs/show_bug.cgi?id=552683#c25

I don't comprehend the 
deprecate-now-but-don't-do-anything-about-it-until-later reasoning and 
I'm super frustrated by the constant threat of breakage.  As a word of 
caution, if IProgressMonitorWithBlocking is removed, EMF's build will 
become the progress monitor that blocks it.  I will make my opinion matter.


While I'm ranting and making myself unpopular, I look at p2's bug list 
and see that it's never reduced.   Instead there are disruptive changes 
that I'd rather not see:


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

Does my opinion matter?  Not so much.  Unfortunately Oomph has many 
wickedly-evil dependencies p2 so, in some ways, lack of change there is 
good...


I'm not being paid to maintain EMF/XSD, Oomph (and the installer), and 
JustJ, but others are being paid and while it's most definitely none of 
my business, I'd so much rather see the time spent fixing bugs than on 
constant cleanup activities, especially the disruptive ones.  If I were 
to spend a lot of time on cleanup activities, I would try to eliminate 
the 20,000 warnings I see in my SDK workspace.


I apologize in advanced to those whose shorts get in a knot over these 
comments.  No offense is intended.  This is an issue of community 
perception and the broader community doesn't perceive the vibrant, 
active developer community we have on the platform; one that I'm very 
grateful to have and to be a part of.  The key take-away is that the 
community generally only perceives the end result.


For example, the community doesn't perceive the goodness from this:

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

But rather perceives the bug that it causes:

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

Every time we delete something (even if it's internal non-API), we will 
definitely break something and someone, sometimes even our own stuff.  
Typically the end user is the first one who notices that, after the 
release, and that user perceives this problem as "Eclipse".  Even at 
Eclipse, not every project downstream from the platform has a rich, 
active, vibrant community to maintain their code base and release 4 
times a year.  Many, if not most, rely on the stability and quality of 
the platform, and when things are deleted 4 times per year, at arbitrary 
points in the cycle, it's hard to keep up with the goodness.


Even the move to Java 11 has been super disruptive to our community; at 
least I assume so because it was super disruptive for me personally.   
Of course this move is totally justified and is arguably goodness, but 
how many things will be broken by the move to Java 11, like this:


https://www.eclipse.org/forums/index.php/mv/msg/1105256/1832430/#msg_1832430

Probably not so many because this is a corner case.

I definitely worked my assets off to ensure that the installer would run 
out-of-the-box for 2020-09 and would even install a JRE if the user 
doesn't have a Java 11 installation available because I'm well aware 
that the failure to do so would reflect poorly on "Eclipse".  And I take 
LTS very seriously.


Again, I apologize in advance for any offense taken.  None is intended.  
We all want "Eclipse" to be great and do what we do to help ensure 
that's the case.  I just feel that the various points of view involved 
could be more balanced if more of them would be considered relevant.


Regards,
Ed

On 18.09.2020 10:26, Wim Jongman wrote:


Should we not support older versions of Eclipse?


There is 2 years notice period so I would say do not support
versions older than 2 years.


We provide LTS so it is not possible for everyone. It would also not 
catch the API break in the i-build.

*
*

 

[platform-dev] Link Handler Auto Registration?

[Ed Merks]

There has been quite some activity around auto registering link 
handlers.   For whatever reason that's not clear to me, in my Oomph 
development environment, the method 
org.eclipse.urischeme.internal.registration.RegistrationWindows.getEclipseLauncher() 
returns null.  In the end, that's because 
/.metadata/.plugins/org.eclipse.pde.core/.install_folders/1592731586281 
does not contain a *.exe.  In my Platform SDK environment there is an 
eclipsec.exe in that analogous folder when I do a self-hosted launch. In 
any case, a null launcher subsequently causes this exception on every 
self-hosted launch:


java.lang.NullPointerException
    at com.sun.jna.Native.toCharArray(Native.java:824)
    at 
com.sun.jna.platform.win32.Advapi32Util.registrySetStringValue(Advapi32Util.java:1233)
    at 
com.sun.jna.platform.win32.Advapi32Util.registrySetStringValue(Advapi32Util.java:1262)
    at 
org.eclipse.urischeme.internal.registration.WinRegistry.setValueForKey(WinRegistry.java:33)
    at 
org.eclipse.urischeme.internal.registration.RegistryWriter.addScheme(RegistryWriter.java:60)
    at 
org.eclipse.urischeme.internal.registration.RegistrationWindows.handleSchemes(RegistrationWindows.java:61)
    at 
org.eclipse.urischeme.AutoRegisterSchemeHandlersJob.run(AutoRegisterSchemeHandlersJob.java:70)

    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

That could be avoided by checking for null like this in 
org.eclipse.urischeme.internal.registration.RegistrationWindows.handleSchemes(Collection, 
Collection)


    @Override
    public void handleSchemes(Collection toAdd, 
Collection toRemove)

            throws Exception {
        String eclipseLauncher = getEclipseLauncher();
        if (eclipseLauncher != null) {
            for (IScheme scheme : toAdd) {
                registryWriter.addScheme(scheme.getName(), 
eclipseLauncher);

            }
        }

But the more fundamental question is, what is the desired/intended 
behavior of org.eclipse.urischeme.AutoRegisterSchemeHandlersJob?   It 
appears the actual behavior is that each IDE that's launched forcibly 
takes the registration, replacing any existing registration. Perhaps 
that's fine and good and is the intent, though when one has 10 Eclipse 
applications running like I do, it's a little questionable.  But note 
that in the case that a self-hosted launch happens to find a *.exe in 
.install_folders (avoiding an NPE error), this also implies that the 
self-hosted launched IDE forcibly takes over the registration such that 
the original host IDE itself is no longer registered.  Surely that is 
not the intent of the design is it?


Regards,
Ed



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

[platform-dev] BREE 11?

[Ed Merks]

Hi,

I understand the platform's products for 4.17 will require Java 11 and 
that this was already changed via:


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

I've had to adapt the Product Catalog Generator to properly take into 
account the fact that while the 4.17 IBuild of the platform's products 
require Java 11, there are as yet no EPP packages that require Java 11.  
I expect that will be the case for all the EPP packages for 2020-09 M1, 
but it's a bit of odd transitional state...


What's not clear to me though is whether the BREEs of any platform's own 
bundles will change to Java 11.  Currently it's still possible to build 
the Eclipse Installer against the 4.17 IBuild such that it still runs on 
Java 1.8, but if the BREEs of the platform's own bundles change, that 
won't be the case.


What should my expectations be looking forward?  Sorry if this was 
already clarified previously and I didn't pay close enough attention...


Regards,
Ed




___
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] Occasional contributors and "complicated" rules

[Ed Merks]

Dani,

Often when I make a contribution it takes me several tries to get the 
versions correct.  E.g., this from yesterday:


  https://git.eclipse.org/r/#/c/164844/

Of course one knows (after a while) that something needs to be 
incremented in general, but one needs to check, has the MANIFEST.MF 
already been incremented, not just blindly do it.  If there is a 
pom.xml, of course its version has to match.   I'm not sure if the API 
tools in the IDE complain when x.y.z has to become x.(y+1).0 but it 
certainly doesn't tell you when x.y.z has to become x.y.(z+100).  It 
would save time if that check would/could be done in the IDE.  Perhaps 
it's an expensive check to run constantly/incrementally, but a manual 
"check bundle API versions" that checked for the same thing that fails 
after a very long wait in Gerrit would make that easier.


Regards,
Ed

On 14.06.2020 18:30, Daniel Megert wrote:
I agree. Plus we use the 'compare-version-with-baseline' Tycho plug-in 
that fails the Gerrit Jenkins build tf the version is not updated when 
required. For details see _Bug 53_ .


Dani



From: Lars Vogel 
To: "Eclipse platform general developers list." 
Date: 13.06.2020 17:17
Subject: [EXTERNAL] Re: [platform-dev] Occasional contributors and 
"complicated" rules

Sent by: platform-dev-boun...@eclipse.org




Hi Jonah,

I tend to update the versions on behalf of the new contributor. Once a 
person starts to contribute more, I try to explain the version rules.


Best regards, Lars

Jonah Graham <_jonah@kichwacoders.com_ 
> schrieb am Sa., 13. Juni 2020, 16:21:

Hello Platform devs,

I want to solicit some input and experience from you to apply to CDT.

CDT roughly follows the Eclipse Platform versioning rules. This leads 
to contributors who only occasionally contribute having more 
difficult time than I think they should have. This increases the 
perception that contributing to CDT is hard. (e.g. trivial fixes that 
pass all tests, still fails build)


How does the platform team deal with this? Do you require new 
contributors to learn all the rules such as incrementing service 
segments and require the contributor to fix it? Or does an experienced 
committer simply make a comment to educate and then the committer 
completes the housekeeping fix themselves?


Up until now I have generally taken the approach of requiring the 
contributor to do this housekeeping, but it feels unwelcoming.


Thank you for any input on how you have handled this in the past, or 
if you have any official policy on this.


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




___
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] backporting and building?

[Ed Merks]

Tony,

From a workspace with everything in it as produced by 
https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning I can see two 
references to org.apache.ant.


   
https://git.eclipse.org/c/pde/eclipse.pde.build.git/tree/org.eclipse.pde.build/feature/feature.xml
   
https://git.eclipse.org/c/platform/eclipse.platform.releng.git/tree/features/org.eclipse.platform-feature/feature.xml

If your application requires directly or indirectly these features, that 
would restrict the versions to the specific org.apache.ant version used 
when these features are built, and I'm pretty sure this is enforced at 
runtime, though not absolutely sure.  Certainly any attempts to do p2 
updates will not be happy to find a feature's requirements missing.  But 
in the end, you do not necessarily need to include these features in 
your application.  E.g., you could copy the 
org.eclipse.platform-feature/feature.xml and use/require that copy 
instead.  In the future you could change the copy to include the 
org.eclipse.platform feature when it's using the newer version of 
org.apache.ant that you require, or use this as an opportunity to


Regards,
Ed

On 09.06.2020 02:30, Homer, Tony wrote:


Hi Jonah-

Thanks for the suggestions and clarifications.

Yes, I did have the wrong link – I only read the commit message and 
didn’t notice that the change was only for the tests.  After I 
realized that, I went ahead with my own changes in which I replaced 
all the instances of ant 1.10.7 with the 1.10.8.qualifier that is in 
Orbit for 2020-06.  So far I have not succeeded in completing a local 
build, but I haven’t spent that much time on it, yet.  I’m not sure if 
I should be building with Java 8 or Java 11 – I tried with both and 
had different problems with each.


>> If you are building your own app, your app probably has its own 
.target or equivalent in the pom file and in that file you can point 
at the new orbit (2020-06), along with the older platform (4.15) version.


I did try this, pretty much exactly as you suggest in my product’s 
target, but the exact version of ant is hard-coded in the platform 
feature, so my build failed:


[ERROR] Missing requirement: org.eclipse.platform.feature.group 
4.15.0.v20200305-0155 requires 'org.eclipse.equinox.p2.iu; 
org.apache.ant [1.10.7.v20190926-0324,1.10.7.v20190926-0324]' but it 
could not be found


Before I go back to attempting a local build, I’m going to try what I 
understand as Christoph Läubrich’s suggestion to just swap out the 
version of Ant after the build.  I’m not sure if the version 
requirements get checked at runtime, but it’s an easy thing to try.


Again, thank you for taking the time to respond!

Tony Homer

*From: * on behalf of Jonah Graham 

*Reply-To: *"Eclipse platform general developers list." 


*Date: *Monday, June 8, 2020 at 6:52 AM
*To: *"Eclipse platform general developers list." 


*Subject: *Re: [platform-dev] backporting and building?

Hi Tony,

I suspect that in your original message you have the wrong link still 
- that may be the cause of some of the confusion that seems to be in 
this conversation. The commit you reference is a  change only to tests 
and I assume that you are not shipping tests nor really need to rerun 
them as part of your RCP application. The platform change that 
actually changes the version of Ant that is shipped is 
https://git.eclipse.org/r/163228 - along with some earlier updates 
that point at newer orbit URLs that include the new ant version.


If you are building your own app, your app probably has its own 
.target or equivalent in the pom file and in that file you can point 
at the new orbit (2020-06), along with the older platform (4.15) 
version. You may need some version constraints in your .product file 
to make sure that only the correct version of ant is included.


On to some of your other questions in case you have this or other 
reasons to rebuild the platform:


> Still just wondering if it is expected that such a change would be 
needed.


I think the change is needed as once a version of Eclipse is released 
its branch is left in a somewhat broken state because the I-build deps 
are deleted. It may be nice if the branches for completed versions 
were left in a buildable state, but that is not a priority for active 
developers, so someone would have to do that work. Please note that 
this problem exists whenever you want to build an older version of 
Eclipse. For example with the multi-repo builds of Eclipse it can be 
quite hard to build an old version of Eclipse to, for example, run git 
bisect to identify a problem. During development lots of old I-builds 
are left so that you can do that, but once a release is done those are 
removed.


PS. There are other members of the community who have the same 
underlying issue - ie using, maintaining/supporting older versions of 
Eclipse platform in their product. See this interesting discussion 
that Andrey started on this topic 

Re: [platform-dev] Start an Eclipse with modified Source

[Ed Merks]

Lars,

Approximately how close to a million were those issues?  It appears to 
be closer to 31:


https://bugs.eclipse.org/bugs/buglist.cgi?classification=Tools=lars=1=substring=Importance=Oomph_format=advanced

None of them are currently unresolved.  I know you are a big fan of 
following the manual steps, but most real people have better thing to do 
than the setup itself.


I definitely don't appreciate the million issues comment; you know I'll 
read it and you know it's not nice and that it's not accurate.  
Moreover, if there being a million issues should stop people from using 
a piece of software, we should all stop using the Platform immediately.


In addition, I tried to do things manually (I was forced to) and spent 
several weeks doing that for the platform 24 Git repositories.  This is 
something no human will want to replicate manually.


Regards,
Ed

On 29.05.2020 13:43, Lars Vogel wrote:

Hi Christoph,

You need to install Git tooling in the SDK and follow the tutorial to 
get rid of the errors.


Feel free to check why the Oomph installer did not work. I checked a 
while ago and reported multiple issues, some of them have been fixed 
others not.


Best regards, Lars




Christoph Läubrich > schrieb am Fr., 29. Mai 2020, 13:33:


Hi Lars,

I downloaded the latest I-Build, opend my Workspacen and now there
are
145.000+ errors and the git perspective is wrecked :-\
Using my old install I disabled all warnings about baselines but
still
no luck as some classes and imports can't be resolved.

I also tried creating a target platform using the IBuild with the
latest
SDK but this didn't worked either.

On your page you mentioned

  "For most Eclipse projects, you can also use the Eclipse installer"

Is Eclipse-Runtime an exception from this rule? If yes, why?

Am 29.05.20 um 12:47 schrieb Lars Vogel:
> Hi Christoph,
>
> I use the approach described in
>
https://www.vogella.com/tutorials/EclipsePlatformDevelopment/article.html
>
> Basically, download latest I-Build, clone repo and setup API
baseline
> (or change setting to warning).
>
> Best regards, Lars
>
> On Fri, May 29, 2020 at 12:44 PM Christoph Läubrich
> mailto:lae...@laeubi-soft.de>> wrote:
>>
>> I used Ooompf to setup an IDE (2020-03) for development of platform
>> code, but is still can't get it to work completely.
>>
>> For example at the moment I get Acces Restriction warnings,
unsatisfied
>> version constraints and unresolved types.
>>
>> Is there any target platform I need to activate?
>> I Also wonder if there is a special product I can start or what
is the
>> common way to start up a "modified" Eclipse to test code changes?
>> ___
>> 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
___
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] Start an Eclipse with modified Source

[Ed Merks]

Christoph,

Did you use this tutorial?

  https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning

If there are issues with it, please record them in 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=536533


The automated setup creates a launcher "Runtime Workspace" that will 
launch with the contents of the workspace. For the tutorial this 
includes *everything* because the Configuration include everything.   
If  you need/want less projects, you can go back to the Project page 
after applying the Configuration to choose only the projects of interest.


The automated setup sets the API baseline (currently 4.15) and creates 
the appropriate target platform (the platform 4.16 I build) so there 
should be no errors.  There are a 20,000 warnings though.


Regards,
Ed

On 29.05.2020 12:44, Christoph Läubrich wrote:
I used Ooompf to setup an IDE (2020-03) for development of platform 
code, but is still can't get it to work completely.


For example at the moment I get Acces Restriction warnings, 
unsatisfied version constraints and unresolved types.


Is there any target platform I need to activate?
I Also wonder if there is a special product I can start or what is the 
common way to start up a "modified" Eclipse to test code changes?

___
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] Clipboard copy / past off popup menu

[Ed Merks]

George,

I'm not sure how others feel, but my feeling is that this mailing list 
is primarily intended for communication with/among the people developing 
the platform itself, so I think it's generally more appropriate ask 
usage questions on the forum:


https://www.eclipse.org/forums/index.php/f/11/

That being said, the only IClipboardSupportFactory I could find was this:

https://git.eclipse.org/c/gmf-runtime/org.eclipse.gmf-runtime.git/tree/org.eclipse.gmf.runtime.emf.clipboard.core/src/org/eclipse/gmf/runtime/emf/clipboard/core/IClipboardSupportFactory.java

But that's from GMF and how to use that is not the expertise of the 
folks developing the platform.  It doesn't look like the GMF forum is 
very helpful so sending you there probably won't help:


  https://www.eclipse.org/forums/index.php/f/16/

Perhaps GMF is using a class derived from EMF and this menuAboutToShow 
method is being called:


https://git.eclipse.org/c/emf/org.eclipse.emf.git/tree/plugins/org.eclipse.emf.edit.ui/src/org/eclipse/emf/edit/ui/action/EditingDomainActionBarContributor.java#n614

You'll need to debug how the actions are being added and which ones are 
being added.


Regards,
Ed

On 10.04.2020 21:47, George Aroush wrote:


Hi everyone,

This is my first post and I’m not sure if I’m posting to the right 
mailing list.


I inherited a plugin development project and I’m learning my way 
through the code and Eclipse plugin development.  So if my question is 
not and use of terms is not clear let me know.


Our application uses IClipboardSupportFactory to take care of copy / 
past that are on the menu-bar.  We also have code that provides copy / 
past function off a popup menu.  This code is NOT invoking the same 
copy / past that code that gets used from the menu-bar copy / past, 
i.e. IClipboardSupportFactory.  Instead, it is using our own class 
that inherits from GlobalAction and it has a different logic for copy 
/ past which is only copying and pasting the UI elements not the 
underlying metadata of our application associated with the UI elements.


My question to the group is this, when I create my popup-menu how do I 
add to IMenuManager the copy / past handlers of 
IClipboardSupportFactory?  If I can do this, then a copy / past action 
from the popup-menu’s copy / past selection will do the right thing.


Btw, using the short-cut keys of Ctrl-C / Ctrl-V is working.  They 
invoke the copy / past handler off IClipboardSupportFactory.


Thanks,

-- George


___
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] How can usiSchemaHandlers be used in internal web browser?

[Ed Merks]

Did you enable Window -> Preferences -> General -> Link Handlers for the 
eclipse+mpc scheme?  Certainly that's needed for clicks of eclipse-mpc 
scheme links a browser to work.


On 07.04.2020 18:10, Mickael Istria wrote:

Hi all,

I'm brainstorming about possibilities to improve and simplify 
Marketplace integration in Eclipse IDE, ideally by reducing the amount 
of specific UI it uses and leveraging more the website (so we maintain 
a single web UI to consume in the IDE instead of having another view 
to maintain it it as well).
I see MPC has enabled support for `eclipse+mpc` protocol handler, 
that's great as invoking some CLI like `eclipse 
eclipse+mpc://marketplace.eclipse.org/install/1640500` 
 works fine.
However, I was expected that such `eclipse+mpc` links in the Internal 
Web Browser would trigger the protocol handler and thus show the 
Marketplace Client dialog but it was not the case.
So I'm curious about the cases where those protocol handlers are 
supposed to work out of the box? Is there some setting, or preference 
or some existing views where I can have a such links working on a 
single click?

If not, are there bugs open on this topic I could monitor/participate to?

Thanks in advance

--
Mickael Istria
Eclipse IDE  
developer, for Red Hat Developers 


___
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] Concerns about org.eclipse.ecf.provider.filetransfer.httpclient45

[Ed Merks]

FYI,

I did some more debugging and I really feel this is a server problem.  
I.e., I believe the server is dropping connections while the headers 
from those connections indicate the connection can be kept alive 
indefinitely.


I opened the following Bugzilla with the details if you're interested:

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

Regards,
Ed

On 04.03.2020 14:37, Thomas Wolf wrote:


On 4 Mar 2020, at 14:11, Aleksandar Kurtakov <mailto:akurt...@redhat.com>> wrote:


On Wed, Mar 4, 2020 at 2:55 PM Ed Merks <mailto:ed.me...@gmail.com>> wrote:


...
start from scratch.   Also, perhaps we'd lose many features, such
as a
connection pool to speed things up.   It's a big open question...


In terms of lose of features my brief look up yielded nothing (e.g.  
connection pool is




On 04.03.2020 13:48, Aleksandar Kurtakov wrote:
> Slightly off topic but keeping up with httpclient has proved to
be a
> big timesync. It's probably about time to start working on
>

https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html

> based filetransfer implementation and stop losing the time to
keep up
> with yet another third party library.



I think you might lose https connections over http proxies that require
basic authentication unless you set a particular system property. See
https://bugs.openjdk.java.net/browse/JDK-8210814 and
https://bugs.eclipse.org/bugs/show_bug.cgi?id=549832 . I presume the
Java 11 HttpClient will behave the same in that respect.

Cheers,

  Thomas

___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Concerns about org.eclipse.ecf.provider.filetransfer.httpclient45

[Ed Merks]

This assumes that the problem really is httpclient's fault, which is 
kind of questionable given how widely used that library is. I'd also be 
concerned about all the problems such as proxy authentication and so on 
that have been carefully ironed out over the years that would need to 
start from scratch.   Also, perhaps we'd lose many features, such as a 
connection pool to speed things up.   It's a big open question...


On 04.03.2020 13:48, Aleksandar Kurtakov wrote:
Slightly off topic but keeping up with httpclient has proved to be a 
big timesync. It's probably about time to start working on 
https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html 
based filetransfer implementation and stop losing the time to keep up 
with yet another third party library.

___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Concerns about org.eclipse.ecf.provider.filetransfer.httpclient45

[Ed Merks]

Andrey,

Thanks for the response!

These are definitely in the platform's build logs, e.g., this one always 
has such entries:


https://ci.eclipse.org/platform/job/eclipse.platform.ui-Gerrit/lastSuccessfulBuild/consoleFull

I too get the sense that this is a new/recent thing.  I thought maybe a 
new version of httpclient was to blame, but I have the same problem in 
an older environment with an older version of httpclient, and I 
definitely *did not *have this highly reproducible problem a few months 
ago when I was using that older environment regularly.


Regards,
Ed

On 04.03.2020 13:41, Andrey Loskutov wrote:
Some time ago I've also stumbled over it while meditating over maven 
build logs:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=558976
I *believe* I haven't seen such errors before, and I *believe* this 
could be due infrastructure changes we had recently.

Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov
*Gesendet:* Mittwoch, 04. März 2020 um 13:31 Uhr
*Von:* "Ed Merks" 
*An:* "Eclipse platform general developers list." 

*Betreff:* [platform-dev] Concerns about 
org.eclipse.ecf.provider.filetransfer.httpclient45


Hi,

I don't know how many of you have noticed things like this in the 
build logs:


  
*12:25:45* Mar 04, 2020 11:25:45 AM org.apache.http.impl.execchain.RetryExec execute*12:25:45* INFO: I/O exception (org.apache.http.NoHttpResponseException) caught when processing request to {s}->https://download.eclipse.org:443: The target server failed to respond*12:25:45* Mar 04, 2020 11:25:45 AM org.apache.http.impl.execchain.RetryExec execute*12:25:45* INFO: Retrying request to {s}->https://download.eclipse.org:443


I'm a bit concerned about the cause of such exceptions.  I've debugged 
where this happens in my Oomph environment.  Specifically it happens 
in org.apache.http.impl.execchain.RetryExec.execute(HttpRoute, 
HttpRequestWrapper, HttpClientContext, HttpExecutionAware) when 
parsing the response header finds nothing with the following stack 
leading to the logged problem:


org.apache.http.NoHttpResponseException.(java.lang.String) line: 47
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(org.apache.http.io.SessionInputBuffer) 
line: 141
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(org.apache.http.io.SessionInputBuffer) 
line: 56
org.apache.http.impl.conn.DefaultHttpResponseParser(org.apache.http.impl.io.AbstractMessageParser).parse() 
line: 259
org.apache.http.impl.conn.LoggingManagedHttpClientConnection(org.apache.http.impl.DefaultBHttpClientConnection).receiveResponseHeader() 
line: 163

org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader() line: 157
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(org.apache.http.HttpRequest, 
org.apache.http.HttpClientConnection, 
org.apache.http.protocol.HttpContext) line: 273
org.apache.http.protocol.HttpRequestExecutor.execute(org.apache.http.HttpRequest, 
org.apache.http.HttpClientConnection, 
org.apache.http.protocol.HttpContext) line: 125
org.apache.http.impl.execchain.MainClientExec.execute(org.apache.http.conn.routing.HttpRoute, 
org.apache.http.client.methods.HttpRequestWrapper, 
org.apache.http.client.protocol.HttpClientContext, 
org.apache.http.client.methods.HttpExecutionAware) line: 272
org.apache.http.impl.execchain.ProtocolExec.execute(org.apache.http.conn.routing.HttpRoute, 
org.apache.http.client.methods.HttpRequestWrapper, 
org.apache.http.client.protocol.HttpClientContext, 
org.apache.http.client.methods.HttpExecutionAware) line: 186
org.apache.http.impl.execchain.RetryExec.execute(org.apache.http.conn.routing.HttpRoute, 
org.apache.http.client.methods.HttpRequestWrapper, 
org.apache.http.client.protocol.HttpClientContext, 
org.apache.http.client.methods.HttpExecutionAware) line: 89
org.apache.http.impl.execchain.RedirectExec.execute(org.apache.http.conn.routing.HttpRoute, 
org.apache.http.client.methods.HttpRequestWrapper, 
org.apache.http.client.protocol.HttpClientContext, 
org.apache.http.client.methods.HttpExecutionAware) line: 110
org.apache.http.impl.client.InternalHttpClient.doExecute(org.apache.http.HttpHost, 
org.apache.http.HttpRequest, org.apache.http.protocol.HttpContext) 
line: 185
org.apache.http.impl.client.InternalHttpClient(org.apache.http.impl.client.CloseableHttpClient).execute(org.apache.http.client.methods.HttpUriRequest, 
org.apache.http.protocol.HttpContext) line: 83
org.eclipse.ecf.provider.filetransfer.httpclient45.HttpClientFileSystemBrowser.runRequest() 
line: 246
org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser$DirectoryJob.run(org.eclipse.core.runtime.IProgressMonitor) 
line: 69

org.eclipse.core.internal.jobs.Worker.run() line: 63

There will be two additional retries, and if those fail too, the 
repository will fail to load (or the artifact will fail to 
download).   In my product catalog generator, I load a whole whack of 
rep

[platform-dev] Concerns about org.eclipse.ecf.provider.filetransfer.httpclient45

[Ed Merks]

Hi,

I don't know how many of you have noticed things like this in the build 
logs:


*12:25:45* Mar 04, 2020 11:25:45 AM org.apache.http.impl.execchain.RetryExec 
execute
*12:25:45* INFO: I/O exception (org.apache.http.NoHttpResponseException) caught 
when processing request to {s}->https://download.eclipse.org:443: The target 
server failed to respond
*12:25:45* Mar 04, 2020 11:25:45 AM org.apache.http.impl.execchain.RetryExec 
execute
*12:25:45* INFO: Retrying request to {s}->https://download.eclipse.org:443

I'm a bit concerned about the cause of such exceptions.  I've debugged 
where this happens in my Oomph environment.  Specifically it happens in 
org.apache.http.impl.execchain.RetryExec.execute(HttpRoute, 
HttpRequestWrapper, HttpClientContext, HttpExecutionAware) when parsing 
the response header finds nothing with the following stack leading to 
the logged problem:


org.apache.http.NoHttpResponseException.(java.lang.String) line: 47
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(org.apache.http.io.SessionInputBuffer) 
line: 141
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(org.apache.http.io.SessionInputBuffer) 
line: 56
org.apache.http.impl.conn.DefaultHttpResponseParser(org.apache.http.impl.io.AbstractMessageParser).parse() 
line: 259
org.apache.http.impl.conn.LoggingManagedHttpClientConnection(org.apache.http.impl.DefaultBHttpClientConnection).receiveResponseHeader() 
line: 163

org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader() line: 157
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(org.apache.http.HttpRequest, 
org.apache.http.HttpClientConnection, 
org.apache.http.protocol.HttpContext) line: 273
org.apache.http.protocol.HttpRequestExecutor.execute(org.apache.http.HttpRequest, 
org.apache.http.HttpClientConnection, 
org.apache.http.protocol.HttpContext) line: 125
org.apache.http.impl.execchain.MainClientExec.execute(org.apache.http.conn.routing.HttpRoute, 
org.apache.http.client.methods.HttpRequestWrapper, 
org.apache.http.client.protocol.HttpClientContext, 
org.apache.http.client.methods.HttpExecutionAware) line: 272
org.apache.http.impl.execchain.ProtocolExec.execute(org.apache.http.conn.routing.HttpRoute, 
org.apache.http.client.methods.HttpRequestWrapper, 
org.apache.http.client.protocol.HttpClientContext, 
org.apache.http.client.methods.HttpExecutionAware) line: 186
org.apache.http.impl.execchain.RetryExec.execute(org.apache.http.conn.routing.HttpRoute, 
org.apache.http.client.methods.HttpRequestWrapper, 
org.apache.http.client.protocol.HttpClientContext, 
org.apache.http.client.methods.HttpExecutionAware) line: 89
org.apache.http.impl.execchain.RedirectExec.execute(org.apache.http.conn.routing.HttpRoute, 
org.apache.http.client.methods.HttpRequestWrapper, 
org.apache.http.client.protocol.HttpClientContext, 
org.apache.http.client.methods.HttpExecutionAware) line: 110
org.apache.http.impl.client.InternalHttpClient.doExecute(org.apache.http.HttpHost, 
org.apache.http.HttpRequest, org.apache.http.protocol.HttpContext) line: 
185
org.apache.http.impl.client.InternalHttpClient(org.apache.http.impl.client.CloseableHttpClient).execute(org.apache.http.client.methods.HttpUriRequest, 
org.apache.http.protocol.HttpContext) line: 83
org.eclipse.ecf.provider.filetransfer.httpclient45.HttpClientFileSystemBrowser.runRequest() 
line: 246
org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser$DirectoryJob.run(org.eclipse.core.runtime.IProgressMonitor) 
line: 69

org.eclipse.core.internal.jobs.Worker.run() line: 63

There will be two additional retries, and if those fail too, the 
repository will fail to load (or the artifact will fail to download).   
In my product catalog generator, I load a whole whack of repositories 
and this happens frequently enough that more often than not, one or more 
repositories fail to load.  This concerns me because with 2 million 
users loading repositories (via updates or via the installer), a 
significant fraction might well run into this same problem.


When I use 
-Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient45 
to disable the provider for this implementation, I of course see no log 
entries nor do any repositories fail to load.


I'm starting to get the feeling that either a) the server is ill-behaved 
or b) there is a problem in the httpclient implementation.  Perhaps some 
Keep-Alive header: is poor or not being respected by the implementation.


I saw something similar here where the server was blamed:

https://support.sonatype.com/hc/en-us/articles/213465028-Understanding-The-target-server-failed-to-respond-in-Nexus-logs

Does anyone have any ideas?

Regards,
Ed





___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] [equinox-dev] 4.15 M3 milestone week reminders

[Ed Merks]

I'm sorry too because in my enthusiasm to get p2's bugs in a manageable 
state I did the same thing. :-(


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

Note that as part of this, I had to fix a build problem too (an unused 
import was failing the API verification).


I too prefer to keep this given it's zero risk.


On 18.02.2020 10:26, Mickael Istria wrote:

Hi all,

I apologize because I merged a patch by mistake today: 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=560068
I think the risk is low, so it's acceptable to keep it. But if you 
prefer reverting if, feel free, it's all right.


Sorry!

___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Eclipse Native Launcher Help Needed

[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 will run by default 
and I think I need to know that in order to implement this request:


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

I need/want to know which java implementation Eclipse will use if the 
eclipse.ini does not contain a -vm option in order to avoid generating a 
-vm option in the eclipse.ini when this value simply hard-codes the 
system default (the Java that the native launcher will find anyway).   
So in general I need/want a way to determine the system default Java on 
all supported OSes and currently I only have a hack that only works on 
Windows and only because the native launcher uses / instead of \ when it 
munges the PATH.


One way I can imagine to do that, as described in 558832, is if the 
native launcher provided the value of the PATH in some other environment 
variable that's exported to (available in) the launched application.   
E.g., something like this, probably in eclipseMain.c:


  setenv("ORIGINAL_PATH", getenv("PATH"), 1);

But I don't know how I can contribute something in order make this 
happen.  I don't even know if this is really the best way or if this is 
even feasible.   Moreover, I don't know how the native launcher is built.


Can anyone help or offer alternative ideas or approaches?

Thanks,
Ed



___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] https://download.eclipse.org/eclipse/updates/4.15-I-builds/ is current broken

[Ed Merks]

FYI,

I imagine a great many builds are failing because 
https://download.eclipse.org/eclipse/updates/4.15-I-builds/ is currently 
broken.


I've opened this Bugzilla:

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

Regards,
Ed

___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] 4.15 M1 milestone week reminders

[Ed Merks]

Dani,

Yes, my comments and concerns are purely and only related to the license 
text in the products.  In their usual diligent manner, our tireless 
release engineers have already addressed that concern.


Last night's build is good again:

https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.15-I-builds/http___download.eclipse.org_eclipse_updates_4.15-I-builds_I20200108-0600.html

Thanks folks!

It would of course be great if ECF could move to EPL 2.0 and also use 
SUA 2.0, but alas, that's not the case.


Any other conversion from http -> https in code or in documentation is 
of course fine and good, though a word of caution is in order because, 
for example, my older Java 8 implementation cannot read from 
archive.eclipse.org via https:


org.eclipse.equinox.p2.core.ProvisionException: Unable to read 
repository at 
https://archive.eclipse.org/webtools/downloads/drops/R3.2/C3.2.0/I-C3.2.0-20100614204142/repository/content.xml.
    at 
org.eclipse.equinox.internal.p2.repository.CacheManager.createCache(CacheManager.java:247)
    at 
org.eclipse.equinox.internal.p2.metadata.repository.SimpleMetadataRepositoryFactory.getLocalFile(SimpleMetadataRepositoryFactory.java:69)
    at 
org.eclipse.equinox.internal.p2.metadata.repository.SimpleMetadataRepositoryFactory.load(SimpleMetadataRepositoryFactory.java:89)
    at 
org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.factoryLoad(MetadataRepositoryManager.java:63)
    at 
org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:775)
    at 
org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:676)
    at 
org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:110)
    at 
org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:105)
    at 
org.eclipse.cbi.p2repo.p2.loader.impl.P2RepositoryLoader.load(P2RepositoryLoader.java:94)
    at 
org.eclipse.cbi.p2repo.p2.loader.impl.P2RepositoryLoader.load(P2RepositoryLoader.java:60)
    at 
org.eclipse.cbi.p2repo.aggregator.p2.util.MetadataRepositoryResourceImpl$RepositoryLoaderJob.run(MetadataRepositoryResourceImpl.java:486)

    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: 
handshake_failure

    at sun.security.ssl.Alerts.getSSLException(Unknown Source)
    at sun.security.ssl.Alerts.getSSLException(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.recvAlert(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown 
Source)

    at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
    at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:396)
    at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:355)
    at 
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
    at 
org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:373)
    at 
org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:394)
    at 
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:237)
    at 
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)

    at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
    at 
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
    at 
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
    at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
    at 
org.eclipse.ecf.provider.filetransfer.httpclient45.HttpClientFileSystemBrowser.runRequest(HttpClientFileSystemBrowser.java:246)
    at 
org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser$DirectoryJob.run(AbstractFileSystemBrowser.java:69)

    ... 1 more

Most likely a root certificate problem because it works fine with the 
231 Java 8 version.


Regards,
Ed

On 08.01.2020 15:30, Daniel Megert wrote:
I agree with the license related changes but all other changes to 
https are fine with me and will not be reverted.


Dani



From: Ed Merks 
To: platform-dev@eclipse.org
Date: 08.01.2020 11:29
Subject: [EXTERNAL] Re: [platform-dev] 4.15 M1 milestone week reminders
Sent by: platform-dev-boun...@eclipse.org




Sravan,
The _http://git.eclipse.org_ <http://git.eclipse.org/>403 was 

Re: [platform-dev] 4.15 M1 milestone week reminders

[Ed Merks]

Sravan,

The http://git.eclipse.org 403 was a bad bug:

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

Its current behavior of a 301 redirection to https://git.eclipse.org is 
argued to be a feature that we should embrace.  I will not argue that 
point, other than to point out that it's just annoying that a simple URL 
connection fails.  But one could call 
java.net.HttpURLConnection.setFollowRedirects(boolean) globally or 
java.net.HttpURLConnection.setInstanceFollowRedirects(boolean) on the 
connection instance so that the 301 is followed...


Imagine now http://www.eclipse.org making the same change.  Every 
browser would just follow the redirect.  Imagine that it just stops 
working entirely as in the 403 case; that's just a bug and if we needed 
to work around that, we'd need to revisit every wiki page and every 
scrap of documentation to change all the URLs everywhere.   It seems to 
me that this is most clearly not feasible activity and would be 
addressed immediately.


So while I do understand your thinking and logic for why you changed 
this in the product definitions (and I definitely *greatly appreciate 
*all the hard work you folks to do keep releng working), to argue that 
we should/must change the legal text in anticipation of 
http://www.eclipse not working reasonably or in anticipation of some 
software being unable to follow redirects is just too much of a leap 
from that starting premise.  Even the internal browser can load 
http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/org.eclipse.setup 
and redirects it to display 
https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/org.eclipse.setup 
so one has to assume that even if http://www.eclipse.org changed its 
behavior to 301, it would continue to work properly for browsing 
purposes at the very least (and for most purposes for that matter).


So I would argue that we avoid doing anything that is highly likely to 
result in yet more license prompts for the users of Eclipse. I.e., just 
leave the SUA 2.0 alone and revisit it if/when there is a substantive 
reason to change the meaningful content.  We all have better things to do...


Regards,
Ed

On 08.01.2020 09:08, Sravan K Lakkimsetti wrote:


Hi,

To me not able to access license page is a bigger problem. If it is 
legal document it should be accessible. By using http we are currently 
depending on http->https redirection service available at eclipse 
foundation. We also seen this service can go down any time like it 
happened on Jan 2, 2020. In my opinion to avoid dependency on 
redirection service and single point of failure it is better to move 
to https protocol instead of unsecure http. This is the reason I tried 
go with https.


What is your suggestion on avoiding the similar failures in future. 
How do we proceed?


-Sravan

*From:*Ed Merks 
*Sent:* 08 January 2020 12:23
*To:* platform-dev@eclipse.org
*Subject:* [EXTERNAL] Re: [platform-dev] 4.15 M1 milestone week reminders

Sravan,

If "we" really want to change the license that is currently used by 
literally 1000s of features/products, we should change it in the 
central license feature first and hope (which is a rather pointless 
hope) that all projects rebuild to use the new version and all of them 
contribute that to SimRel (which seems unlikely to me given this was 
not accomplished in the last 3 months).  We'll also need to hope that 
all copies everywhere (EPP products, for example) are also changed 
(yet again).  Then we should expect all users to re-review the new 
text because they will be forced to do so.  The not-so-impressed user 
user can then agree yet again to what is effectively the same license.


To me this all smacks of completely gratuitous work for dozens or 
hundreds of people with absolutely zero value because browsers switch 
to https automatically when visiting a web link and even if not, any 
concerned user can make sure they view links using https if they're 
concerned that they might be presented with a bogus/hacked bit of 
legal documentation.


In the end, it's really a very inappropriate plan for the platform to 
make this decision for everyone without consulting anyone.  After all, 
it's a legal document so is it really your role to decide to alter 
it?  Moreover, should we not question whether the date needs to be 
changed given this is no longer the "November 22, 2017" version of 
this legal document?


Regards,
Ed

On 08.01.2020 07:11, Sravan K Lakkimsetti wrote:

In my opinion, we should move towards https instead of depending
on http->https redirection made available by webmaster. We should
plan to move to https in this release.

For M1 I suggest to revert the change. But for M3 we should move
to https.

    -Sravan

*From:*Ed Merks  <mailto:ed.me...@gmail.com>
*Sent:* 08 January 2020 11:22
*To:* platform-dev@eclipse.org <mailto:platform-dev@eclipse.org>
*Subject:* [EXTERNAL

[platform-dev] Gerrit Builds are Failing

[Ed Merks]

Gerrit Builds are failing, e.g.,

   https://ci.eclipse.org/jdt/job/eclipse.jdt.core-Gerrit/2556/console
   https://ci.eclipse.org/equinox/job/p2-gerrit/2573/console

I assume all Platform Gerrit verification builds will fail this same way.

The stack traces look like this:

   *10:27:10* [INFO]
   *10:27:10* [INFO]*--- tycho-eclipserun-plugin:1.6.0-SNAPSHOT:eclipse-run
   (api-analysis) @ org.eclipse.jdt.core --- **10:27:10* [INFO] Toolchain in 
tycho-eclipserun-plugin: JDK[/opt/tools/java/oracle/jdk-8/latest/jre]
   *10:27:10* [INFO] Expected eclipse log file: 
/home/jenkins/agent/workspace/eclipse.jdt.core-Gerrit/org.eclipse.jdt.core/target/eclipserun-work/data/.metadata/.log
   *10:27:10* [INFO] Command line:
   *10:27:10*   [/opt/tools/java/oracle/jdk-8/latest/jre/bin/java, -Xmx2048M, 
-jar, 
/home/jenkins/agent/workspace/eclipse.jdt.core-Gerrit/.repository/p2/osgi/bundle/org.eclipse.equinox.launcher/1.5.600.v20191014-2022/org.eclipse.equinox.launcher-1.5.600.v20191014-2022.jar,
 -install, 
/home/jenkins/agent/workspace/eclipse.jdt.core-Gerrit/org.eclipse.jdt.core/target/eclipserun-work,
 -configuration, 
/home/jenkins/agent/workspace/eclipse.jdt.core-Gerrit/org.eclipse.jdt.core/target/eclipserun-work/configuration,
 -data, 
/home/jenkins/agent/workspace/eclipse.jdt.core-Gerrit/org.eclipse.jdt.core/../target/org.eclipse.jdt.core-apiAnalyzer-workspace,
 -application, org.eclipse.pde.api.tools.apiAnalyzer, -project, 
/home/jenkins/agent/workspace/eclipse.jdt.core-Gerrit/org.eclipse.jdt.core, 
-baseline, 
/home/jenkins/agent/workspace/eclipse.jdt.core-Gerrit/org.eclipse.jdt.core/target/org.eclipse.jdt.core-apiBaseline.target,
 -dependencyList, 
/home/jenkins/agent/workspace/eclipse.jdt.core-Gerrit/org.eclipse.jdt.core/target/dependencies-list.txt,
 -failOnError]

   *10:28:03* org.eclipse.core.internal.resources.ResourceException: Errors 
occurred during the build.
   *10:28:03*   at 
org.eclipse.core.internal.resources.Project$1.run(Project.java:568)
   *10:28:03*   at 
org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2292)
   *10:28:03*   at 
org.eclipse.core.internal.resources.Project.internalBuild(Project.java:603)
   *10:28:03*   at 
org.eclipse.core.internal.resources.Project.build(Project.java:116)
   *10:28:03*   at 
org.eclipse.pde.api.tools.internal.ApiAnalysisApplication.start(ApiAnalysisApplication.java:128)
   *10:28:03*   at 
org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203)
   *10:28:03*   at 
org.eclipse.equinox.internal.app.AnyThreadAppLauncher.run(AnyThreadAppLauncher.java:30)
   *10:28:03*   at java.lang.Thread.run(Thread.java:748)
   *10:28:03* Contains: Errors running builder 'Java Builder' on project 
'org.eclipse.jdt.core'.
   *10:28:03* java.lang.ClassCastException: 
org.eclipse.jdt.internal.compiler.ast.MessageSend cannot be cast to 
org.eclipse.jdt.internal.compiler.ast.AllocationExpression
   *10:28:03*   at 
org.eclipse.jdt.internal.compiler.ast.FakedTrackingVariable.cleanUpAfterAssignment(FakedTrackingVariable.java:702)
   *10:28:03*   at 
org.eclipse.jdt.internal.compiler.ast.Assignment.analyseCode(Assignment.java:89)
   *10:28:03*   at 
org.eclipse.jdt.internal.compiler.ast.Block.analyseCode(Block.java:48)
   *10:28:03*   at 
org.eclipse.jdt.internal.compiler.ast.IfStatement.analyseCode(IfStatement.java:109)
   *10:28:03*   at 
org.eclipse.jdt.internal.compiler.ast.Block.analyseCode(Block.java:48)
   *10:28:03*   at 
org.eclipse.jdt.internal.compiler.ast.TryStatement.analyseCode(TryStatement.java:182)
   *10:28:03*   at 
org.eclipse.jdt.internal.compiler.ast.Block.analyseCode(Block.java:48)
   *10:28:03*   at 
org.eclipse.jdt.internal.compiler.ast.ForeachStatement.analyseCode(ForeachStatement.java:133)
   *10:28:03*   at 
org.eclipse.jdt.internal.compiler.ast.Block.analyseCode(Block.java:48)
   *10:28:03*   at 
org.eclipse.jdt.internal.compiler.ast.IfStatement.analyseCode(IfStatement.java:109)
   *10:28:03*   at 
org.eclipse.jdt.internal.compiler.ast.LabeledStatement.analyseCode(LabeledStatement.java:58)
   *10:28:03*   at 
org.eclipse.jdt.internal.compiler.ast.Block.analyseCode(Block.java:48)
   *10:28:03*   at 
org.eclipse.jdt.internal.compiler.ast.IfStatement.analyseCode(IfStatement.java:109)
   *10:28:03*   at 
org.eclipse.jdt.internal.compiler.ast.Block.analyseCode(Block.java:48)
   *10:28:03*   at 
org.eclipse.jdt.internal.compiler.ast.TryStatement.analyseCode(TryStatement.java:182)
   *10:28:03*   at 
org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.analyseCode(MethodDeclaration.java:128)
   *10:28:03*   at 
org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.internalAnalyseCode(TypeDeclaration.java:774)
   *10:28:03*   at 
org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.analyseCode(TypeDeclaration.java:272)
   *10:28:03*   at 
org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.analyseCode(CompilationUnitDeclaration.java:132)
   *10:28:03*   at 

Re: [platform-dev] I would like to help with SWT contributions

[Ed Merks]

o get SWT projects build in Eclipse (best using Oomph as Ed
described).
> Once build in Eclipse there should be a library folder in
> eclipse.platform.swt/bundles/org.eclipse.swt/bin with a script
to build
> the native parts. As I said, never did it on Mac but that could work
> from my experience.
>
> For CI:
> Maybe the following two links are interesting for you.
> Jobs building natives:
> https://ci.eclipse.org/releng/view/SWT%20Natives/
> Job building contributions to SWT:
>
https://ci.eclipse.org/platform/view/Gerrit/job/eclipse.platform.swt-Gerrit/
>
> For building on command line:
> usually it is enough to run
>   mvn verify -P build-individual-bundles
> in repository root (less sure for SWT)
>
> Note that both, maven 3.6.1 and 3.6.2 have breaking bugs for
building
> Eclipse stuff.
>
> https://issues.apache.org/jira/browse/MNG-6642
> https://issues.apache.org/jira/browse/MNG-6765
>
> Regards,
> Paul
>
>
> Am 04.10.2019 um 22:43 schrieb Ned Twigg:
>> Thanks very much, very helpful!!
>>
>>>  I think the problem is that the parent pom is often in
another Git
>> repository, so it's never quite clear to me how one could
actually do a
>> build locally for the platform's projects.
>>
>> I would love the answer to this question, if anyone has it. 
I'm also
>> very curious to know how CI runs.
>>
>> Ned Twigg
>> Lead Software Architect, DiffPlug LLC
>> 540-336-8043 (cell)
>> 888-513-6870 (fax)
>> 340 S Lemon Ave #3433, Walnut, CA 91789
>>
>> ᐧ
>>
>> On Fri, Oct 4, 2019 at 1:25 PM Ed Merks mailto:ed.me...@gmail.com>
>> <mailto:ed.me...@gmail.com <mailto:ed.me...@gmail.com>>> wrote:
>>
>>     Ned,
>>
>>     Comments below.
>>
>>     On 04.10.2019 20:24, Ned Twigg wrote:
>>>     Thanks for the help, we're off to a good start!  One of my
goals
>>>     is to make sure the bug I encountered is reproduced in the
test
>>>     suite, and then fixed after the code change. Otherwise it will
>>>     just break again.
>>>
>>>     The problem with IDE-only is that inevitably there's a
test that
>>>     somebody was running in their IDE that isn't being tested
by CI.
>>     I'm not sure that's the case.  I think (assume) all the
JUnit tests
>>     that one can run from within the IDE also run in the CI
build (and
>>     vice versa).  The problem is often that there are no launchers
>>     committed so one isn't exactly sure how one should run the
tests
>>     from within the IDE, but I don't think you should need to do a
>>     command line build in order to write and run tests.  If my
ability
>>     to contribute depended on first being able to do a command line
>>     build, I would never have been able to contribute anything...
>>>     So I wanted to first make sure that I can do the command-line
>>>     build, and my next step was to get the IDE stuff going. 
Here is
>>>     how I normally do that when I contribute to something:
>>>
>>>     - look in the README
>>>     - it points me to https://www.eclipse.org/swt/fixbugs.php,
which
>>>     doesn't say anything about the command-line build
>>>     - a lot of the links on this page are out-of-date, which
makes me
>>>     question if the instructions are accurate or not
>>>         - Tools link points to Eclipse 3.5
>>>         - Javadoc points to Eclipse Luna
>>>         - Community has CVS links to the Fox widget port
>>>         - Contact Us points to defunct mailing lists
>>     Yes, documentation tends to get out of date. :-(
>>>     - this makes me not trust this link, so I go to the next
link in
>>>     the README:
>>>
https://projects.eclipse.org/projects/eclipse.platform.swt/developer
>>>     - this link says "This project is archived. Some links on this
>>>     page may not work."
>>>     - the next link in the README is the defunct
>>> https://dev.eclipse.org/mailman/listinfo/platform-swt-dev
>>>     - so next I go to CONTRIBUTING
>>>         - which is how I found out about this list
>>     That helped at least. :-)
>>>
>>>

Re: [platform-dev] I would like to help with SWT contributions

[Ed Merks]

Ned,

If it's an issue of setting up a local development environment that can 
be done automatically:


  https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning

SWT is a bit tricky, with some renaming involved to set up the classpath 
in an OS-specific way, but that's handled automatically by the setup.


The above will clone way more projects than you really need, but you can 
go back after the initial automatic selection, selectively choose which 
projects to actually clone; this particular setup chooses all the 
Eclipse SDK projects by default.  You would actually only need the SWT 
project for your focused purpose, but it's super useful to have clones 
of all projects of the Eclipse SDK so that you can contribute anywhere 
and change anything.


Take note of the instructions about getting a Gerrit account and 
changing the clone URIs to be Gerrit Read/Write URIs so that you can 
commit to Gerrit when you want to contribute later.


Regards,
Ed


On 04.10.2019 18:35, Ned Twigg wrote:
Hello!  I really like SWT.  I like contributing to open source, and I 
have a hard time contributing to SWT.  I would like to help make it 
easier to contribute.


I found and documented a simple bug two years ago.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=520488

Today, Niraj very generously supplied a fix, but he cannot test it 
because he doesn't have a mac.  I figured the least I could do was 
help test it, but I cannot get the build to work.  I tried to follow 
the README/CONTRIBUTING, but it seems that a lot of the info there is 
stale.


Is there anyone who can help get me setup?  I will document the 
process, and update the README / CONTRIBUTING.  I also plan to run a 
GitHub mirror with public CI, so that it is easier for people like me 
to at least get started with contributing back to SWT.


Ned Twigg
Lead Software Architect, DiffPlug LLC
540-336-8043 (cell)
888-513-6870 (fax)
340 S Lemon Ave #3433, Walnut, CA 91789
ᐧ

___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] JDT "API" breakage causes a compile error in E4ContextType

[Ed Merks]

FYI,

Yesterday's commit in the following JDT Bugzilla causes a compile error 
in 
org.eclipse.e4.internal.tools.jdt.templates.E4ContextType.initializeContext 
from eclipse.platform.ui.tools:


  https://bugs.eclipse.org/bugs/show_bug.cgi?id=549989#c14

___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] CRLF Problems

[Ed Merks]

Dani,

I added this to my Installation.setup in the Platform SDK IDE:


http://www.omg.org/XMI;
    xmlns:setup.p2="http://www.eclipse.org/oomph/setup/p2/1.0;
    label="Git Bash">
  
  https://download.eclipse.org/oomph/updates/nightly/latest"/>


So that answers the question of what to install and where it comes from.

The new action is only in a nightly build right now and is in this 
plugin for lack of a better home.


With this installed, the context menu of a Repository (in the Git 
Repositories view) will have additional action, including "Fix CRLF".  
It's rather a crude tool, but effective.


Regards,
Ed


On 24.09.2019 14:57, Daniel Megert wrote:

Hi Ed

Where is the tool?

Dani



From: Ed Merks 
To: "Eclipse platform general developers list." 
Date: 24.09.2019 08:45
Subject: [EXTERNAL] [platform-dev] CRLF Problems
Sent by: platform-dev-boun...@eclipse.org




Guys,
The platform's Git repositories are rife with text files that have 
been committed with CRLF rather than LF. These things generally lead 
to totally confusing problems in EGit where files are shown as dirty 
with no apparent actual differences. This is of course a barrier to 
entry for our contributors.  Worse still, the problems are really 
quite hard to fix.  Previous attempts to fix such things indicate that 
it's all to easy to "fix" them incorrectly, e.g.,

_https://git.eclipse.org/r/#/c/148635/_
In this case there were files that had a mixture of CRLF and LF.  The 
naive attempt to fix this using EGit (convert the whole file to LF 
endings) ended up with a Gerrit commit that in actual fact converted 
them all to CRLF rather than converting them all to LF as intended.  I 
needed to change the repository's autocrlf to false in order to 
correctly commit a fix with actual LF endings. Julian Honnen was super 
helpful and responsive processing this contributions. Thanks Julian!!
In any case, to fix these problems more easily, I've implemented a 
utility that I can use (or anyone can use) to automate the process.  
It uses JGit under the covers.  It copies the existing clone (to avoid 
re-cloning the entire repo and to avoid dirtying the existing clone), 
changes the copy's autocrlf to false, deletes the copy's working tree, 
and then does a reset hard to create a fresh new working tree that 
should (and generally does) contain text files with only LF in them.  
All the files in the working tree are then processed to convert any 
remaining CRLF to LF, i.e., to fix any files improperly commited to 
Git in the past.  From this copy one can easily commit to Gerrit a fix 
to correct all improper files.

I used that tool for the following Gerrit commit:
_https://git.eclipse.org/r/#/c/150035/_
I would like to fix all the platform's repositories, but I would not 
like to spend the next weeks waiting for reviews, re-basing multiple 
times, and hoping to eventually get the commit through.  I really do 
actually have better things to do with my time. :-P
I have commit rights for the Platform and Equinox (thanks Lars for 
starting an election for that) so I can do that on my own without 
bothering other people.  E.g., I could fix a feature's "null" provider:

_https://bugs.eclipse.org/bugs/show_bug.cgi?id=550648_
But I do not have commit rights for PDE and JDT.  The PDE folks are 
very responsive, so that's not a problem, but JDT seems to be a dead 
zone of silence.  Sorry for that. I don't intend to criticize anyone 
personally and of course I know that everyone else also has more 
important things to do with their time than deal with trivial deltas.  
Nevertheless, I need to understand how to get someone's attention to 
move forward in this process:

*What do I need to do so that some JDT committer looks a 150035?*
If trivial things can't move forward, it doesn't bode well for moving 
forward on more complex contributions to JDT...

Regards,
Ed___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or 
unsubscribe from this list, visit

https://www.eclipse.org/mailman/listinfo/platform-dev



___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] CRLF Problems

[Ed Merks]

Guys,

The platform's Git repositories are rife with text files that have been 
committed with CRLF rather than LF.  These things generally lead to 
totally confusing problems in EGit where files are shown as dirty with 
no apparent actual differences.  This is of course a barrier to entry 
for our contributors.  Worse still, the problems are really quite hard 
to fix.  Previous attempts to fix such things indicate that it's all to 
easy to "fix" them incorrectly, e.g.,


https://git.eclipse.org/r/#/c/148635/

In this case there were files that had a mixture of CRLF and LF. The 
naive attempt to fix this using EGit (convert the whole file to LF 
endings) ended up with a Gerrit commit that in actual fact converted 
them all to CRLF rather than converting them all to LF as intended.  I 
needed to change the repository's autocrlf to false in order to 
correctly commit a fix with actual LF endings. Julian Honnen was super 
helpful and responsive processing this contributions.  Thanks Julian!!


In any case, to fix these problems more easily, I've implemented a 
utility that I can use (or anyone can use) to automate the process.  It 
uses JGit under the covers.  It copies the existing clone (to avoid 
re-cloning the entire repo and to avoid dirtying the existing clone), 
changes the copy's autocrlf to false, deletes the copy's working tree, 
and then does a reset hard to create a fresh new working tree that 
should (and generally does) contain text files with only LF in them.  
All the files in the working tree are then processed to convert any 
remaining CRLF to LF, i.e., to fix any files improperly commited to Git 
in the past.  From this copy one can easily commit to Gerrit a fix to 
correct all improper files.


I used that tool for the following Gerrit commit:

  https://git.eclipse.org/r/#/c/150035/

I would like to fix all the platform's repositories, but I would not 
like to spend the next weeks waiting for reviews, re-basing multiple 
times, and hoping to eventually get the commit through. I really do 
actually have better things to do with my time. :-P


I have commit rights for the Platform and Equinox (thanks Lars for 
starting an election for that) so I can do that on my own without 
bothering other people.  E.g., I could fix a feature's "null" provider:


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

But I do not have commit rights for PDE and JDT.  The PDE folks are very 
responsive, so that's not a problem, but JDT seems to be a dead zone of 
silence.  Sorry for that.  I don't intend to criticize anyone personally 
and of course I know that everyone else also has more important things 
to do with their time than deal with trivial deltas.  Nevertheless, I 
need to understand how to get someone's attention to move forward in 
this process:


*What do I need to do so that some JDT committer looks a **150035?*

If trivial things can't move forward, it doesn't bode well for moving 
forward on more complex contributions to JDT...


Regards,
Ed

___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Process for Commits

[Ed Merks]

Hi,

What's the process for merging this bug's Gerrit review?

https://bugs.eclipse.org/bugs/show_bug.cgi?id=551156
https://git.eclipse.org/r/#/c/149636/

The verification build takes forever, okay hours, so merging soon rather 
than later would be good.  Could/should/can I do that myself, or should 
some other set of eyes be involved?


Regards,
Ed

___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Need some more current pointers for getting started on JDT projects

[Ed Merks]

Richard,

It sounds like you selected the SSH URIs for cloning.  I.e., not 
https://git.eclipse.org/r/jdt/eclipse.jdt but rather 
ssh://${git.user.id|username}@git.eclipse.org:29418/jdt/eclipse.jdt correct?


I assume you have an Eclipse account, but have you uploaded your public 
key to the server as described in the Gerrit wiki that's referenced by 
the documentation?  I.e., specifically from this section:


  https://wiki.eclipse.org/Gerrit#Git_over_SSH

Also, has an entry for "[git.eclipse.org]:29418 ssh-rsa " been added to 
your ~/.ssh/known_hosts?


Note that it would be better to use 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=536533 as documented in 
the wiki as the place to ask questions or to provide suggestions for 
improvements.  This way the next person who has such an issue will be 
more likely find the answers.


Regards,
Ed

On 16.09.2019 07:01, Richard Steiger wrote:


Ed,

After tying-off previous engagements, I'm back trying to setup the SDK.

The Good News: your doc (below) was extremely helpful, and after 
following it to a T, I was able made significant progress, launching 
the provisioning and installation process.


The Not So Good News: provisioning failed, with the following 
(partial) trace (after one attempt to restart):


Caused by: org.apache.sshd.common.SshException: No more
authentication methods available
  at

org.apache.sshd.client.session.ClientUserAuthService.tryNext(ClientUserAuthService.java:322)
  at

org.apache.sshd.client.session.ClientUserAuthService.processUserAuth(ClientUserAuthService.java:258)
  at

org.apache.sshd.client.session.ClientUserAuthService.process(ClientUserAuthService.java:205)
  at

org.apache.sshd.common.session.helpers.AbstractSession.doHandleMessage(AbstractSession.java:400)
  at

org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:333)
  at

org.apache.sshd.common.session.helpers.AbstractSession.decode(AbstractSession.java:1097)
  at

org.apache.sshd.common.session.helpers.AbstractSession.messageReceived(AbstractSession.java:294)
  at

org.eclipse.jgit.internal.transport.sshd.JGitClientSession.messageReceived(JGitClientSession.java:214)
  at

org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:63)
  at

org.apache.sshd.common.io.nio2.Nio2Session.handleReadCycleCompletion(Nio2Session.java:357)
  at

org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:335)
  at

org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:332)
  at

org.apache.sshd.common.io.nio2.Nio2CompletionHandler.lambda$completed$0(Nio2CompletionHandler.java:38)
  at java.security.AccessController.doPrivileged(Native Method)
  at

org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
  at sun.nio.ch.Invoker.invokeUnchecked(Unknown Source)
  at sun.nio.ch.Invoker$2.run(Unknown Source)
  at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(Unknown Source)
  ... 3 more

Took 1 seconds.
There are failed tasks.
Press Back to choose different settings or Cancel to abort.

This occurred after hitting Back, and having no hint what settings are 
required, just tried clicking Finish, which failed immediately with 
the above trace.  Just before the failure, I got a popup stating that, 
IIRC, SSH needed missing info needed to auth the host, and gave the 
option to just accept all subsequent creds.


The "No more authentication methods available" error message seems to 
suggest that I failed to obtain or supply some essential keys, but am 
hoping that you (or one of y'all) can pinpoint the root cause and 
advise how to resume the provisioning.


Thanks!

-rjs

On 8/12/2019 12:58 AM, Ed Merks wrote:

Richard,

As Paul suggests, if you really want to clone the repos and work with 
(or see all) the source, better to use the installer. There is a 
tutorial describing how the create an installation with the complete 
platform SDK:


https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning

Likely this is overkill for your purpose, but I find this an 
extremely useful resource to have around.  It can help you find out 
how other things are already implemented in the platform and provides 
search capabilities not possible in any other way.  For example, if I 
see a string some where in some dialog or elsewhere in the UI, I can 
search all the source to find where that is specified, e.g., often in 
a properties file.  Then I can figure out the name of that property 
and can search for all uses of that property name in the *.java file 
files.  Typically this will be some static final constant, and then I 
can open a call hierarchy on that constant to find all the places 
that its used.  The advantage of having all the source is that a 
constant's v

Re: [platform-dev] Logging in Eclipse Platform

[Ed Merks]

I'd be unhappy to see yet more deprecated "APIs", i.e., would 
org.eclipse.core.runtime.ILog be deprecated?  Consumers might start to 
feel as if no API is really API anymore.  Everything is just potentially 
in a transient state on the path to ultimate perfection, along with the 
ever-present concern about deletion.


Of course I'm all for progress and improvements, so I'd not vote -1.  
And I most certainly don't want to discourage progress or innovation.  
My biggest concern is simply deprecation and deletion.



On 12.09.2019 18:13, Lars Vogel wrote:

+1

Dirk Fauth > schrieb am Do., 12. Sep. 2019, 18:07:


Actually I would like to get rid of the multiple facades
(FrameworkLog, RuntimeLog, etc. are all forwarding to the OSGi
LogService. And with OSGi R7 it has improved and probably makes
all the facades unnecessary. Why reinventing the wheel if the base
has fixed the issues from the past?

Lars Vogel mailto:lars.vo...@vogella.com>> schrieb am Do., 12. Sep. 2019, 17:44:

I know that statement would trigger a reply. :-)

I think Dirk's vision is to deprecate all other logging
approaches or fascade them.

Would IMHO be nice to have one simple and fast way of logging.
For example, currently writing lots of entries to the error
log can cause UI freezes.

Mickael Istria mailto:mist...@redhat.com>> schrieb am Do., 12. Sep. 2019, 17:40:



On Thu, Sep 12, 2019 at 5:22 PM Lars Vogel
mailto:lars.vo...@vogella.com>>
wrote:

Having one logging solution would be great, as you
pointed out it must
be simple for the IDE case and the e4 RCP case.


As mentioned in the previous thread, there are already N
ways of logging, so adding one more way won't make N+1 == 1.
All the logging approach that are already in are most
likely meant to stay as API, so before starting such
refactoring, I think it needs to be verified how much
value is to be expected from it.
As spotted in the "only few committers care of know the
details about logging", I think that most contributors
don't really care about logging because while it might be
not perfect, it just works fine in the current state and
changing this wouldn't provide much added value to them.
___
platform-dev mailing list
platform-dev@eclipse.org 
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

___
platform-dev mailing list
platform-dev@eclipse.org 
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

___
platform-dev mailing list
platform-dev@eclipse.org 
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev


___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

[platform-dev] Transition of p2 Repositories from 4.13 to 4.14

[Ed Merks]

The transition period between the point time when one release cycle 
shuts down (2019-09/4.13) and the next one begins (2019-12/4.14) is 
always kind of problematic.  At some point I need to prepare the Oomph 
setups for the release and the start of next cycle, and given 4.14 is 
"open" it's an awkward transition.


In particular, at this point in time 
http://download.eclipse.org/eclipse/updates/4.13 is empty (except for 
categories, but nothing is in those categories) so that's in a useless 
state.  And while 
http://download.eclipse.org/eclipse/updates/4.13-I-builds still exists, 
it will be deleted soon, so references to it will need to change to the 
released 4.13 site (and it contains very recent builds that are likely 
newer than the actual release build which makes it feel unstable to 
me).  Eventually a repository like 
http://download.eclipse.org/eclipse/updates/4.12/R-4.12-201906051800 
will be created for the 4.13 release, but that doesn't exist yet for 
4.13.   I imagine it will be created soon so that it can be mirrored 
properly before the release date.


*So  question for the platform release engineers: What is the schedule 
for creating the 4.13 release repository in its final permanent location?*




___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] ACTION REQUIRED: p2 Repository Quality Problems

[Ed Merks]

The discussion seem to have gotten side-tracked around the already-fixed 
problem:


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

Should I review and submit this Gerrit patch myself or will someone else 
do that? I'm never quite sure of the appropriate process here...


*The import question that's still outstanding is the following:**
*

*  How will we update to the correct license and ensure that all feature 
versions are incremented at least minimally?*



On 29.08.2019 17:27, Ed Merks wrote:


Folks,

I've been working on a tool that generates a quality report for p2 
repositories.  The initial prototype is now complete.  I've documented 
it here:


https://wiki.eclipse.org/Oomph_Repository_Analyzer

Things are in pretty rough shape overall.

Given that the Platform team is among the most skilled at managing 
their builds properly, I though it would be best to begin cleaning 
shop ourselves before approaching the broader release train 
participants (which unfortunately I'm quite sure will be like trying 
to herd cats).


I now generate the following page for the Platform's current IBuilds:

https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.13-I-builds/index.html

My biggest concern is the licenses, because quite frankly, that's a 
disaster area.  As Vikas has already observed, this results in what 
appear to be duplicate license prompts:


https://bugs.eclipse.org/bugs/show_bug.cgi?id=549523
https://bugs.eclipse.org/bugs/attachment.cgi?id=279381

This is embarrassing to Eclipse and annoying to the users. Only 
collectively as a group can we can fix this.


There are two major causes for this problem with regard to the Platform.

The first cause is that all the Platform's products have in some way 
messed up the trademark symbol.  I've opened this Bugzilla and 
included a Gerrit commit with the fixes:


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

(Too bad Tycho doesn't like  but good that it's okay with 
| |because I think using the actual unicode symbol is just 
begging for someone to corrupt it again.)


The second cause stems from the fact that CBI produced two bad 
variants of SUA 2.0.  So you'll see that the CBI license composite 
does not contain a valid SUA 2.0.


https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/cbi/updates/license/index.html

The valid one is located in this repo:

http://download.eclipse.org/cbi/updates/license/2.0.2-SNAPSHOT

But it's been almost a year ago that it was fixed and then it stalled:

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

So let's just compose that into the composite to solve the problem, 
right?


That unfortunately is also a problem, because the license is copied 
into the feature's artifact and all the platform's features look like 
this:




I.e., they in no way restrict the version, so if the version resolves 
to a different version (from using an updated composite), the IU 
metadata will be different and the actual artifacts will be different 
too. You can look at this artifact to confirm that this is the case:


https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.13-I-builds/http___download.eclipse.org_eclipse_updates_4.13-I-builds_I20190828-1800/org.eclipse.jdt.feature.jar_3.18.100.v20190828-1800.html

I.e., the feature.properties in this artifact has the license but that 
information is not present in the Git version of feature.properties.  
Also the license.html itself is copied into the artifact during the build.


*So the question is how are we going to fix this in a way that ensures 
we produce new IU versions for all features?* That sounds like a lot 
of work!


Also of concern is unsigned content, but only 
org.eclipse.jdt.core.compiler.batch falls in that category, so that 
seems easy to address.  Hopefully someone will.


Finally there are many missing pack200 artifacts. Although this isn't 
a huge problem---it doesn't break anything---it does result in 
increased network traffic.  The pack200 versions are generally from 
50% to 30% the size of the original *.jar, so jdt.core at 6.6M just by 
itself could save quite some traffic.


*Why are are so so many pack200 artifacts missing?*  Is this easy for 
us to fix?


Regards,
Ed







___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] ACTION REQUIRED: p2 Repository Quality Problems

[Ed Merks]

Aleksandar,

The Gerrit patch I have already works (the Gerrit verification build 
passed) because  works in general.  Of course that's the case 
because no symbol table is needed; any XML parser can just parse the hex 
value to determine the unicode character that's specified.  It seems to 
me not to be worth the effort to try to get  or any other named 
entities that don't have built-in support, to work.


Does  versus  really matter?  No one noticed the bad 
characters in their before so who will notice this or care?


Regards,
Ed

|
|

On 30.08.2019 07:21, Aleksandar Kurtakov wrote:



On Fri, Aug 30, 2019 at 5:12 AM Ed Merks <mailto:ed.me...@gmail.com>> wrote:


Aleksandar,

Yes, the initial patch set in
https://git.eclipse.org/r/#/c/148581/ produced this build:


https://ci-staging.eclipse.org/platform/job/eclipse.platform.releng.aggregator-Gerrit/1079/


Thanks for the pointer. So the issue is at p2 layer more specifically 
ProductFile parser (not tycho) if it's an issue at all as  is 
not valid xml entity at all [1] so the parser is correct. With that 
said I'm unsure how to proceed on this one as it makes sense to be 
able to use html entities. One idea is to define dtd file for product 
files where entities can be listed.


[1] 
https://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references#Predefined_entities_in_XML


With this failure:

Downloaded from 
tycho-snapshots:https://repo.eclipse.org/content/repositories/tycho-snapshots/org/eclipse/tycho/tycho-p2-repository-plugin/1.5.0-SNAPSHOT/tycho-p2-repository-plugin-1.5.0-20190829.120755-59.jar
  (14 kB at 497 kB/s)
*16:33:37* [ERROR] Internal error: java.lang.RuntimeException:
Unable to parse the product file

/home/jenkins/workspace/eclipse.platform.releng.aggregator-Gerrit/eclipse.platform.releng.tychoeclipsebuilder/equinox.starterkit.product/EclipseRTOSGiStarterKit.product:
Problems parsing the product file

/home/jenkins/workspace/eclipse.platform.releng.aggregator-Gerrit/eclipse.platform.releng.tychoeclipsebuilder/equinox.starterkit.product/EclipseRTOSGiStarterKit.product.
The entity "trade" was referenced, but not declared. -> [Help 1]
*16:33:37* org.apache.maven.InternalErrorException: Internal error: 
java.lang.RuntimeException: Unable to parse the product file 
/home/jenkins/workspace/eclipse.platform.releng.aggregator-Gerrit/eclipse.platform.releng.tychoeclipsebuilder/equinox.starterkit.product/EclipseRTOSGiStarterKit.product
*16:33:37*  at org.apache.maven.DefaultMaven.execute 
(DefaultMaven.java:120)
*16:33:37*  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
*16:33:37*  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
*16:33:37*  at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
*16:33:37*  at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native 
Method)
*16:33:37*  at sun.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
*16:33:37*  at sun.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)
*16:33:37*  at java.lang.reflect.Method.invoke (Method.java:498)
*16:33:37*  at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:289)
*16:33:37*  at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
(Launcher.java:229)
*16:33:37*  at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:415)
*16:33:37*  at org.codehaus.plexus.classworlds.launcher.Launcher.main 
(Launcher.java:356)
*16:33:37* Caused by: java.lang.RuntimeException: Unable to parse the 
product file 
/home/jenkins/workspace/eclipse.platform.releng.aggregator-Gerrit/eclipse.platform.releng.tychoeclipsebuilder/equinox.starterkit.product/EclipseRTOSGiStarterKit.product
*16:33:37*  at 
org.eclipse.tycho.p2.impl.publisher.P2GeneratorImpl.getPublisherActions 
(P2GeneratorImpl.java:289)
*16:33:37*  at 
org.eclipse.tycho.p2.impl.publisher.AbstractMetadataGenerator.generateMetadata 
(AbstractMetadataGenerator.java:57)
*16:33:37*  at 
org.eclipse.tycho.p2.impl.publisher.DefaultDependencyMetadataGenerator.generateMetadata
 (DefaultDependencyMetadataGenerator.java:32)
*16:33:37*  at 
org.eclipse.tycho.p2.impl.publisher.DefaultDependencyMetadataGenerator.generateMetadata
 (DefaultDependencyMetadataGenerator.java:1)
*16:33:37*  at 
org.eclipse.tycho.p2.resolver.P2DependencyResolver.getDependencyMetadata 
(P2DependencyResolver.java:148)
*16:33:37*  at 
org.eclipse.tycho.p2.resolver.P2DependencyResolver.setupProjects 
(P2DependencyResolver.java:131)
*16:33:37*  at 
org.eclipse.tycho.core.resolver.DefaultTychoResolver.setupProject 
(DefaultTychoResolver.java:97)
*16:33:37*  at 
org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead 
(TychoMavenLifecycleParticipant.

Re: [platform-dev] ACTION REQUIRED: p2 Repository Quality Problems

[Ed Merks]

Aleksandar,

Yes, the initial patch set in https://git.eclipse.org/r/#/c/148581/ 
produced this build:


https://ci-staging.eclipse.org/platform/job/eclipse.platform.releng.aggregator-Gerrit/1079/

With this failure:

Downloaded from 
tycho-snapshots:https://repo.eclipse.org/content/repositories/tycho-snapshots/org/eclipse/tycho/tycho-p2-repository-plugin/1.5.0-SNAPSHOT/tycho-p2-repository-plugin-1.5.0-20190829.120755-59.jar
  (14 kB at 497 kB/s)
*16:33:37* [ERROR] Internal error: java.lang.RuntimeException: Unable to 
parse the product file 
/home/jenkins/workspace/eclipse.platform.releng.aggregator-Gerrit/eclipse.platform.releng.tychoeclipsebuilder/equinox.starterkit.product/EclipseRTOSGiStarterKit.product: 
Problems parsing the product file 
/home/jenkins/workspace/eclipse.platform.releng.aggregator-Gerrit/eclipse.platform.releng.tychoeclipsebuilder/equinox.starterkit.product/EclipseRTOSGiStarterKit.product. 
The entity "trade" was referenced, but not declared. -> [Help 1] *16:33:37* org.apache.maven.InternalErrorException: Internal error: java.lang.RuntimeException: Unable to parse the product file /home/jenkins/workspace/eclipse.platform.releng.aggregator-Gerrit/eclipse.platform.releng.tychoeclipsebuilder/equinox.starterkit.product/EclipseRTOSGiStarterKit.product

*16:33:37*  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
*16:33:37*  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
*16:33:37*  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
*16:33:37*  at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
*16:33:37*  at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
*16:33:37*  at sun.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
*16:33:37*  at sun.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)
*16:33:37*  at java.lang.reflect.Method.invoke (Method.java:498)
*16:33:37*  at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:289)
*16:33:37*  at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
(Launcher.java:229)
*16:33:37*  at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:415)
*16:33:37*  at org.codehaus.plexus.classworlds.launcher.Launcher.main 
(Launcher.java:356)
*16:33:37* Caused by: java.lang.RuntimeException: Unable to parse the product 
file 
/home/jenkins/workspace/eclipse.platform.releng.aggregator-Gerrit/eclipse.platform.releng.tychoeclipsebuilder/equinox.starterkit.product/EclipseRTOSGiStarterKit.product
*16:33:37*  at 
org.eclipse.tycho.p2.impl.publisher.P2GeneratorImpl.getPublisherActions 
(P2GeneratorImpl.java:289)
*16:33:37*  at 
org.eclipse.tycho.p2.impl.publisher.AbstractMetadataGenerator.generateMetadata 
(AbstractMetadataGenerator.java:57)
*16:33:37*  at 
org.eclipse.tycho.p2.impl.publisher.DefaultDependencyMetadataGenerator.generateMetadata
 (DefaultDependencyMetadataGenerator.java:32)
*16:33:37*  at 
org.eclipse.tycho.p2.impl.publisher.DefaultDependencyMetadataGenerator.generateMetadata
 (DefaultDependencyMetadataGenerator.java:1)
*16:33:37*  at 
org.eclipse.tycho.p2.resolver.P2DependencyResolver.getDependencyMetadata 
(P2DependencyResolver.java:148)
*16:33:37*  at 
org.eclipse.tycho.p2.resolver.P2DependencyResolver.setupProjects 
(P2DependencyResolver.java:131)
*16:33:37*  at 
org.eclipse.tycho.core.resolver.DefaultTychoResolver.setupProject 
(DefaultTychoResolver.java:97)
*16:33:37*  at 
org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead 
(TychoMavenLifecycleParticipant.java:90)
*16:33:37*  at org.apache.maven.DefaultMaven.doExecute 
(DefaultMaven.java:264)
*16:33:37*  at org.apache.maven.DefaultMaven.doExecute 
(DefaultMaven.java:192)
*16:33:37*  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
*16:33:37*  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
*16:33:37*  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
*16:33:37*  at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
*16:33:37*  at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
*16:33:37*  at sun.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
*16:33:37*  at sun.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)
*16:33:37*  at java.lang.reflect.Method.invoke (Method.java:498)
*16:33:37*  at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:289)
*16:33:37*  at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
(Launcher.java:229)
*16:33:37*  at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:415)
*16:33:37*  at org.codehaus.plexus.classworlds.launcher.Launcher.main 
(Launcher.java:356)
*16:33:37* Caused by: org.eclipse.core.runtime.CoreException: Problems parsing 

[platform-dev] ACTION REQUIRED: p2 Repository Quality Problems

[Ed Merks]

Folks,

I've been working on a tool that generates a quality report for p2 
repositories.  The initial prototype is now complete.  I've documented 
it here:


  https://wiki.eclipse.org/Oomph_Repository_Analyzer

Things are in pretty rough shape overall.

Given that the Platform team is among the most skilled at managing their 
builds properly, I though it would be best to begin cleaning shop 
ourselves before approaching the broader release train participants 
(which unfortunately I'm quite sure will be like trying to herd cats).


I now generate the following page for the Platform's current IBuilds:

https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.13-I-builds/index.html

My biggest concern is the licenses, because quite frankly, that's a 
disaster area.  As Vikas has already observed, this results in what 
appear to be duplicate license prompts:


   https://bugs.eclipse.org/bugs/show_bug.cgi?id=549523
   https://bugs.eclipse.org/bugs/attachment.cgi?id=279381

This is embarrassing to Eclipse and annoying to the users.  Only 
collectively as a group can we can fix this.


There are two major causes for this problem with regard to the Platform.

The first cause is that all the Platform's products have in some way 
messed up the trademark symbol.  I've opened this Bugzilla and included 
a Gerrit commit with the fixes:


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

(Too bad Tycho doesn't like  but good that it's okay with 
| |because I think using the actual unicode symbol is just 
begging for someone to corrupt it again.)


The second cause stems from the fact that CBI produced two bad variants 
of SUA 2.0.  So you'll see that the CBI license composite does not 
contain a valid SUA 2.0.


https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/cbi/updates/license/index.html

The valid one is located in this repo:

  http://download.eclipse.org/cbi/updates/license/2.0.2-SNAPSHOT

But it's been almost a year ago that it was fixed and then it stalled:

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

So let's just compose that into the composite to solve the problem, right?

That unfortunately is also a problem, because the license is copied into 
the feature's artifact and all the platform's features look like this:




I.e., they in no way restrict the version, so if the version resolves to 
a different version (from using an updated composite), the IU metadata 
will be different and the actual artifacts will be different too. You 
can look at this artifact to confirm that this is the case:


https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.13-I-builds/http___download.eclipse.org_eclipse_updates_4.13-I-builds_I20190828-1800/org.eclipse.jdt.feature.jar_3.18.100.v20190828-1800.html

I.e., the feature.properties in this artifact has the license but that 
information is not present in the Git version of feature.properties.  
Also the license.html itself is copied into the artifact during the build.


*So the question is how are we going to fix this in a way that ensures 
we produce new IU versions for all features?*  That sounds like a lot of 
work!


Also of concern is unsigned content, but only 
org.eclipse.jdt.core.compiler.batch falls in that category, so that 
seems easy to address.  Hopefully someone will.


Finally there are many missing pack200 artifacts. Although this isn't a 
huge problem---it doesn't break anything---it does result in increased 
network traffic.  The pack200 versions are generally from 50% to 30% the 
size of the original *.jar, so jdt.core at 6.6M just by itself could 
save quite some traffic.


*Why are are so so many pack200 artifacts missing?*  Is this easy for us 
to fix?


Regards,
Ed







___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Where Does org.eclipse.license Come From?

[Ed Merks]

Rolf,

Thanks!  And indeed, here is one of the bad lines:

https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/eclipse.platform.releng.tychoeclipsebuilder/platform.sdk/platform.sdk.product#n69

No doubt someone edited this as non-UTF-8 and corrupted it that way.

Now I can track down the remaining problems and fix them.  I think it 
will make sense to include these product projects in the full SDK setup...


Cheers,
Ed


On 24.08.2019 14:11, Rolf Theunissen wrote:

Otherwise, maybe these ones?
https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/eclipse.platform.releng.tychoeclipsebuilder


___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Where Does org.eclipse.license Come From?

[Ed Merks]

Rolf,

No, I mean the platform's own products.  There are five of them:

If I search for "Eclipse Platform SDK" in my platform SDK workspace, 
there are no matching strings.  I looked through the "platform" repos in 
https://git.eclipse.org/c/ (that aren't already in my workspace) but I 
can find nothing that seems related there.  So I cannot figure out where 
the following IUs originates, not even the text for its name, and most 
especially not the corrupted license text:



  range='[4.0.0,4.13.0.I20190607-0725)' severity='0' description='An 
update for 4.x generation Platform SDK'/>

  
    Platform SDK*'/>

**
    
    

    
  
  
    name='org.eclipse.platform.sdk' version='4.13.0.I20190607-0725'/>

  
  
    name='toolingorg.eclipse.platform.sdk.application' 
range='[4.13.0.I20190607-0725,4.13.0.I20190607-0725]'/>
    name='tooling.org.eclipse.update.feature.default' range='[1.0.0,1.0.0]'>

  
    (org.eclipse.update.install.features=true)
  
    
    name='toolingorg.eclipse.configuration.macosx' range='[1.0.0,1.0.0]'>

  
    (osgi.os=macosx)
  
    
    name='tooling.source.default' range='[1.0.0,1.0.0]'/>
    name='toolingorg.eclipse.platform.sdk.configuration' 
range='[4.13.0.I20190607-0725,4.13.0.I20190607-0725]'/>
    name='toolingorg.eclipse.configuration' range='[1.0.0,1.0.0]'>

  
    (!(osgi.os=macosx))
  
    
    name='org.eclipse.platform.feature.group' 
range='[4.13.0.v20190607-0954,4.13.0.v20190607-0954]'/>
    name='org.eclipse.equinox.p2.user.ui.source.feature.group' 
range='[2.4.400.v20190516-1504,2.4.400.v20190516-1504]'/>

    
    name='org.eclipse.equinox.p2.user.ui.feature.group' 
range='[2.4.400.v20190516-1504,2.4.400.v20190516-1504]'/>
    name='tooling.osgi.bundle.default' range='[1.0.0,1.0.0]'/>
    name='org.eclipse.platform.source.feature.group' 
range='[4.13.0.v20190607-0954,4.13.0.v20190607-0954]'/>

  
  
  
    
  
addRepository(type:0,location:http${#58}//download.eclipse.org/eclipse/updates/4.13,name:The 
Eclipse Project 
Updates);addRepository(type:1,location:http${#58}//download.eclipse.org/eclipse/updates/4.13,name:The 
Eclipse Project 
Updates);addRepository(type:0,location:http${#58}//download.eclipse.org/releases/2019-09,name:2019-09);addRepository(type:1,location:http${#58}//download.eclipse.org/releases/2019-09,name:2019-09);mkdir(path:${installFolder}/dropins);

  
    
  
  
    url='http://eclipse.org/legal/epl/notice.php'>

**
    
  



On 24.08.2019 13:51, Rolf Theunissen wrote:

"the platform products" are you referfing the the EPP packages?

In that case:
https://git.eclipse.org/c/epp/org.eclipse.epp.packages.git

At least a quick check shows that they do not mention EPL 2.0 yet.

Regards,
Rolf

Op za 24 aug. 2019 om 13:28 schreef Ed Merks <mailto:ed.me...@gmail.com>>:


The org.eclipse.license question was kind of a stupid one I must
admit.  I'm well aware of the CBI repository, using it as the
basis against which to validate license correctness, but I got
completely sidetracked thinking this thing used by the platform
must from some platform repository.  Silly me, and thanks for all
the friendly help on that one!

__

As a follow up question.  Where do the platform's products come
from?  I can't find any corresponding .product files.

The reason I ask is that the only valid licenses in the platform's
p2 repos are the ones that come from EMF and ECF.  All other
licenses are corrupted in some way. This naturally leads to the
assumption that this is something that Oomph can fix or address:

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

But it is not something I can fix.  It must be fixed at the source
of the bad license.

I believe I tracked down the source of most of the bad licenses in
the platform's repos, but not for the products; these have yet two
more different variants of the SUA 2.0.

If someone could enlighten me on where the products come from,
then I'll be able to make progress to eliminate at least this one
source of end-user annoyance.

Regards,
Ed

On 24.08.2019 12:59, Vikas Chandra wrote:

>>if anyone uses other ways to solve such a puzzle. :)
How about searching for org.eclipse.license eclipse git repo
and then clicking on the 1st link?

Regards,
Vikas

- Original message -
From: Michael Keppler 
<mailto:michael.kepp...@gmx.de>
Sent by: platform-dev-boun...@eclipse.org
<mailto:platform-dev-boun...@eclipse.org>
To: platform-dev@eclipse.org <mailto:platform-dev@eclipse.org>
Cc:
Subject: [EXTERNAL] Re: [platform-dev] Where Does
org.eclipse.license Come From?
Date: Sat, Aug 24, 2019 4:16 PM
Am 23.08.2019 um 11:30 schrieb Ed Merks:
>

Re: [platform-dev] Where Does org.eclipse.license Come From?

[Ed Merks]

The org.eclipse.license question was kind of a stupid one I must admit.  
I'm well aware of the CBI repository, using it as the basis against 
which to validate license correctness, but I got completely sidetracked 
thinking this thing used by the platform must from some platform 
repository.  Silly me, and thanks for all the friendly help on that one!


__

As a follow up question.  Where do the platform's products come from?  I 
can't find any corresponding .product files.


The reason I ask is that the only valid licenses in the platform's p2 
repos are the ones that come from EMF and ECF.  All other licenses are 
corrupted in some way. This naturally leads to the assumption that this 
is something that Oomph can fix or address:


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

But it is not something I can fix.  It must be fixed at the source of 
the bad license.


I believe I tracked down the source of most of the bad licenses in the 
platform's repos, but not for the products; these have yet two more 
different variants of the SUA 2.0.


If someone could enlighten me on where the products come from, then I'll 
be able to make progress to eliminate at least this one source of 
end-user annoyance.


Regards,
Ed

On 24.08.2019 12:59, Vikas Chandra wrote:

>>if anyone uses other ways to solve such a puzzle. :)
How about searching for org.eclipse.license eclipse git repo
and then clicking on the 1st link?

Regards,
Vikas

- Original message -
From: Michael Keppler 
Sent by: platform-dev-boun...@eclipse.org
To: platform-dev@eclipse.org
Cc:
Subject: [EXTERNAL] Re: [platform-dev] Where Does
org.eclipse.license Come From?
Date: Sat, Aug 24, 2019 4:16 PM
Am 23.08.2019 um 11:30 schrieb Ed Merks:
> Does anyone know where I might find it?  I'd be ever so grateful
for a
> pointer!

Ed, you recently taught us to use the eclipse.org index for
finding the
sources of Java types. It can help with that question, too.

Using the "Discover provided capabilities" dialog from the Oomph
repository browser with the input "org.eclipse.license" we can
find jars
with the URL
http://download.eclipse.org/cbi/updates/license/2.0.2-SNAPSHOT and
similar, pointing us to the "cbi" project.

Given that information, we can ask gerrit to find
"org.eclipse.license"
in repositories related to "cbi":
https://git.eclipse.org/r/#/q/projects:cbi+org.eclipse.license. That
shows several related source changes.

Of course I would like to know if anyone uses other ways to solve
such a
puzzle. :)

Ciao, Michael

___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev



___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev