Tycho doesn't honor 'limit-modules' from '.classpath' about tycho HOT 18 CLOSED

@dhendriks thanks for you request. Tycho currently does not honors any settings in claspath but I'm currently working to support at least some basic things.

To speed up with integration, you could:

• Provide a small (executable) reproducer that shows your problem in form of a github repo, even better provide an itest showing your problem see here for some examples
• Provide a patch that fixes the problem, its all open source and everyone is encourage to participate!

If this feature is critical to your mission or you need enterprise-support:

• You can sponsor me (or search for someone else with java skills) and offer a funding for this new feature

from tycho.

@dhendriks can you provide a reproducer or PR that adds an integration-test for this?

from tycho.

compiler.limit.modules.zip

This zip contains a reproducer.

When I execute mvn clean verify -Dtycho-version=2.3.0, using JDK 11, I get:

...
[ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:2.3.0:compile (default-compile) on project bundle: Compilation failure: Compilation failure:
[ERROR] C:\Users\dhendri1\Desktop\compiler.limit.modules\bundle\src\org\w3c\dom\SomeClass.java:[1]
[ERROR]         package org.w3c.dom;
[ERROR]                 ^^^^^^^^^^^
[ERROR] The package org.w3c.dom conflicts with a package accessible from another module: java.xml
[ERROR] 1 problem (1 error)
...

The bundle provides package org.w3c.dom, as does JDK module java.xml. This is not allowed in Java 11.

By replacing bundle/pom.xml by bundle/pom-to-fix-build.xml, the build succeeds.

from tycho.

Thanks for the example, one question:

<compilerArgs>
    <arg>--add-modules</arg>
    <arg>java.base</arg>
    <arg>--limit-modules</arg>
    <arg>java.base</arg>
</compilerArgs>

versus

<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-11">
  <attributes>
	  <attribute name="module" value="true"/>
	  <attribute name="limit-modules" value="java.base"/>
  </attributes>
</classpathentry>

would you expects that --add-modules is always equal to --limit-modules to limit-modules in .classpath?

from tycho.

Do you think you can create a PR that adds an integration test based on your example? Just make sure you have signed the ECA and only include the failing aspect.

from tycho.

Isn't it all a workaround for https://bugs.eclipse.org/bugs/show_bug.cgi?id=571363 ? If https://bugs.eclipse.org/bugs/show_bug.cgi?id=571363 is a valid solution, I suggest we close this one as won't fix.

from tycho.

Don't know, its still possible and valid to configure this through JDT so I don'T see a reason to not support this case (for whatever it is used).

from tycho.

I think that bug 571363 is not a full solution. It seems to be about a sub-package of a JDK package, e.g. org.w3c.dom.svg that is not in JDK, but in JDT, that causes problems as it is a sub-package of org.w3c.dom, which is in the JDK.

In general, a plugin may have new classes for org.w3c.dom, which is a package of the JDK directly, and not a sub-package. It could be considered bad form to do this. But since it did not lead to issues in older Java versions, many such code is out there. For legacy and compatibility reasons, sometimes we still need to use them. This is just an example, but there may be more cases where at least temporarily this is practically needed, and not covered by bug 571363.

from tycho.

@dhendriks I have a working solution for this if you could contribute your testcase as an integration-test (or explicitly state that it is EPL 2.0 licensed) I think we can integrate this.

from tycho.

@laeubi I tried to set up the test case as an integration-test best I could. If it is not directly suitable, maybe you could adapt it? I'm a committer for the Eclipse ESCET project, so ECA is taken care of. I hereby contribute my test case under EPL 2.0.

from tycho.

would you expects that --add-modules is always equal to --limit-modules to limit-modules in .classpath?

I tried to remove --add-modules in the POM and it still works. It seems only --limit-modules is needed, which would be consistent with .classpath.

from tycho.

@laeubi I tried to set up the test case as an integration-test best I could. If it is not directly suitable, maybe you could adapt it? I'm a committer for the Eclipse ESCET project, so ECA is taken care of. I hereby contribute my test case under EPL 2.0.

I have adjusted the test a bit and added it to the PR, please take a look if it still covers your use-case, this will fail with current-tycho-snapshot and succeed when applying the patch.

from tycho.

PR content looks good to me. I do wonder one thing: you seem to be the author and have signed off personally, although GitHub doesn't really show the author/committer information explicitly/separately as far as I know. Should there by an Also-by for me?

from tycho.

That would (AFAIK) only work if you have submitted the test as a PR not as a zip attachment.

from tycho.

https://www.eclipse.org/projects/handbook/#resources-commit indicates it can be added for additional authors. The wording there indeed seems to suggest it is not mandatory.

Since it is just part of the commit message, I'm sure how it can or can't work?

from tycho.

Github only shows the mail/authors address if your are committing something ,so if you can provide me with your address + deired name I can add this to the merge-commit:

Also-by: Dennis Hendriks <... this is hidden to me ...>

from tycho.

See https://gitlab.eclipse.org/eclipse/escet/escet/-/commit/fd596b02c7fd5408b3e3bc2bf6a38118871216a7.patch

from tycho.

Thanks for fixing this issue!

from tycho.