Sloeber/eclipse is re-indexing every project of a workspace at startup

[hreintke]

Hi Jantje,

Back to arduino development after a pause.

Moving from 4.3 to 4.4 and/or git-master. In git-master there is a fix to the stm32 VARIANT_H issue. But for this I see similar but not 100% identical behavior on startup of sloeber.

Main issue is that a startup, all projects in the workspace are re-indexed by eclipse. In my case, with a workspace with around 65 projects, it takes 5-10 minutes of high cpu usage before all gets quiet. The first 30-60 seconds sloeber/eclipse is not even responsive.

What I notice in the eclipse .log file, that it probably is triggered by an sloeber update of the index.

These are the messages from the .log at startup (4.4 version). I use a small test workspace with two projects.

!ENTRY org.eclipse.egit.ui 2 0 2021-10-16 13:15:08.685
!MESSAGE Warning: The environment variable HOME is not set. The following directory will be used to store the Git
user global configuration and to define the default location to store repositories: 'C:\Users\Herman'. If this is
not correct please set the HOME environment variable and restart Eclipse. Otherwise Git for Windows and
EGit might behave differently since they see different configuration options.
This warning can be switched off on the Team > Git > Confirmations and Warnings preference page.

!ENTRY io.sloeber.core 8 0 2021-10-16 13:15:29.841
!MESSAGE Index of project changed :ArdISP

!ENTRY io.sloeber.core 8 0 2021-10-16 13:15:33.201
!MESSAGE Index of project changed :BluetoothTest

What could be the reason for the index change at startup ?

[jantje]

I think this is a duplicate of #1391

!ENTRY io.sloeber.core 8 0 2021-10-16 13:15:33.201
!MESSAGE Index of project changed :BluetoothTest

Is sloeber telling it got an alert that the index has changed. This is after the fact I didn't have time yet to tackle #1391 but I assume this is caused by the version 4.4 change since then the "project properties-> arduino->apply and close" is also called at the opening of the project and it wrongly assumes there is a change that requires a clean of the project.

By the way you can open and close' project in eclipse avoiding large tasks at startup when having plenty of projects in your workspace

[hreintke]

Did not know about open/close project, thx.

On startup. After migrating the workspace, I removed the

                // This is not install job but to migrate 4.3 to 4.4
                // A refresh seems to trigger the code at a convenient time
                final IWorkspaceRoot workspaceRoot = ResourcesPlugin.getWorkspace().getRoot();
                for (IProject curProject : workspaceRoot.getProjects()) {
                    if (curProject.isOpen()) {
                        try {
                            curProject.refreshLocal(DEPTH_INFINITE, monitor);
                        } catch (@SuppressWarnings("unused") CoreException e) {
                            // ignore
                        }
                    }
                }

from runInstallJob()

As once the upgrade is done this is not necessary anymore. Correct ?

Sloeber starts without indexing all open projects, does not show platform/port information in the project explorer view.

-> can you point me to the location in the code where that is added ?

Selecting a project (pushing the > in front of the name) triggers the indexing of that project. It does not remove the "release directory" from the project.

But : Doing a build of that project triggers the re-indexing of all other open projects in the workspace. After that, only part of the projects have their platform/port info displayed.

-> Any idea why / where the trigger happens ?

In the logfile there are notifications like this :

!ENTRY org.eclipse.cdt.core 4 0 2021-10-17 14:50:15.153
!MESSAGE Error: Cannot run program "-D__IN_ECLIPSE__=1": Launching failed
!STACK 0
java.io.IOException: Cannot run program "-D__IN_ECLIPSE__=1": Launching failed
    at org.eclipse.cdt.utils.spawner.Spawner.exec(Spawner.java:367)
    at org.eclipse.cdt.utils.spawner.Spawner.<init>(Spawner.java:98)
    at org.eclipse.cdt.utils.spawner.ProcessFactory.exec(ProcessFactory.java:111)
    at org.eclipse.cdt.core.CommandLauncher.execute(CommandLauncher.java:190)
    at org.eclipse.cdt.internal.core.BuildRunnerHelper.build(BuildRunnerHelper.java:274)
    at org.eclipse.cdt.managedbuilder.language.settings.providers.AbstractBuiltinSpecsDetector.runProgramForLanguage(AbstractBuiltinSpecsDetector.java:799)
    at org.eclipse.cdt.managedbuilder.language.settings.providers.AbstractBuiltinSpecsDetector.runForLanguage(AbstractBuiltinSpecsDetector.java:727)
    at org.eclipse.cdt.managedbuilder.language.settings.providers.AbstractBuiltinSpecsDetector.runForEachLanguage(AbstractBuiltinSpecsDetector.java:592)
    at org.eclipse.cdt.managedbuilder.language.settings.providers.AbstractBuiltinSpecsDetector$1.runInWorkspace(AbstractBuiltinSpecsDetector.java:518)
    at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:42)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

