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

2024-02-23 Thread Jonah Graham via platform-dev
Hi Thomas,

Hannes is helping from the background while on holiday  :-)

The short answer is run mvn clean verify, building all the SWT jars with
ant is not supported anymore.

HTH
Jonah

~~~
Jonah Graham (he/him)
Kichwa Coders
www.kichwacoders.com


On Fri, 23 Feb 2024 at 03:17, Thomas Singer  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.
>
> --
> Best regards,
> Thomas Singer
>
>
> On Thu, 22-Feb-24 17:48, Jonah Graham wrote:
> > Hi Thomas,
> >
> > Please see
> >
> https://github.com/eclipse-platform/eclipse.platform.swt/issues/513#issuecomment-1899423505
> > for the answer.
> >
> > Hannes, who has done the great work on refactoring and improving the
> build
> > flows in this areas, asked if I can respond to your email because he
> > doesn't currently have full access to his email.
> >
> > Thanks
> > Jonah
> >
> >
> > ~~~
> > Jonah Graham (he/him)
> > Kichwa Coders
> > www.kichwacoders.com
> >
> >
> > On Thu, 22 Feb 2024 at 09:08, Thomas Singer via platform-dev <
> > platform-dev@eclipse.org> wrote:
> >
> >> Until now we were using ANT to build SWT jars from sources:
> >>
> >> 
> >>  
> >>  
> >>  
> >> 
> >>
> >> It looks like the binaries repository content somehow has been moved
> >> into the main SWT sources repository, but also the structure changed. Is
> >> there some documentation how to build it now using ANT?
> >>
> >> Thanks in advance.
> >> Tom
> >> ___
> >> 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 to build SWT jars from sources?

2024-02-22 Thread Jonah Graham via platform-dev
Hi Thomas,

Please see
https://github.com/eclipse-platform/eclipse.platform.swt/issues/513#issuecomment-1899423505
for the answer.

Hannes, who has done the great work on refactoring and improving the build
flows in this areas, asked if I can respond to your email because he
doesn't currently have full access to his email.

Thanks
Jonah


~~~
Jonah Graham (he/him)
Kichwa Coders
www.kichwacoders.com


On Thu, 22 Feb 2024 at 09:08, Thomas Singer via platform-dev <
platform-dev@eclipse.org> wrote:

> Until now we were using ANT to build SWT jars from sources:
>
> 
> 
> 
> 
> 
>
> It looks like the binaries repository content somehow has been moved
> into the main SWT sources repository, but also the structure changed. Is
> there some documentation how to build it now using ANT?
>
> Thanks in advance.
> Tom
> ___
> 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 do I build eclipse with my changes?

2023-08-25 Thread Jonah Graham via platform-dev
Hi Christopher,

Building Eclipse is a big task (long running + perhaps some non-trivial
prerequisites) - perhaps you can explain what parts of Eclipse you are
trying to build. Once your PR gets merged then normal build processes will
do it. While developing I recommend doing everything in the Eclipse
development environment.

> Christoph Läubrich explained on Jul 7, 2023

Are you referring to this comment
<https://github.com/eclipse-platform/eclipse.platform.debug/pull/112#issuecomment-1626869075>?
In it the discussion seems to address the issue that you should add to the
target platform. Alternatively you can simply open additional projects in
your workspace covering all the interdependent projects you are working on.
e.g. provision an Eclipse SDK development environment and then add the
projects from your company into that workspace.

Hope that helped - and if not, please ask followup questions.
Jonah



~~~
Jonah Graham (he/him)
Kichwa Coders
www.kichwacoders.com


On Fri, 25 Aug 2023 at 15:05, Christopher Genly via platform-dev <
platform-dev@eclipse.org> wrote:

> I have the eclipse development environment produced by oomph.   As
> described here: https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning
> I can launch a new eclipse from the development eclipse, but there are
> problems installing software into the development eclipse.  Christoph
> Läubrich explained on Jul 7, 2023 that this is a known problem in
> eclipse.platform.debug.
> So, instead, I'd like to build eclipse with my changes, and then run
> that.  How do I do that?
>
> Thanks
> ___
> 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] What does this mean: The nested job 'message-check' is requesting 'pull-requests: read', but is only allowed 'pull-requests: none'?

2023-08-25 Thread Jonah Graham via platform-dev
Hi Christopher,

It looks like the workflow (
https://github.com/chgenly/eclipse.platform/blob/master/.github/workflows/ci.yml)
has some assumptions that the pushes to master are on Eclipse's own
version, rather than your fork.

You can simply ignore the error, but if you can reproduce the error, then
filing a bug on
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues
would be helpful!

When you create the Pull Request back to Eclipse the workflows should run
as expected.

Jonah

~~~
Jonah Graham (he/him)
Kichwa Coders
www.kichwacoders.com


On Fri, 25 Aug 2023 at 14:58, Christopher Genly via platform-dev <
platform-dev@eclipse.org> wrote:

> I just pushed a change to my branch.  This error is reported:
>
>
> <https://github.com/chgenly/eclipse.platform/actions/runs/5979137511/workflow>
> *Invalid workflow file: *.github/workflows/ci.yml#L16
> <https://github.com/chgenly/eclipse.platform/actions/runs/5979137511/workflow>
> The workflow is not valid. .github/workflows/ci.yml (Line: 16, Col: 3):
> Error calling workflow
> 'eclipse-platform/eclipse.platform.releng.aggregator/.github/workflows/checkMergeCommits.yml@master'.
> The nested job 'message-check' is requesting 'pull-requests: read', but is
> only allowed 'pull-requests: none'.
>
> This is from:
>
> https://github.com/chgenly/eclipse.platform/actions/runs/5979137511
>
> What does it mean and how do I fix it?
>
> This is where my fork is:
>
> https://github.com/chgenly/eclipse.platform
>
> ___
> 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] [jdt-dev] Immediate feedback on ecj changes for jdt and platform build

2023-07-13 Thread Jonah Graham via platform-dev
Hi Andrey,

That is a great change in process. Well done on pushing that through the
pipe as I imagine it was quite a lot of interconnected work (certainly
looks that way based on how many comments are in the issues!)

Jonah

~~~
Jonah Graham (he/him)
Kichwa Coders
www.kichwacoders.com


On Thu, 13 Jul 2023 at 11:33, Andrey Loskutov via jdt-dev <
jdt-...@eclipse.org> wrote:

> Hi all,
>
> with [1] we have now immediate feedback loop on ecj compiler changes (in
> org.eclipse.jdt.core.compiler.batch [2]).
> Before changes in [1] we only (manually) updated compiler after every
> milestone/release build.
>
> What does it mean now: on any compiler code change the ecj compiler is
> re-built from sources and used as compiler for the rest of the build.
>
> This has following immediate consequences:
>
> 1) If we push PR to jdt.core github repo, we build ecj in Jenkins from PR
> commit first and use that ecj to build the rest of JDT code for this PR. If
> we break compiler (without noticing that in tests), Jenkins may fail
> immediately just by compiling JDT code.
> 2) If we merge commits to master branch of jdt.core github repo, following
> platform aggregator builds in Jenkins & next nightly platform SDK build
> will use JDT head commit to build ecj and use that ecj to build the rest of
> the platform SDK code.
> 3) If we change the way how ecj generates bytecode (like in [3]), next SDK
> build might be declared "unstable" (because build would produce different
> binaries for bundles with no changes in source code). In such case the
> affected bundles source code need to be "touched" to get "stable" SDK build
> (assuming ecj produces correct code). Should it be the worst case and ecj
> would produce wrong bytecode, we have either to fix compiler for the next
> SDK build or just revert offending compiler commit. I hope this shouldn't
> happen often, but it is better *we* detect bad change and not downstream
> consumers.
>
> With the points above we hope to get faster feedback on ecj compiler
> changes.
>
> [1]
> https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/1203
> [2]
> https://github.com/eclipse-jdt/eclipse.jdt.core/tree/master/org.eclipse.jdt.core.compiler.batch
> [3] https://github.com/eclipse-jdt/eclipse.jdt.core/pull/1139
>
> --
> Kind regards,
> Andrey Loskutov
>
> Спасение утопающих - дело рук самих утопающих
>
> https://www.eclipse.org/user/aloskutov
> ___
> jdt-dev mailing list
> jdt-...@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jdt-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 Eclipse News into make Eclipse Website

2023-07-05 Thread Jonah Graham
Hi folks,

It seems that the new eclipse.dev domain name and redirects has taken out
Eclipse News.

Any thoughts on merging
https://github.com/eclipse-platform/www.eclipse.org-eclipse-news into
https://github.com/eclipse-platform/www.eclipse.org-eclipse?

I know there have been lots of git repo merging recently which I am
grateful for, but I haven't paid much attention to the process.

Any volunteers to merge these repos, or any objection to doing this merge?

Jonah


~~~
Jonah Graham (he/him)
Kichwa Coders
www.kichwacoders.com


-- Forwarded message -
From: Matt Ward (@mward) 
Date: Wed, 5 Jul 2023 at 10:42
Subject: Re: Help Desk | broken redirection to eclipse.dev (#3358)
To: 


Matt Ward <https://gitlab.eclipse.org/mward> commented
<https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/3358#note_1168040>:


TL;DR: merge the content of
https://github.com/eclipse-platform/www.eclipse.org-eclipse-news into
https://github.com/eclipse-platform/www.eclipse.org-eclipse into a new
/news directory and this should fix itself.

The issue here is that for reasons of antiquity the Eclipse platform
project ended up with 2 sites: e.o/eclipse and e.o/eclipse/news , with the
news 'site' being a hack to allow all committers on the various platform
related projects to contribute.

While that has worked the newer tooling behind eclipse.dev is driven by the
PMI which expects a single 'site' per project.

—
View it on GitLab
<https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/3358#note_1168040>.

You're receiving this email because of your account on gitlab.eclipse.org.
Unsubscribe
<https://gitlab.eclipse.org/-/sent_notifications/6ef5461c2b094e7c66c208ce31a2f49c/unsubscribe>
from this thread · Manage all notifications
<https://gitlab.eclipse.org/-/profile/notifications> · Help
<https://gitlab.eclipse.org/help>
___
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 Accessibility Documentation

2023-04-26 Thread Jonah Graham
Thanks for persisting and finding the root cause.

Jonah
~~~
Jonah Graham (he/him)
Kichwa Coders
www.kichwacoders.com


On Wed, 26 Apr 2023 at 07:50, Thomas Singer  wrote:

> Hi Jonah,
>
> This snippet is (at least on Windows 11 where I've tried) broken because
> of following bug:
>
> <https://github.com/eclipse-platform/eclipse.platform.swt/issues/645>
>
> --
> Best regards,
> Thomas Singer
>
>
> On 29-Mar-23 15:54, Jonah Graham wrote:
> > Have a look at this snippet which is titled "Give accessible names to a
> > tree and its tree items"
> >
> >
> https://github.com/eclipse-platform/eclipse.platform.swt/blob/master/examples/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet291.java
> >
> > Jonah
> > ~~~
> > Jonah Graham (he/him)
> > Kichwa Coders
> > www.kichwacoders.com
> >
> >
> > On Wed, 29 Mar 2023 at 09:32, Thomas Singer  wrote:
> >
> >> Let's start with an example:
> >>
> >> Our tree controls are owner-drawn. For some reason I don't remember, the
> >> TreeItem's text is set to " ". How can I change the spoken text for
> >> Narrator if, for example, the selection is changed? Thanks in advance.
> >>
> >> --
> >> Best regards,
> >> Thomas Singer
> >> ___
> >> 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] SWT Accessibility Documentation

2023-03-29 Thread Jonah Graham
Have a look at this snippet which is titled "Give accessible names to a
tree and its tree items"

https://github.com/eclipse-platform/eclipse.platform.swt/blob/master/examples/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet291.java

Jonah
~~~
Jonah Graham (he/him)
Kichwa Coders
www.kichwacoders.com


On Wed, 29 Mar 2023 at 09:32, Thomas Singer  wrote:

> Let's start with an example:
>
> Our tree controls are owner-drawn. For some reason I don't remember, the
> TreeItem's text is set to " ". How can I change the spoken text for
> Narrator if, for example, the selection is changed? Thanks in advance.
>
> --
> Best regards,
> Thomas Singer
> ___
> 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 wiki pages migrated to github

2023-02-28 Thread Jonah Graham
Thanks Simeon for doing the migrations.

PS Some of the links in your email don't go to where the display is
showing, e.g. the swt wiki link actually goes to JDT wiki.


Jonah
~~~
Jonah Graham (he/him)
Kichwa Coders
www.kichwacoders.com


On Tue, 28 Feb 2023 at 08:37, S A  wrote:

> Hi all,
> The eclipse.org wiki will be shutdown in future (see
> https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/681), so I've
> migrated SWT wiki pages from https://wiki.eclipse.org/
> <https://wiki.eclipse.org/JDT> to:
> https://github.com/eclipse-platform/eclipse.platform.swt/wiki
> <https://github.com/eclipse-jdt/eclipse.jdt.core/wiki>
>
> Note that I'm not too familiar with the SWT wiki pages, so I migrated what
> SWT related topics I could find. If there is an SWT category in the Eclipse
> wiki, I couldn't find it.
> For big changes to the wiki, the git repo of the wiki is:
> https://github.com/eclipse-platform/eclipse.platform.swt.wiki.git
> If you see some missing content that was not migrated (or any other
> problem), please comment on
> https://github.com/eclipse-platform/eclipse.platform.swt/issues/559 or
> fix the problem yourself. Links between wiki pages in particular can be
> broken, since I had to adjust links manually during the suggested migration
> process. Images likewise need extra work, I might have overlooked a missing
> image here or there.
>
> Best regards,
> Simeon
> ___
> 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] Allowing bundles to target Java 17 for 2022-06 release

2023-01-24 Thread Jonah Graham
+1 for moving to Java 17 for BREE.

IIRC on past BREE upgrades various sub-parts of Platform held back on older
versions. Is the proposal to remove those special cases for the move to
Java 17?

Jonah

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


On Tue, 24 Jan 2023 at 14:12, Aleksandar Kurtakov 
wrote:

> Hey everyone,
> Our test dependencies (e.g. reddeer), our build tool (tycho) and etc.
> already require Java 17 thus the whole releng is using Java 17 now with no
> dependency on Java 11 anymore.
> Due to that there are already test bundles that target Java 17 and use
> Java 17 language features. Feel free to do so even more.
> As automated Java 11 testing is impossible nowadays I think it's time for
> us to allow bundles to go to Java 17 BREE after March release.
> I welcome constructive discussion which should include how and who is
> going to take care of Java 11 testing/verification if there is disagreement
> for this move.
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
> ___
> 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] Fwd: [eclipse-ide-wg] Eclipse IDE Steering Committee Working Group Election - Committer Member Seat Nomination Period Extended

2022-09-20 Thread Jonah Graham
Hi folks,

Please see below. I forwarded the last email about this right before the
deadline, fortunately the deadline has been extended now.

Please submit your nomination, including self-nomination, to the
eclipse-ide...@eclipse.org mailing list
<https://accounts.eclipse.org/mailing-list/eclipse-ide-wg>. Or feel free to
drop me a line if you want to know more about what the role entails (short
summary is 60 minute meeting every other week).

Thanks
Jonah


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


-- Forwarded message -
From: Zahra Fazli 
Date: Tue, 20 Sept 2022 at 11:34
Subject: [eclipse-ide-wg] Eclipse IDE Steering Committee Working Group
Election - Committer Member Seat Nomination Period Extended
To: Discussions on Eclipse IDE Working Group 


*Dear All, *



* We are writing to inform you that we are extending the nomination period
for the Committer Member representative for the Steering Committee.  The
extended period will run till September 28, 2022 (EOB).  By way of
reminder, the commitment involved is to participate in a bi-weekly call and
to participate in discussions on the committee’s mailing list(s).   We are
also pleased to announce Martin Lippert (VMware Inc.) has accepted the
nomination to represent the Supporter Members at the Steering Committee
level.  As Martin's nomination was uncontested, there is no requirement to
hold an election. Thank you Martin for your continuing support!Best
Regards, Zahra *-- * Zahra Fazli*

