[#1668] API types to simplify work with launch configuration attributes #1669

ruspl-afed · 2024-12-19T15:19:08Z

identify launch attribute
connect it with preference metadata (to supply defaults/label/description)
read attribute from configuration
write attribute to configuration working copy
demonstrate usage for ExternalTools

eclipse-platform-bot · 2024-12-19T15:23:34Z

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

ant/org.eclipse.ant.launching/META-INF/MANIFEST.MF
ant/org.eclipse.ant.ui/META-INF/MANIFEST.MF
debug/org.eclipse.ui.externaltools/META-INF/MANIFEST.MF

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

Git patch

From 9d9fc2199cde44fd761137da4d6184cafbefd898 Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <[email protected]>
Date: Mon, 10 Mar 2025 11:24:15 +0000
Subject: [PATCH] Version bump(s) for 4.36 stream


diff --git a/ant/org.eclipse.ant.launching/META-INF/MANIFEST.MF b/ant/org.eclipse.ant.launching/META-INF/MANIFEST.MF
index 701a5b50f8..9c9a10f1a4 100644
--- a/ant/org.eclipse.ant.launching/META-INF/MANIFEST.MF
+++ b/ant/org.eclipse.ant.launching/META-INF/MANIFEST.MF
@@ -3,7 +3,7 @@ Bundle-ManifestVersion: 2
 Bundle-Localization: plugin
 Bundle-Name: %pluginName
 Bundle-SymbolicName: org.eclipse.ant.launching;singleton:=true
-Bundle-Version: 1.4.700.qualifier
+Bundle-Version: 1.4.800.qualifier
 Bundle-Activator: org.eclipse.ant.internal.launching.AntLaunching
 Require-Bundle: org.eclipse.core.runtime;bundle-version="[3.29.0,4.0.0)",
  org.eclipse.debug.core;bundle-version="[3.12.0,4.0.0)",
diff --git a/ant/org.eclipse.ant.ui/META-INF/MANIFEST.MF b/ant/org.eclipse.ant.ui/META-INF/MANIFEST.MF
index 14d67d91bc..d9d8d92c9a 100644
--- a/ant/org.eclipse.ant.ui/META-INF/MANIFEST.MF
+++ b/ant/org.eclipse.ant.ui/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %pluginName
 Bundle-SymbolicName: org.eclipse.ant.ui; singleton:=true
-Bundle-Version: 3.10.0.qualifier
+Bundle-Version: 3.10.100.qualifier
 Bundle-Activator: org.eclipse.ant.internal.ui.AntUIPlugin
 Bundle-Vendor: %providerName
 Bundle-Localization: plugin
diff --git a/debug/org.eclipse.ui.externaltools/META-INF/MANIFEST.MF b/debug/org.eclipse.ui.externaltools/META-INF/MANIFEST.MF
index 3d7bc00b7c..40216b2a14 100644
--- a/debug/org.eclipse.ui.externaltools/META-INF/MANIFEST.MF
+++ b/debug/org.eclipse.ui.externaltools/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %Plugin.name
 Bundle-SymbolicName: org.eclipse.ui.externaltools; singleton:=true
-Bundle-Version: 3.6.500.qualifier
+Bundle-Version: 3.6.600.qualifier
 Bundle-Activator: org.eclipse.ui.externaltools.internal.model.ExternalToolsPlugin
 Bundle-Vendor: %Plugin.providerName
 Bundle-Localization: plugin
-- 
2.48.1

Further information are available in Common Build Issues - Missing version increments.

github-actions · 2024-12-19T15:46:35Z

Test Results

1 947 files 1 947 suites 1h 37m 35s ⏱️
4 720 tests 4 696 ✅ 24 💤 0 ❌
14 160 runs 13 993 ✅ 167 💤 0 ❌

Results for commit e1b3b60.

♻️ This comment has been updated with latest results.

mickaelistria · 2024-12-19T15:53:59Z

As mentioned in the call, some example using this API proposal would be helpful. There is probably some content in org.eclipse.ui.externaltools/External Tools Base/org/eclipse/ui/externaltools/internal/launchConfigurations you can tweak to leverage this API.

ruspl-afed · 2025-01-30T12:15:58Z

I'm not sure why it is is failing @HannesWell

11:59:41.178 [ERROR] Failed to execute goal org.eclipse.tycho:tycho-apitools-plugin:4.0.11-SNAPSHOT:verify (verify) on project org.eclipse.debug.core: 
Execute ApiApplication failed: InvocationTargetException: EmptyStackException -> [Help 1]

HannesWell · 2025-01-30T20:04:07Z

I'm not sure why it is is failing @HannesWell

11:59:41.178 [ERROR] Failed to execute goal org.eclipse.tycho:tycho-apitools-plugin:4.0.11-SNAPSHOT:verify (verify) on project org.eclipse.debug.core: 
Execute ApiApplication failed: InvocationTargetException: EmptyStackException -> [Help 1]

It looks like your change is breaking API-tools^^
I have replayed the Jenkins build the -e set to get an more informative stack-trace:
https://ci.eclipse.org/platform/job/eclipse.platform/job/PR-1669/7/

ruspl-afed · 2025-01-31T06:56:53Z

Thank you @HannesWell for your assistance.

It looks like your change is breaking API-tools^^

WOW! But that wasn't part of my plan. It looks like this issue was already reported. Interesting, may be I can have a deeper look to it soon.

And still interested in your feedback regarding PR content.

ruspl-afed · 2025-02-01T06:32:01Z

After supporting record for API Tools everything is green @HannesWell

ruspl-afed · 2025-02-04T06:43:49Z

ok, a few more days for discussion and I'm going to merge it

HannesWell · 2025-02-05T00:37:44Z

After supporting record for API Tools everything is green @HannesWell

Thank you for that fix/enhancement of API-tools! It's much appreciated.

And still interested in your feedback regarding PR content.

Sorry for not responding. It has been some busy days recently. I have not forgotten this, just didn't have the time for it.
I try my best to have look at it in the next days.

HannesWell

I had a more detailed look at it and understand the goal and see the benefits from this: Better type-safety and more convenient read and writes.
Nevertheless I'm not sure that these benefits really carry the weight of the change, because currently the new API surface is very big.
Below I made some suggestion to make the API more compact, maybe we can then achieve a sufficiently got relation of advantages to API surface.

With these suggestions we would end up with just the LaunchAttributeIdentity and LaunchAttributeDefined types. Maybe we could even 'inline' the former into the latter and would then still get benefits mentioned above.
And eventually just having an ILaunchAttribute interface added with a few static factories to create them is something that could indeed be a in my opinion suitable addition.

debug/org.eclipse.debug.core/core/org/eclipse/debug/core/LauchAttributeIdentityRecord.java

debug/org.eclipse.debug.core/core/org/eclipse/debug/core/LaunchAttributeDefined.java

debug/org.eclipse.debug.core/core/org/eclipse/debug/core/LaunchAttributeProbe.java

debug/org.eclipse.debug.core/core/org/eclipse/debug/core/LaunchAttributeRead.java

debug/org.eclipse.debug.core/core/org/eclipse/debug/core/LaunchAttributeWrite.java

...c/org/eclipse/core/externaltools/internal/launchConfigurations/LaunchAttributeArguments.java

HannesWell · 2025-02-08T00:09:57Z

debug/org.eclipse.debug.core/core/org/eclipse/debug/core/LaunchAttributeRead.java

+		if (String.class.equals(type)) {
+			return type.cast(configuration.getAttribute(id, String.class.cast(value.get())));
+		}


Couldn't we have this if-chain in the constructor and then encapsulate the action into a lambda and just execute it here?

not so sure

ruspl-afed · 2025-02-08T13:08:06Z

Thank you for your feedback @HannesWell

PR was reimplemented according to your comments.
I'm not sure why we are fighting for reducing number of API types with adding more API methods and more implementation code the the interface compilation unit, but the result looks much more closer to the old good Eclipse 2.0 style of Debug subsystem.

HannesWell · 2025-02-09T12:08:53Z

I'm not sure why we are fighting for reducing number of API types with adding more API methods and more implementation code the the interface compilation unit, but the result looks much more closer to the old good Eclipse 2.0 style of Debug subsystem.

I don't consider it as a fight, more as a search for (ideally) the best solution. Of course what is best is also a matter of opinion, but at least my personal opinion is that in general I like more compact APIs better. However can you please explain to me what the advantage is of defining in types what could be methods respectively why exactly this is Eclipse-2.0 style and why it's bad (I haven't been around back then)?
With the suggestions made we could still define typed launch-attributes using LaunchAttribute(-Defined/Definition) as static constant and read/write with it from/to a LaunchConfiguration in a more convenient way, couldn't we?

But of course others can have other opinions about it and I invite everyone to share theirs.

ruspl-afed · 2025-02-09T13:26:57Z

You are right @HannesWell , it's definitely a matter of personal opinion. For me the old good Eclipse 2.0 style means a lot of static definitions, favoring of primitive types in API and a lot of setters to reuse one instance as long as one can. All this was actual 25 years ago for ancient JVMs. Nowadays we have modern JVM and very dynamic environment where non-replaceable static definition can cause problems and saving memory due to mutability of objects does not justify the cost of (much more complex) code support.

And even if I've stopped naming interfaces with "I" for new code and prefer simple immutable objects with very simple interfaces, I've done a lot following your comments to make this API improvement better suited to the surrounding code.

Now the question is: what else should be improved in this PR? I still can see your "change requested" veto but your latest comment doesn't content any direct change requests. Please clarify.

ruspl-afed · 2025-02-11T18:42:08Z

Hello @HannesWell
What else do you think should be changed in this PR?

HannesWell

You are right @HannesWell , it's definitely a matter of personal opinion. For me the old good Eclipse 2.0 style means a lot of static definitions, favoring of primitive types in API and a lot of setters to reuse one instance as long as one can. All this was actual 25 years ago for ancient JVMs. Nowadays we have modern JVM and very dynamic environment where non-replaceable static definition can cause problems and saving memory due to mutability of objects does not justify the cost of (much more complex) code support.

My concern is not about a few objects more or less, I look at these new types from a consumer-perspective and how difficult a new API is to understand and learn. And there my experience/opinion is that 'distributed' types are more difficult and having it compact makes the capabilities easier to discover (as an IMO bad example: try to configure a JFace resource manager properly to be disposed with a Control and a child of the global registry).
As far as I know the problematic part of the Eclipse 2.0 style you referring to is that there tend to be only one large class that provided almost everything as static methods that don't allow dynamics, e.g. the Platform class in eclipse.runtime.
But at least from my perspective we are here talking about static factories on types (classes or interfaces), which I don't consider old-style. In fact I have the impression that's often the preferred way over constructors and many are added in Eclipse. From the top of my head I remember e.g. ILog or IPath or in the JDK there is Path.of() or the brand-new Classfile-API also makes heavy use of static factory methods AFAIK.

And even if I've stopped naming interfaces with "I" for new code and prefer simple immutable objects with very simple interfaces

Personally I'm also not fully convinced that it's best to prefix all interfaces I. But in the end Eclipse is an existing code-base and when adding elements considering how new code fits into the existing code-base is IMO also an item to consider. Of course that doesn't make it simpler. Immutability is also something I think has many advantages and I try to achieve. For simple interfaces on the other hand, I would say it depends and that's IMO where the work starts and were the quality of an API is measured, if the 'right' size is found.

Now the question is: what else should be improved in this PR? I still can see your "change requested" veto but your latest comment doesn't content any direct change requests. Please clarify.

Sorry, I simply oversaw that you made changes. I was very busy of getting rid of the JXPath dependency in platform.ui.
I have now made another pass, please see the comments below.

debug/org.eclipse.debug.core/core/org/eclipse/debug/core/ILaunchAttribute.java

...e.core.externaltools/src/org/eclipse/core/externaltools/internal/IExternalToolConstants.java

debug/org.eclipse.debug.core/core/org/eclipse/debug/core/ILaunchAttributeIdentity.java

HannesWell

Thanks for the update.
I didn't had the time for a detailed review. I still think we should handle the case where the default value depends on other attributes, because IIRC we have this case multiple times in PDE and I would like to have this covered. But I'll provide a specific example for that.

I'll be on vacation now, but when back I'll come back to this. Sorry for the further delay.

debug/org.eclipse.debug.core/core/org/eclipse/debug/core/ILaunchAttribute.java

ruspl-afed · 2025-07-20T07:12:25Z

@HannesWell I changed it to a state that we discussed on a meeting:

remove ILaunchAttributeIdentity
minimize API surface

ruspl-afed · 2025-07-23T05:44:09Z

@HannesWell do you have more comments on this one?

HannesWell · 2025-07-23T08:39:11Z

@HannesWell do you have more comments on this one?

I didn't had the time yet to look into this, but definitely want to.
Try to respond until the end of this week and will also look how to use this for PDE.

* identify launch attribute * connect it with preference metadata (to supply defaults/label/description) * read attribute from configuration * write attribute to configuration working copy * demonstrate usage for ExternalTools

HannesWell · 2025-07-28T19:49:18Z

@HannesWell do you have more comments on this one?

I didn't had the time yet to look into this, but definitely want to. Try to respond until the end of this week and will also look how to use this for PDE.

I only had the time for a short look at this change and in general I think this looks very good now. But I'd like to do an in depth review and try my best to do it tomorrow or Wednesday.

HannesWell

Thank you for the update.

Conceptually I'm really happy with it now and for the API I just have one suggestion about the name of the probe method. And we should consider to have more factories to avoid verbosity in simple cases.

Everything else are just minor internal implementation details.

HannesWell · 2025-07-30T21:47:52Z

...se.ant.ui/Ant Tools Support/org/eclipse/ant/internal/ui/launchConfigurations/AntMainTab.java

-		catch (CoreException e) {
-			// do nothing
-		}
+		fCurrentLocation = IExternalToolConstants.LAUNCH_ATTRIBUTE_LOCATION.probe(configuration);


Before fCurrentLocation was left unchanged, if getAttribute() threw. But as the code below also handles empty optional, I think this change is fine.

HannesWell · 2025-07-30T21:48:32Z

...e.core.externaltools/src/org/eclipse/core/externaltools/internal/IExternalToolConstants.java

 	 */
-	String UI_PLUGIN_ID = "org.eclipse.ui.externaltools"; //$NON-NLS-1$;
+	String UI_PLUGIN_ID = "org.eclipse.ui.externaltools"; //$NON-NLS-1$ ;


Can you please remove the unnecessary trailing semicolon here and below?

Suggested change

String UI_PLUGIN_ID = "org.eclipse.ui.externaltools"; //$NON-NLS-1$ ;

String UI_PLUGIN_ID = "org.eclipse.ui.externaltools"; //$NON-NLS-1$

HannesWell · 2025-07-30T21:50:14Z

...g/eclipse/core/externaltools/internal/launchConfigurations/ExternalToolsProgramMessages.java

+
+	public static String LaunchAttributeArguments_name;
+
+
+	public static String LaunchAttributeLocation_name;
+
+
+	public static String LaunchAttributeWorkingDirectory_name;


Please avoid excessive new lines.

Suggested change

public static String LaunchAttributeArguments_name;

public static String LaunchAttributeLocation_name;

public static String LaunchAttributeWorkingDirectory_name;

public static String LaunchAttributeArguments_name;

public static String LaunchAttributeLocation_name;

public static String LaunchAttributeWorkingDirectory_name;

HannesWell · 2025-07-30T21:52:13Z

.../External Tools Base/org/eclipse/ui/externaltools/internal/model/IExternalToolConstants.java

@@ -1,5 +1,5 @@
 /*******************************************************************************
- * Copyright (c) 2000, 2013 IBM Corporation and others.
+ * Copyright (c) 2000, 2025 IBM Corporation and others.


I cannot see any relevant change in this class, beside white-space changes.
If that's correct, please leave this class untouched.

HannesWell · 2025-07-30T21:54:29Z

debug/org.eclipse.debug.core/core/org/eclipse/debug/core/ILaunchAttribute.java

+	 *            must not be <code>null</code>
+	 * @return the {@link Optional} with attribute value
+	 */
+	Optional<V> probe(ILaunchConfiguration configuration);


I have to admit that I found the method name probe a bit unusual (and I'm not even sure it fit's perfectly here).
What about just naming this method to the ordinary name get()? With read one could somehow expect that it could fail.

Suggested change

Optional<V> probe(ILaunchConfiguration configuration);

Optional<V> get(ILaunchConfiguration configuration);

HannesWell · 2025-07-30T21:57:35Z

debug/org.eclipse.debug.core/core/org/eclipse/debug/core/ILaunchAttribute.java

+	 * @param type the value type of the attribute, must not be
+	 *            <code>null</code>


Instead of ``nullI generally would just use{@code null}`.

Suggested change

* @param type the value type of the attribute, must not be

* <code>null</code>

* @param type the type of the attribute value, must not be {@code null}

HannesWell · 2025-07-30T22:00:18Z

debug/org.eclipse.debug.core/core/org/eclipse/debug/core/ILaunchAttribute.java

+	 * @param value the {@link Function} to calculate of default value of the
+	 *            attribute from {@link ILaunchConfiguration}, must not be
+	 *            <code>null</code>


Maybe name this parameter defaultValue?

Suggested change

* @param value the {@link Function} to calculate of default value of the

* attribute from {@link ILaunchConfiguration}, must not be

* <code>null</code>

* @param defaultValue the {@link Function} to calculate the default value of the

* attribute for a given {@link ILaunchConfiguration}, must not be

* {@code null}.

As it's mentioned very often that an attribute may not be null, what about stating that once in the interface description and only mention the cases where null is allowed (I assume nowhere?)

HannesWell · 2025-07-30T22:02:56Z

debug/org.eclipse.debug.core/core/org/eclipse/debug/core/ILaunchAttribute.java

+	static <V> ILaunchAttribute<V> of(String id, Class<V> type, Function<ILaunchConfiguration, V> value, String name) {
+		return new ConsiderStringVariables<>(id, type, value, name, name);
+	}


As many callers just specify lc -> null as default value, what do you think about providing two more overloads for convenience for attributes that have a fixed default and no default:

of(String id, Class<V> type, V defaultValue, String name)

of(String id, Class<V> type, String name)

They can then just call the main of method with a corresponding lambda.

HannesWell · 2025-07-30T22:07:58Z

debug/org.eclipse.debug.core/core/org/eclipse/debug/core/ConsiderStringVariables.java

+		if (String.class.equals(type)) {
+			working.setAttribute(id, String.class.cast(value));
+		} else if (Integer.class.equals(type)) {
+			working.setAttribute(id, Integer.class.cast(value).intValue());
+		} else if (Boolean.class.equals(type)) {
+			working.setAttribute(id, Boolean.class.cast(value).booleanValue());
+		} else if (List.class.equals(type)) {
+			working.setAttribute(id, List.class.cast(value));
+		} else if (Map.class.equals(type)) {
+			working.setAttribute(id, Map.class.cast(value));
+		} else if (Set.class.equals(type)) {
+			working.setAttribute(id, Set.class.cast(value));
+		} else {
+			working.setAttribute(id, value);
+		}


Is the distinction for the actual type actually necessary? AFAICT all special methods delegate to the object accepting variant any ways?

Suggested change

if (String.class.equals(type)) {

working.setAttribute(id, String.class.cast(value));

} else if (Integer.class.equals(type)) {

working.setAttribute(id, Integer.class.cast(value).intValue());

} else if (Boolean.class.equals(type)) {

working.setAttribute(id, Boolean.class.cast(value).booleanValue());

} else if (List.class.equals(type)) {

working.setAttribute(id, List.class.cast(value));

} else if (Map.class.equals(type)) {

working.setAttribute(id, Map.class.cast(value));

} else if (Set.class.equals(type)) {

working.setAttribute(id, Set.class.cast(value));

} else {

working.setAttribute(id, value);

}

working.setAttribute(id, value);

Similarly, although I haven't checked it in detail, the readInternal method maybe can be simplified too?

HannesWell · 2025-07-30T22:10:55Z

debug/org.eclipse.debug.core/core/org/eclipse/debug/core/ConsiderStringVariables.java

+ *
+ * @see IStringVariableManager
+ */
+record ConsiderStringVariables<V>(String id, Class<V> type, Function<ILaunchConfiguration, V> defaults, String name, String description) implements ILaunchAttribute<V> {


Name and description seem unused atm.

Suggested change

record ConsiderStringVariables<V>(String id, Class<V> type, Function<ILaunchConfiguration, V> defaults, String name, String description) implements ILaunchAttribute<V> {

record ConsiderStringVariables<V>(String id, Class<V> type, Function<ILaunchConfiguration, V> defaultValue) implements ILaunchAttribute<V> {

ruspl-afed force-pushed the 1668 branch 3 times, most recently from ceac906 to 0eaee71 Compare January 30, 2025 11:38

ruspl-afed force-pushed the 1668 branch from 5740dd9 to 35d8960 Compare February 1, 2025 05:55

HannesWell force-pushed the 1668 branch from 35d8960 to 8beaf15 Compare February 7, 2025 23:30

HannesWell requested changes Feb 8, 2025

View reviewed changes

ruspl-afed force-pushed the 1668 branch 3 times, most recently from aebee8c to a278c9a Compare February 8, 2025 13:00

ruspl-afed force-pushed the 1668 branch from a278c9a to 195c995 Compare February 11, 2025 17:16

HannesWell reviewed Feb 12, 2025

View reviewed changes

ruspl-afed force-pushed the 1668 branch 5 times, most recently from 1d54c43 to 502eedc Compare February 12, 2025 15:45

HannesWell reviewed Mar 3, 2025

View reviewed changes

debug/org.eclipse.debug.core/core/org/eclipse/debug/core/ILaunchAttribute.java Outdated Show resolved Hide resolved

ruspl-afed force-pushed the 1668 branch 2 times, most recently from 146cae3 to 0d99094 Compare March 14, 2025 06:24

ruspl-afed force-pushed the 1668 branch 3 times, most recently from 1c2827e to 425af03 Compare July 20, 2025 07:09

ruspl-afed force-pushed the 1668 branch 3 times, most recently from cfe45ed to e808a43 Compare July 20, 2025 14:21

ruspl-afed requested a review from HannesWell July 20, 2025 15:42

ruspl-afed force-pushed the 1668 branch from e808a43 to 893238c Compare July 23, 2025 05:43

ruspl-afed force-pushed the 1668 branch from 893238c to e1b3b60 Compare July 24, 2025 13:04

HannesWell reviewed Jul 30, 2025

View reviewed changes

	String UI_PLUGIN_ID = "org.eclipse.ui.externaltools"; //$NON-NLS-1$ ;
	String UI_PLUGIN_ID = "org.eclipse.ui.externaltools"; //$NON-NLS-1$

	Optional<V> probe(ILaunchConfiguration configuration);
	Optional<V> get(ILaunchConfiguration configuration);

		* @param type the value type of the attribute, must not be
		* <code>null</code>

	* @param type the value type of the attribute, must not be
	* <code>null</code>
	* @param type the type of the attribute value, must not be {@code null}

	record ConsiderStringVariables<V>(String id, Class<V> type, Function<ILaunchConfiguration, V> defaults, String name, String description) implements ILaunchAttribute<V> {
	record ConsiderStringVariables<V>(String id, Class<V> type, Function<ILaunchConfiguration, V> defaultValue) implements ILaunchAttribute<V> {

[#1668] API types to simplify work with launch configuration attributes #1669

Are you sure you want to change the base?

[#1668] API types to simplify work with launch configuration attributes #1669

Uh oh!

Conversation

ruspl-afed commented Dec 19, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

eclipse-platform-bot commented Dec 19, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Dec 19, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results

Uh oh!

mickaelistria commented Dec 19, 2024

Uh oh!

ruspl-afed commented Jan 30, 2025

Uh oh!

HannesWell commented Jan 30, 2025

Uh oh!

ruspl-afed commented Jan 31, 2025

Uh oh!

ruspl-afed commented Feb 1, 2025

Uh oh!

ruspl-afed commented Feb 4, 2025

Uh oh!

HannesWell commented Feb 5, 2025

Uh oh!

HannesWell left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ruspl-afed commented Feb 8, 2025

Uh oh!

HannesWell commented Feb 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ruspl-afed commented Feb 9, 2025

Uh oh!

ruspl-afed commented Feb 11, 2025

Uh oh!

HannesWell left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

HannesWell left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ruspl-afed commented Jul 20, 2025

Uh oh!

ruspl-afed commented Jul 23, 2025

Uh oh!

HannesWell commented Jul 23, 2025

Uh oh!

HannesWell commented Jul 28, 2025

Uh oh!

HannesWell left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ruspl-afed commented Dec 19, 2024 •

edited

Loading

eclipse-platform-bot commented Dec 19, 2024 •

edited

Loading

github-actions bot commented Dec 19, 2024 •

edited

Loading

HannesWell commented Feb 9, 2025 •

edited

Loading