Most certainly these are for projects which have no platform.

[jantje]

As once the upgrade is done this is not necessary anymore. Correct ?

As the comment says so that should be correct. However the code has never been tested without it so it may be needed. Also the curProject.refreshLocal is the same as pressing F5 so if something doesn't work you can always press F5 as workaround.

Sloeber starts without indexing all open projects, does not show platform/port information in the project explorer view.

I assume this is something you see after you did the code change you mentioned. Which kind of proves the code does more than only trigger the migration.

The problem is as follows (as I recall it): When a project is opened Sloeber needs to internally configure itself. This is done inside public synchronized boolean configure(ICProjectDescription prjCDesc, boolean prjDescWritable) in SloeberProject class This code will do the migration if needed. This code should be called at the project open event (send by eclipse) but both the ICProjectDescription and the project need to be writeable for the migration to be successful which they aren't at that point in time. I'm not sure they need to be writeable after the migration but I don't think they should be. The ICProjectDescription needs to be writeable to remove the environment variables and the project needs to be writeable to add the .sproject file (with the conceptual content of the environment variables)

The listener for the open project is resourceChangeListener In the method resourceChanged you will see it calls curSloeberProject.sloeberCfgChanged(); which calls Helpers.deleteBuildFolder(myProject, activeConfig.getName());

but curSloeberProject.sloeberCfgChanged(); should not be called for newly opened projects because above the call it states

        // no sloeber.cfg files have been modified
        if (changedSloeberCfgFiles.size() == 0)
            return;

This test should be true and the method should return (and as such stop the deletion of the release folder) So the question is why is changedSloeberCfgFiles not empty

[jantje]

