better support justj #154

laeubi · 2021-06-17T12:17:29Z

The documentation of justj contaisn severals hint/issues on configuration for tycho. We shoudl try to better support justj.

One example is that currently using justj requires to use <resolveWithExecutionEnvironmentConstraints>false</resolveWithExecutionEnvironmentConstraints> in some cases as tycho otherwhise fails to resolve some bundles/dependecies, also the explicit configuration of <executionEnvironment>org.eclipse.justj.openjdk.hotspot.jre.full-15</executionEnvironment> seems superflous.

One can currently easyly break a build by simply reference justj as a repository...

The text was updated successfully, but these errors were encountered:

mickaelistria · 2021-06-17T15:11:03Z

JustJ documentation is outdated, this was slightly improved in latest Tycho release.
See for example https://www.eclipse.org/tycho/sitedocs/target-platform-configuration/target-platform-configuration-mojo.html#executionEnvironment which does mention how to let resolution use JustJ simply by not injecting a particular EE; this is simpler to understand and more correct than using resolveWithExecutionEnvironmentConstraints=true (which will inject even more extra units to emulate the EE while one would typically want less)

laeubi · 2021-06-17T15:38:50Z

In my particular case I was not able to make it work, as soon as I enable the <executionEnvironment>org.eclipse.justj.openjdk.hotspot.jre.full-15</executionEnvironment> I get complaints from some dependecies tha e.g. are compiled with and claim to require JavaSE-8, maybe its just another configuration option.

The main point here is, that I think we should somehow detect something like justj in the target and configure tycho somewhat automatic so "just it works" without much extra configuration.

mickaelistria · 2021-06-17T15:54:57Z

In my particular case I was not able to make it work, as soon as I enable the org.eclipse.justj.openjdk.hotspot.jre.full-15

That's not what's in the doc (also doc might be unclear). For this to work, JustJ must be part of the resolved target platform, as a dependency of any form, and <executionEnvironment>none</executionEnvironment>.

The main point here is, that I think we should somehow detect something like justj in the target and configure tycho somewhat automatic so "just it works" without much extra configuration.

That's a good idea; but not desired in the general case: if I'm building a random bundle and using in the TP a p2 repo that contains JustJ, it doesn't imply at all that JustJ should be the EE and should take priority over the EE that's deduced from the .target or MANIFEST.MF file. This should remain a user decision and setting, not something to automate.
It would IMO seem more interesting to detect this error case and improve the error message with a hint about how to troubleshot this particular case.
"Something like JustJ" => a unit that contains some capabilities with osgi.ee namespace.

laeubi · 2021-06-17T16:02:03Z

(also doc might be unclear)

at least to me obviously :-\

if I'm building a random bundle and using in the TP a p2 repo that contains JustJ, it doesn't imply at all that JustJ should be the EE and should take priority over the EE that's deduced from the .target or MANIFEST.MF file

But that's what actually happens (and why I opened this ticket) as

The JustJ JREs have explicit negative requirements to exclude a.jre and a.jre.javase from consideration during resolution

that leads in my case to a state where I was not able to build anyone once I include the justj as a repository (even though I just reference it in a product as a feature).

mickaelistria · 2021-06-17T16:14:20Z

OK, I now understand the issue about negative requirements.
Currently, the JustJ repo is only suitable when added to a repository/product module build; it's indeed causing issues for regular bundle/feature builds. I have not investigated further how this issue with the negative requirement can be removed; when we have a a.jre.unit defined by Tycho for dependency resolution and JustJ is not a dependency, I don't think we should see such error about justj making resolution fail.

Signed-off-by: Christoph Läubrich <laeubi@laeubi-soft.de>

laeubi · 2021-06-21T05:35:42Z

@mickaelistria I have created an example that shows the problem.
If you build the project it will fail with

[ERROR] Cannot resolve project dependencies:
[ERROR]   Software being installed: a.jre.javase 11.0.0
[ERROR]   Software being installed: product-with-justj-features 0.0.1
[ERROR]   Cannot satisfy dependency: org.eclipse.justj.openjdk.hotspot.jre.full 11.0.2.v20200815-0835 depends on: org.eclipse.equinox.p2.iu; a.jre.javase 0.0.0
[ERROR]   Cannot satisfy dependency: org.eclipse.justj.openjdk.hotspot.jre.full.feature.group 11.0.2.v20200815-0835 depends on: org.eclipse.equinox.p2.iu; org.eclipse.justj.openjdk.hotspot.jre.full [11.0.2.v20200815-0835,11.0.2.v20200815-0835]
[ERROR]   Cannot satisfy dependency: product-with-justj-features 0.0.1 depends on: org.eclipse.equinox.p2.iu; org.eclipse.justj.openjdk.hotspot.jre.full.feature.group 0.0.0