*Membership Process Lead | **Eclipse Foundation*

*Eclipse Foundation* <https://www.eclipse.org/>*: The Community for Open
Innovation and Collaboration*
___
eclipse-ide-wg mailing list
eclipse-ide...@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipse-ide-wg
___
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] Better spellings support for code editors

2022-06-27 Thread Jonah Graham
Hi Gayan,

I am not sure if anyone has a better answer - but certainly improving spell
checking in Eclipse would be nice. IIRC the current spell checking is
rather editor specific, which is why Eclipse CDT has its own fork of the
JDT one. I would be happy to get rid of the CDT specific code if possible,
especially as no one has been keeping it up to date.

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


On Sat, 25 Jun 2022 at 14:46, Gayan Perera  wrote:

> Hi All,
>
> i recently came across a vscode Code spelling plugin which support most of
> the language constructs in language such as Java and Typescript from my
> usage.
>
> When i looked into the source code, I found it has been implemented as a
> LS. So i was wondering to implement a plugin for this with a language
> client to integrate into Eclipse. I have raised few questions to the author
> about this usage here
> https://github.com/streetsidesoftware/vscode-spell-checker/discussions/2040
>
> Please let me know what you all think as well.
>
> Best regards,
> Gayan.
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev


Re: [platform-dev] Cannot push to github g...@github.com:eclipse-platform/eclipse.platform.ui.git

2022-05-18 Thread Jonah Graham
Hi Marcus,

One step you need to do is connect your Eclipse and GitHub accounts - see
this email I wrote a while ago for advice:
https://www.eclipse.org/lists/eclipse-dev/msg11927.html

Jonah


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


On Wed, 18 May 2022 at 10:49, Lars Vogel  wrote:

> Marcus, as you are a committer for platform you should be able to assign
> reviewers to your PRs
>
> On Wed, May 18, 2022 at 2:54 PM Hoepfner, Marcus via platform-dev <
> platform-dev@eclipse.org> wrote:
>
>> I don’t even see proposals for reviewers.
>>
>>
>>
>> *From: *platform-dev  on behalf of Ed
>> Merks 
>> *Date: *Wednesday, 18. May 2022 at 14:45
>> *To: *platform-dev@eclipse.org 
>> *Subject: *Re: [platform-dev] Cannot push to github g...@github.com:
>> eclipse-platform/eclipse.platform.ui.git
>>
>> 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
>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Feclipse-platform%2Feclipse.platform.ui=05%7C01%7Cmarcus.hoepfner%40sap.com%7C7e1e99d5203c40f186b208da38cc546b%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637884747497888699%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=uQW5c4UUo%2FZnRyBsRkTKhmmnxGUyuzgNPr0IqxSRalE%3D=0>
>> .
>>
>> 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%7C7e1e99d5203c40f186b208da38cc546b%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637884747497888699%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=GqGNUNRt1V6sZsG9CJo0wis4SB%2FtNcgqBvQwdqtGiy8%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%7C7e1e99d5203c40f186b208da38cc546b%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637884747497888699%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=omd4i5iBbXtJxaAvbt8PetFOglF3H4ddbJBz%2B4hZufg%3D=0>
>> does not really say a lot and points to a wiki page which is talking about
>> gerrit.
>>
>>
&

Re: [platform-dev] New Eclipse IDE New and Noteworthy page

2022-05-05 Thread Jonah Graham
Hi Lars,

Thanks for the positive feedback!

Lakshmi and Vikas have for the past few years initiated the collecting of
highlights for the landing page (see for example
https://www.eclipse.org/lists/ide-dev/msg02055.html) and that is passed to
webdev team to turn into the nice page.

A lot of stuff was done for 2022-03 that improved "our" lives
(Ecipse plug-in developers) - hopefully you can identify some general Java
improvements to highlight for 2022-06. Look for the callout on ide-dev in
the coming weeks.

Thanks!
Jonah


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


On Thu, 5 May 2022 at 12:25, Lars Vogel  wrote:

> Hi Jonah,
>
> Looks great, thanks.
>
> Improvement suggestion: The highlight sections on the main page seem a bit
> PDE heavy which is not relevant for the regular Java developer. Maybe add
> more Java related highlights in the future.
>
> Best regards, Lars
>
> Jonah Graham  schrieb am Do., 5. Mai 2022, 16:31:
>
>> Hello Platform-devs,
>>
>> In case you hadn't seen it yet, Eclipse IDE has a new website and content
>> is being migrated to it from eclipse.org. The main thing is
>> https://eclipse.org/eclipseide is now on https://eclipseide.org/release/
>>
>> There will be more changes to that website as the Eclipse IDE WG cleans
>> up more things too with the heavy lifting being done by the EF webdev team
>>
>> One of the items is the Eclipse IDE's N page is now live -
>> https://eclipseide.org/release/noteworthy/
>>
>> A couple of the key improvements to the page:
>> -  "New features for Java developers" (for example) is listed directly on
>> the page. In the past the N page only included a link to the top level
>> Eclipse Project, now the N page also has links to the Eclipse Project's
>> sub-N pages. This resolves for me a long held issue that the N for Java
>> developers was hidden away a bit too much.
>> - All the older N pages, back to 2018-12 are now included too under a
>> drop down menu under the current release's N content.
>> - The Eclipse Platform release notes are now linked directly from the N
>> page too.
>> - There is a place to put "urgent" release notes like the warning for
>> Windows 10 users directly on that page.
>>
>> Enjoy and I hope you all enjoy this change and appreciate the Eclipse
>> webdev team for making it happen!
>> Jonah
>>
>> ~~~
>> Jonah Graham
>> Kichwa Coders
>> www.kichwacoders.com
>>
>>
>> -- Forwarded message -
>> From: Zhou Fang (@zhoufang) 
>> Date: Thu, 5 May 2022 at 10:11
>> Subject: Re: eclipseide.org | Migrate Eclipse IDE landing pages to
>> ide-wg website (#10)
>> To: 
>>
>>
>> Zhou Fang <https://gitlab.eclipse.org/zhoufang> commented on a discussion
>> <https://gitlab.eclipse.org/eclipse-wg/ide-wg/eclipseide.org/-/issues/10#note_722491>:
>>
>>
>> The change is now live!
>>
>> https://eclipseide.org/release/noteworthy/
>>
>> We can now work on updating the link for “New and Noteworthy” on
>> https://www.eclipse.org/downloads/packages/, which will from
>> https://www.eclipse.org/eclipse/news/[release verison]/ to
>> https://eclipseide.org/release/noteworthy/
>>
>> —
>> View it on GitLab
>> <https://gitlab.eclipse.org/eclipse-wg/ide-wg/eclipseide.org/-/issues/10#note_722491>.
>>
>> You're receiving this email because of your account on gitlab.eclipse.org.
>> If you'd like to receive fewer emails, you can unsubscribe
>> <https://gitlab.eclipse.org/-/sent_notifications/0c900844ab370bc9b767d718db1d28d0/unsubscribe>
>> from this thread or adjust your notification settings.
>>
>> Copyright © Eclipse Foundation, Inc. All Rights Reserved. Privacy
>> Policy <https://www.eclipse.org/legal/privacy.php> | Terms of Use
>> <https://www.eclipse.org/legal/termsofuse.php> | Copyright Agent
>> <https://www.eclipse.org/legal/copyright.php>
>> ___
>> 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] New Eclipse IDE New and Noteworthy page

2022-05-05 Thread Jonah Graham
Hello Platform-devs,

In case you hadn't seen it yet, Eclipse IDE has a new website and content
is being migrated to it from eclipse.org. The main thing is
https://eclipse.org/eclipseide is now on https://eclipseide.org/release/

There will be more changes to that website as the Eclipse IDE WG cleans up
more things too with the heavy lifting being done by the EF webdev team

One of the items is the Eclipse IDE's N page is now live -
https://eclipseide.org/release/noteworthy/

A couple of the key improvements to the page:
-  "New features for Java developers" (for example) is listed directly on
the page. In the past the N page only included a link to the top level
Eclipse Project, now the N page also has links to the Eclipse Project's
sub-N pages. This resolves for me a long held issue that the N for Java
developers was hidden away a bit too much.
- All the older N pages, back to 2018-12 are now included too under a
drop down menu under the current release's N content.
- The Eclipse Platform release notes are now linked directly from the N
page too.
- There is a place to put "urgent" release notes like the warning for
Windows 10 users directly on that page.

Enjoy and I hope you all enjoy this change and appreciate the Eclipse
webdev team for making it happen!
Jonah

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


-- Forwarded message -
From: Zhou Fang (@zhoufang) 
Date: Thu, 5 May 2022 at 10:11
Subject: Re: eclipseide.org | Migrate Eclipse IDE landing pages to ide-wg
website (#10)
To: 


Zhou Fang <https://gitlab.eclipse.org/zhoufang> commented on a discussion
<https://gitlab.eclipse.org/eclipse-wg/ide-wg/eclipseide.org/-/issues/10#note_722491>:


The change is now live!

https://eclipseide.org/release/noteworthy/

We can now work on updating the link for “New and Noteworthy” on
https://www.eclipse.org/downloads/packages/, which will from
https://www.eclipse.org/eclipse/news/[release verison]/ to
https://eclipseide.org/release/noteworthy/

—
View it on GitLab
<https://gitlab.eclipse.org/eclipse-wg/ide-wg/eclipseide.org/-/issues/10#note_722491>.

You're receiving this email because of your account on gitlab.eclipse.org.
If you'd like to receive fewer emails, you can unsubscribe
<https://gitlab.eclipse.org/-/sent_notifications/0c900844ab370bc9b767d718db1d28d0/unsubscribe>
from this thread or adjust your notification settings.

Copyright © Eclipse Foundation, Inc. All Rights Reserved. Privacy Policy
<https://www.eclipse.org/legal/privacy.php> | Terms of Use
<https://www.eclipse.org/legal/termsofuse.php> | Copyright Agent
<https://www.eclipse.org/legal/copyright.php>
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev


[platform-dev] Fwd: Help Desk | A bunch of Jenkins instances are down (#1184)

2022-04-14 Thread Jonah Graham
Hi Platform folk,

A number of CI instances used by platform and related projects are
currently down. I have filed the below ticket already.

If there was a scheduled outage announcement I missed, kindly let me know!

Jonah

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


-- Forwarded message -
From: Jonah Graham (@jograham) 
Date: Thu, 14 Apr 2022 at 13:11
Subject: Help Desk | A bunch of Jenkins instances are down (#1184)
To: 


Jonah Graham <https://gitlab.eclipse.org/jograham> created an issue: #1184
<https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1184>
<#m_-653878710967807976_summary>Summary

https://ci.eclipse.org/simrel/ and others seem down. I hope I haven't
missed some announcement of a planned outage, nothing listed on
https://www.eclipsestatus.io/

cc: @emerks <https://gitlab.eclipse.org/emerks>
<#m_-653878710967807976_relevant-logs-andor-screenshots>Relevant logs
and/or screenshots

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

[image: image]
<https://gitlab.eclipse.org/eclipsefdn/helpdesk/uploads/eb1501207b51cfdda2dd231f2bcc6660/image.png>

A number of other instances down too:

[image: image]
<https://gitlab.eclipse.org/eclipsefdn/helpdesk/uploads/0af4a25176e023270d2e391c4c900034/image.png>

—
View it on GitLab
<https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1184>.
You're receiving this email because of your activity on gitlab.eclipse.org.
If you'd like to receive fewer emails, you can unsubscribe
<https://gitlab.eclipse.org/-/sent_notifications/efb681fa6dc20f1002f51bd44c416ede/unsubscribe>
from this thread or adjust your notification settings.

Copyright © Eclipse Foundation, Inc. All Rights Reserved. Privacy Policy
<https://www.eclipse.org/legal/privacy.php> | Terms of Use
<https://www.eclipse.org/legal/termsofuse.php> | Copyright Agent
<https://www.eclipse.org/legal/copyright.php>
___
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] Turn on protected branches?

2022-03-31 Thread Jonah Graham
> Of course rebasing a green PR may lead to a red main branch in bad
circumstances

At the moment the Platform CI rebuilds every open PR against current master
on every master commit. That build is done with a merge commit of PR and
master, so even the 1 in 1000 cases you are seeing probably goes away too.

The above may change once there start being a lot of open PRs and the CI is
forever rebuilding PRs.

For example
https://github.com/eclipse-platform/eclipse.platform.resources/pull/4 has
been rebuilt 14 times
https://ci.eclipse.org/platform/job/eclipse.platform.resources/job/PR-4/
even though there has only been a single commit on that PR.

HTH in the decision making.

Jonah

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


On Thu, 31 Mar 2022 at 12:34, Michael Keppler 
wrote:

> Am 29.03.2022 um 21:38 schrieb Gayan Perera:
> >
> > It would be really good if we can enforce ff-merge only to avoid hard
> > to trace history graphs.
> >
> That's one of the things that makes one-time-contributors abandon their
> change after initial submission quite often, to my experience. They
> can't do anything than rebasing, and rebasing again, and so on, every
> time that a project committer submitted one of their own changes first.
> And every time the hope on someone really merging the change goes down a
> bit more.
>
> Just get used to rebasing as default merge strategy instead. That also
> gives a linear history, doesn't require contributors to repeatedly do
> work that doesn't create value and has in fact been already used on the
> eclipse gerrit by some projects without any issues.
>
> Of course rebasing a green PR may lead to a red main branch in bad
> circumstances, so chances of breaking the main branch are a bit higher
> than with ff only. In our company we use rebase on merge and we see it
> between 1 and 2 times per 1 commits, that the target branch is
> broken because of this (where "ff only" would have detected a broken
> build). I would claim that there are _way_ more broken builds because of
> other uncontrolled changes (some permission changed on some eclipse
> server, an upgrade of some tool that everyone thought is unrelated,
> ...), so that this tiny additional chance of a red main branch doesn't
> really matter. But it improves the ability to just merge _everything_
> that has been reviewed and tested, instead of exactly 1 out of the same
> set of changes, and then someone having to rebase and to wait 20 minutes
> for building until the next 1 change can be merged.
>
> Ciao, Michael
>
> ___
> 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] Customizing Github Organization Pages

2022-03-31 Thread Jonah Graham
You can also ask Webmaster for temporary admin privileges so that you can
iterate faster.

Jonah

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


On Thu, 31 Mar 2022 at 10:15, Mickael Istria  wrote:

> Sorry, I missed the line between the 2 images, where you already
> explicitly answer my question before I even asked this. "we must open a
> helpdesk issue to update that information."; so OK, it's helpdesk only, too
> bad but we'll use it anyway.
>
> Before we open a ticket, we need to agree of how we want ot set those
> fields, here is a suggestion
> * Organization display name: Eclipse Platform
> * Email: platform-dev@eclipse.org
> * description: "Eclipse Platform is a framework for rich client
> applications in Java, powering the Eclipse IDE and other toolsets"
> * URL: https://www.eclipse.org/eclipse/ or
> https://projects.eclipse.org/projects/eclipse.platform ?
> * billing: webmas...@eclipse.org
> ?
>
> ___
> 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] Turn on protected branches?

2022-03-29 Thread Jonah Graham
There seems to be broad agreement, so I have gone ahead and raised
https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1088 on the HelpDesk

There are a number of other branch protections we can put in place, e.g.
"Require branches to be up to date before merging" and "Require linear
history" which together give you something equivalent to the
fast-forward-only strategy in Gerrit. But we can evolve over time.

Jonah

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


On Fri, 25 Mar 2022 at 06:47, Jonah Graham  wrote:

>
>
> On Fri., Mar. 25, 2022, 05:32 Mickael Istria,  wrote:
>
>>
>>
>> On Fri, Mar 25, 2022 at 9:46 AM  wrote:
>>
>>> Well, if direct pushing to the repository is disallowed it should be
>>> disabled. I accidently made my first error with not creating a PR. And got
>>> nor error message. Highly confusing.
>>>
>>
>> Committers still and forever will have direct access to the Git repo.
>> Having push capabilities to project repo is the very essence of being a
>> committer over being a contributor.
>>
>
> *Direct* push to branch is not a committer privilege, but a project
> choice. Protecting branches, even from committers, is a good idea. Many
> Gerrit projects disabled direct push (ie you had to create a gerrit review
> first). Github branches can (and I strongly recommend should) be protected
> to, at least to require a PR first.
>
> I assume these repos have force push disabled too ad I believe webmaster
> does that by default, but if not that should be enabled too.
>
> Jonah
>
>
>
>
>>
>>>
>>>
___
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.text migrated to GitHub

2022-03-26 Thread Jonah Graham
On Sat., Mar. 26, 2022, 06:25 Wim Jongman,  wrote:

> The transition team is making great progress.
>
> On behalf of everyone:  Thank you all!
>


I second that!

Jonah


> Cheers, Wim
>
> On Fri, 25 Mar 2022 at 16:16, Mickael Istria  wrote:
>
>> eclipse.platform.text Git repository is now moved to GitHub:
>> https://github.com/eclipse-platform/eclipse.platform.text
>> 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.text.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, 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] Turn on protected branches?