I have been looking at the resourceChanged code and .... there is room for improvement :-(

[hreintke]

I have no sloeber.cfg file anywhere. Should that have been generated ?

[jantje]

A sloeber.cfg file is only there when you share a configuration in project properties->arduino The existence of sloeber.cfg may be a workaround

[hreintke]

I have the plugin within it's own eclipse (Install the projects into the SDK via the EGit interface.) Running from that I can correctly start the sloeber-ide.

But I get a lot of debug messages from socketlistener and JmDNS.

16:32:04.513 [SocketListener(DESKTOP-D5U4K1Q-fritz-box.local.)] DEBUG javax.jmdns.impl.JmDNSImpl - DESKTOP-D5U4K1Q-fritz-box.local. handle query: dns[query,10.0.0.152:5353, length=94, id=0x0, questions=2
questions:
    [Pointer@2126962850 type: TYPE_PTR index 12, class: CLASS_IN index 1, name: _%9E5E7C8F47989526C9BCD95D24084F6F0B27C5ED._sub._googlecast._tcp.local.]
    [Pointer@1614082757 type: TYPE_PTR index 12, class: CLASS_IN index 1, name: _googlecast._tcp.local.]]
16:32:04.558 [JmDNS(DESKTOP-D5U4K1Q-fritz-box.local.).Timer] DEBUG javax.jmdns.impl.tasks.Responder - Responder(DESKTOP-D5U4K1Q-fritz-box.local.).run() JmDNS responding to: [Pointer@2126962850 type: TYPE_PTR index 12, class: CLASS_IN index 1, name: _%9E5E7C8F47989526C9BCD95D24084F6F0B27C5ED._sub._googlecast._tcp.local.]
16:32:04.558 [JmDNS(DESKTOP-D5U4K1Q-fritz-box.local.).Timer] DEBUG javax.jmdns.impl.tasks.Responder - Responder(DESKTOP-D5U4K1Q-fritz-box.local.).run() JmDNS responding to: [Pointer@1614082757 type: TYPE_PTR index 12, class: CLASS_IN index 1, name: _googlecast._tcp.local.]
16:32:06.818 [SocketListener(DESKTOP-D5U4K1Q-fritz-box.local.)] DEBUG javax.jmdns.impl.DNSIncoming - DNSIncoming() questions:2 answers:0 authorities:0 additionals:0
16:32:06.818 [SocketListener(DESKTOP-D5U4K1Q-fritz-box.local.)] DEBUG javax.jmdns.impl.JmDNSImpl - DESKTOP-D5U4K1Q-fritz-box.local. handle query: dns[query,10.0.0.201:5353, length=63, id=0x0, questions=2
questions:

Do you know the way to switch those off ?

[jantje]

This is caused by the bonjour service and I don't know a better way than turning of the bonjour service in preferences->arduino

[hreintke]

Thx, worked.

I now have a working dev environment. If you want me to test anything, just let me know.

[jantje]

I now have a working dev environment.

good :-)

If you want me to test anything, just let me know.

It is pretty complicated code (also because I don't know what I'm doing) and I don't know what your capabilities are so I do not know what you can do. But resourceChanged is there to respond to open project and to sloeber.cfg file changes Once the migration is done (no more need to read/write CDT descriptions ) this should be lots easier.

As you can see in the code the opening (getSloeberProject) is always followed by a config change call (sloeberCfgChanged). And this is probably causing the reindex.

                                SloeberProject curSloeberProject = SloeberProject.getSloeberProject(curProject, false);
                                if (curSloeberProject == null) {
                                    // this is not a sloeber project;
                                    // make it one?
                                } else {
                                    curSloeberProject.sloeberCfgChanged();
                                }

[hreintke]

Learning eclipse CDT.

Noticed the following in public class IndexerController

There is :

    public static void doNotIndex(IProject project) {
        Common.log(new Status(Const.SLOEBER_STATUS_DEBUG, Activator.getId(),"Do not index "+project.getName())); //$NON-NLS-1$
        fProjects.add(project);
        getIndexController();
    }
    public static void index(IProject project) {
        Common.log(new Status(Const.SLOEBER_STATUS_DEBUG, Activator.getId(),"index "+project.getName())); //$NON-NLS-1$
        fProjects.remove(project);
        ICProject cProject = CoreModel.getDefault().getCModel().getCProject(project.getName());
        getIndexController().notifyIndexerSetup(cProject);
    }

    public static IndexerController getIndexController() {
        if (theController==null) {
            theController=new IndexerController();
            CCorePlugin.getIndexManager().addIndexerSetupParticipant(theController);
        }
        return theController;

    }

Is it intentional that in donotindex there is only getIndexController() I would expect something like

        fProjects.add(project);
        ICProject cProject = CoreModel.getDefault().getCModel().getCProject(project.getName());
        getIndexController().postponeIndexerSetup(cProject);

Does not solve issues as I see now.

Secondly : I found that debugging the indexer can be done with startup options.

A debug log of the indexer could be helpful. For this create a text file with following content (e.g. IndexerDebugOptions.txt):

org.eclipse.cdt.core/debug=true
org.eclipse.cdt.core/debug/pdomtimings=true
org.eclipse.cdt.core/debug/indexer=true
org.eclipse.cdt.core/debug/parser=true
org.eclipse.cdt.core/debug/deltaprocessor=true
org.eclipse.cdt.core/debug/scanner=true
org.eclipse.cdt.core/debug/model=true
org.eclipse.cdt.core/debug/indexer/statistics=true
org.eclipse.cdt.core/debug/indexer/activity=true
org.eclipse.cdt.core/debug/indexer/problems=false

And then starting up with sloeber-ide -debug IndexerDebugOptions.txt

That works, but I's like to use that with the sloeber dev environment (run as eclipse application from io.sloeber.core project). Do you know whether that is possible ?

[jantje]

Learning eclipse CDT.

Great :-)

Is it intentional that in donotindex there is only getIndexController()

It has been a while since I have written this code but I would say yes. Basically getIndexController registers a IndexerSetupParticipant. This allows CDT to ask if it is ok to index before starting to index. So basically doNotIndex only adds the project to a project list and index removes it from the list and triggers a indexrequest for the project. But all of this only works if the IndexerSetupParticipant is registered therefore the getIndexController is called in both doNotIndex and index as getIndexController registers the IndexerSetupParticipant.

Secondly : I found that debugging the indexer can be done with startup options.

Great

