Re: [platform-dev] PMC Approval required for Committer Election for Elsa Zacharia on Eclipse Platform
Hi all, I realize because of this notification I forgot about it and didn't vote here. Sorry about that, I should definitively have added a +1 to Elsa earlier. Thanks and welcome Elsa! On Tue, Feb 13, 2024 at 6:05 AM emo--- via platform-dev < platform-dev@eclipse.org> wrote: > The Committer Election for Elsa Zacharia on project Eclipse Platform > (eclipse.platform) concluded successfully. > > PMC leads and members can click the election link below to review and > approve. > > Election: > > https://projects.eclipse.org/projects/eclipse.platform/elections/election-elsa-zacharia-committer-eclipse-platform > > Project: https://projects.eclipse.org/projects/eclipse.platform > > ___ > platform-dev mailing list > platform-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev > > -- Mickael Istria Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat <https://developers.redhat.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 to erase current fork and create new one
Hi, You can just delete all branches from your fork and create new ones. ___ 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] Avoid code freezing in master?
Hi, Back in the time before Git, I would have strongly advocated that we do maximum effort to never shutdown the "master" branch, when it was more or less hosting all the development. Now, we have pretty nice branching, and PRs, with builds on PRs... so that developing on a branch provides everything necessary. But I imagine that what I mention as "everything" is missing at least 1 thing, or you wouldn't have asked ;) So the question is: what do you think is missing during this time which makes you less efficient? "Just" a complete SDK build including some extra commits you'd like to test? If it is so, I'm afraid it would be hard for the project to provide it as Alex mentioned: maintaining 2 build branches in parallel is beyond the current human capacity of the project, and contributing to SimRel/EPP and then starting a new versions does actually require a lot of tedious and error-prone work, which can itself justify the freeze (which is bringing some quietness and less distraction to the releng duties for those to be handled as best). But if the requirement is " a complete SDK build including some extra commits you'd like to test", then I think we can uncouple it from the build infra, and instead evaluate possible approaches to more easily build a custom SDK, or patch an existing one, with locally built bundles. I'm don't know yet what a technical solution could be, but as mentioned, I think it shouldn't rely on the freeze/release/I-Build process for that; it'd better be something easy enough to do on user's end. 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] Moving bundles with history from a Git repo to another
Hi all, I've been asked a couple times how to migrate some folders (eg bundles) from a Git repository to another, and this preserving the history. While I don't remember the exact details, here are the steps I've carried on: * from the *source* Git repo ** Make sure you're on latest master ** use "git filter-repo" (from https://github.com/newren/git-filter-repo/ ) to just keep the subpart of the repository you need, basically passing the directories you want to keep ** check the content of the repo on the filesyste, ** check `git history` for a long time, to ensure that history seems to contain relevant things only and that the history seems complete (basically the 1st commit of legacy history is still visible -with a different hash though- in the filtered history) ** `git push myFork HEAD:refs/heads/filtered-repo` * From the *target* repo ** Make sure you're on latest master ** add your local fork of source repo as remote `git remote add myForkOfSourceRepo git://github.com/me/sourceRepo` ** `git fetch myForkOfSourceRepo filtered-repo` ** `git merge --allow-unrelated-history FETCH_HEAD` (leave default merge commit and message) ** Fix various pom.xml, bump versions.,, as needed until local build work ** `git add ` changes then `git commit -m "Adapt releng for move of X, Y, Z from sourceRepo` ** Push to your fork ** Create a PR * From the source repo ** Get back to latest master ** Remove all moved content ** Adapt pom.xml and so on until build works ** Commit ** Create PRs * On each of both PRs, add a link to the other one, as they will need to be merged at the same time * Once PRs are merged, trigger an I-Build and hope for a successful build in the next 40 minutes; or fix. HTH -- Mickael Istria Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat <https://developers.redhat.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] Creating new Bundle
Hello, Just clone https://github.com/eclipse-platform/eclipse.platform/ , add your content in team/bundles, then `git commit` it and make a PR. HTH ___ 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] Disable SVG support on Linux?
Hi, I'm not aware of a particular option to disable SVG support. However, there might be some bug somewhere causing this latency. Feel free to open an issue with steps to reproduce and a jstack taken duringt the freeze so this might be investigated. Maybe there are some parts of SVG loading that could be run in another non-Ui thread? ___ 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] [platform-releng-dev] Process for a security/bugfix release for the Eclipse Platform
Hi, On Tue, Jul 18, 2023 at 6:04 PM Marta Rybczynska via platform-releng-dev < platform-releng-...@eclipse.org> wrote: > Would a security fix need to wait for next 3-month release? This could be > in conflict with the 90 days vulnerability release policy. Consider this > scenario: > - A vulnerability is reported two weeks before the release and the team > needs some time to prepare a fix. > - The fix is ready one month after the release > - 90 days will come two weeks BEFORE the next release > Releasing a vulnerability information to the public without a release > fixing it is against best practices and it would be beneficial to avoid it. > > Do you consider running a separate bugfix release? > So far, with the current processes and maintainers, the answer is no. This 90 days vulnerability release process cannot work for Eclipse Platform in some cases. However, as usual, if someone is willing to take care of doing security releases to enforce this, then it would be welcome. Could you please point me to documentation/discussions on how you do handle > or would handle such a situation? > If we want to comply with a 90-days vulnerability release process, I see only 2 solutions: either more frequent releases (ie moving Platform to 2-months releases) or someone actually willing to take care of producing security releases. None is something that can be done trivially as they all have impact or requirements that may not be in the best interest of the current maintainers. HTH ___ 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] Immediate feedback on ecj changes for jdt and platform build
Hi Andrey, all, Thank you for doing this. While I'm doing investigation work on ECJ, this has proven to be very helpful! Cheers, ___ 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-dev] Master branch is open for 4.29 development
Thanks! ___ 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 Build
Hi, Please see https://wiki.eclipse.org/Platform-releng/Platform_Build for explanation of how to build the Eclipse Platform and https://github.com/eclipse-platform/eclipse.platform.swt/wiki/Devel-GTK-Dev-guide for particular GTK stuff. The version of SWT was bumped by +0.1.0 during last cycle, which means it has new APIs and some bundles are probably consuming those new API; so by auditing the version, it seems like the combination you wish to achieve (latest platform with old SWT) is then not possible. With the link above and good knowledge of Maven, Tycho and PDE, you may be able to hack something to enforce another locally built version of SWT, but overall it will be annoying and difficult for questionable value. If you can make a PR that fixes https://github.com/eclipse-platform/eclipse.platform/issues/212 while still working with supported environments, there are chances that it get merged and than part of the official build. This is IMO the most profitable path forward, although it's not certain it can work. Note that if you're stuck in an environment that is not supported anymore, you may consider alternative distributions of Eclipse IDE, such as Flatpak one; with such container-like installations, most libs -including GTK- are supposed to be included in a compatible way. https://flathub.org/apps/org.eclipse.Java . HTH Mickael ___ 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] [ide-dev] Progress with JDT-LS in Eclipse IDE integration
> Do other languages also benefit from this work or is it a java specialization? Other language server/debug adapter integrations cam benefit from it when the case is handled by "standard" LSP, and the code that handles it is in LSP4E or LSP4J. We recently found a very subtle bug in eclipseide-jdtls (as JDT-LS extensively uses some particular LSP construct, more than other LS integrations we're gardening), and could fix this bug in LSP4E, so the fix is profitable to other integrations as well. And same goes for Generic Editor, and I suspect soon for Platform Debug UI. HTH ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
[platform-dev] Progress with JDT-LS in Eclipse IDE integration
Hello, For those interested, I'm willing to share some progress with the experimental alternative of Java Tooling in Eclipse IDE, which relies on JDT-LS and LSP4E integration in Generic Editor instead of JDT-UI for edition, and -quite recently- on the java-debug-adapter (which implements the Debug Adapter Protocol on top of the JDT Debug JDI Model) and the DAP integration part of LSP4E in Eclipse Platform Debug instead of JDT specific Debug UI. The current state of things is rather encouraging: it's now possible to efficently enough edit Java code in Eclipse IDE with the Generic Editor and JDT-LS (as long as the code is included in a Java project); most features are working well. However, in real-life usage, we can easily identify some important features of JDT-UI that are missing and yet to implement (my top 1 is currently Ctrl+Shift+O not doing anything in generic editor); there are also some more or less annoying glitches here and there. Similar thing for debug support: there is a decent Debug support, but it's rather fresh, so no support for Launch Configurations, no particular support for anything beyond running a Java main, missing Inspect... however when an application is running with the Debug Adapter, there are stack traces, breakpoints, variables & Inspect... working, so it's usable. But again, it's not as good as direct JDT UI, it's still relatively frequent to switch back to JDT editor for some feature. This is the current goal really make it never necessary to switch back to JDT editor. On the other and more successful hand, the promise of "low-cost" integration is fulfilled, implementing that has been relatively cheap, it's been easy to create much value (assuming we don't compare to JDT UI/Debug but think of what is possible "from scratch") within a few weeks. And the other promise of factorization is also fulfilled: working on that integration has actually triggered bugfixes/features proposals in JDT-LS, JDT-Core, LSP4E, Platform... and each of this change actually benefits the ecosystem more widely (eg JDT-UI can benefit from some improvements that have been proposed while improving eclipseide-jdtls integration). This approach allows our team of Eclipse contributors at Red Hat to properly serve the goals given by our company while still serving the Eclipse ecosystem the best we can. We'll keep working on this approach for a while. So if you're interested in trying it, and maybe even contributing, the entry point is https://github.com/redhat-developer/eclipseide-jdtls . Cheers, -- Mickael Istria Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat Developers <https://developers.redhat.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] Review practice
On Thu, Mar 30, 2023 at 1:40 PM Sebastian Zarnekow < sebastian.zarne...@gmail.com> wrote: > Hi there, > > It might be my poor understanding of the current process, so I'm asking > here on the mailing list: > Are reviews a prerequisite for stuff that's supposed to be merged into > platform? > A working build+test is usually a requirement. Peer reviews are not a prerequisite for committers, but it's still a good practice to get someone else to look at a patch before merging, even for committers. For non-committers, a review/approval from a committer is a requirement before a merge anyway. HTH ___ 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] Reusing generic editor features in JDT
Hi, Interested people can look at https://github.com/mickaelistria/eclipse.jdt.ls.client and install it from https://marketplace.eclipse.org/content/jdt-language-server-client-eclipse-ide . It's still immature, but it works and allows to get the generic editor working with JDT-LS in the Eclipse IDE, with or without JDT-UI. Cheers, On Sat, Nov 19, 2022 at 10:24 AM Gayan Perera wrote: > Hi all, > > This is really good news. If we can phase out jdt.ui and may be make it a > light weight UI layer just to support additional custom JDT protocol parts > in LSP, the JDT.LS will heavily benefit since we don't need to always > change both jdt.ui and jdt.ls when we need to implement a new feature. > > Best regards, > Gayan. > > On Fri, Nov 18, 2022 at 12:43 PM Mickael Istria > wrote: > >> Hi all, hi Gayan, >> >> I'm reviving this old thread that is the most relevant place to share >> some progress: >> In https://github.com/rgrunber/eclipse.jdt.ls.client (there is a p2 repo >> linked), you can see some progress on the topic of using JDT-LS in Eclipse >> IDE. >> Currently, it just starts JDT-LS externally, from a separate installation >> as a separate process (similarly to what Wild Web Developer does with >> LemMinX); but it already does a decent bit of work that way. In the code, >> you can also find code that has tried to start JDT-LS in the same process >> as the workspace, and this seems to be both tricky and technically >> interesting; some issues were reported to JDT-LS about how this kind of >> integration can be made to work, but this is not trivial. The first >> iteration was then to keep the easier separate-process approach, but I (and >> others are welcome to join) will try to keep investigating having JDT-LS in >> the same process because I see major potential benefits in this. >> 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 > -- Mickael Istria Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat Developers <https://developers.redhat.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] Retriever a build on eclipse.platform
Hi, You simply need to login, go to the particular build page and you should see a "rebuild" or "retrigger" icon on the left that you can click. I don't think it's worth documenting it in Platform as it's purely about Jenkins usage which is really well documented by the Jenkins project itself. ___ 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] Selection hard to see on Linux (dark theme)
Hi, If it's an issue you can reproduce with all text editors, it would be https://github.com/eclipse-platform/eclipse.platform.text ; it it's specific to JDT then https://github.com/eclipse-jdt/eclipse.jdt.ui/ HTH ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
[platform-dev] A future without source features?
Hi all, I'd like to raise to general awareness a technical proposal for Platform and others, that I believe is worth progressively going mainstream as it's a noticeable simplification to multiple processes, and that is very likely to be achievable in a short timeframe. Basically, the idea is to get rid of source features. Indeed, source features are not so important artifacts per se, what really matters is making source bundles available at build-time (to include them in p2 repositories or products) and at dev-time (to make them available in the IDE). But nowadays, none of those do require source features: Tycho now has a cool "includeAllSources" flag on the tycho-p2-repository-plugin https://tycho.eclipseprojects.io/doc/latest/tycho-p2/tycho-p2-repository-plugin/assemble-repository-mojo.html#includeAllSources that allows to (drumroll) include all sources available from the reactor or the target-platform for each bundle of the resulting p2 repository; and PDE already has capability to find locally available source bundles in the .target or the installation path and will soon have ability to resolve more source bundles from target-platform on demand: https://github.com/eclipse-pde/eclipse.pde/pull/425. Moreover, the m2e intergration with PDE makes that source bundles also become available locally when the artifact originates from a Maven repository. All that make that instead of managing source feature artifact, we have workflows to make source features available to the user basically with just 1 flag at build time. On Platform, this would allow to avoid lots of "touch" commits when an external version of a dependency changes; we can stop listing transitive deps in feature.xml (p2 resolves them) but still have their source bundles in p2 repo (Tycho adds them). Of course, things are rarely perfect on 1st shot; but the more people try to make it perfect, the more it is likely to become so. To get there, anyone interested please consider trying those new capabilities and report issues. In the best case, you may be able to get rid of source features and some build customization; in the worst case you'll report issue. Cheers, -- Mickael Istria Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat Developers <https://developers.redhat.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] Reusing generic editor features in JDT
Hi all, hi Gayan, I'm reviving this old thread that is the most relevant place to share some progress: In https://github.com/rgrunber/eclipse.jdt.ls.client (there is a p2 repo linked), you can see some progress on the topic of using JDT-LS in Eclipse IDE. Currently, it just starts JDT-LS externally, from a separate installation as a separate process (similarly to what Wild Web Developer does with LemMinX); but it already does a decent bit of work that way. In the code, you can also find code that has tried to start JDT-LS in the same process as the workspace, and this seems to be both tricky and technically interesting; some issues were reported to JDT-LS about how this kind of integration can be made to work, but this is not trivial. The first iteration was then to keep the easier separate-process approach, but I (and others are welcome to join) will try to keep investigating having JDT-LS in the same process because I see major potential benefits in this. Cheers, ___ 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] Drop usage of useJDK=BREE?
On Sunday, September 18, 2022, Christoph Läubrich wrote: > A recent bug in Tycho has reveled that actually the useJDK=BREE option is broken for Java 9+ and instead "only" a release build was performed in contrast to using the "real" JVM. > > As no one seem to noticed this for a long time, I wonder if we should simply drop useJDK=BREEom platform builds except for Bundles that require Java 8 and only enable it there (I think its only equinox using Java8? -1. Let's instead make useJDK=BREE work as expexted. This is an important part to guarantee correct compatibility and requirement declaration, we've just been lucky to not break things in the meantime while this is/was not working, but this check is still desirable. -- Mickael Istria Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat Developers <https://developers.redhat.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] Reusing generic editor features in JDT
On Wed, Sep 7, 2022 at 2:29 PM Gayan Perera wrote: > another question is the is it worth to spend time on improving the jdt ui > parts when more things are happening in vscode java ? I do not know and wouldn't dare betting on one or the other ;) But I can share some personal impressions: I think that by nature of how JDT can integrate natively in Eclipse IDE, it is and will always be more capable of deeper and more powerful integration than what LSP and vscode-java will ever be capable of achieving. Having access to ICompilationUnit in the UI is extremely more powerful than whatever LSP will ever be able to specify. Because of that, if we're to implement a crazy new UI approach for Java development, then it will be easier and faster to achieve with JDT-UI than with vscode-java; and so I think JDT UI is still here to stay and also here to grow. But growing doesn't mean sticking to the current state, it can also mean that for some operations, if we're happy with the generic LSP-based implementation, then JDT-UI could drop some of its specific workflows/UIs and adopt common LSP ones. So on the long run, I would imagine JDT UI dropping progressively some of the most "basic" things that LSP does equally well (but I don't think it's that many things...); and focusing on advanced and powerful integration that cannot be achieved with LSP; basically expressing more added-value. > Since JDT UI contains many features and trying built aside on top of > generic editor might seems like building another vscode java on eclipse > isn’t it ? Yes, it's kind of it. I imagine Java development in Eclipse IDE could become like vscode-java on Eclipse IDE + some very advanced features provided by JDT-UI that cannot be achieved through LSP. When looking more and more extensions for java echo system is popping up > and eclipse extensions are rarely updated. > Extensions being rarely updated is also an indicator of Platform and extension stability. I used to care too much about such metrics; but my personal and I think definitive conclusion on it is that they're worth nothing and are just data used and misused by people in a way that serves their own business goals (ie there is a goal and some people build an interpretation of the data that serve this goal, but could easily have build an opposite interpretation of the data if it were to serve another goal) more than data that is actually analyzed objectively to identify opportunities for real technical progress. The only data that I think matters is the amount and diversity of code contributors. Cheers, ___ 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] Reusing generic editor features in JDT
On Wed, Sep 7, 2022 at 12:39 PM Gayan Perera wrote: > Thanks for the feedback, do we have support in the lsp4e to start a LS > in-process? Specially if the LS implementation is java ? > There is no API for that, but in LSP4E tests, the MockConnectionProvider shows how to start an LSP4J-based language server in same process and bind/pipe the streams together. So maybe just copying it and using the JDTLanguageServer instance instead of the MockLanguageServer would work. It would be great if you publish such code in a dedicated public GitHub repo. I'll happily join the effort occasionally. ___ 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] Reusing generic editor features in JDT
On Wed, Sep 7, 2022 at 11:56 AM Gayan Perera wrote: > Hi all Hi, I see that generic editor is getting more features similar to vscode editor > with tm4e. Is there a way that we can slowly migrate jdt editor to use the > generic editor ? Any ideas or hints ? > I think it's way too early to start thinking about a migration. But it's definitely the right time to start investigating this topic further. A first step would be to try get JDT-LS started in Eclipse IDE (in the same process, not as a separate one so the Java model is shared between JDT-LS and JDT UI!). With that, it would allow the Generic Editor to provide edition features similar to what vscode-java offers, based on the LSP stuff, but still to also get the JDT UI features (which are mostly commands, builders and other stuff) working on the same model. So things like build and existing refactoring wizards and so on would be able to work on the Generic Editor that would "only" deal with edition assistance. Once this starts to work, then we can try a feature gap analysis to find out whether the gap can be filled. If it appears the gap is easy to fill, then we can start discussing about the strategy regarding editor(s). > I’m mainly focused on having mote generic views and editors features in > eclipse platform to make different language experience some what similar. > That is indeed one of the purpose of Generic Editor. ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
[platform-dev] Blocker issue for 4.25
Hi all, https://github.com/eclipse-platform/eclipse.platform.debug/issues/77 is a major regression in current I-Build. It's a blocker for 4.25. Contributions to remediation are welcome (on the ticket). Cheers, -- Mickael Istria Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat Developers <https://developers.redhat.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] Proposed API contract change for UIEvents.* interfaces
Hi all, I've suggested https://github.com/eclipse-platform/eclipse.platform.ui/pull/219 which is expected to facilitate addition of extra events in the e4 workbench. It's only a change in API contract (no actual payload/breaking change at runtime). The impact would be that some people would then see some API Tools error is they do implement the interface; but this change is backward compatible. Please add your concerns or approval to this issue. If there is no concern, I'll probablu merge it by the end of this week or next week. Cheers, -- Mickael Istria Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat Developers <https://developers.redhat.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] [pde-dev] PDE and GitHub
Hi Vikas, Like Lars, I'm also unsure adding more tickets and bureaucracy as a requirement will help the committers in being more efficient. Can you please explain the current problems that you or others face with tracking in the current state? Maybe we can find some tricks (eg GitHub queries) to satisfy you needs without requiring an issue for every PR if the contributor didn't reporting an issue a-priori was useful. Cheers ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] Better spellings support for code editors
Hi, On Mon, Jun 27, 2022 at 9:35 PM Jonah Graham wrote: > 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. > While I'm 100% agreeing with this, I'm unsure how things currently work. What are the parts of the JDT spell-checker that have JDT specific code and require replacement by CDT specific code? I imagine that it would be possible to let language support add document annotation on "spell-checkable" areas and let a generic spell-check process those. ___ 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-dev] Eclipse and Equinox 4.24 (2022-06) are available
>- > > https://download.eclipse.org/releases/2022-06/202206151000/plugins/org.eclipse.jetty.io_10.0.9.jar > (also >other jetty plugins) >- > > https://download.eclipse.org/releases/2022-06/202206151000/plugins/org.osgi.util.function_1.2.0.202109301733.jar >- > > Those are upstream jars as shipped by upstream projects on Maven. They are signed in p2 metadata using PGP. See https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2Fp2_pgp.html for a more detailed explanation. HTH ___ 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 vscode light theme for eclipse
> > Can you please detail what are those things? > > Usually I work a considerable amount in the debug perspective, > inspecting many different files, libraries, having outlines and type > hierarchies and looking at log outputs with hundred of projects. > This would still be possible, the debug perspective button is on the left column, and you'd get the usual 4 tabfolders. > Also the Git Stagin is something I have enabled for each and every > perspective I use, in some rare cases I maximize a view but most of the > time there are multiple ones that are important to me. > The proposal doesn't prevent that, it's really only about hiding/moving some coolbars and changing colors. The perspective things remain preent and usable. You could already do it yourself in your workbench: move the perspective switch, the run buttons, hide toolbar, make fullscreen and you get most of what Gayan's screenshot shows, except the colors. So having just one code editor and nothing else beside some collapsed > projects is something you will almost never see on my screen if I'm not > trying to came up with the most minimal reproducer in a workspace I have > just created right now. This is not what the proposal is about. ___ 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 vscode light theme for eclipse
On Mon, May 30, 2022 at 10:15 AM Christoph Läubrich wrote: > > * some "hype" colors > > ?? Searching for "hype" colors gives me some strange results about > make-up vendors :-D > Well hype==VSCode in the IDE world. But we all know VSCode is also a lot of make up over a traditional workbench, so you weren't that far ;) > Don't get me wrong but what are the stuff in the edges then? Perspective and view shortcuts. > By the way, Eclipse do not uses toolbars but 'coolbars' already, but does > it change > anything if we do not call them "toolbar" anymore? > The menu still says "Show/Hide Toolbar", we're talking about the top toolbar here, with many buttons in it. Whats the point of this? Do I need to learn all 18.058 Shortcuts in the > future to use Eclipse? > Or use Ctrl+3. Just like people who use VSCode do happily use Ctrl+P. > * Moved run shortcuts to the bottom > > Whats the advantage of this, beside that it collides with usual Os > (windows / linux) task bar now? > Not really an advantage, more noticeable a side-effect of toolbar removal. > * persective switcher collapsed on the left > > Seems like a personal preference or is there any advantage? > We're actually discussing all that. And personal preferences do matter, but the opportunity is to ship here something disrupting that in the end most people are likely to prefer because it looks lighter/fresher. Having preferences on the left (or somewhere else) allows to remove them from toolbar and hide toolbars without loosing perspective switch. It's the current convention in VSCode, Theia, (upcoming) IntelliJ... > > > -IMO- without loosing any usability (once users have learned about > Ctrl+3). > > I think this is arguable, I need Eclipse to *work* I don't need it to > look great on a screenshot in the web... > So please argue why this would then make Eclipse not working. So from that screenshot, I'm missing most of the stuff I need to work > with Can you please detail what are those things? ___ 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 vscode light theme for eclipse
On Mon, May 30, 2022 at 9:47 AM Christoph Läubrich wrote: > All I can see is a screenshot which seems to collapse some things to the > bottom in contrast to the usual left right? > Also: * some "hype" colors * no more toolbar * no more menu * Moved run shortcuts to the bottom * persective switcher collapsed on the left All that makes UI feel lighter without loosing any functionality, and -IMO- without loosing any usability (once users have learned about Ctrl+3). I think all those are good ideas that deserve to be discussed -maybe individually- as things we could bring to the default workbench layout and theme. I particularly like getting rid of the toolbar. As people don't like Eclipse icons because they "look like they're from the 90's", it's good to hide most of them and much simpler than trying to change them all. ___ 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] [ide-dev] New vscode light theme for eclipse
Thanks Gayan, I've evolved my local workbench to look a bit more like the one you suggested, hiding toolbars, making it fullscreen by default... So far so good. Maybe it's the kind of refreshment we need for the IDE to look much leaner without really changing anything: shipping a different default layout, without toolbar, moving the run and perspective someplace else...? We could even make it default in the SDK as long as it's not breaking any form of functionality/extensibility (sure it's disruptive, but not worse and also not too hard for users to restore to previous state). Cheers, ___ 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] [ide-dev] New vscode light theme for eclipse
Hi Gayan, Thanks for sharing, that looks really good! How is it working in term of usability? Is it all driven by Ctrl+3? Is there any particular existing workflow that becomes more difficult with this "lightened" skin? I personally use the Run/Debug toolbar items a lot and am wondering if there is any alternative that could fit my need and could allow me to remove the toolbar. In any case, if this seems functional and nothing is really missing, even if some workflows are slightly more difficult, I'm personally fine having such a theme directly built-in the IDE. Cheers, ___ 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 PR's & jenkins settings
> So I took the freedom to change this settings for all github jobs Thank you! ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] eclipse.platform.ui Git repository now on GitHub
Things are fine now and migration is complete. ___ 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] Experience with Github migration
Hi Sravan, Thanks for that. I think that while some questions do remain open, most committers have managed to get more and more comfortable with GitHub and the development pace has not been drastically hurt by this migration. We also see some nice addiitons to the development flow as a side-effect of the migration, leveraging some GitHub capabilities like reusable workflows for some checks. So thanks to everyone in making it possible, every comment, question, suggestion has helped to minimize the pain and to grow the value we can aim at obtaining! I've tweeted https://twitter.com/EclipseJavaIDE/status/1513799199657238531 to share this achievement to the wider community, and hopefully engage a few new people in contributing. If you use twitter, and retweet is welcome! We may see some new (and newb) people trying to contribute in the next weeks/months. Let's be welcoming and patient with them. They're may become the ones who'll be able to work on issues most of us couldn't address so far! Cheers, ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] eclipse.platform.ui Git repository now on GitHub
On Mon, Apr 11, 2022 at 5:20 PM Ed Merks wrote: > There is a new comment here suggesting it's not quite done: > > https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1151#note_679407 > > I did already migrate the setup, but the pull request defaulted to the > wrong (current default R1_0) branch, though I could change that manually... > > I guess I wasn't patient enough. Sorry. > Oops, neither was I! I missed this comment and as everything works fine enough with the GitHub repo, I processed the next step as if GitHub repo was ready. Let's put things on hold until it's complete... -- Mickael Istria Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat Developers <https://developers.redhat.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] eclipse.platform.ui Git repository now on GitHub
eclipse.platform.ui Git repository is now moved to GitHub: https://github.com/eclipse-platform/eclipse.platform.ui If you see this message, perform GitHub migration by (assuming the legacy Gerrit repo is called `upstream`) $ git reset --hard HEAD $ git remote set upstream g...@github.com: eclipse-platform/eclipse.platform.ui.git $ git pull upstream master -- Mickael Istria Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat Developers <https://developers.redhat.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] Eclipse IDE 2022‑03 Enterprise Java/Web: Java compilation errors/warnings in project explorer on file level only (perspective "Java EE")
On Fri, Apr 8, 2022 at 11:57 AM Stefan Kowski wrote: > Is this a bug/new feature or can I configure the perspective to restore > the old behaviour? > Definitely a bug. Please report it with the minimal steps to reproduce the issue at https://github.com/eclipse-platform/.github/issues -- Mickael Istria Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat Developers <https://developers.redhat.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] Milestones for Releases
On Mon, Apr 4, 2022 at 8:07 PM Gayan Perera wrote: > Hi all, > > Could we use a placeholder project for capturing all JDT issues inside the > eclipse-jdt organization ? That way we can use inbuilt github milestones > and labels to filter issues ? > That could be https://github.com/eclipse-jdt/.github ___ 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
I've added a bit more content to the https://github.com/eclipse-platform/.github/blob/main/profile/README.md so it's now visible on profile page: https://github.com/eclipse-platform . It's totally open for improvements. I've also opened https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1102 to customize the metadata fields a bit more. ___ 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
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
Re: [platform-dev] Customizing Github Organization Pages
Hi Ed, While contributing a .github/README.md file seems like regular Git/GitHub stuff that any committer can tackle, I do not see the links to configure the organization (eg set links, names and so on). Are those supposed to be accessible to committers? to project leads? Or do we need to open an helpdesk ticket to get them modified? If you don't know, I can open an helpdesk ticket to ask; I'm pretty sure that if we're insistent and annoying enough (and I know we can be!) the Foundation staff will consider just letting us access more organization and repo settings ;) ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] Intended Bug-Tracker for Platform-projects hosted on GitHub
On Wed, Mar 30, 2022 at 6:00 PM Andrey Loskutov wrote: > Beside this, users don't want to "learn about project structure, question > how we organize things and etc." just to submit a bug. > However, right now we move from one bugzilla instance to a not organized > / not managed list of individual repository bug trackers, where the poor > users have no clue at all how to find *anything* matching their own > understanding of "Eclipse IDE bug". > Ideally we should have *one* entry point, not because contributors > need that but because our users need that. > How we plan to manage that is another question, but since we don't want to > have complicated plans, let's assume we will manage it somehow. > This is a discussion we have once every 5 years, with the same rants, the same wishes, and the same (lack of) result. In any case, Platform != Eclipse IDE. Eclipse IDE is mostly EPP or IDE Working Group lately; so I would suggest to bring this idea of those entities handling this story if they can do better than us (Eclipse project committers). > Unfortunately, the "gigantic" github power was not enough so far to > provide a bug tracker per organization, so the trackers are always per > repository. > A bit like Bugzilla components. > Also there is no possibility to add a README for the organization that > would point to a bug tracker. > Wrong. you can see for example https://github.com/Microsoft/ which does include an organization README. And you can add such README to the .github repository of the organization, which already hosts a CODE_OF_CONDUCT and a CONTRIBUTING file. > So if the "only" proposed alternatives so far are: > 1) have N (> 20) bug trackers and let user find the right one (current > state). > 2) have N+1 bug trackers but designate one as the main entry point and > link that everywhere (including IDE). > We as contributors will have exact same effort moving bugs from one bug > tracker to another one, but the users will have a single point and no need > to guess. > 1000% agreeing: one more tracker doesn't solve the problem of too many trackers (as a concretization of "1 more X doesn't resolve the problem of too many Xs"). But there are good news: GitHub allows to disable issue tracker on repositories. So we can decide of 1 repository per org that's supposed to receive issue reports, and ask EF to disable issue trackers on all others; and then adapt the README, CONTRIBUTING and all other relevant files to reference that particular tracker. We may even start taking such a decision and implement it right now, migrating all issues to that "master" tracker, even before the particular repo trackers get disabled and the "master" tracker becomes the only one for the organization. ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
[platform-dev] Migration plan of eclipse.platform.ui to GitHub: April 11th
Hi all, The eclipse.platform.ui is the only Eclipse Platform project repository left to migrate to GitHub; not so surprisingly it's also the current most active one and the most crowded one regarding Gerrit queue. To ensure relatively low disturbance for ongoing work and to not add risk to next milestone, we plan to migrate the eclipse.platform.ui repo on *April 11th*. Please do your best to complete your ongoing submissions before that date. We'd also appreciate if committers could spend time processing some open reviews, and closing all possible ones (merging if it's worth it, abandoning if it's worth it). For issues you're unsure about, you can leave them open. As part of the migration, we'll then Abandon all open Gerrit reviews with a message instructing their owners how to migrate them to GitHub if they're still interested. Thanks in advance, and enjoy your last dozen of days with Gerrit! -- Mickael Istria Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat Developers <https://developers.redhat.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] [eclipse-dev] eclipse.platform.runtime & eclipse.platform.resources moved to GitHub
On Fri, Mar 25, 2022 at 10:39 AM Christoph Läubrich wrote: > You can hav "organization wide" files with creating a '.github' repo see > for example: > https://github.blog/changelog/2021-09-14-readmes-for-organization-profiles/ > so one https://github.com/eclipse-platform/.github/CONTRIBUTING.md > should apply to all that do not have an own one... Thanks Christoph. Definitely the best way to go forward, I've opened https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1064 ___ 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-dev] eclipse.platform.runtime & eclipse.platform.resources moved to GitHub
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. > If possible the error message should provide a link to a how-to-contribute. > Good idea. However we don't have a good CONTRIBUTING.md file at hand that we can add to repos while we're migrating them to GitHub. Someone who feels the need for it needs to step in to write such a good doc in the right expected grain, and make a suggestion to https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/24 to include such doc as we migrate repos. ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
[platform-dev] eclipse.platform.runtime & eclipse.platform.resources moved to GitHub
Those Git repository are now moved to GitHub: https://github.com/eclipse-platform/eclipse.platform.runtime and https://github.com/eclipse-platform/eclipse.platform.resources . Please immediately set you `upstream` repo url to use GitHub instead of Gerrit $ cd /path/to/eclipse.platform.runtime $ git remote set-url upstream g...@github.com: eclipse-platform/eclipse.platform.runtime.git $ cd /path/to/eclipse.platform.resources $ git remote set-url upstream g...@github.com: eclipse-platform/eclipse.platform.resources.git Also update your development files (Oomph profiles, *.psf files...) to adjust your workflow. -- Mickael Istria Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat Developers <https://developers.redhat.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] Github workflow
Hi, I'm putting a few answers here, but those could go to the document pointed out by Sravan (which by the way could be renamed to CONTRIBUTING.md) > I don't like forks and used to have branches on main repo - not > recommended. > Indeed. The "upstream" repo shouldn't be used as a workspace for ongoing work. Your workspace is your fork. I don't like multiple commits in one PR and always use amend/force push - > not recommended. > That's *not* not recommended. It's just something that is up to the submitter, we shouldn't recommend anything here and let contributors build the workflow they prefer. What needs to be recommended is how we merge and keep a meaningful granularity for commits, not how contributors submit their PRs. > I never use command line git and do everything from Eclipse - but some > recommended to use git CLI. > What typical commands do you have in mind? GitHub really is standard Git when it comes to push/fetch, the only thing to know is that reference to fetch/merge a PR is `pulls/123/head`, so there is no Git fanciness needed and EGit can be used for most operations. The only operation needed is the creation of a pull request and its review, that usually happens via an external tool (eg GitHub website). > Egit support missing or not - not clear. What exactly is missing, why CLI > is needed? > There is decent support for GitHub in EGit. If anything is missing, it should be reported to EGit. > It is unclear / undocumented how to *properly* refer to bugs in commits > (full url? repo-name/id? just id?). > It is unclear if we should now use dedicated github bug trackers *per > repository* to report bugs, or will be there some higher level bug tracker > for entire platform organization? > I believe that is still to be determined, as we're growing collective experience here. > Once the PR is created, I see that builds somehow triggered in equinox, > but I neither get mails that they are stared nor they are finished. That's an interesting thought. I don't know whether there is some option to allow email notifications for votes. ___ 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
On Tue, Mar 22, 2022 at 1:39 PM Wim Jongman wrote: > > >> What particularly do you think does not work well with it? >> > > File reviews or bound to the commit id and when you force push, the review > is gone. See the screenshot below. This makes it very hard for the reviewer > to see if their suggestions have been followed. > I don't have the same experience here in general: using force push shows a line that allows to diff the previous and current version. On the review page, the former review comments are still shown, and marked as "Outdated" if the code changed in a way that the review is not easy to transfer to newer patch. ___ 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
On Tue, Mar 22, 2022 at 12:23 PM Wim Jongman wrote: > Also, we need to discuss the --force parameter. It will not work well with > the Github review system. > What particularly do you think does not work well with it? > I propose to just keep committing on the branch (a bit like Gerrit change > sets) and then always(!) Squash and Merge > What's in the branch and how it's organized is the choice of the contributor. They may want to append commits or push --force. As reviewers, we shouldn't have to care about it; and feel free to use Squash and Merge if it seems better, or even ask contributors to reorganize their commits before merging if it seems necessary. What's important is that what we merge is in good quality of code and also of history, so we keep the history sane. But this is not really a contributor's duty to achieve that, more a reviewer's one. Of course, we should avoid --force on the "upstream" eclipse repo. ___ 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
Hi, On Tue, Mar 22, 2022 at 10:46 AM Wim Jongman wrote: > >1. Go to your fork and "Fetch upstream" [1] > > Why do you need to do that? Particularly if you never use master/main? FWIW, may workflow is $ git fetch eclipse master $ git checkout FETCH_HEAD [... do changes ...] $ git commit -m "My super fix (#123)" $ git push me HEAD:refs/heads/issue-123 Create PR If needed, improve, rebase, `git push me --force HEAD:issue-123` Upon PR merge, just remove my issue-123 branch. This allows to not care about the master/main branch in my fork. I can even happily delete it, and it gives me more guarantee to keep in sync! ___ 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 migration and Gerrit reviews
On Saturday, March 19, 2022, Wim Jongman wrote: > I have two stale open Gerrits that still might be useful. Will Gerrit be available after the move so that I can convert them to PR's? Yes. -- Mickael Istria Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat Developers <https://developers.redhat.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] eclipse.platform.ua migrated to GitHub
eclipse.platform.ua Git repository is now moved to GitHub: https://github.com/eclipse-platform/eclipse.platform.ua . Please immediately set you `upstream` repo url to use GitHub instead of Gerrit $ git remote set-url upstream g...@github.com: eclipse-platform/eclipse.platform.ua.git Also update your development files (Oomph profiles, *.psf files...) to adjust your workflow. -- Mickael Istria Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat Developers <https://developers.redhat.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] eclipse.platform.ui.tools migrated to GitHub
eclipse.platform.ui.tools Gut repository is now moved to GitHub: https://github.com/eclipse-platform/eclipse.platform.ui.tools . Please immediately set you `upstream` repo url to use GitHub instead of Gerrit $ git remote set upstream g...@github.com: eclipse-platform/eclipse.platform.releng.git Also update your development files (Oomph profiles, *.psf files...) to adjust your workflow. Cheers, -- Mickael Istria Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat Developers <https://developers.redhat.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?)
On Wed, Mar 16, 2022 at 10:15 PM Jonah Graham wrote: > 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]) > Thanks for the reminder. I'll ask for removal of the Gerrit repo for LSP4E. A notice about the migration was send 5 months ago; people who wanted to continue their patches have migrated them and the remaining one are not relevant anymore. ___ 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-dev] Migration of eclipse.platform.common and eclipse.platform.team
On Tue, Mar 15, 2022 at 10:03 AM Mickael Istria wrote: > > > On Mon, Mar 14, 2022 at 6:53 PM Sravan K Lakkimsetti < > sravankum...@in.ibm.com> wrote: > >> Migration of the mentioned repositories is complete and new repositories >> are >> >> >> >>1. https://github.com/eclipse-platform/eclipse.platform.common >>2. https://github.com/eclipse-platform/eclipse.platform.team >> >> > It looks like CI is not triggering new build for PRs. > Sorry, that's wrong, those repos are fine. It's the Equinox one I had in mind and the issue is already covered with https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/987 -- Mickael Istria Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat Developers <https://developers.redhat.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] [eclipse-dev] Migration of eclipse.platform.common and eclipse.platform.team
On Mon, Mar 14, 2022 at 6:53 PM Sravan K Lakkimsetti < sravankum...@in.ibm.com> wrote: > Migration of the mentioned repositories is complete and new repositories > are > > > >1. https://github.com/eclipse-platform/eclipse.platform.common >2. https://github.com/eclipse-platform/eclipse.platform.team > > It looks like CI is not triggering new build for PRs. ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] Adding new menus using the menuContribution extension point into Search menu
Hi Gayan, > But seems like the search menu is not available when my menuContributions are processed. Have you identified the reason why the search menu isn't contributed in 1st place? Does the plugin that contribute your menu has a dependency on the plugin that contributes this parent search menu, as it might affect the order? ___ 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
On Friday, February 18, 2022, Sebastian Zarnekow < sebastian.zarne...@gmail.com> wrote: > The Bot that does the auto-closing at Eclipse though doesn't give a heads-up, many tickets are never looked at. I personally look at all notifications I receive from Bugzilla and react to auto-close tickets either by taking the decision of not reopening, or by reopening with extra info, just like it's recommended in the message. And I'm happy with it bith as a reporter and a committer. But if some people take the decision to not care about those notifications ,don't read them, don't react and fully ignore the bug just like if notifications were not sent, then it's not really the process or the bot notifications that's to blame if some bugs are ignored... > If the only interaction with the reporter is an automated `Please reopen` It's not what the message that comes with auto-close recommends as possible reaction, and I've personally seen -and even fixed- several bugs that I would have ignored if there were no notification. Maybe it's not something you've encountered yet,but it does exist anyway. > it's just sad and the poorest version of valuing contributors. I find keeping the bug open and letting reporter face a heavy silence or build hope that it will just get fixed while no code contributor will care to fix it is in the end less nice to contributors that telling them "hey that's old! Is it still relevant? If yes, please reopen" > IIRC whenever people ask how to contribute, part of the answer is also "file bug reports". Who told that the goal or even the real effect here is to reduce the amount if incoming bug reports? There's probably something you misunderstood. -- Mickael Istria Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat Developers <https://developers.redhat.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] Vote to stop bug auto-closing in all Eclipse platform projects
On Fri, Feb 18, 2022 at 11:09 AM Liviu Ionescu wrote: > Personally, when I see my tickets automatically closed, I regret the time > spent to file the reports, and I start to think about looking for alternate > solutions to replace the buggy project. > Reporters can also read the message that's send with the close message to know why it is closed and other possible reactions. If the final decision will be to auto-close the tickets, and we really care > for the users, sorry to say it, but how about providing a link to VS Code? That won't change much. VSCode also auto-close inactive tickets: https://github.com/microsoft/vscode/issues/52247#issuecomment-400660468 > This might also reduce the risk of having the tickets reopened... :-( You totally misunderstood the rationale in favor auto-closing. Having tickets reopened is exactly what auto-closing is meant for, it's the desired effect that someone will read the notification and think the ticket is still worth a comment to revive it, providing extra info even just a "still happens with latest release". Good triaging/prioritizing means we have people doing this kind of work, as the committers are not doing it because they're busy with other things and have their own goals and motivations that can often be different from just making some random users happy, it's fair to give some more responsibility to the community in triaging/verifying their bugs themselves; so at least someone care. Auto-closing implies some triaging: it's reopened => still worth being considered, no-one reopens => no need to care, no need to keep tracking it. ___ 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
On Friday, February 18, 2022, Andrey Loskutov wrote: >> And it's important that we understand that in the way we interact with consumers, and also in the way we plan to future of the project. > > You don't see that you contradict youself? > According to this, we seem to plan to "auto close" the future of the project. I don't contradict myself, you just fail at reading me correctly (or I fail at explaining my thoughts correctly). Closing bugs is actually more likely to help project focusing on its preseny and future than keeping tons of probably outdated or irrelevant bugs open with a dead silence around them. It does force some triaging or contributiin actions from stakeholders that are otherwise just forgetting about this issue. It does boost community activity. Reopened bugs usually start discussions that wouldn't have happened without an auto-close... it's probably more helpful to boost bugzilla discussions that all committer efforts united. Only arguments against it are just emotions (I don't want this email, I'm annoyed people don't care enough abou my issue...) but there is no solid data points to consolidate not closing is helpfulto the project and community IMO, while I see tons of auto-closed bugs that turned into a happy end. -- Mickael Istria Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat Developers <https://developers.redhat.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] Vote to stop bug auto-closing in all Eclipse platform projects
On Fri, Feb 18, 2022 at 8:23 AM Andrey Loskutov wrote: > May be I'm living in some parallel universe, but in my world Eclipse > Platform is utterly under-resourced > Every OSS project is as much resourced as people need it. If it's really under-resourced to its consumers, then their consumers can contribute resources. If they don't it implies that it's OK-resourced. And it's important that we understand that in the way we interact with consumers, and also in the way we plan to future of the project. > that's the main reson bugs aren't processed as it should be and therefore > closed without any activity. > I'm surprised that people still hope that a 20+ years old project that has been used constantly by 3 to 12 million users can have an empty backlog and expect its developers to resolve all its bugs/requirements. Maybe I've been only part of "dirty" teams and projects, but from my various experiences in a diverse set of organizations and goals, I've never seen a team nor a project expecting to fix or implement every issue or idea someone ever faced. And the amount of open issues has always kept growing. There are priorities, there are things that no-one care about, there are ideas that were good years ago and are now bad... not everything must be done; filtering and prioritizing is a key factor of success. It's totally fine to tell people that as a committer you don't care enough about X to work on it but would welcome further resources to take care of X, and it's exactly what the auto-close bugs are about. ___ 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
> We all know that the root cause of this discussion is the 10+ years of under-resourcing for Eclipse platform. Eclipse Platform is not under-resourced. It's OK-resourced, and just like any project would benefit from more resources, but let's move the resources discussion away and focus on the community aspects of auto-closing bugs. > Do we expect big players to come back and sponsor teams of developers again as it was in 00ths? I doubt so. Perhaps, small companies and individuals from the community are the only hope. I don't get how it's related to the discussion about auto-closing bugs or not. And I also don't get how Alex's answer triggered that question. And if yes, how auto-close could help to recruit new resources for > triaging (not even dreaming about bug fixing) from the community? Auto-closing is more likely to stimulate people in trying to contribute than just keeping the bug silent. At least, people can decide to reopen with more details, or to add other information (not useful anymore, was fixed), and that's a form of contribution already. Sometimes they reopen with frustration and this can trigger a new conversation with some committers to help them in contributing more. On the other hand, keeping the bugs open but silent brings no interaction and thus no new opportunity to recruit. It just make the project seem dead. ___ 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
-1 ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] Fwd: [Bug 305081] [api] IInstallableUnit#getFilter is marked noReference
On Thu, Feb 10, 2022 at 11:42 AM Ed Merks wrote: > And while you might not keep lists, auto closing issues reminds not just > you that attention is needed but it reminds the users that you don't keep a > list. And it might will tell the users that you don't really care about > backlogs of issues enough to track them.Whatever isn't dealt with in a > few days or weeks will linger for the robot's auto-close lifetime by which > point the reporter hopefully doesn't care anymore either. Of course the > problem is not that we nor you don't care, we're all just super busy. But > what impression do we want to give the users? That we're so busy we need a > robot to help us? > I think it's great if users perceive things that way, because -at least from my POV- that's exactly how they are. So we build less false expectations and less disillusion. ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] Fwd: [Bug 305081] [api] IInstallableUnit#getFilter is marked noReference
FWIW, I personally like the "reminder" about old bugs I once cared about and then have forgotten about, and that often allows me to take a decision of whether I'm fine seeing them closed (sometimes marking them as resolved or not important any more), or whether I need to reopen them with more context. I almost never do active triaging of those bugs by looking at a bug list. The only triaging I do happens by reacting to these notifications. Remove the notifications, and I'll personally be doing less triaging as a result (for the very little it counts in practice). If I had to vote, I'd vote -0 for the removal of autoclose, which means I don't mind overall about the decision, but if it were only me I would keep the autoclose. ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] [pde-dev] main vs test source causing annoyance
My final comment, as I won't continue discussion further, not enough time to waste. I stand to my opinion here: setting "will cause failures downstream unless downstream opts-out of the failure" on bundles just "because we can" without thinking of how test flag actually works and which constraints it does add to consumers was a bad idea as it reduced the quality of Eclipse Platform by requesting efforts from adopters for no value to balance that (as opposed to eg move to newer Java). At that stage, I'd like to just invite anyone to really spend time looking at what the "test" flag means to JDT and Tycho, so they may better understand why it doesn't make sense in this context. "Test" flag is just not a decoration, it has some semantics about visibility in the workspace that are not at all compatible with how PDE currently works. "test" flag was designed for Maven where a project has multiple scopes/visibility, that doesn't match usual PDE. As a consequence, I also think building further logic in PDE on top this "test" flag assuming it's just a reliable decoration for fragments or whatever is also a misuse of the test flag and is likely to be fragile in a near future. But I and we all can survive that; it's an annoyance and not a blocker. I just wish I considered it more seriously earlier before this got applied widely. ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] [pde-dev] main vs test source causing annoyance
On Fri, Jan 28, 2022 at 10:41 AM Andrey Loskutov wrote: > to avoid possible issues in production environment where the test bundle > will be most likely not deployed. > We're in a modular world, you never know what's deployed and in which context; and you can't assume how things are consumed. M So what is the problem? Just add the flag to test bundles you are working > on and that's it. > The problem is that it's inconsistent: build works fine because it does OSGi, and just opening the project in my workspace will cause an error to pop-up. Then I'll need to put the same flag, potentially annoying transitively other consumers of my test bundle if their are any. It might have no value for you because you know which bundles are supposed > to be deployed and which not in the production > Define "production". Here for Platform, there are committers that are all supposed to understand that kind of things when merging or reviewing. I suspect if there is no value for me, there is no value for any committer, thus no compelling value for the project. > but other people might not have that knowledge and happily consume API > from the test projects inside production projects. > There are already API tools, internal, x-friends... flags to highlight all that in a more OSGi-native way, so the value added by this flag is 0 compared to it. And the org.eclipse.ui.tests.harness bundle can be interesting in some cases in production of other projects (eg SWTBot is using IIRC in its "production"). I'm still not convinced about the value and would really like to read some existing discussion or bug report where this flag has helped anyone; because I could see here, and earlier in Tycho (that interprets that flag differently/correctly as opposed to how Platform/PDE sets it) that is has caused some trouble. ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] [pde-dev] main vs test source causing annoyance
On Fri, Jan 28, 2022 at 10:13 AM Andrey Loskutov wrote: > Could you provide a concrete example of such error with explanation what > and where is broken / wrong configured > I'm working in LSP4E, and consuming some test bundles from the SDK (DisplayHelper and other utilities). So far so good for the last years or so. I usually have the dependencies in my target-platform (not that visibility of content is not influenced at all by the test flag here, it's plain PDE/OSGi resolution ruling), so far so good. Now I open one of the Platform test bundles I depend on. It does configure the test flag for its source folder; then all of a sudden, my LSP4E test bundle show errors and PDE refuses to process it because it requires me to change a flag it order to see content of this bundle (which I can perferctly see in the PDE/OSGi world where this flag is absent). So I have no other choice that setting this flag in LSP4E or I cannot develop. It's interrupting my workflow and I do not see any value to compensate this interruption; and luckily I know deeply all those projects to easily find how to remediate, I can imagine some people who are less aware of those things get lost. > how it can be improved? > Just removing the "not main code of the project, need a flag to consume" flag for the main content of those bundles would be correct. Also I'm not sure PDE adds something to metadata to enforce this warning. > It has some operations that do set the flag according to the bundle name, but maybe not automatically, could be on import. ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] [pde-dev] main vs test source causing annoyance
On Fri, Jan 28, 2022 at 9:40 AM Christoph Läubrich wrote: > 1) making a rule that forbids marking tests as "test" is really not > helping in any case but only shows we try to fix a broken concept. > The broken concept is that "test" means "non-main, need a flag to consume", while code inside a test bundle is the main code and is visible according to usual OSGi rules without further filtering, not some sidekick stuff. So what's broken is marking test sources inside test bundles as "non-main, need a flag to consume" while they are regular source. 2) The concept of "test-fragments" is and was always broken, its just > PDE that refuses to support common concepts and thus we where forced to > use them for years leading to hard to find, hard to manage and hard to > run tests. > > So it would be better to (now that Tycho supports this and its still > possible to run them in JDT/PDE) migrate to either > > a) put *unit* tests that test /internal/ state (e.g. not exported API) > in a 'src_test' folder > b) put *integration* tests that test the /exported/ state (e.g. public > exported API, interaction with the UI) ... > > then there is no need for "test-fragments" and no need for annoyance and > all this maps perfectly to whats common to most developers. > > > 1. it's "contaminating": changing it requires downstream consumers to > > also act on their .classpath to get things working again > > I would say it gives consumers a "valuable warning that they do assume > wrong things" :-) > > > 2. it's adding no value in the traditional plugin development workflow > > It does as the "traditional plugin development workflow" was always a > workaround because the tools we are using refused to support this. As > this is different now I don't see any reason for keeping this workarounds. > > > 3. it can even cause troubles now that support for test folders in > > Plugins can be interpreted differently by PDE or Tycho (just like > > tests in Maven world). > > They are not interpreted differently, PDE simply do not make any > distinction (JDT does!). > > By the way its not PDE adding that meta-data as far as I know, the only > one doing it automatically is m2eclipse. All that is another topic, I'm talking here about things working as expected according to usual workflows and artifacts that have worked for 20 years and basically suggesting we fix the current state to restore consistency with OSGi runtime: what is exported in the main jar is not test. ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
[platform-dev] main vs test source causing annoyance
Hi, I'm seeing more and more frequently in my workbench errors such as "Project has only main sources but depends on project 'org.eclipse.text.tests' which has only test sources." which prevents from developing as JDT refuses to build in such case. That was implemented in https://bugs.eclipse.org/bugs/show_bug.cgi?id=539998 and made more frequent as more and more bundles added test information in there .classpath. I think overall, this practice is a bad idea for Eclipse plugin development and for Platform, because 1. it's "contaminating": changing it requires downstream consumers to also act on their .classpath to get things working again 2. it's adding no value in the traditional plugin development workflow 3. it can even cause troubles now that support for test folders in Plugins can be interpreted differently by PDE or Tycho (just like tests in Maven world). I think we should act on fixing those .classpath and emit a rule to not use those "test" metadata on test bundles. Also, we should probably make PDE *not* add those metadata for plugins by default. There would be less trouble and no loss as far as I know. What do you think? -- Mickael Istria Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat Developers <https://developers.redhat.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] Best approach to branch good old Eclipse 3.8
On Thu, Jan 20, 2022 at 2:00 PM Mário Marinato wrote: > Mickael, yeah, I'm aware that some of the things we do might benefit > others, and I'm going to suggest it to our team. > The bug number 492861 might be a good place to start, since most of the > items listed there have not been addressed: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=492861 > It was closed-wontfix'd last year due to lack of activity. > As the last comment on the bug mentions """ If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. """ > In case we do start contributing, are the instructions found on > https://wiki.eclipse.org/Platform/How_to_Contribute the ones we should > follow? > Yes. ___ 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] Best approach to branch good old Eclipse 3.8
On Wed, Jan 19, 2022 at 8:59 PM Mário Marinato wrote: > This is what kept us from moving into Eclipse 4 territory. > Then it's a pity because e4 allows you to use your custom renderers for about anything, including views, toolbars... See PartRenderingEngine class for inspiration of how to plug a different renderer for the IDE. Also keep in mind that the features you're implementing might be interesting to some others. In such case, please consider contributing your enhancement directly to Eclipse Platform. ___ 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] Best approach to branch good old Eclipse 3.8
Hi, On Wed, Jan 19, 2022 at 5:28 PM Mário Marinato wrote: > - Upgrade our whole RCP to Eclipse 4 and work on adding back the > Presentation classes. > Definitely better, by thousands hours of work. Even better would be to re-evaluate whether you can replace your Presentation class by other mechanisms offers by more recent Eclipse, such as theming. HTH ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] PGP Signing Question?
On Mon, Jan 3, 2022 at 2:12 PM Ed Merks wrote: > I've opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=578024 to track > this issue.Minimally the help for the dialog should describe how to > find such external PGP services and in our case specifically how to verify > that this is an Eclipse project's key. We can discuss the details there. > I can try to help iron out the wrinkles... > OK. So, for example, if I have the question "is it guaranteed that two > different org.bouncycastle.openpgp.PGPPublicKey instances might have the > same org.bouncycastle.openpgp.PGPPublicKey.getKeyID() values" that should > be a p2 Bugzilla? I wouldn't ask that on platform-dev but I would have > thought to ask on p2-dev rather than open a question Bugzilla. I see no > reason to assume that the getKeyID values are unique, though I suppose the > chances of collisions are vanishingly small (and downstream utility class > seem to assume this). > For question, p2-dev is probably the best place. For the particular question about keyIDs, they should not really be used in practice (see https://evil32.com/ ), instead, users should look at key fingerprints as what they'd expect as being the id. > I've opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=578023 to track > this issue. > Thanks. ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] PGP Signing Question?
On Mon, Jan 3, 2022 at 11:55 AM Ed Merks wrote: > Is there a bug here? I don't think we can expect the users to grant trust > on the basis of some hexadecimal numbers... > Actually, they can grant trust based on those numbers because users should verify those signers are trusted, eg by checking whether the ids are matching some verified keys in some external PGP services. But indeed, the UI is still rough and still needs to be improved. Where/what is the best way for asking question and for discussing the > implementation details? I posted on platform-dev because the entire > platform is affected by these design decisions, but perhaps I should > restrict this to p2-dev or elsewhere? > Bugs against p2 are the best channel IMO. > I expect there is a concern about the size of many such the duplicates > keys, but with both jar and *.xz compression that isn't really so much a > problem. I.e., 1000 copies of the key has minimal impact on the size > compressed artifacts as seen here where the artifacts.xml has 1000 copies > of the key: > OK, I probably made a wrong estimation back then, and maybe adding the signer key to each artifact would be preferable. And even the > org.eclipse.equinox.p2.tests.engine.CertificateCheckerTest.testPGPSignedArtifactUntrustedKey() > test works that way... > Yes, this is supposed to work with key as artifact property. The metrics you shared seem to highlight it would be a better approach, so please open a bug to Platform/Releng so we can try to improve that. ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] Getting the solution of a P2 resolve operation including missing requirements
On Sun, Jan 2, 2022 at 8:42 AM Ed Merks wrote: > so everyone doing interesting > p2 things ends up using various internal things... > That's true. But at least, by contributing to p2 (or PDE or whatever existing project that can match), you get more contributors and free (ie as in paid by IBM and Red Hat) releng, so you basically would end with less work on your end. ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] Unsigned Content?
On Fri, Dec 17, 2021 at 9:11 AM Ed Merks wrote: > Here is what happens when the installer tries to install > org.mockito.mockito-core into a Platform SDK IDE: > > java.lang.NullPointerException > at > org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.buildPGPTrustore(CertificateChecker.java:311) > at > org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker$1.get(CertificateChecker.java:63) > at > org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker$1.get(CertificateChecker.java:1) > at > org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.checkCertificates(CertificateChecker.java:126) > at > org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.start(CertificateChecker.java:83) > at > org.eclipse.equinox.internal.p2.engine.phases.CheckTrust.completePhase(CheckTrust.java:63) > at > org.eclipse.equinox.internal.p2.engine.Phase.postPerform(Phase.java:254) > at org.eclipse.equinox.internal.p2.engine.Phase.perform(Phase.java:105) > at > org.eclipse.equinox.internal.p2.engine.PhaseSet.perform(PhaseSet.java:50) > at > org.eclipse.equinox.internal.p2.engine.Engine.perform(Engine.java:80) > at > org.eclipse.equinox.internal.p2.engine.Engine.perform(Engine.java:48) > at > org.eclipse.equinox.internal.provisional.p2.director.PlanExecutionHelper.executePlan(PlanExecutionHelper.java:46) > at > org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl$3.commit(ProfileTransactionImpl.java:549) > at > org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl.commit(ProfileTransactionImpl.java:345) > at > org.eclipse.oomph.setup.p2.impl.P2TaskImpl.perform(P2TaskImpl.java:905) > at > org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.doPerformNeededSetupTasks(SetupTaskPerformer.java:3851) > at > org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performNeededSetupTasks(SetupTaskPerformer.java:3779) > at > org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performTriggeredSetupTasks(SetupTaskPerformer.java:3760) > at > org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.perform(SetupTaskPerformer.java:3638) > at > org.eclipse.oomph.setup.ui.wizards.ProgressPage$9.run(ProgressPage.java:600) > at > org.eclipse.oomph.setup.ui.wizards.ProgressPage$11$1.run(ProgressPage.java:727) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) > Why? Because > org.eclipse.equinox.internal.p2.engine.phases.CheckTrust.completePhase(IProgressMonitor, > IProfile, Map) knows the profile, but the certificate > checker doesn't know to check that profile but rather checks the self > profile. I imagine the p2 director will have such problems too, or perhaps > it will not fail but also might not actually check the correct profile... > Such feedback is really welcome. Can you please open a dedicated bug for this issue and add me as CC ? I wonder though if n projects have to duplicate the effort n times if that > will be n times the work. > The effort of consuming upstream artifacts from Maven is equivalent to the effort of consuming artifacts from Orbit. So there is no extra effort involved for consumers, they just change a version in their .target and that's all. "Downstream" projects can also directly consume bundles provided by their "upstream" ones in a plain p2 way. For example, a project that need mockito can just take Mockito from Platform instead of Orbit, without playing with Maven dependencies. It's actually already a common and efficient: may target files don't reference Orbit and pick the libs that's provided by their "upstream". > Also, might we end up with n versions of each such bundle? > We already do have N versions of several libs, split across multiple repositories (eg some older projects don't rebuild against latest Orbit and still include older libs). p2 -during SimRel aggregation or installation on user end- does take care of picking the best and tries to avoid multiple versions when this can be avoided. Consuming libs from Maven instead of Orbit doesn't really change the problem/solution in the end. ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] Issue with 'Invalid registry object' on Eclipse RCP based app since 4.21
Hi, I suggest you enable your application for remote debugging, adding the `-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=1044` VM arg to config.ini; then with your development IDE, connect to this remote Java application and put breakpoints in UIExtensionTracker. HTH ___ 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] Need reviewer for https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/187903
Thanks Sebastian, that was very fast! ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
[platform-dev] Need reviewer for https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/187903
Hi all, https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/187903 has the permission to get into RC2 from PMC. But the freeze plan requires another committer to review and approve the patch as well. Can anyone please have a look and give the necessary +1 to merge (or -1 to prevent from merging if someone sees a bug). Thanks in advance -- Mickael Istria Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat Developers <https://developers.redhat.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] [eclipse-dev] RFC: Eclipse TLP migration to Github
Hi all, Some interesting feedback, mainly expressing the concrete concerns of such migration in day-to-day development of the Eclipse Project, was provided. The document has tried to capture them and provided answers of how some Gerrit workflows translate to GitHub, when possible. So I'd encourage anyone interested to have a new look at this document, and to provide feedback, particularly about workflows they'd be missing and that we'd like to have investigated before actual move. Note that although it's closely related so it's captured in the same doc, migration from Bugzilla to GitHub issues is currently *not* in the scope of what the PMC agreed upon moving, the focus for the nearer future should really remain on GitHub PRs + Bugzilla, more than GitHub issues. Cheers ___ 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] [equinox-dev] RFC: Eclipse TLP migration to Github
On Fri, Oct 15, 2021 at 8:09 AM Christoph Läubrich wrote: > As I'm always advocated to use Github +1 implied by nomination ;-) > > I'd just like to recomment to use the migration process to also merge > some of the related repositories eg, everything relate to jdt in one > repository (same for pde, platform, equinox) as this cluttering of code > makes it hard to create consistent PRs across repository boundaries of > related code. > That's a different topic and I believe if we want to make faster progress towards GitHub, we need to keep both separated and act towards them independently without making 1 a prerequisite for the other. ___ 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?
On Thu, Oct 7, 2021 at 10:28 PM Jonah Graham wrote: > 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? > Yes, adding keys to the artifact metadata instead of repo is probably the most convenient at the moment. ___ 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?
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 ___ 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] [platform-releng-dev] 4.22 I-Build: I20211006-1800
+1 for marking this build as unstable and removing it from the I-Builds reference; it's also affecting CI builds. I've reverted the culprit patch and merged the revert although I couldn't see the test succeeding for the reason above. ___ 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] API Errors for SWT
Hi, About API check, IIRC, it was not completely automated in SWT because it was requiring a preliminary step to install the right .classpath for the environment and so on. Back then it was more than what we were able to implement in a timely manner. Maybe this could more easily be added now so those checks could be automated. Cheers, ___ 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 Verification for eclipse.platform.releng
The job for the master branch ( https://ci.eclipse.org/platform/job/eclipse.platform.releng/job/master/ ) shows the same failures. So I think you can ignore them for your current patch. ___ 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] Changing default IAdapterManager in Platform?
I've opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=576024 as we are facing yet another issue because of this limitation (in supporting multiple adapters from editor to IToggleBreakpointsTarget this time). ___ 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
On Tue, Sep 14, 2021 at 3:06 PM Mickael Istria wrote: > > > On Tue, Sep 14, 2021 at 3:01 PM Christoph Läubrich > wrote: > >> This seems to define (new) dedicated actions instead of using the >> eclipse default ones, so is it not possible to use the eclipse debug.ui >> ones with generic editor? > > > Sorry, I don't know. But as Alexander mentioned, it could make sense to > add support for Generic Editor directly in debug.ui , as long as the > generic editor remains an optional requirement (ie no specific Generic > Editor API is used). > 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. -- Mickael Istria Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat Developers <https://developers.redhat.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] generic editor and breakpoints
On Tue, Sep 14, 2021 at 3:01 PM Christoph Läubrich wrote: > This seems to define (new) dedicated actions instead of using the > eclipse default ones, so is it not possible to use the eclipse debug.ui > ones with generic editor? Sorry, I don't know. But as Alexander mentioned, it could make sense to add support for Generic Editor directly in debug.ui , as long as the generic editor remains an optional requirement (ie no specific Generic Editor API is used). ___ 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
Hi, LSP4E has support for the Debug Adapter Protocol and that allows to leverage breakpoints in the Generic Editor; it's successfully used for HTML, JS, TS, Rust... debugging. You can look at the code of LSP4E and get inspired. A starting point could be https://git.eclipse.org/c/lsp4e/lsp4e.git/tree/org.eclipse.lsp4e.debug/plugin.xml#n55 HTH ___ 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-dev] Moving to Jenkinsfile (was Re: ATTENTION: Turn off of git protocol)
Hi, I'm going to start adoption of Jenkinsfile and replace Gerrit jobs for Platform and p2. https://bugs.eclipse.org/bugs/show_bug.cgi?id=574667 will track progress. Cheers, ___ 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-dev] Moving to Jenkinsfile (was Re: ATTENTION: Turn off of git protocol)
FWIW this would take the form of * a job for each repo, like https://ci.eclipse.org/platform/job/eclipse.platform.debug/configure * a Jenkinsfile for each repo, like https://git.eclipse.org/r/c/platform/eclipse.platform.debug/+/182617 ___ 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] Moving to Jenkinsfile (was Re: [eclipse-dev] ATTENTION: Turn off of git protocol)
At the moment, if we opt for the "multi branch pipeline" integration between Gerrit and Jenkinsfile, we'd lose the ability to retrigger a build with a "please rebuild". People who need a rebuild would have to follow the link to Jenkins and click the build button. I personally don't see that as a blocker for adoption of Jenkinsfile. What do others think? ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
[platform-dev] Moving to Jenkinsfile (was Re: [eclipse-dev] ATTENTION: Turn off of git protocol)
Hi, I've spent some time investigating usage of Jenkinsfile for Platform. At the moment, the Platform/p2/JDT/PDE... CI instances are missing the Gerrit pipeline plugin, which allows to deal with discovery of branches and reviews to automatically trigger builds. I think we'll need this first, otherwise moving to Jenkinsfile is way less interesting as a lot of configuration remains necessary on Jenkins itself. I've opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=574488 Cheers, ___ 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-dev] ATTENTION: Turn off of git protocol
Hi Mikael, I don't think we'll need this Jenkins plugin, but we won't hesitate to ping you if we change are mind! Thanks for the proposal! ___ 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] [equinox-dev] ATTENTION: Turn off of git protocol
On Fri, Jun 25, 2021 at 6:43 PM Aleksandar Kurtakov wrote: > Isn't it time to start using Jenkinsfile for each git repository and use > that to trigger gerrit builds? > That would make our scripts easier to grep and find/automate such changes > in the future. If there are few others interested in helping out and > finding out such work beneficial I would like to discuss with them how we > can best handle this change. > +1. Jenkinsfile are great and act as a great documentation for people who want to build locally. They also make it easier for anyone to contribute to build orchestration, progressively allowing build expertise to be better shared and thus free some time the typical "release enginers" to work on more innovative things and bring more redundancy to avoid the whole project being stuck in case 1 or 2 people are away. I consider such declarative CI files as an important criterion of project vitality nowadays. ___ 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] Platform SWT/JFace: Window.getInitialSize()/getInitialLocation() not being called if ToolBarManager is used
Hi, If you think this is a bug, please report it to https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Platform ___ 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] Is it possible to reuse/hook into the JUnitPlugin result view?
Hi, The issue is that since it's all about listeners that are placed on plugin action, the org.eclipse.unittest.ui plugin needs to be activated before starting the launch or it will fail at listening to the launch startup. Starting the view is 1 way to do it. So basically, yes, you'll need the launch configuration to show the view or activate the bundle in another way before actually starting the launch. Proposal to improve this situation would be highly welcome. Please add me and Victor as CC of tickets you might open on that topic. HTH ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