interestingly the build succeeds if one only uses a plugin based (just comment out the <module>feature-product</module>) but emits a warning
[WARNING] Mirror tool: Problems resolving provisioning plan.: [Unable to satisfy dependency from product-with-justj-bundles 0.0.1 to org.eclipse.equinox.p2.iu; org.eclipse.justj.openjdk.hotspot.jre.full [11.0.2.v20200815-0835,11.0.2.v20200815-0835].]
that suggest that instead there is actually something wrong.

laeubi · 2021-06-21T05:50:02Z

What makes the build succeed in this case is adding

<plugin>
     <groupId>org.eclipse.tycho</groupId>
     <artifactId>target-platform-configuration</artifactId>
     <version>${tycho-version}</version>
     <configuration>
        <executionEnvironment>org.eclipse.justj.openjdk.hotspot.jre.full-11</executionEnvironment>
     </configuration>
  </plugin>

as suggested in the documentation. In a larger project I'm getting resolution errors with this configuration (I'm currently try to reproduce this as well).

Also as suggested I wonder if we could somehow "detect" the presence of such an ee in the target and maybe configure this by default?

laeubi · 2021-06-21T05:55:10Z

e.g. CustomEEResolutionHandler has checks to find a unit for the specified EE, so it seems possible to search for all units providing an EE and select the one that best fits.

laeubi · 2021-06-21T07:51:58Z

For the problematic dependency I get

Missing requirement: com.github.haifengl.smile-core 1.5.3 requires 'osgi.ee; (&(osgi.ee=JavaSE)(version=1.8))' but it could not be found

during the build (without justj everything works fine or if I disable resolveWithExecutionEnvironmentConstraints).

laeubi · 2021-06-21T07:55:28Z

Using <executionEnvironment>none</executionEnvironment> results in

[ERROR] Internal error: java.lang.IllegalStateException: Full specification of custom profile is not (yet) determined -> [Help 1]
org.apache.maven.InternalErrorException: Internal error: java.lang.IllegalStateException: Full specification of custom profile is not (yet) determined
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:120)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:957)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:193)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
Caused by: java.lang.IllegalStateException: Full specification of custom profile is not (yet) determined
	at org.eclipse.tycho.core.ee.ExecutionEnvironmentConfigurationImpl.getFullSpecification(ExecutionEnvironmentConfigurationImpl.java:131)
	at org.eclipse.tycho.core.osgitools.OsgiBundleProject.getResolverState(OsgiBundleProject.java:272)
	at org.eclipse.tycho.core.osgitools.OsgiBundleProject.resolveClassPath(OsgiBundleProject.java:174)
	at org.eclipse.tycho.core.resolver.DefaultTychoResolver.resolveProject(DefaultTychoResolver.java:142)
	at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.lambda$resolveProjects$0(TychoMavenLifecycleParticipant.java:127)
	at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
	at java.base/java.util.stream.WhileOps$1$1.accept(WhileOps.java:99)
	at java.base/java.util.ArrayList$ArrayListSpliterator.tryAdvance(ArrayList.java:1631)
	at java.base/java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:127)
	at java.base/java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:502)
	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:488)
	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
	at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
	at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
	at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.resolveProjects(TychoMavenLifecycleParticipant.java:158)
	at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:102)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:264)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
	... 11 more

HannesWell · 2021-06-24T10:11:31Z

What makes the build succeed in this case is adding
<plugin>
     <groupId>org.eclipse.tycho</groupId>
     <artifactId>target-platform-configuration</artifactId>
     <version>${tycho-version}</version>
     <configuration>
        <executionEnvironment>org.eclipse.justj.openjdk.hotspot.jre.full-11</executionEnvironment>
     </configuration>
  </plugin>
as suggested in the documentation. In a larger project I'm getting resolution errors with this configuration (I'm currently try to reproduce this as well).

Also as suggested I wonder if we could somehow "detect" the presence of such an ee in the target and maybe configure this by default?