That works, but I's like to use that with the sloeber dev environment (run as eclipse application from io.sloeber.core project). Do you know whether that is possible

I modified my launch configuration as below

then the console output logged this.

So I guess that should work

[hreintke]

Yes, that works, thx.

Busy with comparing indexing behavior between "CDT managed c++ project" and "Arduino sketch" And getting an understanding of the indexer itself. Sometimes see two indexing actions, directly behind each other, on Arduino projects. Not any idea yet why that happens, and not constantly reproducible yet.

Question :

Do you know how the board/port info is added to the project display ?

[jantje]

Do you know how the board/port info is added to the project display ?

offcourse I do. Sloeber provides a decorator (this is eclipse stuff not CDT) It is "defined" in the plugin.xml of the ui part of sloeber You can (de)activate it in the preferences

[hreintke]

Getting some understanding how things are working.

When not converting project at the start, Sloeber starts without indexing all open projects, does not show platform/port information in the project explorer view.

Not showing platform/port is caused in public static synchronized SloeberProject getSloeberProject(IProject project, boolean allowNull)

Object sessionProperty = null;
                try {
                    sessionProperty = project.getSessionProperty(sloeberQualifiedName);
                    if (null != sessionProperty) {
                        Common.log(new Status(IStatus.WARNING, Activator.getId(),
                                "returning new session sp "));
                        SloeberProject ret = (SloeberProject) sessionProperty;
                        return ret;
                    }
                } catch (CoreException e) {
                    e.printStackTrace();
                }

There sessionProperty == null -> No platform/port shown.

Futher investigating ongoing.

[jantje]

--EDIT-- Though the statement below is true it is not what happens in this case. See more info in next comment

The session property is a very special use case for configuration copying I do not think this is related to the startup issue

[jantje]

Sorry but my previous comment was wrong. In this particular case the sessionProperty being null means that the "sloeber project is not yet open/configured" In other words the eclipse project is open but Sloeber has is not yet aware and needs to load it's data. It is the code below what you provided that causes the issue

                if (!allowNull) {
                    SloeberProject ret = new SloeberProject(project);
                    return ret;
                }

I think the test should be: if there is a .sproject file or !allowNull Because if there is a .sproject file no migration should be done so no writable project description is needed nor a writable project

Note that I'm more and more convinced these are racing conditions which I do not see on my Intel(R) Core(TM) i5-4250U CPU @ 1.30GHz 1.90 GHz

[hreintke]