2022-03-25 Thread Jonah Graham
On Fri., Mar. 25, 2022, 05:32 Mickael Istria,  wrote:

>
>
> On Fri, Mar 25, 2022 at 9:46 AM  wrote:
>
>> Well, if direct pushing to the repository is disallowed it should be
>> disabled. I accidently made my first error with not creating a PR. And got
>> nor error message. Highly confusing.
>>
>
> Committers still and forever will have direct access to the Git repo.
> Having push capabilities to project repo is the very essence of being a
> committer over being a contributor.
>

*Direct* push to branch is not a committer privilege, but a project choice.
Protecting branches, even from committers, is a good idea. Many Gerrit
projects disabled direct push (ie you had to create a gerrit review first).
Github branches can (and I strongly recommend should) be protected to, at
least to require a PR first.

I assume these repos have force push disabled too ad I believe webmaster
does that by default, but if not that should be enabled too.

Jonah




>
>>
>>
___
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] Github workflow

2022-03-24 Thread Jonah Graham
Andrey,

I am pretty sure all of this can be done with github, but requires writing
bots to handle it.

For example, we could make it so only bot has write access under normal
circumstances and instead of pressing "merge" in github ui a committer adds
an /approve comment. That bot can do things like squash and merge, and add
extra headers to the commit message like Gerrit does today. (a bot like
this often can be configured to wait for tests to complete and then do the
merge automatically)

There may be such bot already that can be reused. Kubernates has a really
nice and complex bot that fixes many of the issues with github's default
flow for their use.

The k8s PR document is quite complete for their flow
https://github.com/kubernetes/community/blob/master/contributors/guide/pull-requests.md


Here is the commands to the bot https://prow.k8s.io/command-help

While I believe it is true that committers/contributors can "just do it"
with github, many large and successful projects on github add significantly
to the default github experience.

Try searching for "github merge bot" to see how many other people have
attacked this problem.

I am glad to see such a discussion happening here. There is indeed no one
"correct" way to use Github and having a contributor guide that addresses
these and other questions is good for the community.

Jonah

On Thu., Mar. 24, 2022, 12:35 Christoph Läubrich, 
wrote:

> If you don't like to suggest to Egit to add some magic, you can suggest
> to Github to add a similar header:
>
> https://github.community/
>
> Am 24.03.22 um 17:30 schrieb Andrey Loskutov:
> >> Gesendet: Donnerstag, 24. März 2022 um 17:03 Uhr
> >> Von: "Christoph Läubrich" 
> >> An: platform-dev@eclipse.org
> >> Betreff: Re: [platform-dev] Github workflow
> >>
> >> Sorry for confusion then I probably don't get it. What has Egit/Eclipse
> >> Ui to do with gerrit?
> >
> > Nothing.
> > I use Egit to read the history.
> > Because I work with my code from within my IDE, not with github.
> > Gerrit writes url of the PR to the commit header.
> > I can see this url in egit on every commit.
> > I can click it and go directly to the PR in the browser.
> >
> >> If I check with with my eclipse SDK things like "Bug " are not
> >> linked even though they are on git-eclipse or do you mean
> >>
> >> Reviewed-on:?
> >>
> >> in the commit message if it was merged through gerrit?
> >
> > Exact, see
> https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=43187fa1ce25eb04c7fe417ffd3e1f7bb025577f
> for example
> >
> >> Github provides similar and as EGit already knows how to handle Github
> >> PRs it should be possible to show such a link, the git magics is
> >> described here:
> >>
> >> https://stackoverflow.com/a/17819027/9503281
> >
> > No, that's completely different story.
> > It is not in the commit, it adds a lot of "dead" remote branches to your
> history, making it unusable.
> > See the config I've used and result I've got.
> > So in short, there is no way to get same user experience with github
> right now.
> > And I for sure don't want this dead pull branches to show up in my
> history view.
> >
> >> So your best bet would be to ask Egit to add support for this (probably
> >> there is already support for this but I have never used/found that).
> >
> > There is nothing, I'm using latest nightly.
> >
> > Kind regards,
> > Andrey Loskutov
> >
> > Спасение утопающих - дело рук самих утопающих
> >
> > https://www.eclipse.org/user/aloskutov
> >
> >
> > ___
> > platform-dev mailing list
> > platform-dev@eclipse.org
> > To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev


Re: [platform-dev] triggerWinGerrit

2022-03-21 Thread Jonah Graham
On Mon, 21 Mar 2022 at 03:47, Aleksandar Kurtakov 
wrote:

>
>
> On Mon, Mar 21, 2022 at 9:34 AM Christoph Läubrich 
> wrote:
>
>>  > Is it possible / permissible to allow all platform projects
>>  > to use such a mechanism?
>>
>> If the project is already migrated to github you can configure an
>> (additional) verification action using Github actions:
>>
>>
>> https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources
>
>
> As announced (https://www.eclipse.org/lists/platform-dev/msg03429.html)
> SWT repos are scheduled to be moved next Monday - after that people can
> experiment with GH actions .
>
>


Thanks all for the replies. Yes, it would be best to simply reevaluate this
in the coming weeks once SWT is moved.

Jonah


>
>>
>> Am 20.03.22 um 16:57 schrieb Jonah Graham:
>> > Hi folks,
>> >
>> > I recently came across triggerWinGerrit  (thanks Sarika).
>> >
>> > I can see https://ci.eclipse.org/releng/job/jdt-debug-win-gerrit-test/
>> > <https://ci.eclipse.org/releng/job/jdt-debug-win-gerrit-test/> is
>> > configured for triggerWinGerrit - but I can't find any mention of it
>> > elsewhere.
>> >
>> > Is it possible / permissible to allow all platform projects to use such
>> > a mechanism? For example SWT would really benefit because of all the
>> > platform specific code. I really would like
>> > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/192078
>> > <https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/192078>
>> to
>> > run :-)
>> >
>> > Jonah
>> >
>> >
>> > ~~~
>> > Jonah Graham
>> > Kichwa Coders
>> > www.kichwacoders.com <http://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
>>
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
> ___
> 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] triggerWinGerrit

2022-03-20 Thread Jonah Graham
Hi folks,

I recently came across  triggerWinGerrit  (thanks Sarika).

I can see https://ci.eclipse.org/releng/job/jdt-debug-win-gerrit-test/ is
configured for triggerWinGerrit - but I can't find any mention of it
elsewhere.

Is it possible / permissible to allow all platform projects to use such a
mechanism? For example SWT would really benefit because of all the platform
specific code. I really would like
https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/192078 to run
:-)

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


Re: [platform-dev] how long will repos remain on gerrit (read-only?)

2022-03-16 Thread Jonah Graham
Thanks. I guess I'll have to prioritize saving all that random work
somewhere for when (if) I get around to migrating it to PRs

(sorry for so much WIP - I have a lot more ideas than time to follow up on
all of them)

On Wed., Mar. 16, 2022, 17:32 Aleksandar Kurtakov, 
wrote:

>
>
> On Wed, Mar 16, 2022 at 11:15 PM Jonah Graham 
> wrote:
>
>> Hi folks,
>>
>> How long will the gerrits for platform projects moving to GitHub be left
>> around? (Sorry if this is asked and answered somewhere else)
>>
>
> We will not let them stay after moving. Process is like
> https://git.eclipse.org/r/c/platform/eclipse.platform.team/+/185449 where
> it's abandoned with instruction how to move it to PR. As the repo becomes
> read only there is no difference whether it's open or abandoned, you can
> recreate it as PR although if not ready it is better to have it in your own
> fork.
> For how long gerrits will stay it's a question for EF. If the repo is
> archived - gerrits are gone. Webmaster team asks for when repo can be
> archived in gerrit which we try to delay for Eclipse TLP repos (doing
> better than Tycho migration!) but that's beyond us.
>
>
>>
>> I have various WIP gerrits[1] that I hope to come back to one day. Until
>> now I have considered gerrit a safe place to store such WIP (as I would my
>> own fork on GitHub).
>>
>> In addition, the review comments of the gerrits are very valuable when
>> trying to unravel an old issue.
>>
>> I ask because some projects that have migrated from gerrit to GitHub seem
>> to have lost their gerrit entries (Tycho[2]) while others still live on
>> gerrit (like LSP4E[3])
>>
>
> LSP4E seems to have missed the last step in the migration which should be
> fixed and become read-only soon.
>
>
>>
>> [1] https://git.eclipse.org/r/c/platform/eclipse.platform.debug/+/181035
>> or https://git.eclipse.org/r/c/equinox/rt.equinox.p2/+/170563
>> [2] https://git.eclipse.org/r/165496 for
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=564670 is no longer
>> available
>> [3] https://git.eclipse.org/r/admin/repos/lsp4e/lsp4e
>>
>> 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
>>
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
> ___
> 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] how long will repos remain on gerrit (read-only?)

2022-03-16 Thread Jonah Graham
Hi folks,

How long will the gerrits for platform projects moving to GitHub be left
around? (Sorry if this is asked and answered somewhere else)

I have various WIP gerrits[1] that I hope to come back to one day. Until
now I have considered gerrit a safe place to store such WIP (as I would my
own fork on GitHub).

In addition, the review comments of the gerrits are very valuable when
trying to unravel an old issue.

I ask because some projects that have migrated from gerrit to GitHub seem
to have lost their gerrit entries (Tycho[2]) while others still live on
gerrit (like LSP4E[3])

[1] https://git.eclipse.org/r/c/platform/eclipse.platform.debug/+/181035 or
https://git.eclipse.org/r/c/equinox/rt.equinox.p2/+/170563
[2] https://git.eclipse.org/r/165496 for
https://bugs.eclipse.org/bugs/show_bug.cgi?id=564670 is no longer available
[3] https://git.eclipse.org/r/admin/repos/lsp4e/lsp4e

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


Re: [platform-dev] [cross-project-issues-dev] Sad News

2022-03-01 Thread Jonah Graham
I am sorry to hear that. Please pass on my condolences to Kit's family and
colleagues here in Eclipse Community, at IBM and elsewhere.

Please take the time to enter your thoughts on Eclipse's memorial page too
https://gitlab.eclipse.org/eclipsefdn/memorials - I have started the entry
(waiting for merge) in
https://gitlab.eclipse.org/eclipsefdn/memorials/-/merge_requests/12 based
on Pradeep's words.

Jonah


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


On Tue, 1 Mar 2022 at 10:43, Pradeep Balachandran 
wrote:

> Dear Friends,
>
>
>
> I have a sad news to share.
>
>
>
> Kit Lo, Technical Lead for IBM Eclipse SDK, based out of IBM RTP lab,
> passed away on Saturday, Feb 26th. He was on a routine run on Saturday and
> collapsed on the way. Kit has been with IBM for 32+ years, working in
> various roles and different teams. In the past decade, Kit was the lead for
> Translation / Globalization efforts across various products. About 5 years
> ago, Kit took up the IES Technical Lead role. Kit was a very hard worker,
> continuous learner and always willing to go the extra mile to help those in
> need. Kit was also very active in Eclipse Open Source Community. He was the
> co-lead for Eclipse Babel project (community driven translation of strings
> in Eclipse distribution) and in the past year, he also took up the
> additional role of Eclipse IDE Release Engineer.
>
>
>
> We in the Eclipse team in IBM, are still trying to come to terms with the
> fact that Kit is no longer with us. Kit was a great friend, mentor and
> guide for those who worked closely with him. We are lucky to have worked
> with him. Kit will be sorely missed.
>
>
>
> Pradeep
>
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-...@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-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

2022-02-17 Thread Jonah Graham
-1 to stop auto-closing.

McQ's arguments ring true for me.

My personal preference  would prefer a much more aggressive auto-close
strategy - however I do hear the active committers saying they don't like
it.

Jonah

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


On Thu, 17 Feb 2022 at 03:58, Andrey Loskutov  wrote:

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


Re: [platform-dev] [cross-project-issues-dev] Anyone with ruby skills willing to help getting maven-target support for dependabot?

2022-01-30 Thread Jonah Graham
Sounds interesting. This may be a good GSOC topic?

https://wiki.eclipse.org/Google_Summer_of_Code_2022_Ideas

Jonah

On Sun., Jan. 30, 2022, 02:54 Christoph Läubrich, 
wrote:

> Hi,
>
> the maven-target locations are around for a while and projects are
> already starting to use them (e.g. m2e).
>
> A good tooling addition for this feature would be if dependabot[1] could
> automatically suggest updates for such dependencies declared in a target
> file.
>
> I have created a feature-request [2] but I'm not familiar with ruby,
> thus I'd like to ask if someone on the list is more familiar and willing
> to provide a PR for getting this feature in.
>
> [1]
>
> https://github.blog/2020-06-01-keep-all-your-packages-up-to-date-with-dependabot/
> [2] https://github.com/dependabot/dependabot-core/issues/4682
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-...@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-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] Pull request rejected because "Eclipse project is currently in a code freeze period"

2022-01-10 Thread Jonah Graham
Hi Thomas,

This is frozen during milestone/rc weeks for a few days - these happen
every three weeks so I don't think that there is any chance of a branch
being made for that. The patch can be merged once the freeze is complete,
or even during the freeze period if approved by a committer. For releases
the branches are made and master is closed for a reasonably short period of
time.

Note that the expectation for Eclipse project committers is to be testing
and bugfixing only during that freeze - see
https://www.eclipse.org/lists/eclipse-dev/msg11842.html for more details.

I hope that clarifies things, please let us know if you have any questions.
Jonah

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


On Tue, 4 Jan 2022 at 04:24, Thomas Singer  wrote:

> Hi,
>
> My pull request was rejected by the Platform Bot with the message
>
> > Build and test are OK, but Eclipse project is currently in a code freeze
> period.
> > Please wait for end of code freeze period before merging.
>
> Wouldn't it be possible to simply fork off a release branch during code
> freeze period and allow to continue commits in master?
>
> --
> Best regards,
> Thomas Singer
>
> ___
> 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.org-planning-council] Unsigned Content?

2021-12-17 Thread Jonah Graham
On Fri, 17 Dec 2021 at 11:08, Aleksandar Kurtakov 
wrote:

>
>
> On Fri, Dec 17, 2021 at 5:03 PM Jonah Graham 
> wrote:
>
>> (there are two mailing lists in this chain - some emails are not in
>> planning council archive)
>>
>> > The community with which I'm familiar tended to build consensus around
>> decisions.
>>
>> I empathise with the Eclipse PMC, and as I pointed out in
>> various Planning Council and IDE WG calls, Eclipse PMC are a TLP that can
>> do what they want (within EDP, etc). As far as I can tell they have tried
>> to build consensus, but we are 4 months into the process of trying to get
>> consensus on this issue and we remain log jammed.
>>
>> As a reminder, the next step is "Wayne has volunteered to try and put
>> together the document that is digestible by the IDE WG and reviewers."
>> (from https://wiki.eclipse.org/Planning_Council/2021-12-01)
>>
>> If the 2022-03 release ships with Eclipse Platform 4.22, that would be
>> surprising, but not the end of the world. However my understanding is that
>> for Eclipse Platform 4.23 all bundles that are currently in SimRel will
>> continue to be jarsigned anyway. If something has changed in that regard:
>>
>> > So from now on things like Jetty updates and other third party updates
>> will go with PGP signing only from Eclipse TLP.
>>
>
> My (personal) plan is to not do any dependency updates for 2022-03 of
> platform content that gets in Simrel. If there are updates that can't be
> updated (CVE, breakage with newer Java, etc.) - these go with PGP signing .
>

Thank you for that extra detail.


>
>
>
>>
>> then maybe we have something to hurry us along.
>>
>> Thank you Eclipse PMC for lighting a suitable sized fire under our
>> collective behinds.
>>
>> And finally another reminder "The steering committee is onboard with the
>> general direction of this work. The work looks promising and no plan to
>> change direction." (from 16 Nov IDE WG minutes
>> https://www.eclipse.org/lists/eclipse-ide-wg/msg00114.html)
>>
>> Jonah
>>
>> ~~~
>> Jonah Graham
>> Kichwa Coders
>> www.kichwacoders.com
>>
>>
>> On Fri, 17 Dec 2021 at 03:45, 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.SetupTask

Re: [platform-dev] Unsigned Content?

2021-12-17 Thread Jonah Graham
(there are two mailing lists in this chain - some emails are not in
planning council archive)

> The community with which I'm familiar tended to build consensus around
decisions.

I empathise with the Eclipse PMC, and as I pointed out in various Planning
Council and IDE WG calls, Eclipse PMC are a TLP that can do what they want
(within EDP, etc). As far as I can tell they have tried to build consensus,
but we are 4 months into the process of trying to get consensus on this
issue and we remain log jammed.

As a reminder, the next step is "Wayne has volunteered to try and put
together the document that is digestible by the IDE WG and reviewers."
(from https://wiki.eclipse.org/Planning_Council/2021-12-01)

If the 2022-03 release ships with Eclipse Platform 4.22, that would be
surprising, but not the end of the world. However my understanding is that
for Eclipse Platform 4.23 all bundles that are currently in SimRel will
continue to be jarsigned anyway. If something has changed in that regard:

> So from now on things like Jetty updates and other third party updates
will go with PGP signing only from Eclipse TLP.

then maybe we have something to hurry us along.

Thank you Eclipse PMC for lighting a suitable sized fire under our
collective behinds.

And finally another reminder "The steering committee is onboard with the
general direction of this work. The work looks promising and no plan to
change direction." (from 16 Nov IDE WG minutes
https://www.eclipse.org/lists/eclipse-ide-wg/msg00114.html)

Jonah

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


On Fri, 17 Dec 2021 at 03:45, 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 

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

2021-12-09 Thread Jonah Graham
Assuming you can't use Ed's suggestion, the link I sent you before gives
you clone command to use.

e.g.

git clone "https://git.eclipse.org/r/platform/eclipse.platform.swt.binaries;
&& (cd "eclipse.platform.swt.binaries" && mkdir -p .git/hooks && curl -Lo
`git rev-parse --git-dir`/hooks/commit-msg
https://git.eclipse.org/r/tools/hooks/commit-msg; chmod +x `git rev-parse
--git-dir`/hooks/commit-msg)

Jonah

On Thu., Dec. 9, 2021, 07:29 Thomas Singer,  wrote:

> I somehow found now this page:
>
> <
> https://git.eclipse.org/c/gerrit/platform/eclipse.platform.swt.binaries.git/
> >
>
> but when trying to clone from
>
> <
> https://git.eclipse.org/r/gerrit/platform/eclipse.platform.swt.binaries.git
> >
>
> it fails:
>
> > $ git clone
> https://git.eclipse.org/c/gerrit/platform/eclipse.platform.swt.binaries.git/
> > Cloning into 'eclipse.platform.swt.binaries'...
> > fatal: repository '
> https://git.eclipse.org/c/gerrit/platform/eclipse.platform.swt.binaries.git/'
> not found
>
> --
> Best regards,
> Thomas Singer
> =
> syntevo GmbH
> www.syntevo.com
>
>
> On 2021-12-09 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 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?

2021-12-09 Thread Jonah Graham
https://git.eclipse.org/r/admin/repos/platform/eclipse.platform.swt.binaries

HTH,
Jonah

On Thu., Dec. 9, 2021, 07: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.
>
> --
> Best regards,
> Thomas Singer
> =
> syntevo GmbH
> www.syntevo.com
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev


Re: [platform-dev] reference counting for native resources

2021-12-08 Thread Jonah Graham
Thanks Niraj for the advice.

In the end Nikita (in the bug
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=577649>) made me realize
that I didn't need to overcomplicate things as all the memory is freed at
once I don't need to work too hard to reference count the multiple
references to the same block of memory.

Jonah

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


On Wed, 8 Dec 2021 at 02:13, Niraj Modi  wrote:

> Hi Jonah,
> We have a simple Sleak tool that monitors the graphics resources only but
> not all native reference counting that you are looking for. Please check if
> it helps, SWT article on Sleak:
> https://www.eclipse.org/articles/swt-design-2/sleak.htm
>
> Regards,
> Niraj Modi
>
> ----- Original message -
> From: "Jonah Graham" 
> Sent by: "platform-dev" 
> To: "Eclipse platform general developers list." 
> Cc:
> Subject: [EXTERNAL] [platform-dev] reference counting for native resources
> Date: Mon, Dec 6, 2021 9:12 PM
>
> Hi folks,
>
> I am working on some performance issues with TextLayout (may fix part of
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=168557 - at least on
> Windows)
>
> One of the performance issues is that we make copies of large buffers over
> and over again when a little bit of pointer arithmetic + sharing buffers
> improves the situation.
>
> Are there any examples in SWT already of reference counting of native
> resources?
>
> Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=577649 is for tracking
> this specific part of the work.
>
> 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
>
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev


[platform-dev] reference counting for native resources

2021-12-06 Thread Jonah Graham
Hi folks,

I am working on some performance issues with TextLayout (may fix part of
https://bugs.eclipse.org/bugs/show_bug.cgi?id=168557 - at least on Windows)

One of the performance issues is that we make copies of large buffers over
and over again when a little bit of pointer arithmetic + sharing buffers
improves the situation.

Are there any examples in SWT already of reference counting of native
resources?

Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=577649 is for tracking
this specific part of the work.

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


Re: [platform-dev] [p2-dev] [cbi-dev] Eclipse Foundation public PGP key?

2021-10-07 Thread Jonah Graham
So for any practical use based on the build scripts we have today (b3 or
tycho mirroring) the keys should be an  artifact property so that they
"travel" around with the artifacts through the various mirroring stages?
Otherwise there is some updates needed to build scripts to say copy the
keys from repo to repo when doing the mirror?

Jonah

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


On Thu, 7 Oct 2021 at 15:41, Mickael Istria  wrote:

>
>
> On Thu, Oct 7, 2021 at 9:36 PM Jonah Graham 
> wrote:
>
>> In the above link, what is the difference between artifact metadata and
>> artifact repository? I feel like I am missing knowledge of some of the
>> terminology.
>>
>
> The artifact repository contains the artifact metadata + some properties.
> The pgp.publicKeys property can be set either as a repository property or
> as an artifact property. The former has the advantage of sharing the key
> for all artifacts, the later of the advantage of being attached onto the
> artifact metadata so it's supposed to be copied if you mirror the artifact
> with usual p2 mechanisms.
> HTH
> ___
> p2-dev mailing list
> p2-...@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/p2-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] [cbi-dev] Eclipse Foundation public PGP key?

2021-10-07 Thread Jonah Graham
Hi Mickael,


On Fri, 23 Apr 2021 at 08:32, Mickael Istria  wrote:

> Hi all,
>
> Thanks to Mikael (Barbero) for encouraging exclusion of any automated form
> of trust at the moment, we're making some concrete progress here:
> * artifacts provider can now attach PGP signatures to the p2 metadata and
> p2 will ensure all those signatures are correct for the given artifact when
> downloading it; installation will fail early if a signature is incorrect.
> For the moment, public keys for verification current are also to be placed
> in p2 metadata.
> https://www.eclipse.org/eclipse/news/4.20/platform_isv.php#pgp-signature-verification
>

In the above link, what is the difference between artifact metadata and
artifact repository? I feel like I am missing knowledge of some of the
terminology.

Thanks,
Jonah



>
___
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] CVS support plugin discontinuation

2021-09-23 Thread Jonah Graham
Thank you all for your earlier thoughts and replies. I hope they prove to
be useful to others as my proposal was rejected and my client is
uninterested in funding support for CVS support in Eclipse going forward.
Unless/until someone funds this work, I won't be doing anything further on
it from my end.

Jonah

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


On Mon, 20 Sept 2021 at 09:58, Jonah Graham  wrote:

>
> On Mon, 20 Sept 2021 at 02:47, Lars Vogel  wrote:
>
>>
>> Jonah, do you have interest in keeping cvs support around or are you
>> just asking to check for options?
>>
>
> Hi Lars,
>
> I have no personal interest in CVS - however I have one client who still
> uses CVS. I have asked them about CVS support in Eclipse going forward and
> I am waiting for their response. The answers to my questions were
> sufficient to put a proposal together for them.
>
> However, this may simply be the kick they need to move their legacy stuff
> off CVS and onto git.
>
> Thanks
> Jonah
>
___
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] CVS support plugin discontinuation

2021-09-20 Thread Jonah Graham
On Mon, 20 Sept 2021 at 02:47, Lars Vogel  wrote:

>
> Jonah, do you have interest in keeping cvs support around or are you
> just asking to check for options?
>

Hi Lars,

I have no personal interest in CVS - however I have one client who still
uses CVS. I have asked them about CVS support in Eclipse going forward and
I am waiting for their response. The answers to my questions were
sufficient to put a proposal together for them.

However, this may simply be the kick they need to move their legacy stuff
off CVS and onto git.

Thanks
Jonah
___
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] CVS support plugin discontinuation

2021-09-17 Thread Jonah Graham
Hello folks,

I am reaching out to you because I *may* need to take this on. But before I
do I want to confirm a couple of things:

- Can the CVS features be released as needed and live in their own p2 site
going forward and that p2 site contribute to SimRel?
- Can the Platform team still "host" the features/git repo/p2 site for
them? (As opposed to having to spin up a new project?)

I think my options are to:
1) either split CVS features out of the repo[1] and fixup the build/etc so
that it can build independently
2) create a mirror of the CVS features of the last release and host that
somewhere internal
3) simply tell users to point at old release p2 sites to install CVS into
their newer Eclipse.

The advantage of (1) is that, if needed, future fixes can actually be done
- and done in the open source easily, but that would require a Yes to my
two questions.

Thanks
Jonah

[1]
https://git.eclipse.org/r/plugins/gitiles/platform/eclipse.platform.team/

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


On Fri, 17 Sept 2021 at 10:04, Aleksandar Kurtakov 
wrote:

> Hey everyone,
> CVS is dead technology but we still lose precious releng time in making
> sure versions are changed so it's updated clean from previous release,
> useless bits are still built on every patch review, tests are not run and
> so on. All that for nothing as we don't know whether there is any user left
> and whether the plugin is even still functional.
>
> With all that said, Eclipse TLP PMC is planning to have 4.22/2021-12
> release be the last one containing CVS support . It's a standalone feature
> not included in Eclipse SDK  nor in any EPP (AFAIK) thus it shouldn't
> affect many people (if anyone!). Being standalone, building it separately
> should be easy in case anyone is willing to preserve it.
> If you're still using CVS and depend on this plugin availability please
> raise your voice now and contact us on platform-dev@eclipse.org to plan
> and organize the split of CVS feature and you taking over release duties
> for it.
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-...@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-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] generic editor and breakpoints

2021-09-14 Thread Jonah Graham
On Tue, 14 Sept 2021 at 09:07, Mickael Istria  wrote:

>
> And if you plan to work on it, please add me as CC on related tickets. I'd
> really like to remove this duty from LSP4E is Platform happens to be allow
> a more powerful and generic solution.
>

Please CC me as well.

Thanks,
Jonah
___
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

2021-05-27 Thread Jonah Graham
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 
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


Re: [platform-dev] How do I track Eclipse Project Plan changes

2021-05-24 Thread Jonah Graham
Thanks Sravan for confirming all that.

I have requested a JustJ release for Java 16 as it seems inappropriate to
ship the EPP with Java 15 in light of your comments. See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=573734#c4

Jonah


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


On Mon, 24 May 2021 at 23:36, Sravan K Lakkimsetti 
wrote:

> Hi,
>
>
>
> Java 16 was supposed to be target platform for 4.20 release. We stopped
> using Java15 in our testing from M1 itself. In the supported platform we
> should have made it clear in the first version itself.
>
> Last week when I am creating freeze plan, I noticed this and updated the
> targeted java versions. Sorry for not updating the commit message.
>
>
>
> Please note: Going forward, Platform will drop support for java versions
> as soon as they go out of support by OpenJDK unless the version id declared
> as LTS by Oracle.
>
>
>
> Thanks and Regards,
> Sravan
>
> Sravan Kumar Lakkimsetti
> IBM India Pvt Ltd,
> Embassy Golf Links Business Park, C Block,
> Off Indiranagar-Kormangla Inner Ring Road,
> Bangalore - 560071, India
>
>
>
> *From:* Jonah Graham 
> *Sent:* 25 May 2021 04:00
> *To:* Eclipse platform general developers list. 
> *Subject:* [EXTERNAL] [platform-dev] How do I track Eclipse Project Plan
> changes
>
>
>
> Hi folks,
>
>
>
> As part of my release planning for EPP I looked at Java 16 support earlier
> in the dev cycle. As of now JustJ has not made a Java 16 release available
> - there is a milestone[1].
>
>
>
> As part of that conversation I consulted the 4.20 project plan[2] (around
> M2 date) and Java 16 was not part of the target environment.
>
>
>
> Last week, Java 16 was added (and Java 15 was removed).[3]  The git commit
> message does not reference a bug, nor contain any information about the
> change (the commit message is just about aarch64 change).
>
>
>
> Going forward I have a question - how do I track changes in the Eclipse
> Project Plan? Do I subscribe to gerrit notifications? Is there a better
> source of truth? I suppose I should have known that 4.20 was going to have
> Java 16 at target environment, but now a couple of days before EPP M3 I am
> considering changing to Java 16 and I am not sure what to do.
>
>
>
> Any thoughts?
>
>
>
> BTW I think releasing the IDE bundled with the latest Java instead of LTS
> Java is a mistake that I will take up with the Eclipse IDE WG and the
> Eclipse Planning Council. With the current plan we are shipping EOL Java
> versions with Eclipse IDE as alternating IDE releases are lined up to the
> Java release EOL date (really they are lined up to the new Java releases,
> but that date is the same for non-LTS).
>
>
>
> Thanks
>
> Jonah
>
>
>
>
>
> [1] https://www.eclipse.org/lists/justj-dev/msg00023.html
>
> [2]
> https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_20.xml
>
> [3] https://git.eclipse.org/r/c/www.eclipse.org/eclipse/+/180723
>
>
> ~~~
> 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] How do I track Eclipse Project Plan changes

2021-05-24 Thread Jonah Graham
Hi folks,

As part of my release planning for EPP I looked at Java 16 support earlier
in the dev cycle. As of now JustJ has not made a Java 16 release available
- there is a milestone[1].

As part of that conversation I consulted the 4.20 project plan[2] (around
M2 date) and Java 16 was not part of the target environment.

Last week, Java 16 was added (and Java 15 was removed).[3]  The git commit
message does not reference a bug, nor contain any information about the
change (the commit message is just about aarch64 change).

Going forward I have a question - how do I track changes in the Eclipse
Project Plan? Do I subscribe to gerrit notifications? Is there a better
source of truth? I suppose I should have known that 4.20 was going to have
Java 16 at target environment, but now a couple of days before EPP M3 I am
considering changing to Java 16 and I am not sure what to do.

Any thoughts?

BTW I think releasing the IDE bundled with the latest Java instead of LTS
Java is a mistake that I will take up with the Eclipse IDE WG and the
Eclipse Planning Council. With the current plan we are shipping EOL Java
versions with Eclipse IDE as alternating IDE releases are lined up to the
Java release EOL date (really they are lined up to the new Java releases,
but that date is the same for non-LTS).

Thanks
Jonah


[1] https://www.eclipse.org/lists/justj-dev/msg00023.html
[2]
https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_20.xml
[3] https://git.eclipse.org/r/c/www.eclipse.org/eclipse/+/180723

~~~
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


Re: [platform-dev] Why does DebugPlugin need eventlisteners in order to schedule runnables?

2021-05-20 Thread Jonah Graham
Hi Anton,

That code was written a long time ago (2004) -
https://bugs.eclipse.org/bugs/show_bug.cgi?id=30779 - so it may be
difficult to get any first hand knowledge of the answer.

When the code was first written that job (EventDispatchJob) would have
nothing to do if there were no listeners as the job was only dispatching
events to listeners.

Then in 2007 - see comment in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=178902#c2 - the same job was
used to handle the event queue and asyncExec queue.

My best guess is that no one noticed until now as in (almost!) all debug
sessions there will be at least one listener.

I recommend you submit a bug & gerrit that simply removes the optimization
in shouldSchedule. And as a workaround in the meantime, you could add a
dummy listener (DebugPlugin.addDebugEventListener) in your TCF session.

I hope that helps and let us know if the above solves your problem.
Jonah

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


On Thu, 20 May 2021 at 14:40, Anton Bäckström 
wrote:

> Hi,
>
> I have a question about  the scheduling mechanism in
> org.eclipse.debug.core.DebugPlugin.
> This code in particular:
>
> *public boolean shouldSchedule() {*
> *return !(isShuttingDown() || fEventListeners.isEmpty());*
> *}*
>
> Why does the DebugPlugin need to have EventListeners registered in order
> to schedule runnables?
>
>
> Our use case is a debugger based on TCF. It uses the RunToLineAdaper from
> CDT, with an adapter from TCF, in order to perform a Run To Line action.
>
> In CDT, this code will, through a few steps, end up calling the
> shouldSchedule() above:
>
> *private void runInBackground(Runnable r) {*
> *DebugPlugin.getDefault().asyncExec(r);*
> *}*
>
>
> There are no EventListeners related to the DebugPlugin regarding Run To
> Line in TCF, which makes me confused.
>
> Run To Line just so happens to work if, and only if, I have the Memory
> View open, since it has EventListeners registered on the DebugPlugin. But
> those listeners are unrelated to Run To Line.
>
> Perhaps I need to reach out to the TCF or CDT mailing list, but for
> starters I would be happy if someone could explain why the shouldSchedule()
> function looks like it does.
>
> Best regards,
> --
>
> Anton Bäckström
> Cobham Gaisler
>
> Cobham Gaisler AB, Kungsgatan 12, SE-411 19, GÖTEBORG, Sweden.
> +46 (0) 31 775 8650, www.cobhamaes.com/gaisler
> Please consider the environment before printing this email
>
>___
> 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] Website idea

2021-05-17 Thread Jonah Graham
Hi Wim,

I gave it a try https://github.com/eclipse/birt-website/pull/11 but ran
into some problems. I am happy to help you debug/test out the flow as a
non-committer on BIRT.

Jonah

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


On Mon, 17 May 2021 at 05:58, Wim Jongman  wrote:

> Hi,
>
> In the BIRT project, we have converted the website exactly as I have it in
> mind for our website. *Not the L but the workflow*.
>
> 1. The website is generated from markdown
> 2. An "edit this page" link brings you to the source
> 3. A change and pull request will update an intermediate website on Github
> pages for testing (optional, but BIRT uses it)
> 4. On merge-pull-request, the main website will be updated
>
> Please try the workflow by clicking on the "Edit" link at the bottom of
> any of the pages and tell me what you think:
>
> https://eclipse.github.io/birt-website/docs/what-is-birt
>
> 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


Re: [platform-dev] Track SWT allocations

2021-04-16 Thread Jonah Graham
Perhaps like "-ea" it can be added by default to launch configurations -
https://help.eclipse.org/2021-03/topic/org.eclipse.jdt.doc.user/reference/preferences/java/ref-preferences-junit.htm?cp=1_4_4_0_7

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


On Fri, 16 Apr 2021 at 08:25, Christoph Läubrich 
wrote:

> Is this evaluate every time or only once? Maybe there is some wa to
> couple this to the -dev option?
>
> Am 16.04.21 um 14:05 schrieb Wim Jongman:
> > Not for production but all committers and contributors should probably
> > activate it. It is activated by default on the SDK.
> >
> > -Dorg.eclipse.swt.graphics.Resource.reportNonDisposed=true
> >
> >
> > ___
> > 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] canonical way to handle optional dependencies

2021-04-15 Thread Jonah Graham
Thanks Tom. That is a very interesting option too. Is there a way from the
main bundle to know if the fragment is available? In CDT's case "NoLeak"
uses "UILeaker".

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


On Thu, 15 Apr 2021 at 09:56, Tom Schindl via platform-dev <
platform-dev@eclipse.org> wrote:

> Hi,
>
> An option to ban the offending guy from the codebase would be to move
> the offending class to a fragment.
>
> Let's say we have
>
> MyBundle
>+ my.class.UILeaker
>  - methodA(String)
>  - methodB(String)
>  - leakMethod(Shell)
>
> We could refactor it to:
>
> ---8<---
> MyBundle
>+ my.class.NoLeak
>  - methodA(String)
>  - methodB(String)
>
> MyBundleCompatFragment
>+ my.class.UILeaker extends my.class.NoLeak
>  - leakMethod(Shell)
> ---8<---
>
> Your fragment needs to provide a Eclipse-ExtensibleAPI in the MANIFEST,
> as the fragment but this would make your bundle free from the optional
> requires (the fragment would require the UI stuff) and as Host and
> Fragment share the same classloader you could even call package-scoped
> APIs from the fragment.
>
> Tom
>
> Am 15.04.21 um 15:42 schrieb Jonah Graham:
> > Thanks Alex for the insights. This is one of those APIs that I don't
> > think is used in practice (but you can never be sure). CDT adopted the
> > same API deletion process as Platform, so we can delete it without the
> > major version bump. Therefore using new methods may be a good solution
> > to handle the period between deprecation and deletion.
> >
> > Jonah
> >
> >
> > ~~~
> > Jonah Graham
> > Kichwa Coders
> > www.kichwacoders.com <http://www.kichwacoders.com>
> >
> >
> > On Thu, 15 Apr 2021 at 09:36, Alex Blewitt  > <mailto:alex.blew...@gmail.com>> wrote:
> >
> > On 15 Apr 2021, at 14:05, Jonah Graham  > <mailto:jo...@kichwacoders.com>> wrote:
> >  >
> >  > Most of the dependencies on the UI are relatively easy to
> > resolve. However one area is in the API - the API includes
> > references to org.eclipse.ui.dialogs.IOverwriteQuery, and in the
> > headless case these references are null.
> >
> > The problem is that if it is part of the API (ie method argument,
> > return value) then the class has to be loaded in order to call that
> > method, even with a null value. If you attempt to call this method
> > then it will attempt to load the ui class and when it’s not found it
> > will raise a ClassNotFound error (or similar).
> >
> > In order to fix it you’ll need to change the API to take a more
> > generic object (like Object) which will allow you to call the method
> > with a null value, and you can pass through the untyped value to
> > where it needs to be used, casting it at the point of use (or using
> > a reflective call that obscure the types).
> >
> > You may find the right evolution path is to create a second method
> > with the same signature but using Object in place, migrating the
> > code paths to that method, and leaving a call path from the old to
> > the new. You can then mark the old API as deprecated and invite
> > callers to move over to the new call.
> >
> > Using the same method name has both advantages and disadvantages; if
> > you are calling with null then you’ll need to disambiguate by
> > casting to Object but might facilitate changeover when you delete
> > the old method; if you use a new name then callers will have to
> > change source code to take advantage of the changed api but will
> > likely be easier to determine if code has been moved from old to new
> > patterns.
> >
> > In either case it is a new method signature which won’t be source
> > compatible for old callers, so it’s probably a major version bump
> > when you remove the old call path.
> >
> > Alex
> > ___
> > platform-dev mailing list
> > platform-dev@eclipse.org <mailto:platform-dev@eclipse.org>
> > To unsubscribe from this list, visit
> > https://www.eclipse.org/mailman/listinfo/platform-dev
> > <https://www.eclipse.org/mailman/listinfo/platform-dev>
> >
> >
> > ___
> > platform-dev mailing list
> > platform-dev@eclipse.org
> > To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
> >
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev


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

2021-04-15 Thread Jonah Graham
It would be an option - but seems to me to be too much work. I also don't
particularly like the idea of having org.eclipse.ui.* packages floating
about the ecosystem that aren't the real ones.

Thanks
Jonah

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


On Thu, 15 Apr 2021 at 09:16, Christoph Läubrich 
wrote:

> Wouldn't it be an option to simply supply a "cli-only" bundle that
> supplies the missing interfaces with dummy implementations?
>
> Am 15.04.21 um 15:04 schrieb Jonah Graham:
> >
> > On Thu, 15 Apr 2021 at 08:38, Christoph Läubrich  > <mailto:lae...@laeubi-soft.de>> wrote:
> >
> > I think there is no "one fits all". Optional dependency are really
> > problematic to handle right and should be avoided as they often mean
> > your bundle/services are not well shaped.
> >
> >
> > Thanks - I do agree.
> >
> > If you describe your case it might be possible to give some more
> advice.
> >
> >
> > The issue is we (CDT project) have a bundle that has been around for a
> > very long time. It is supposed to be a "core" bundle, but has some UI
> > dependencies in it. This bundle is used headlessly today, and there are
> > UI code paths than when run headlessly are effectively no-ops.
> >
> > Most of the dependencies on the UI are relatively easy to resolve.
> > However one area is in the API - the API includes references
> > to org.eclipse.ui.dialogs.IOverwriteQuery, and in the headless case
> > these references are null.
> >
> > We would like to refactor the code so that an installation can be made
> > that has no UI bundles included in it. The long plan is to deprecate and
> > remove the code that depends on UI, but in the meantime we wanted to
> > make the UI dependency optional.
> >
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=572850
> > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=572850> tracks the
> actual
> > work.
> >
> > Thanks
> > Jonah
> >
> >
> >
> > Am 15.04.21 um 13:38 schrieb Jonah Graham:
> >  > Hello,
> >  >
> >  > (Not sure this is on topic for the list - but not sure where to
> ask.)
> >  >
> >  > What is the canonical way to check if an optional dependency is
> > available?
> >  >
> >  > I know of a couple of methods:
> >      >
> >  > 1. wrapping code in try/catch and catching something wide like
> > Throwable
> >  > or NoClassDefFoundError
> >  > 2. checking for bundle status (e.g. calling
> >  > Platform.getBundle(symbolicName) and Bundle.getState)
> >  >
> >  > Thank you.
> >  > Jonah
> >  >
> >  >
> >  >
> >  >
> >  > ~~~
> >  > Jonah Graham
> >  > Kichwa Coders
> >  > www.kichwacoders.com <http://www.kichwacoders.com>
> > <http://www.kichwacoders.com <http://www.kichwacoders.com>>
> >  >
> >  > ___
> >  > 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/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 mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev


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

2021-04-15 Thread Jonah Graham
Thank you Wim for confirming I was on the right path and for the suggestion
to wrap it all in a static method and class.

Jonah

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


On Thu, 15 Apr 2021 at 08:55, Wim Jongman  wrote:

> Yes, those are two good options. AFAIK there is no additional magic that
> you miss.
>
> I would wrap the dependency checking in a static class. e.g use
> if(DepBundleChecker.isAvailable()){ .. do something ..} instead of catching
> class loading exceptions. It's a bit more elegant but it stays a pita.
>
> Cheers,
>
> Wim
>
> On Thu, Apr 15, 2021 at 1:39 PM Jonah Graham 
> wrote:
>
>> Hello,
>>
>> (Not sure this is on topic for the list - but not sure where to ask.)
>>
>> What is the canonical way to check if an optional dependency is available?
>>
>> I know of a couple of methods:
>>
>> 1. wrapping code in try/catch and catching something wide like Throwable
>> or NoClassDefFoundError
>> 2. checking for bundle status (e.g. calling
>> Platform.getBundle(symbolicName) and Bundle.getState)
>>
>> Thank you.
>> 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


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

2021-04-15 Thread Jonah Graham
On Thu, 15 Apr 2021 at 08:38, Christoph Läubrich 
wrote:

> I think there is no "one fits all". Optional dependency are really
> problematic to handle right and should be avoided as they often mean
> your bundle/services are not well shaped.
>

Thanks - I do agree.


> If you describe your case it might be possible to give some more advice.
>

The issue is we (CDT project) have a bundle that has been around for a very
long time. It is supposed to be a "core" bundle, but has some UI
dependencies in it. This bundle is used headlessly today, and there are UI
code paths than when run headlessly are effectively no-ops.

Most of the dependencies on the UI are relatively easy to resolve. However
one area is in the API - the API includes references
to org.eclipse.ui.dialogs.IOverwriteQuery, and in the headless case these
references are null.

We would like to refactor the code so that an installation can be made that
has no UI bundles included in it. The long plan is to deprecate and remove
the code that depends on UI, but in the meantime we wanted to make the UI
dependency optional.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=572850 tracks the actual work.

Thanks
Jonah




>
> Am 15.04.21 um 13:38 schrieb Jonah Graham:
> > Hello,
> >
> > (Not sure this is on topic for the list - but not sure where to ask.)
> >
> > What is the canonical way to check if an optional dependency is
> available?
> >
> > I know of a couple of methods:
> >
> > 1. wrapping code in try/catch and catching something wide like Throwable
> > or NoClassDefFoundError
> > 2. checking for bundle status (e.g. calling
> > Platform.getBundle(symbolicName) and Bundle.getState)
> >
> > Thank you.
> > Jonah
> >
> >
> >
> >
> > ~~~
> > Jonah Graham
> > Kichwa Coders
> > www.kichwacoders.com <http://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] canonical way to handle optional dependencies

2021-04-15 Thread Jonah Graham
Hello,

(Not sure this is on topic for the list - but not sure where to ask.)

What is the canonical way to check if an optional dependency is available?

I know of a couple of methods:

1. wrapping code in try/catch and catching something wide like Throwable or
NoClassDefFoundError
2. checking for bundle status (e.g. calling
Platform.getBundle(symbolicName) and Bundle.getState)

Thank you.
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


Re: [platform-dev] New Website

2021-03-29 Thread Jonah Graham
Hi Wim/all,

This is great - and on behalf of the CDT team I am closely following
because we will probably do the same for the CDT project.

Some notes based on my experimentation with what you provided:

- I didn't understand step 2 about "process can be tested locally" at
first. The link provided was to Jenkins stuff (
#how-to-build-my-projects-website-with-jenkins
<https://github.com/EclipseFdn/hugo-eclipsefdn-website-boilerplate#how-to-build-my-projects-website-with-jenkins>)
which I assume is out of scope for "local" builds.
- It turns out that the anchor in the link was probably wrong as your repo
[1] has a good getting started for the new repo (s/eclipse/wimjongman/ in
the git clone line until it is promoted to eclipse's github org)
- On the build machine hugo 0.81.0 is used (as documented on the wiki[2]) -
but the 0.80.0 version that is available as a snap in Ubuntu seems to work
fine. If there is a minimum or suggested version that may be good to have
in the readme too? Especially for those of us new to the Hugo technology[3]
- If using snap (and you are new to snap installs) make sure you clone the
repo into somewhere in your home directory or you get errors when running
hugo (like Error: open /var/lib/snapd/void: permission denied)

[1] https://github.com/wimjongman/platform-web/tree/staging/#getting-started
[2]
https://wiki.eclipse.org/Jenkins#How_to_build_my_project.27s_website_with_Jenkins.3F
[3] https://gohugo.io/

Thanks Wim!

Jonah

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


On Mon, 29 Mar 2021 at 17:22, Wim Jongman  wrote:

> It took a long struggle but our webmasters did it and we now have a very
> easy website process.
>
> 1. We just edit some markdown files e.g. [1]
> 2. The whole process can be tested locally to make sure the changes are ok
> [2]
> 3. The build converts the website to static HTML and pushes it to the main
> server [3]
>
> I have converted the main page from php/html to markdown [1]
>
> ## RESULT
> old: https://www.eclipse.org/eclipse
> new https://staging.eclipse.org/eclipse
>
> Cheers, Wim
>
> [1] https://github.com/wimjongman/platform-web/tree/staging/content
> [2]
> https://github.com/EclipseFdn/hugo-eclipsefdn-website-boilerplate#how-to-build-my-projects-website-with-jenkins
> [3]
> https://ci.eclipse.org/platform/view/Other/job/TEMP_WEBSITE_DEPLOYMENT/
>
> ___
> 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] Has the time come?

2021-03-18 Thread Jonah Graham
On Thu, 18 Mar 2021 at 09:31, Mickael Istria  wrote:

> You picked the example that suits your answer. Picking
> https://github.com/eclipse/eclipse.jdt.core with 198 stars and 127 forks
> can bring different conclusions.
>

I think this one is a great example. There are 8 open PRs (and 6 closed
ones) on that GH repo. AFAICT only a fraction of them have transitioned
their improvement to gerrit.

I have submitted a change

to fix the language on
https://wiki.eclipse.org/Development_Resources/Contributing_via_Git#via_GitHub
which implies that PRs are actually accepted :-)

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

2021-03-16 Thread Jonah Graham
The idea of allowing contributors to decide how they want to contribute is
an interesting idea. Eclipse CDT has had a mirror on github for a long
time, and, as you can't disable Pull Requests on a GitHub repo, we get a
sporadic PR via the GH web interface. I wonder whether as an early
transition point simply allowing those that want to provide a change via a
PR would work?

Jonah



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


On Tue, 16 Mar 2021 at 11:37, Wim Jongman  wrote:

> Instead of pushing to a branch in the main repo which is for committers
> only, there is also the "Fork Workflow". This would be the workflow for
> contributors.
>
> I've added this to the wiki:
> https://wiki.eclipse.org/Platform-releng/Migration_To_GitHub
>
>
>
>
> ___
> 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] Has the time come?

2021-03-11 Thread Jonah Graham
On Thu, 11 Mar 2021 at 11:00, Ed Merks  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  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 listplatform-...@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] Has the time come?

2021-03-10 Thread Jonah Graham
> "...inline images..."

+100 for this aspect - it applies to issues, PRs and Wiki. Especially being
able to Paste an image in directly.


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


On Wed, 10 Mar 2021 at 13:00, Ned Twigg  wrote:

> Eclipse has a GUI, and it's really helpful to develop GUIs using a tool
> which allows inline images. GitHub PRs and issues work really well together.
> ᐧ
>
> On Wed, Mar 10, 2021 at 8:27 AM Mickael Istria  wrote:
>
>> Hi,
>>
>> Let's capture the main parts of the discussion at
>> https://wiki.eclipse.org/Platform-releng/Migration_To_GitHub so we can
>> more easily plan action here.
>>
>> I'm personally in favor of the eventual move to GitHub, despite my huge
>> love and respect for Gerrit. However, I think we should wait for the
>> "contributing to an Eclipse.org project via GitHub" contribution flow to
>> become nicer, typically when we can get rid of the Signed-Off-By
>> requirement and when any user has a few clicks operation to sign the ECA
>> from GitHub pull requests.
>>
>> As mentioned on other threads, I believe we should stick to bugzilla for
>> issues: GitHub issue tracker is a weak, messy, ugly-after-3-comments, hard
>> to navigate... tool. I'm using it for a few projects much smaller than
>> Platform and don't find it as productive as Bugzilla. I've participated to
>> some discussions on bigger projects (VSCode and others) and found that the
>> lack of semantic relationship (depends/requires/duplicates...) pollutes the
>> discussions and forces to read 40 comments just to find the right link to a
>> requirement.
>>
>> About the CI, any volunteer should start writing the necessary GitHub
>> actions and/or Jenkinsfile to get builds triggered against GitHub Pull
>> Requests. If this files are demonstrated to work well (eg on some cloned
>> repo), then we could consider adding them already inside the repositories
>> as a preliminary step...
>>
>> Once we have the requirements identified and covered, we may be able to
>> progressively move 1 repo after the other as soon as project is ready. I'd
>> advise starting by evaluating for instance migration of PDE to GitHub: what
>> needs to be changed for this to fully work all along the release process?
>>
>> Cheers,
>> ___
>> 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] Has the time come?

2021-03-10 Thread Jonah Graham
Best of both worlds?

https://gerrit.googlesource.com/plugins/github/+/master/README.md

Jonah

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


On Wed, 10 Mar 2021 at 09:38, Wim Jongman  wrote:

> Hi,
>
> Can we discuss the move to GitHub again?
>
> Cons:
> * No Gerrit -> best review system ever
>
> Pros:
> * All the developers are there.
> * No Gerrit -> easy entry for new devs
>
> Cheers,
>
> Wim
>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev


Re: [platform-dev] org.eclipse.epp.logging.aeri.feature relocated?

2021-02-10 Thread Jonah Graham
Hi Jonathan,

Despite the name, the Marketplace Client is its own project (for historical
reasons that I don't know it is a sub-project of EPP), it is an important
project and I assume there is no plan to deprecate it. But best ask them.
See https://projects.eclipse.org/projects/technology.packaging.mpc and
https://accounts.eclipse.org/mailing-list/mpc-dev

Jonah

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


On Wed, 10 Feb 2021 at 14:58, Jonathan Williams 
wrote:

> Hi Jonah,
>
> Thanks for the reply. I did a bit of digging, as I had thought we were
> leveraging this feature for some error reporting functionality in our
> product - but it turns out the references are all vestigial and it is
> not needed after all.
>
> I must have missed the announcement about EPP. I see there is also the
> Marketplace Client from EPP (org.eclipse.epp.mpc). Are those features
> likely to meet a similar fate, in a future release?
>
> Thanks,
>
> Jonathan
>
> On Tue, 2021-02-09 at 19:21 -0500, Jonah Graham wrote:
> > Hi Jonathan,
> >
> > Logging was part of EPP project (epp-...@eclipse.org). It had stopped
> > being maintained a few years ago and was removed from the simrel
> > recently.
> >
> > Are you/BlackBerry using it? Do you have your own logging server to
> > send the automated error reports to?
> >
> > Thanks,
> > Jonah
> >
> > On Tue., Feb. 9, 2021, 18:20 Jonathan Williams, <
> > jonwilli...@blackberry.com> wrote:
> > > Hi,
> > >
> > > I'm in the process of updating my product to the 2020-12 platform,
> > > and
> > > when I try to build my upstream repository, I get errors related to
> > > the org.eclipse.epp.logging.aeri.feature that I didn't get when I
> > > tested last year against the M1 build. Looking at the 2020-12
> > > repositories, I see the milestone builds dated in October have
> > > these
> > > packages in the repo, but subsequent ones (including the latest) do
> > > not. Have these been relocated to another repository somewhere.
> > > I've
> > > attempted to slueth their location myself but my Google-fu is
> > > failing
> > > me. I'm hoping someone can point me in the right direction!
> > >
> > > TIA
> > >
> --
> Jonathan Williams
> Systems Software Developer
> Office: +1 (613) 595-3700
> jonwilli...@blackberry.com
> BlackBerry®  Intelligent Security. Everywhere.
>
> --
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>
___
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.epp.logging.aeri.feature relocated?

2021-02-09 Thread Jonah Graham
Hi Jonathan,

Logging was part of EPP project (epp-...@eclipse.org). It had stopped being
maintained a few years ago and was removed from the simrel recently.

Are you/BlackBerry using it? Do you have your own logging server to send
the automated error reports to?

Thanks,
Jonah

On Tue., Feb. 9, 2021, 18:20 Jonathan Williams, 
wrote:

> Hi,
>
> I'm in the process of updating my product to the 2020-12 platform, and
> when I try to build my upstream repository, I get errors related to
> the org.eclipse.epp.logging.aeri.feature that I didn't get when I
> tested last year against the M1 build. Looking at the 2020-12
> repositories, I see the milestone builds dated in October have these
> packages in the repo, but subsequent ones (including the latest) do
> not. Have these been relocated to another repository somewhere. I've
> attempted to slueth their location myself but my Google-fu is failing
> me. I'm hoping someone can point me in the right direction!
>
> TIA
>
> --
> Jonathan Williams
> Systems Software Developer
> Office: +1 (613) 595-3700
> jonwilli...@blackberry.com
> BlackBerry®  Intelligent Security. Everywhere.
>
> --
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
___
platform-dev mailing list
platform-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev


Re: [platform-dev] Gerrit Spam

2021-01-25 Thread Jonah Graham
Turning on "Silent Start Mode" omits the build started messages, but
the build completed messages will still come through.

HTH
Jonah

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


On Mon, 25 Jan 2021 at 09:06, Alex Blewitt  wrote:

> This is added by the Gerrit Trigger.
>
> https://plugins.jenkins.io/gerrit-trigger/
>
> There’s a ’silent’ mode, which presumably suppresses that message, but I
> don’t know if it also suppresses the build succeed/failed messages either.
>
> Alex
>
> On 25 Jan 2021, at 13:30, Wim Jongman  wrote:
>
> Hi,
>
> I can do without the "Build started" messages from Gerrit.
>
> Do I have supporters for this? Otherwise, I don't want to waste the
> webmaster's time asking for a solution.
>
> Cheers,
>
> Wim
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
___
platform-dev 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 debug "Choose workspace" dialog workflow?

2020-11-11 Thread Jonah Graham
Hi folks,

As this has come up a few times over the past couple of years I raised  Bug
568726 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=568726> to
document osgi.dataAreaRequiresExplicitInit. If someone can review or
improve the associated gerrit
<https://git.eclipse.org/r/c/platform/eclipse.platform.common/+/172109> I
submitted that would be great.

Jonah

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


On Wed, 11 Nov 2020 at 03:10, Homer, Tony  wrote:

> Thanks so much Andrey, this put me on the right track!  You were right, I
> had added a reference to a convenience method which caused another plugin
> to be loaded, which used the resources plugin.
>
>
>
> After using an empty location field and adding 
> -Dosgi.dataAreaRequiresExplicitInit=true
> to the launch config, the product crashed on launch and I could find the
> problem from the stack trace.
>
>
>
> *From: * on behalf of Andrey Loskutov <
> losku...@gmx.de>
> *Reply-To: *"Eclipse platform general developers list." <
> platform-dev@eclipse.org>
> *Date: *Tuesday, November 10, 2020 at 11:42 PM
> *To: *"platform-dev@eclipse.org" 
> *Subject: *Re: [platform-dev] how to debug "Choose workspace" dialog
> workflow?
>
>
>
> Hi Tony,
>
>
>
> Just leave the location field in the launch config empty.
>
>
>
> Your problem with pre-selected default workspace is because one of your
> dependencies that start early uses resources plugin before workspace
> location is set.
>
> You will see who does it if you will
> add -Dosgi.dataAreaRequiresExplicitInit=true argument to the Eclipse VM
> arguments (which is recommended to do anyway).
>
>
>
> Kind regards,
> Andrey Loskutov
>
> Спасение утопающих - дело рук самих утопающих
>
> https://www.eclipse.org/user/aloskutov
>
>
>
>
>
> *Gesendet:* Mittwoch, 11. November 2020 um 00:22 Uhr
> *Von:* "Homer, Tony" 
> *An:* "Eclipse platform general developers list." <
> platform-dev@eclipse.org>
> *Betreff:* [platform-dev] how to debug "Choose workspace" dialog workflow?
>
> I recently made a change in an Eclipse product to switch from a static
> product declaration to a dynamic product declaration, as documented here:
>
>
> https://help.eclipse.org/2020-09/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fextension-points%2Forg_eclipse_core_runtime_products.html%3D2_1_1_30
>
>
>
> After making this change, most everything works as expected, but the
> “Choose workspace” dialog is no longer displayed on startup.  The workspace
> can be switched via the File>Switch Workspace menu item, but on subsequent
> starts, the selection has not been saved (RECENT_WORKSPACES is empty) and
> the default workspace is opened.  I imagine that my dynamic product
> implementation is causing this, so I want to step through the workflow (by
> the way, if anyone reading has an idea of how I could have broken this,
> please let me know!).
>
>
>
> However, as far as I can tell, when launching an “Eclipse Application”
> there is no way to avoid specifying the target workspace in the workspace
> data section, so on initial launch, the “Choose workspace” dialog is not
> displayed.  Trying to exercise the workflow via File>Switch Workspace also
> fails, because an error occurs (“Missing System Property - Unable to
> relaunch the platform because the eclipse.vm property has not been set.").
>
>
>
> How can I debug the “Choose workspace” dialog workflow with an “Eclipse
> Application” launch?
>
>
>
> ___ 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] how to debug "Choose workspace" dialog workflow?

2020-11-10 Thread Jonah Graham
Hi Tony,

> How can I debug the “Choose workspace” dialog workflow with an “Eclipse
Application” launch?

Use @noDefault and you will get the prompt under normal conditions. You can
debug 
org.eclipse.ui.internal.ide.application.IDEApplication.checkInstanceLocation(Shell,
Map) to see why your code is working as it is. You can read more about the
special location options in
https://help.eclipse.org/2020-09/topic/org.eclipse.platform.doc.isv/reference/misc/runtime-options.html#locations

HTH,
Jonah

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


On Tue, 10 Nov 2020 at 18:23, Homer, Tony  wrote:

> I recently made a change in an Eclipse product to switch from a static
> product declaration to a dynamic product declaration, as documented here:
>
>
> https://help.eclipse.org/2020-09/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fextension-points%2Forg_eclipse_core_runtime_products.html%3D2_1_1_30
>
>
>
> After making this change, most everything works as expected, but the
> “Choose workspace” dialog is no longer displayed on startup.  The workspace
> can be switched via the File>Switch Workspace menu item, but on subsequent
> starts, the selection has not been saved (RECENT_WORKSPACES is empty) and
> the default workspace is opened.  I imagine that my dynamic product
> implementation is causing this, so I want to step through the workflow (by
> the way, if anyone reading has an idea of how I could have broken this,
> please let me know!).
>
>
>
> However, as far as I can tell, when launching an “Eclipse Application”
> there is no way to avoid specifying the target workspace in the workspace
> data section, so on initial launch, the “Choose workspace” dialog is not
> displayed.  Trying to exercise the workflow via File>Switch Workspace also
> fails, because an error occurs (“Missing System Property - Unable to
> relaunch the platform because the eclipse.vm property has not been set.").
>
>
>
> How can I debug the “Choose workspace” dialog workflow with an “Eclipse
> Application” launch?
>
>
> ___
> 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

2020-11-06 Thread Jonah Graham
Hi Liviu,

Is that different to how 2020-09 R is? How about compared to the eclipse
Platform's M2:
https://download.eclipse.org/eclipse/downloads/drops4/I20201106-0710/

Thanks for the extra info.

Jonah

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


On Fri, 6 Nov 2020 at 16:57, Liviu Ionescu  wrote:

> I'm reusing this thread, since it is a continuation of the discussion
> related to the subject.
>
> From the new M2 URL:
>
> I downloaded the eclipse-cpp-2020-09-R-macosx-cocoa-x86_64.dmg file using
> the browser, into $HOME/Downloads.
>
> I opened the .dmg (with double click in Finder) and used drag & drop to
> copy Eclipse.app into $HOME/tmp.
>
> When I checked the result, the entire folder seems to be quarantined:
>
> ilg@wks ~ % cd tmp
> ilg@wks tmp % xattr Eclipse.app
> com.apple.quarantine
> ilg@wks tmp % xattr Eclipse.app/Contents
> com.apple.quarantine
> ilg@wks tmp % xattr Eclipse.app/Contents/Info.plist
> com.apple.quarantine
> ilg@wks tmp %
>
> Similarly, I downloaded
> eclipse-embedcpp-2020-12-M2-macosx-cocoa-x86_64.tar.gz from the same URL.
>
> cd ~/tmp
> mv Eclipse.app Eclipse-dmg.app
> tar xf ~/Downloads/eclipse-embedcpp-2020-12-M2-macosx-cocoa-x86_64.tar.gz
>
> The result is also quarantined, exactly like the previous one.
>
> When opening the two Eclipses for the first time they behaved absolutely
> identically, the user was asked to confirm opening an app downloaded from
> internet, and if confirmed, the two Eclipses appeared equally functional.
>
> Can some other Mac user confirm this behaviour?
>
> I'm using macOS 10.15.7.
>
>
> Thank you,
>
> 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] Commit messages

2020-10-24 Thread Jonah Graham
Perhaps standardize in the recommendations from:

https://chris.beams.io/posts/git-commit/

The seven rules of a great Git commit message

*Keep in mind: This
 has

all

been
 said
 before
.*


   1. Separate subject from body with a blank line
   
   2. Limit the subject line to 50 characters
   
   3. Capitalize the subject line
   
   4. Do not end the subject line with a period
   
   5. Use the imperative mood in the subject line
   
   6. Wrap the body at 72 characters
   
   7. Use the body to explain *what* and *why* vs. *how*
   


On Sat., Oct. 24, 2020, 08:12 Wim Jongman,  wrote:

> Hello,
>
> Andrey recently pointed out on a couple of commits that commit messages
> could be better. I agree with that.
>
> Can we discuss this?
>
> Cheers,
>
> Wim
>
> A list of recent commits is here:
> https://git.eclipse.org/c/platform/eclipse.platform.ui.git/log/
>
>
> ___
> 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] MacOS .dmg vs .tar.gz

2020-10-13 Thread Jonah Graham
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


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

2020-09-18 Thread Jonah Graham
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 matter how hard it is tried it will become harder
> and harder and admitting that can save us quite a lot of frustration. One
> can look at what is the current "extended" support e.g. Firefox does it
> roughly for a year. And we live in that reality - JVMs break API on 6
> months, GTK will have more than a huge change very shortly (4.x), latest
> MacOS requires changing the binaries produced due to new CPU architecture,
> IE is being replaced by Chrome engine powered engine and so on and on. With
> all that said - either projects start working on their deps to keep the
> support for things for longer or it will be gone not because WE WANT to
> remove it but because WE HAVE to in order to throw the next release out and
> keep it working on the new versions of our dependencies.
> P.S. Before anyone brings the paid vs rest developers conversation again I
> want to make smth crystal clear - No one just pays anyone to work on
> whatever he wants in whatever way he wants if you find such a place let me
> know. With faster and faster ecosystem changes an official task (aka being
> paid for) for some of us is "REDUCE MAINTENANCE COST" and getting the blame
> for not going to the extend that someone would like to see it while moving
> like a snake (compared to other projects with which you compete for
> resources) definitely has a positive and thankful effect for spending "my
> own time" (quotes on purpose) trying to keep things going in the least
> disruptive way possible while still preserving people to work on the
> "thing".
> P.S. 2 I would l

[platform-dev] Occasional contributors and "complicated" rules

2020-06-13 Thread Jonah Graham
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


Re: [platform-dev] backporting and building?

2020-06-08 Thread Jonah Graham
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 (https://www.eclipse.org/lists/platform-dev/msg02171.html) that
resulted in this entry on the wiki (
https://wiki.eclipse.org/Platform/How_to_Contribute#Contributing_to_maintenance_release_branches).
It seems you, Andrey and others have similar issues to handle.

I hope the above helps. Let me know if I have misunderstood the direction
you are aiming for.

Jonah

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


On Mon, 8 Jun 2020 at 00:19, Christoph Läubrich 
wrote:

> Just wondering:
>
> You wrote that you are having a RCP application, won't it be easier to
> simply patch the ant version in your final product?
>
> Am 07.06.20 um 16:44 schrieb Homer, Tony:
> > Hi Dani-
> >
> > Thanks for responding.
> >
> > Yes, updating to Ant 1.10.8 mitigates
> > https://nvd.nist.gov/vuln/detail/CVE-2020-1945, which is what I need to
> do.
> >
> > Tony Homer
> >
> > *From: * on behalf of Daniel Megert
> > 
> > *Reply-To: *"Eclipse platform general developers list."
> > 
> > *Date: *Sunday, June 7, 2020 at 1:23 AM
> > *To: *"Eclipse platform general developers list." <
> platform-dev@eclipse.org>
> > *Subject: *Re: [platform-dev] backporting and building?
> >
> > Hi Tony
> >
> > That commit only changes the Ant version in a test class. Is this really
> > what you want to backport?
> >
> > Dani
> >
> >
> >
> > From: "Homer, Tony" 
> > To: "platform-dev@eclipse.org" 
> > Date: 06.06.2020 22:51
> > Subject: [EXTERNAL] [platform-dev] backporting and building?
> > Sent by: platform-dev-boun...@eclipse.org
> >
> > 
> >
> > I have an RCP product that is currently building against 4.15 and due to
> > release timing I cannot update to 4.16 until after the current release
> > cycle.
> >
> > I’d like to backport this fix to 4.15:
> >
> >
> https://git.eclipse.org/c/platform/eclipse.platform.git/commit/?id=4a27c8ad20b921af8df9731037aa756d70d6875f
> >
> > Applying the patch is no problem, but I’ve never built platform before.
> >
> > I’m not sure if I need to check out all the repos or can just checkout
> > one of them.
> >
> > I’m not sure what build command to use.
> >
> > I looked for instructions, but there are none listed on the developer
> > resources page:
> >
> > https://projects.eclipse.org/projects/eclipse.platform/developer
> >
> > I also looked at ci and it helped with the build command, but I couldn’t
> > work out what I need to do to setup my environment:
> >
> > https://ci.eclipse.org/linuxtools/job/linuxtools-master/142/console
> >
> > Is there a doc tha

Re: [platform-dev] [cross-project-issues-dev] SWT on Gtk will require Gtk 3.20+ in 2020-06

2020-05-19 Thread Jonah Graham
On Tue, 19 May 2020 at 01:39, Aleksandar Kurtakov 
wrote:

>
>
> On Tue, May 19, 2020 at 5:17 AM Jonah Graham 
> wrote:
>
>> Hello folks,
>>
>> I am trying to resolve a problem* that only affects Ubuntu 16.04. The
>> announcement to ctoss-project-issues said "All non EOLed Linux
>> distributions are already on Gtk 3.24" - however Ubuntu 16.04 which is EOL
>> in 2024 <https://wiki.ubuntu.com/Releases> uses GTK 3.18
>> <https://packages.ubuntu.com/xenial/libgtk-3-0>.
>>
>> Do we (eclipse dev community) consider Ubuntu 16.04 EOL for Eclipse
>> purposes. If so and if GTK 3.18 isn't really supported going forward I am a
>> lot less likely to invest the time to fix this problem.
>>
>
> Yes, Supported OSes for Eclipse purposes are described at
> https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_16.xml#target_environments
> .  If we go the path of supporting OSes as long as their providers do we
> would still had to support RHEL 6 (even 5) with their GTK 2.x till 2024.
>

Thank you for confirming this.


>
>
>>
>> * If you are interested:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=549013 is the problem I am
>> trying to fix, the existing fix regressed other stuff ( see
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=558536 and its dups ) so I
>> have to back it out and try again. BTW I don't know for sure if it is a GTK
>> problem or an Ubuntu global menu problem or some other interaction
>> between everything.
>>
>
> My first guess would be global menu interaction. You may want to look
> (although we are not adding back support for 3.18) at Menu.gtk_hide/show as
> there is code guarded with OS.ubuntu_menu_proxy_get() != 0 - the work there
> might not be needed or not enough after changes in the menu proxy Ubuntu
> installs.
>

I have a pretty good understanding of what the problem is now and I will be
adding details to the bug. The OP of the bug did provide a fix once, so
they may be motivated to again. The short cause of the problem is that the
accelerator for the top level menus change while the menu is open, causing
the menu to close (i.e. menuitem's text changes from File to ). I have
a small reproducer I will attach to the bug, but that only fails on Ubuntu
16.04 with global menu, so after the hours I have spent investigating and
testing this I am done once I write it up.

Thanks for your help!
Jonah



>
>
>>
>> Thanks for your input,
>> Jonah
>>
>> ~~~
>> Jonah Graham
>> Kichwa Coders
>> www.kichwacoders.com
>>
>>
>> On Thu, 12 Mar 2020 at 05:12, Aleksandar Kurtakov 
>> wrote:
>>
>>> Hey everyone,
>>> SWT min Gtk version is going to be bumped again this release (to require
>>> Gtk 3.20+). All non EOLed Linux distributions are already at Gtk 3.24.
>>> We plan to bump Gtk requirement to 3.24 for September release too.
>>> This is important step so SWT work on GTK4 can be started now and thus
>>> the needs of it being expressed to GTK devs on time so we don't end in the
>>> GTK3 situation when porting SWT to it was started only after GTK 3.0 was
>>> final thus leading to many hacks.
>>>
>>> Work will be handled in
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=561047 .
>>>
>>> --
>>> Alexander Kurtakov
>>> Red Hat Eclipse Team
>>> ___
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-...@eclipse.org
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>
>> ___
>> platform-dev mailing list
>> platform-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
>
>
> --
> Alexander Kurtakov
> Red Hat Eclipse Team
> ___
> 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] SWT on Gtk will require Gtk 3.20+ in 2020-06

2020-05-18 Thread Jonah Graham
Hello folks,

I am trying to resolve a problem* that only affects Ubuntu 16.04. The
announcement to ctoss-project-issues said "All non EOLed Linux
distributions are already on Gtk 3.24" - however Ubuntu 16.04 which is EOL
in 2024 <https://wiki.ubuntu.com/Releases> uses GTK 3.18
<https://packages.ubuntu.com/xenial/libgtk-3-0>.

Do we (eclipse dev community) consider Ubuntu 16.04 EOL for Eclipse
purposes. If so and if GTK 3.18 isn't really supported going forward I am a
lot less likely to invest the time to fix this problem.

* If you are interested:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=549013 is the problem I am
trying to fix, the existing fix regressed other stuff ( see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=558536 and its dups ) so I
have to back it out and try again. BTW I don't know for sure if it is a GTK
problem or an Ubuntu global menu problem or some other interaction
between everything.

Thanks for your input,
Jonah

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


On Thu, 12 Mar 2020 at 05:12, Aleksandar Kurtakov 
wrote:

> Hey everyone,
> SWT min Gtk version is going to be bumped again this release (to require
> Gtk 3.20+). All non EOLed Linux distributions are already at Gtk 3.24.
> We plan to bump Gtk requirement to 3.24 for September release too.
> This is important step so SWT work on GTK4 can be started now and thus the
> needs of it being expressed to GTK devs on time so we don't end in the GTK3
> situation when porting SWT to it was started only after GTK 3.0 was final
> thus leading to many hacks.
>
> Work will be handled in
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=561047 .
>
> --
> Alexander Kurtakov
> Red Hat Eclipse Team
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-...@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-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] making identical changes to multiple platforms for SWT

2020-05-15 Thread Jonah Graham
Thanks Sravan for the info.

On Fri., May 15, 2020, 06:48 Sravan K Lakkimsetti, 
wrote:

> Hi Jonah,
>
>
>
> Please update Javadoc for windows flavour. That will be copied to other
> flavours during Javadoc bash stage. We do run this tool on SWT source
> during RC2 timeframe for each release
>
>
>
> Thanks
>
> Sravan
>
>
>
> *From:* Daniel Megert 
> *Sent:* 14 May 2020 20:41
> *To:* Eclipse platform general developers list. 
> *Subject:* [EXTERNAL] Re: [platform-dev] making identical changes to
> multiple platforms for SWT
>
>
>
> The SWT team runs it once before each milestone. Nothing you have to worry
> about :-)
>
> Dani
>
>
>
> From:Jonah Graham 
> To:"Eclipse platform general developers list." <
> platform-dev@eclipse.org>
> Date:14.05.2020 16:55
> Subject:[EXTERNAL] Re: [platform-dev] making identical changes to
> multiple platformsfor SWT
> Sent by:platform-dev-boun...@eclipse.org
> --
>
>
>
>
> Cool, can you help me find the bash tool? I couldn't find it in the
> repo/wiki, but I am not sure what to look for.
>
> Thanks,
> Jonah
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
>
>
> On Thu, 14 May 2020 at 10:42, Sravan K Lakkimsetti <
> sravankum...@in.ibm.com> wrote:
> For Javadoc we have Javadoc bash tool which synchronizes java doc.
> Unfortunately for code we need to apply changes manually
>
> -Sravan
>
> *From:* Jonah Graham 
> *Sent:* 14 May 2020 20:01
> *To:* Eclipse platform general developers list. 
> *Subject:* [EXTERNAL] [platform-dev] making identical changes to multiple
> platforms for SWT
>
> Hello SWT devs,
>
> I am working on Bug 563018 (Make SWT Colors no longer require disposal)
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=563018> and as part of
> that I need to make the same change to all three os platforms' version of
> Color (and others). Are there tools/scripts/etc that synchronize such
> changes between platforms, or do I need to manually apply the same change
> to each platform?
>
> 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
>
>
>
> ___
> 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] making identical changes to multiple platforms for SWT

2020-05-14 Thread Jonah Graham
Cool, can you help me find the bash tool? I couldn't find it in the
repo/wiki, but I am not sure what to look for.

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


On Thu, 14 May 2020 at 10:42, Sravan K Lakkimsetti 
wrote:

> For Javadoc we have Javadoc bash tool which synchronizes java doc.
> Unfortunately for code we need to apply changes manually
>
>
>
> -Sravan
>
>
>
> *From:* Jonah Graham 
> *Sent:* 14 May 2020 20:01
> *To:* Eclipse platform general developers list. 
> *Subject:* [EXTERNAL] [platform-dev] making identical changes to multiple
> platforms for SWT
>
>
>
> Hello SWT devs,
>
>
>
> I am working on Bug 563018 (Make SWT Colors no longer require disposal)
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=563018> and as part of
> that I need to make the same change to all three os platforms' version of
> Color (and others). Are there tools/scripts/etc that synchronize such
> changes between platforms, or do I need to manually apply the same change
> to each platform?
>
>
>
> 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


[platform-dev] making identical changes to multiple platforms for SWT

2020-05-14 Thread Jonah Graham
Hello SWT devs,

I am working on Bug 563018 (Make SWT Colors no longer require disposal)
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=563018> and as part of that
I need to make the same change to all three os platforms' version of Color
(and others). Are there tools/scripts/etc that synchronize such changes
between platforms, or do I need to manually apply the same change to each
platform?

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


Re: [platform-dev] Saying Goodbye To SWT

2019-12-16 Thread Jonah Graham
Hi Eric,

Good luck on the next step of your journey. You have made a valuable
contribution to SWT and the stability, quality and features of the Eclipse
platform over the last 4+ years!

Enjoy your new role on Che!

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


On Mon, 16 Dec 2019 at 14:07, Eric Williams  wrote:

> Hello everyone,
>
> I have some rather bittersweet news to share: as of this Wednesday I
> will no longer be working on the Eclipse/SWT team at Red Hat. I haven't
> left the company, but I will be moving to a new group where I'll be
> working on Eclipse Che (specifically Che plugins).
>
> SWT was my first journey into professional software development, as was
> the Eclipse team at Red Hat. I have learned a lot over the years, and I
> hold very dear the experiences I have had. I'd also like to thank all of
> you who make SWT and the Eclipse community great -- there are some
> seriously talented people working on the Eclipse Platform, and I believe
> it is better off because of it. It's been an honour to work with all of
> you, and I have full confidence that SWT (and the Eclipse IDE in
> general) will continue to flourish in the future.
>
> I'll be finishing up some Gerrits in the coming days, as well as
> unassigning myself from bugs. I'll keep an ear out for things that I can
> respond to quickly, and I'll still be keeping my commit rights. Other
> than that I'll be officially starting my new duties as of Wednesday
> December 18th.
>
> I've really enjoyed my time here, and I wish you all the best. Don't be
> strangers!
>
>
> Eric
>
> ___
> 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] Changing default IAdapterManager in Platform?

2019-11-29 Thread Jonah Graham
I think the case that Mickael brings up here (which originated from here
<https://github.com/eclipse/wildwebdeveloper/issues/294>) is a case where
the extra context is already being passed in. The adaptableType already has
the context that is needed to properly resolve - however unlike the column
index, depending on the context a different adapter factory can do that
resolution.

> Does anyone have some more knowledge about this area to share whether it
seems like a good idea or not?

I have been tripped up by this in the past, indeed CDT-DSF requires
extenders to arbitrarily extend and reference a subclass so that a unique
adaptable type object can be referenced by the adapter manager/extension
point. It would be nice if any factory could provide such adaptions based
on more than just the type of the adaptable object.

Jonah

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


On Fri, 29 Nov 2019 at 06:57, Alexander Fedorov <
alexander.fedo...@arsysop.ru> wrote:

> Hi Mickael,
>
> This is the common software evolution problem, now we want to consider
> multiple instances instead of the single one.
> We have very similar problem for JFace label/content providers. Let me
> illustrate it with ITableLabelProvider that extends its "contextless"
> parent with methods like:
>
> public Image getColumnImage(Object element, int columnIndex);
>
> So, here we have additional "columnIndex" argument to resolve the image,
> in our case the "context" is as trivial as one int. But we can consider
> passing some Function to generalize it.
>
> I think the same idea may be applied for IAdapter framework : we can add a
> "context" Function to register/resolve  adapters according to the client
> needs.
>
> Regards,
> AF
>
> 29.11.2019 13:10, Mickael Istria пишет:
>
> Hi all,
>
> We've got an interesting case with LSP4E vs LinuxTools, both registering a
> factory with the same signature (adptableType -> adapterType). The dummy
> expectation was that it was legal to have multiple factories and that as
> long as the current factory returns null, another one would be tried and so
> on.
> However, digging in the code of AdapterManager, it's actually keeping
> track of a single adapter factory, ignoring other ones. Which one is used
> is randomish and probably depends on bundle activation order or ordering in
> the extension registry. The AdapaterManager is documented to behave like
> this, we should probably not change it.
> However, the IAdapterManager is more flexible and could allow
> implementations to keep and use multiple factories with same signatures.
> That would resolve our case and would more generally provide much more
> power and flexibility in usage and implementation of adapter factories.
> So I'm considering writing and using in InternalPlatform a new
> implementation of the AdapterManager.
>
> Does anyone have some more knowledge about this area to share whether it
> seems like a good idea or not?
>
> Thanks in advance
>
> --
> Mickael Istria
> Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
> developer, for Red Hat Developers <https://developers.redhat.com/>
>
> ___
> platform-dev mailing listplatform-...@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visithttps://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

Re: [platform-dev] Preparing SWT native code for building from a shell?

2019-07-08 Thread Jonah Graham
PS If the gerrit job for SWT binaries does compile the binaries as part of
that check it may be useful too:
https://ci.eclipse.org/platform/job/eclipse.platform.swt.binaries-Gerrit/
~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Mon, 8 Jul 2019 at 11:57, Jonah Graham  wrote:

> Hi Torkild,
>
> I hope you get some more concrete answers than this, but in the past when
> I have been stuck resolving such issues I have found the build scripts on
> Jenkins used to build very useful. Can you replicate the build machine's
> process? (https://ci.eclipse.org/releng/job/SWT-native-build/):
>
> I think it goes roughly like this (for x86_64):
> ant -f
> eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.x86_64/build.xml
> copy_library_src_and_create_zip
> mkdir buildnatives
> cd buildnatives
> unzip
> ../eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.x86_64/tmpdir/org.eclipse.swt.gtk.linux.x86_64.master.zip
> export MODEL=x86_64
> export OUTPUT_DIR=$PWD/libs
> sh build.sh clean install
> # delete existing libs if present
>
> cp $PWD/libs/* 
> ../eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.x86_64
> # then build the bundles with maven
>
> HTH,
> Jonah
>
> On Sun., Jul. 7, 2019, 19:25 Torkild U. Resheim, 
> wrote:
>
>> Hi Platform developers,
>>
>> I'm picking up an old project of mine again, building the Eclipse
>> Platform for the Raspberry Pi[1].
>>
>> The new Raspberry Pi 4 should be able to cope with the Eclipse IDE much
>> better than the previous versions, although I'm mostly interested in using
>> PiPlug as one can see in the screenshot[2] in a home automation project.
>>
>> I wanted to write a script that did most of the job and came over an
>> issue. In order to build the SWT binaries I first have to import the
>> "eclipse.platform.swt" project into eclipse, rename the ".classpath_gtk"
>> file then do a build in order to prepare the code into the "bin" folder. So
>> I am wondering whether you are aware of a way of doing this step without
>> having to start Eclipse and invoke a build. I would prefer to be able to do
>> everything from a bash script, including copying the files to an actual
>> Raspberry Pi and do the compilation there.
>>
>> I've looked at the "SWT Classpath Builder.launch" code, but I see no way
>> of running that outside of Eclipse. Also replicating what these Ant scripts
>> does, may be a bit of a hassle.
>>
>> Best regards,
>> Torkild U. Resheim
>>
>> [1] https://resheim.net/2013/05/running-eclipse-rcp-applications-on.html
>> [2]
>> https://resheim.net/2014/07/building-eclipse-target-platform-raspberry-pi.html
>> ___
>> 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] Preparing SWT native code for building from a shell?

2019-07-08 Thread Jonah Graham
Hi Torkild,

I hope you get some more concrete answers than this, but in the past when I
have been stuck resolving such issues I have found the build scripts on
Jenkins used to build very useful. Can you replicate the build machine's
process? (https://ci.eclipse.org/releng/job/SWT-native-build/):

I think it goes roughly like this (for x86_64):
ant -f
eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.x86_64/build.xml
copy_library_src_and_create_zip
mkdir buildnatives
cd buildnatives
unzip
../eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.x86_64/tmpdir/org.eclipse.swt.gtk.linux.x86_64.master.zip
export MODEL=x86_64
export OUTPUT_DIR=$PWD/libs
sh build.sh clean install
# delete existing libs if present
cp $PWD/libs/* 
../eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.x86_64
# then build the bundles with maven

HTH,
Jonah

On Sun., Jul. 7, 2019, 19:25 Torkild U. Resheim,  wrote:

> Hi Platform developers,
>
> I'm picking up an old project of mine again, building the Eclipse Platform
> for the Raspberry Pi[1].
>
> The new Raspberry Pi 4 should be able to cope with the Eclipse IDE much
> better than the previous versions, although I'm mostly interested in using
> PiPlug as one can see in the screenshot[2] in a home automation project.
>
> I wanted to write a script that did most of the job and came over an
> issue. In order to build the SWT binaries I first have to import the
> "eclipse.platform.swt" project into eclipse, rename the ".classpath_gtk"
> file then do a build in order to prepare the code into the "bin" folder. So
> I am wondering whether you are aware of a way of doing this step without
> having to start Eclipse and invoke a build. I would prefer to be able to do
> everything from a bash script, including copying the files to an actual
> Raspberry Pi and do the compilation there.
>
> I've looked at the "SWT Classpath Builder.launch" code, but I see no way
> of running that outside of Eclipse. Also replicating what these Ant scripts
> does, may be a bit of a hassle.
>
> Best regards,
> Torkild U. Resheim
>
> [1] https://resheim.net/2013/05/running-eclipse-rcp-applications-on.html
> [2]
> https://resheim.net/2014/07/building-eclipse-target-platform-raspberry-pi.html
> ___
> 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] failed gerrit for reasons I don't understand

2019-06-25 Thread Jonah Graham
Hi folks,

I submitted a gerrit <https://git.eclipse.org/r/#/c/96800/> and it failed,
but I don't think I caused this issue. Can someone with more knowledge
comment. This is the error (console link
<https://ci.eclipse.org/platform/job/eclipse.platform.ui-Gerrit/19053/console>
):

*14:44:36* [INFO] *--- tycho-eclipserun-plugin:1.4.0:eclipse-run
(api-analysis) @ org.eclipse.e4.ui.workbench ---
**14:44:36* [INFO] Toolchain in tycho-eclipserun-plugin:
JDK[/opt/public/common/jdk1.8.0_x64-latest/jre]*14:44:36* [INFO]
Expected eclipse log file:
/home/cbi/genie.platform/workspace/eclipse.platform.ui-Gerrit/bundles/org.eclipse.e4.ui.workbench/target/eclipserun-work/data/.metadata/.log*14:44:36*
[INFO] Command line:*14:44:36*
[/opt/public/common/jdk1.8.0_x64-latest/jre/bin/java, -Xmx2048M,
-jar, 
/home/cbi/genie.platform/workspace/eclipse.platform.ui-Gerrit/.repository/p2/osgi/bundle/org.eclipse.equinox.launcher/1.5.400.v20190515-0925/org.eclipse.equinox.launcher-1.5.400.v20190515-0925.jar,
-install, 
/home/cbi/genie.platform/workspace/eclipse.platform.ui-Gerrit/bundles/org.eclipse.e4.ui.workbench/target/eclipserun-work,
-configuration,
/home/cbi/genie.platform/workspace/eclipse.platform.ui-Gerrit/bundles/org.eclipse.e4.ui.workbench/target/eclipserun-work/configuration,
-data, 
/home/cbi/genie.platform/workspace/eclipse.platform.ui-Gerrit/bundles/org.eclipse.e4.ui.workbench/../target/org.eclipse.e4.ui.workbench-apiAnalyzer-workspace,
-application, org.eclipse.pde.api.tools.apiAnalyzer, -project,
/home/cbi/genie.platform/workspace/eclipse.platform.ui-Gerrit/bundles/org.eclipse.e4.ui.workbench,
-baseline, default, -dependencyList,
/home/cbi/genie.platform/workspace/eclipse.platform.ui-Gerrit/bundles/org.eclipse.e4.ui.workbench/target/dependencies-list.txt,
-failOnError]*14:44:48* Some blocking (most likely link/compilation)
errors are present:*14:44:48* * Marker [on:
/org.eclipse.e4.ui.workbench/plugin.xml, id: 196, type:
org.eclipse.pde.core.problem, attributes: [categoryId: , compilerKey:
compilers.p.unresolved-ex-points, lineNumber: 70, message: Unknown
extension point: 'org.eclipse.ui.trace.traceComponents', problemId:
4135, severity: 2], created: 6/25/19 2:44 PM]*14:44:48* Some blocking
(most likely link/compilation) errors are present ^^^*14:44:49* [INFO]



Thanks,
Jonah

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com
___
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] [SWT] Bugzilla etiquette question

2019-06-18 Thread Jonah Graham
On Tue, 18 Jun 2019 at 08:46, Becker, Matthias  wrote:

> Hi all,
>
> I don't know how to do this: "Interested committers should register for
> bug updates or incoming Gerrits of there component."
> Can you please explain?
>
>
To be clear, there is no way other than following the email/account for
register for bug updates. (Gerrit does have the option as previously
mentioned.) So if the bug creator removes the *-inbox@ email address there
is no way easy way for people to be automatically notified.

However, if there is concern about people changing the assignee before
creation, then the *-inbox@ email address can be added to the default CC
for the components. The default CC cannot be changed until after bug is
created AFAIK. This can be done on the bugzilla management page (for
committers): https://dev.eclipse.org/committers/bugs/bugz_manager.php

HTH,
Jonah
___
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] Jenkins build failure: All available display numbers are allocated or blacklisted

2019-06-10 Thread Jonah Graham
Dani has pointed you to the immediate fix (needs reboot with displays
cleared because some display numbers have not been returned to pool
properly).

The underlying bug is related to how the VNC plug-in for Jenkins is
written. The Display numbers are not a resource that Jenkins knows how to
wait on, so the build runs when it has an executor to run it, but will then
fail. To resolve that would need work on Jenkins side, see
https://plugins.jenkins.io/xvnc for the plug-in details. Realistically no
one is likely to fix the xvnc plug-in (last had a release 3 years ago).

The "modern" solution to this will be converting the platform CI instance
to run on openshift so that the xvnc plug-in is dropped from use. That is
what we are doing on CDT now and we haven't seen this particular error
since. (I don't know how much effort that conversion is, and/or if it is
scheduled to happen?)

Jonah

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


On Mon, 10 Jun 2019 at 06:22, Rolf Theunissen 
wrote:

> Hi,
>
> Lately I had many builds fail with the error below. Apparently, the number
> of displays is to low. Moreover, I would rather have my build wait in the
> build queue for displays to become available, than fail like this.
>
> Does anybody have an idea how to fix this?
>
> Best regards,
> Rolf Theunissen
>
> *12:11:44* Triggered by Gerrit: https://git.eclipse.org/r/142555*12:11:44* 
> Building remotely on centslave2 
> <https://ci.eclipse.org/platform/computer/centslave2> (centos) in workspace 
> /home/cbi/genie.platform/workspace/eclipse.platform.ui-Gerrit@2*12:11:44* 
> [WS-CLEANUP] Deleting project workspace...*12:11:44* [WS-CLEANUP] Deferred 
> wipeout is used...*12:11:44* [WS-CLEANUP] Done*12:11:44* No credentials 
> specified*12:11:44* Cloning the remote Git repository*12:11:44* Cloning 
> repository 
> git://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git*12:11:44*  > 
> /usr/local/bin/git init 
> /home/cbi/genie.platform/workspace/eclipse.platform.ui-Gerrit@2 # 
> timeout=10*12:11:44* Fetching upstream changes from 
> git://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git*12:11:44*  > 
> /usr/local/bin/git --version # timeout=10*12:11:44*  > /usr/local/bin/git 
> fetch --tags --progress 
> git://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git 
> +refs/heads/*:refs/remotes/origin/**12:12:15*  > /usr/local/bin/git config 
> remote.origin.url 
> git://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git # 
> timeout=10*12:12:16*  > /usr/local/bin/git config --add remote.origin.fetch 
> +refs/heads/*:refs/remotes/origin/* # timeout=10*12:12:16*  > 
> /usr/local/bin/git config remote.origin.url 
> git://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git # 
> timeout=10*12:12:16* Fetching upstream changes from 
> git://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git*12:12:16*  > 
> /usr/local/bin/git fetch --tags --progress 
> git://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git 
> refs/changes/55/142555/2*12:12:20*  > /usr/local/bin/git rev-parse 
> 26d66074608c9a32f9c35c5cdd0743c5d71896f7^{commit} # timeout=10*12:12:20* 
> JENKINS-19022: warning: possible memory leak due to Git plugin usage; see: 
> https://wiki.jenkins-ci.org/display/JENKINS/Remove+Git+Plugin+BuildsByBranch+BuildData*12:12:20*
>  Checking out Revision 26d66074608c9a32f9c35c5cdd0743c5d71896f7 
> (refs/changes/55/142555/2)*12:12:20*  > /usr/local/bin/git config 
> core.sparsecheckout # timeout=10*12:12:20*  > /usr/local/bin/git checkout -f 
> 26d66074608c9a32f9c35c5cdd0743c5d71896f7*12:12:21* Commit message: "Bug 
> 485167 - Towards running DynamicPluginsTestSuite with UiTestSuite"*12:12:21*  
> > /usr/local/bin/git rev-parse FETCH_HEAD^{commit} # timeout=10*12:12:21*  > 
> /usr/local/bin/git rev-list --no-walk 
> 1ab6d2484ee0dc9383bc15b651f392188740479e # timeout=10*12:12:22* FATAL: All 
> available display numbers are allocated or blacklisted.*12:12:22* allocated: 
> [160, 161, 162, 163, 164, 165, 166, 167, 168, 169]*12:12:22* blacklisted: 
> []*12:12:22* java.lang.RuntimeException: All available display numbers are 
> allocated or blacklisted.*12:12:22* allocated: [160, 161, 162, 163, 164, 165, 
> 166, 167, 168, 169]*12:12:22* blacklisted: []*12:12:22*at 
> hudson.plugins.xvnc.DisplayAllocator.doAllocate(DisplayAllocator.java:59)*12:12:22*
>   at 
> hudson.plugins.xvnc.DisplayAllocator.allocate(DisplayAllocator.java:49)*12:12:22*
> at hudson.plugins.xvnc.Xvnc.doSetUp(Xvnc.java:106)*12:12:22*at 
> hudson.plugins.xvnc.Xvnc.setUp(Xvnc.java:96)*12:12:22*   at 
> jenkins.tasks.SimpleBuildWrapper.setUp(SimpleBuildWrapper.java:146)*12:12:22* 
>at hudson.model.Build$BuildExecution.doRun(Build.java:1