I recently integrated the JustJ-JRE 11 in our build where we build bundles, features and products together and everything worked fine when using only the quoted configuration mentioned by you. But this only worked with Tycho 2.3.0 and not before.
I reported it in the JustJ form, which lead to the latest update of the JustJ-doc.

In order to make it work, I had to debug Tycho (since the doc was not updated yet) and found the following classes as interesting parts:

org.eclipse.tycho.core.ee.ExecutionEnvironmentConfigurationImpl
org.eclipse.tycho.core.osgitools.AbstractTychoProject#readExecutionEnvironmentConfiguration(ReactorProject, MavenSession,ExecutionEnvironmentConfiguration)

Maybe this helps you in debugging for your problem.
Of course it would be even better if no special configuration would be possible.
I did not fully understand the concept of the a.jre yet but from what I read it is often causing problems and there are attempts/desires to remove it. Maybe this would help here too.

mickaelistria · 2021-06-28T09:36:59Z

Using none results in [ERROR]

OK, this should be fixed. I'm looking at it.

mickaelistria · 2021-07-01T07:08:26Z

I found out that adding the EE unit to rootIUs in P2ResolverImpl.resolveDependencies() helps to silent the conflict between a.jre.javase and justj: with the rootIUs being an extra constraint, p2 knows what to do and doesn't face conflict. That helps for bundles.
But it has an opposite effect for products; those would still have to set <executionEnvironment>none</executionEnvironment> when using JustJ or they get polluted by irrelevant a.jre.javase stuff.

laeubi · 2021-07-01T07:28:36Z

polluted by irrelevant a.jre.javase stuff

Thanks for the analysis, does this matter in any way?

mickaelistria · 2021-07-01T09:47:03Z

Having extra a.jre.javase in product doesn't matter as long as they're not required together with justj. Building a bundle and building a product have opposite expectations: the bundle should force isage of the a.jre.javase from EE by default to get justj ignored, while the product shouldn't force any EE ehen justj is required.

laeubi · 2021-07-01T09:52:25Z

I include justj as a feature in the products where it is relevan't should this include justj even though it is "ignored"?

Signed-off-by: Christoph Läubrich <laeubi@laeubi-soft.de>

mickaelistria · 2021-07-01T16:46:03Z

See #167 which shows a demo of how different projects play with JustJ. It looks like recent update to newer Equinox/p2 improved the situation enough so

nothing particular is required for bundles (although it's likely JustJ units might be used in place of the expected a.jre.javase ones)
modules that want to include justj (eg products) need to set <executionEnvironment>none</executionEnvironment> to avoid the a.jre.javase to leak in.

laeubi · 2021-07-03T04:23:40Z

I found out that adding the EE unit to rootIUs in P2ResolverImpl.resolveDependencies() helps to silent the conflict between a.jre.javase and justj: with the rootIUs being an extra constraint, p2 knows what to do and doesn't face conflict. That helps for bundles.

@mickaelistria do you think we can add this change as a first step? Together with your example I think this is already a valuable improvement.

mickaelistria · 2021-07-03T08:06:27Z

See #167 is building fine on top of latest master; with just <executionEnvironment>none</executionEnvironment> for products that do include JustJ and without any change. I'm still unsure there is much we need to fix for the case of the bundle.
For the product, there is probably a way to get <executionEnvironment>none</executionEnvironment> not necessary.

mickaelistria · 2021-07-03T08:07:18Z

And let me repeat that "resolveWithExecutionEnvironmentConstraints" is a bad thing and should be avoided. I actually hope we can deprecate and remove this flag soon.

laeubi · 2021-07-03T09:06:38Z

resolveWithExecutionEnvironmentConstraints" is a bad thing and should be avoided

Not using that option my build fails with:

[ERROR] Internal error: java.lang.IllegalStateException: Full specification of custom profile is not (yet) determined -> [Help 1]
org.apache.maven.InternalErrorException: Internal error: java.lang.IllegalStateException: Full specification of custom profile is not (yet) determined
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:120)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:957)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:193)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
Caused by: java.lang.IllegalStateException: Full specification of custom profile is not (yet) determined
	at org.eclipse.tycho.core.ee.ExecutionEnvironmentConfigurationImpl.getFullSpecification(ExecutionEnvironmentConfigurationImpl.java:131)
	at org.eclipse.tycho.core.osgitools.OsgiBundleProject.getResolverState(OsgiBundleProject.java:325)
	at org.eclipse.tycho.core.osgitools.OsgiBundleProject.resolveClassPath(OsgiBundleProject.java:196)
	at org.eclipse.tycho.core.resolver.DefaultTychoResolver.resolveProject(DefaultTychoResolver.java:173)
	at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.lambda$resolveProjects$0(TychoMavenLifecycleParticipant.java:127)
	at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
	at java.base/java.util.stream.WhileOps$1$1.accept(WhileOps.java:99)
	at java.base/java.util.ArrayList$ArrayListSpliterator.tryAdvance(ArrayList.java:1631)
	at java.base/java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:127)
	at java.base/java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:502)
	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:488)
	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
	at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
	at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
	at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.resolveProjects(TychoMavenLifecycleParticipant.java:158)
	at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:102)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:264)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
	... 11 more