OK, I don't know how to test whether a .sproject exists, but I do know it's there. I changed it to if (!allowNull || true) {

Getting decorated text "Please wait" now as myIsInMemory is false Skipping that myIsInMemory test, shows the correct decorated text but also initiates indexing.

Step by step getting to see what is happening (and hopefully why)

Edit : I have Intel(R) Core(TM) i7-10510U CPU @ 1.80GHz 2.30 GHz

Edit 2 : What I have now : I am using a workspace with projects that are already converted. In Activator.java I changed to :

                for (IProject curProject : workspaceRoot.getProjects()) {
                    if (curProject.isOpen()&&false) {

So no initial refresh.

In sloeberproject.java getSloeberproject :

                if (!allowNull || true) {
                    SloeberProject ret = new SloeberProject(project);
                    return ret;
                }

In sloeberproject.java getDecoratedText :

        String pleaseWait = "Please wait"; //$NON-NLS-1$
        if (!myIsInMemory || myIsConfiguring) {
 //           return pleaseWait;
        }

Also return value when !myIsInMemory.

Then when ICProjectDescription prjDesc = CoreModel.getDefault().getProjectDescription(myProject); is executed, the indexing starts.

[jantje]

First of all: "I appreciate your dedication" Most people would have given up by now. So congratulations. Why is it so hard? Because we are dealing with code that has been created by many people with different views without "architectural overview". This means documentation (that should have been written before code is written) is not existing, api's functionality change over time. Add to that that new people (like us) join in and have no clue what it is all about, how it is supposed to work and add stuff (which is very likely suboptimal to say the least) Add to that the non linear behaviour caused by events, triggers, subscriptions .... which behave differently based on hardware and use case. But only by biting the bullet, working hard and learning something like Sloeber can be build. So again congratulations :-)

Secondly, the code you are currently investigating is relatively new. Also I am/was not experienced in this area and I had a really hard time to get things to work. As the code is new it has not been hardened by changes nor by usage. As this was all new to me the quality of the initial code is "doubtful" So do not assume "Jantje knew what he was doing" or "the code does what was intended (matching function names)"

So for instance I assumed SloeberProject ret = new SloeberProject(project); would return an initialized project. Which apparently it doesn't

As to

Then when ICProjectDescription prjDesc = CoreModel.getDefault().getProjectDescription(myProject);
is executed, the indexing starts.

getProjectDescription should not start a indexing but setProjectDescription most likely will

And here is something important. I didn't understand the consequences of using setProjectDescription and I used it liberally ... which I should not have done. I tackled a lot of places but there are probably still plenty of places remaining where setProjectDescription is called for no good reason. Also note that Sloeber uses CDT in a very unique way. A way most CDT developers never thought someone would use it and as such: has never been tested. For instance the public class IndexerController is a late add-on to solve "plugins on top of CDT" and may be your best bet to fix the indexing problem. Like stop the index for a sloeber project when it is opened and remove it when Sloeber is initialized.

[jantje]

I don't know how to test whether a .sproject exists, but I do know it's the

Somethings along the line project.getFile("sproject").exists()

[hreintke]

First of all: "I appreciate your dedication"

Thx.

Also note that Sloeber uses CDT in a very unique way. A way most CDT developers never thought someone would use it and as such: has never been tested.

What is the uniqueness of the cdt usage of sloeber ?

Is there any cdt documentation on the (internals of the) indexer / listeners Edit : Found this : https://help.eclipse.org/latest/index.jsp?nav=%2F14

[jantje]

What is the uniqueness of the cdt usage of sloeber ?

Several things. To name some CDT works with the compiler in the path. As you know Sloeber works with a compiler per configuration. This impacts the indexer CDT works with library projects or executable projects. Sloeber provides it's own makefile generator that allows to generate a library and link that library with other code in one single project.

Edit : Found this : https://help.eclipse.org/latest/index.jsp?nav=%2F14

That is about as good as it gets. Stackoverflow can be helpful from time to time https://stackoverflow.com/questions/tagged/eclipse But the biggest problem with eclipse development is understanding which plugin may provide the functionality you are looking for. I'm also subscribed to the CDT dev list https://accounts.eclipse.org/mailing-list/cdt-dev and there is an archive. In general I can't say I have found eclipse communities welcoming

[hreintke]

Looking into differences between c++ projects and arduino projects.

In the indexer logging I regularly see ' Discover compiler built-in language settings,5,main]]`

Difference on the project/.settings/language.settings.xml' file

In a c++ project this is a file which is not updated. In an arduino project, after a fresh startup, that file is always rewritten once, just after the first time a project is selected. And.. after the first time selecting an arduino project the indexer kicks in with full indexing. On a c++ project nothing happens then.

Can't find where you set/update the language setting of a project. Can you point me to that.

Edit : As soon as Arduino Compiler Settings is included in the preprocessor providers for a project, the indexing has unwanted behavior for that project. Removing that seems to make the indexer quiet. Investigation continues...

If I deselect Arduino Compiler settings and update the CDT Built in compiler settings to the arduino ones :

Indexing works and there is no full indexing at startup, selecting or opening the project

[jantje]

In the indexer logging I regularly see ' Discover compiler built-in language settings,5,main]]`

This is probably caused by what I described as "CDT works with the compiler in the path. As you know Sloeber works with a compiler per configuration." in my post above. It is quite possible Sloeber triggers to many discovery requests but there will be more than in a normal CDT project.

Can't find where you set/update the language setting of a project. Can you point me to that.

"the language setting of a project." would I be happy if I knew what that meant. Here are a couple of things that may represent this. The sloeber core plugin.xml defines a language setting If you look at the ArduinoLanguageProvider that is provided as class for this language provider you will see it only returns a compiler command. Also in the core plugin.xml is the gnu makefile generation stuff which is basically the hart of the CDT/Sloeber make implementation. For instance the ArduinoLanguageProvider uses info from this part to get to the actual command. For instance in this section are the environment variable class SloeberConfigurationVariableSupplier that passes the boards.txt and platform.txt key value pairs to CDT As Sloeber works with environment variables changing the key value pairs can mean changing the command line and this may trigger a discovery and subsequently a indexing.

Indexing works and there is no full indexing at startup, selecting or opening the project

From the info provided above you can see that I will expect that this change will cause problems with the discovery and probably deleting the makefiles and rebuild won't work as well

I think the extra indexings are caused by SloeberProject configure or by the ArduinoLanguageProvider. The configure method originally was only called when doing apply->close in the project properties->arduino As such it was pretty safe to do "extra work" and I made sure things worked after doing so. Now there are 2 change events triggering the code as well.

The ArduinoLanguageProvider is suspect as it may be that CDT compares the command with previous versions and if it is different will cause a discovery.

[hreintke]

Thx, found all the info you were referring to. Now focussing on sloeberProject.configure()

[hreintke]

Still busy, as you said it's not easy. See a lot of things happening but figuring out why it happens.

Also comparing 4.3 & git master. Also 4.3 does (sometimes ?) indexing at startup.

Is there somewhere a list on which listeners can be installed/used in the eclipse/cdt environment ?

[jantje]

Still busy, as you said it's not easy.

I know. It is a very steep learning curve. I've been doing this for over 10 years now but I still feel like a newbee.

See a lot of things happening but figuring out why it happens.

Is about the hardest thing with all this triggering and asynchronous actions and lots of programmers not really knowing what they do (That is about 100% of us)

Is there somewhere a list on which listeners can be installed/used in the eclipse/cdt environment ?

I fear not. But honestly I do think that /io.sloeber.core/src/io/sloeber/core/listeners/IndexerController.java is your best bet. If the sloeber project is not yet configured; indexing should be postponed. Maybe you can configure the sloeber project at that time if not you should postpone it and call /io.sloeber.core/src/io/sloeber/core/listeners/IndexerController.index at the end of configure

FYI I'm currently working on the java compatibility issue and doing some major refactoring. I'm trying to stay away from the stuff you are looking at so we do not have merging problems.

[jantje]

Any progress? I ask because I have a huge change in regards to java compatibility. I do not want to bother you with merging your changes ;-)

[jantje]

I have fixed #1391 which causes a reindexing for sure because all the output files are deleted. I'm not sure whether Sloeber runs an indexing now at the project open but I'm also not sure if CDT indexes a project at project open. The root cause was that project open and configuration changes were both mapped on the same call in resourceChangeListener. When there is a config change Sloeber deletes the build folder as that may be needed. To fix the problem I implemented a different strategy for config changes and project open. The other changes are related to making a cleaner cut between CDT (holding the configurations) and Sloeber (holding the arduino info related to the configurations) and old sloeber way (all is in cdt configurations)

If you have some spare time; please check whether this fixes your problem

[jantje]

This bugzilla passed by today. May be related https://bugs.eclipse.org/bugs/show_bug.cgi?id=575408

[hreintke]

Hi Jantje,

Sorry for not responding properly to your questions. I have been busy with other things the last months but will return to sloeber esp32/rp2040 later this month. But can and will be doing the check you requested on Dec 8 next week.

Is there anything else you want met to test/verify.

[hreintke]

Hi Jantje, Did another try to find/analyze the issue but have to admit that I have no progress at all. No idea how to get any further. I will stick to the workaround of having most of the projects closed to minimize the effect,

Wil stop working on it, but will restart if you want specific options to be evaluated.

[jantje]

It is a very complicated issue requiring in depth knowledge of eclipse cdt and sloeber (and maybe even other plugins installed) Thinking about this. If CDT does not persist it's indexing info (and why should it) an indexing is necessary at startup. However multiple indexing starts were made and still may be made.

[hreintke]

CDT does persist indexing info.

It is in .metadata.plugins\org.eclipse.cdt.core\\.pdom

Edit (Off topic) :

Busy cleaning up and getting a fresh environment. Building sloeber from git master with maven gives this error.

[ERROR] Cannot resolve project dependencies:
[ERROR]   Software being installed: io.sloeber.product 4.4.1.qualifier
[ERROR]   Missing requirement: io.sloeber.product 4.4.1.qualifier requires 'org.eclipse.equinox.p2.iu; org.eclipse.ecf.f
iletransfer.httpclient45.feature.feature.group 0.0.0' but it could not be found

Have you seen that before and/or do you know how to solve ?

[jantje]

Have you seen that before and/or do you know how to solve ?

I have seen similar issues on my build server.

This is a typical eclipse dependency problem probably related to new eclipse release where @wimjongman normally comes to rescue.