mickaelistria · 2021-07-03T10:29:55Z

Please add a test that shows this error.

laeubi · 2021-07-03T10:32:38Z

See my initial example and #154 (comment) what should show the problem.

mickaelistria · 2021-07-03T10:36:05Z

See #167 which includes your example and have things working fine.

…yet) determined Signed-off-by: Christoph Läubrich <laeubi@laeubi-soft.de>

laeubi · 2021-07-03T12:23:33Z

See #167 which includes your example and have things working fine.

Well you asked for an example that reproduces the error (and it doesn't really help to reference a different/adjusted one where it work then...), so for completeness I created: #174 that shows a common setup and fails with the given error...

Using <executionEnvironment>none</executionEnvironment> it fails
using <resolveWithExecutionEnvironmentConstraints>false</resolveWithExecutionEnvironmentConstraints> succeeds...

mickaelistria · 2021-07-03T13:31:38Z

As mentioned <executionEnvironment>none</executionEnvironment> should only be set for products at the moment. Nothing seems required for bundles, which actually are better using the a.jre.javase untils that match their EE better. So to improve JustJ support, we need to find a way for product resolution to not fail without this flag.
<resolveWithExecutionEnvironmentConstraints>false</resolveWithExecutionEnvironmentConstraints> should simply never ever be used.

laeubi · 2021-07-03T14:26:31Z

But still executionEnvironment=none should not result in obsure error or do I misunderstand something?

laeubi · 2021-07-03T16:38:10Z

has executionEnvironment=none any impact if jsutj is not used? Maybe one should simply behave as if none is set for every product (actually a product can't have an EE anyways....)

mickaelistria · 2021-07-05T13:26:56Z

has executionEnvironment=none any impact if jsutj is not used?

Yes, this won't inject an unit to emulate the EE (a.jre.javase) and if no EE is already present in TP, it will make dependency resolution fails because of missing osgi.ee capabilities.

laeubi · 2021-09-19T15:30:04Z

@mickaelistria is your recent change to drop JREAction related here?

mickaelistria · 2021-09-19T19:47:06Z

Is your recent change to drop JREAction related here?

I don't think so.

bjmi · 2022-02-18T02:33:07Z

After innumerous attempts to include a JustJ JRE 11 into a product build I luckily found this https://www.eclipse.org/forums/index.php?t=msg&th=1106526&goto=1836594&#msg_1836594

In the end, it's all kind of voodoo black magic, and all kind of frustrating.

The only working solution for me was: org.eclipse.justj.buildtime=true

<artifactId>target-platform-configuration</artifactId>
<configuration>
    <dependency-resolution>
        <profileProperties>
            <org.eclipse.justj.buildtime>true</org.eclipse.justj.buildtime>
        </profileProperties>
    </dependency-resolution>
</configuration>

None of following settings worked for me.

<executionEnvironment>org.eclipse.justj.openjdk.hotspot.jre.full-11</executionEnvironment>
<filters><filter><type>p2-installable-unit</type><id>a.jre.javase</id><removeAll /></filter></filters>

laeubi · 2022-02-18T05:08:26Z

"Did not work" is a bit vague can you explain the setup / problems your are encountered? Tycho include an example for a JustJ + product here: https://github.com/eclipse/tycho/tree/master/demo/justj/product

bjmi · 2022-02-28T13:36:23Z

Given:

Folder / module with Eclipse Target
.target platform file contains
<targetJRE path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-11"/>
Product folder / module
pom.xml contains

<repository>
    <id>justj</id>
    <url>https://download.eclipse.org/justj/jres/11/updates/release/latest/</url>
    <layout>p2</layout>
</repository>

.product file contains

<features>
    ...
    <feature id="org.eclipse.justj.openjdk.hotspot.jre.full" installMode="root"/>
</features>

Building the whole reactor (bundles, features, target, product) fails very early when resolving dependencies and finally ends up with

[ERROR] Cannot resolve project dependencies:
[ERROR]   Software being installed: a.jre.javase 11.0.0
[ERROR]   Software being installed: acme.product 1.0.0.qualifier
[ERROR]   Cannot satisfy dependency: acme.product 1.0.0.qualifier depends on: org.eclipse.equinox.p2.iu; org.eclipse.justj.openjdk.hotspot.jre.full.feature.group 0.0.0
[ERROR]   Cannot satisfy dependency: org.eclipse.justj.openjdk.hotspot.jre.full 11.0.14.v20220201-1322 conflicts with: org.eclipse.equinox.p2.iu; a.jre.javase 0.0.0
[ERROR]   Cannot satisfy dependency: org.eclipse.justj.openjdk.hotspot.jre.full.feature.group 11.0.14.v20220201-1322 depends on: org.eclipse.equinox.p2.iu; org.eclipse.justj.openjdk.hotspot.jre.full [11.0.14.v20220201-1322,11.0.14.v20220201-1322]
[ERROR] 
[ERROR] See https://wiki.eclipse.org/Tycho/Dependency_Resolution_Troubleshooting for help.

laeubi · 2022-10-19T04:54:11Z

@bjmi if you still see issues with 3.0.0 release pleas open a new issue with your problem at best provide an integration-test to demonstrate the issue.

laeubi added a commit to laeubi/tycho that referenced this issue Jun 21, 2021

Example for eclipse-tycho#154

64fd84a

Signed-off-by: Christoph Läubrich <laeubi@laeubi-soft.de>

mickaelistria pushed a commit to mickaelistria/tycho that referenced this issue Jul 1, 2021

Example for eclipse-tycho#154

89bd339

Signed-off-by: Christoph Läubrich <laeubi@laeubi-soft.de>

mickaelistria added a commit to mickaelistria/tycho that referenced this issue Jul 1, 2021

Issue eclipse-tycho#154 more examples

8994083

mickaelistria added a commit to mickaelistria/tycho that referenced this issue Jul 2, 2021

Issue eclipse-tycho#154 more examples

81a394f

laeubi added a commit to laeubi/tycho that referenced this issue Jul 3, 2021

Issue eclipse-tycho#154 Full specification of custom profile is not (…

6f518bb

…yet) determined Signed-off-by: Christoph Läubrich <laeubi@laeubi-soft.de>

laeubi mentioned this issue Jul 29, 2021

requires 'osgi.ee; (&(osgi.ee=JavaSE)(version=11))' but it could not be found #205

Closed

laeubi closed this as completed Oct 19, 2022

laeubi added this to the 4.0 milestone Jun 24, 2023

better support justj #154

better support justj #154

Comments

laeubi commented Jun 17, 2021

mickaelistria commented Jun 17, 2021

laeubi commented Jun 17, 2021

mickaelistria commented Jun 17, 2021

laeubi commented Jun 17, 2021

mickaelistria commented Jun 17, 2021

laeubi commented Jun 21, 2021

laeubi commented Jun 21, 2021

laeubi commented Jun 21, 2021

laeubi commented Jun 21, 2021

laeubi commented Jun 21, 2021

HannesWell commented Jun 24, 2021 • edited Loading

mickaelistria commented Jun 28, 2021

mickaelistria commented Jul 1, 2021

laeubi commented Jul 1, 2021

mickaelistria commented Jul 1, 2021

laeubi commented Jul 1, 2021

mickaelistria commented Jul 1, 2021

laeubi commented Jul 3, 2021

mickaelistria commented Jul 3, 2021

mickaelistria commented Jul 3, 2021

laeubi commented Jul 3, 2021

mickaelistria commented Jul 3, 2021

laeubi commented Jul 3, 2021

mickaelistria commented Jul 3, 2021

laeubi commented Jul 3, 2021

mickaelistria commented Jul 3, 2021

laeubi commented Jul 3, 2021

laeubi commented Jul 3, 2021

mickaelistria commented Jul 5, 2021

laeubi commented Sep 19, 2021

mickaelistria commented Sep 19, 2021

bjmi commented Feb 18, 2022

laeubi commented Feb 18, 2022

bjmi commented Feb 28, 2022

laeubi commented Oct 19, 2022

HannesWell commented Jun 24, 2021 •

edited

Loading