With #53 there is an alternative approach to inject additional Requirements through P2MetadataProvider, this should replace the current explicit handling on different places (compile/test/...)

Looking at https://www.eclipse.org/tycho/sitedocs/index.html there is a full list of the Tycho modules and plugins. These all link to pages ending in index.html which appear to be blank for all the non aggregator modules.

For example choose Tycho OSGi Compiler Plugin. The actual docs for this plugin can be reached by replacing index.html with plugin-info.html.

For the compiler plugin this is not a major issue as it can be reached from the sidebar but this is not a comprehensive list of all plugins (this subset is defined here). To give a concrete example, I can't find a way to navigate to this page (for the Version Bump plugin) from within the site itself.

This is a minor issue but it results in some useful pages only being found via a search engine whereas it would be nice if all pages were reachable from the site itself.

in org.eclipse.tycho.p2.resolver.P2DependencyResolver.getDependencyMetadata(MavenSession, MavenProject, List, OptionalResolutionAction)

there is a call to pluginRealmHelper.execute that loops over the plugins and calls a runnable for each plugin. with the context classloader set.

This leads to the same code executed over and over again (in a simple test project it calls the extension 4 times), as this can contain poetnially heavy operations it seems vastfull to call the code over and over again.

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=563388

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=562889

In a customer Tycho build I see the error below.

We solved it by setting the following property:
<maven.compiler.release>11</maven.compiler.release>

Feel free to close this bug, in case you think there is nothing Tycho can or should be doing here.

[WARNING] Unable to determine 'maven.compiler.release' property
automatically
java.io.FileNotFoundException: File
/usr/lib/jvm/java-11-openjdk-11.0.10.0.9-1.el7_9.x86_64/lib/ct.sym does
not exist
at org.eclipse.jdt.internal.compiler.util.CtSym.init
(CtSym.java:126)
at org.eclipse.jdt.internal.compiler.util.CtSym.
(CtSym.java:120)
at org.eclipse.jdt.internal.compiler.util.JRTUtil.lambda$1
(JRTUtil.java:136)
at java.util.concurrent.ConcurrentHashMap.compute
(ConcurrentHashMap.java:1908)
at org.eclipse.jdt.internal.compiler.util.JRTUtil.getCtSym
(JRTUtil.java:133)
at org.eclipse.tycho.compiler.AbstractOsgiCompilerMojo.getReleaseLevel
(AbstractOsgiCompilerMojo.java:846)
at org.eclipse.tycho.compiler.AbstractOsgiCompilerMojo.getCompilerConfiguration
(AbstractOsgiCompilerMojo.java:580)
at copied.org.apache.maven.plugin.AbstractCompilerMojo.execute
(AbstractCompilerMojo.java:330)
at org.eclipse.tycho.compiler.AbstractOsgiCompilerMojo.execute
(AbstractOsgiCompilerMojo.java:338)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
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 jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native
Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at 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)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native
Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.apache.maven.wrapper.BootstrapMainStarter.start
(BootstrapMainStarter.java:39)
at org.apache.maven.wrapper.WrapperExecutor.execute
(WrapperExecutor.java:122)
at org.apache.maven.wrapper.MavenWrapperMain.main
(MavenWrapperMain.java:61)

Like with eclipse-m2e/m2e-core#120 but as we already have a setup file maybe just some additional wiring is required?

Since Tycho 2.0, the Tycho maven plugins require Java 11. That’s fine. Unfortunately, since Tycho 2.1.0, your tests now also require Java 11, even if they themselves have a Bundle-RequiredExecutionEnvironment of JavaSE-1.8 and a toolchain is configured to launch the tests with a Java 1.8 JVM.

Ultimately, the test runtime fails to launch with an error message like this one:

!ENTRY org.eclipse.tycho.surefire.junit57 2 0 2021-04-15 12:11:12.112
!MESSAGE Could not resolve module: org.eclipse.tycho.surefire.junit57 [200]
  Unresolved requirement: Require-Capability: osgi.ee; filter:="(&(osgi.ee=JavaSE)(version=11))"

And this is unfortunate, as the org.eclipse.tycho.surefire.junit* libraries really don’t require Java 11. The only version 55.0 (aka Java 11) class file in the org.eclipse.tycho.surefire.junit57-2.3.0.jar, for example, is module-info.class. And then there are these two classes:

META-INF/versions/9/org/junit/platform/commons/util/ModuleUtils$ModuleReferenceScanner.class
META-INF/versions/9/org/junit/platform/commons/util/ModuleUtils.class

But they are, as befits a multi-version JAR, hidden away in META-INF/versions/9, so all that prevents the test runtime from still supporting Java 1.8 is a too restrictive Require-Capability declaration.

I hence propose to still declare the org.eclipse.tycho.surefire.junit*libraries as compatible with Java 1.8 – which they are, in fact. This makes it possible, using toolchains, to build your plugins with Java 11, but still test them against Java 1.8, if that’s what they need to run against in the wild.

Bugzilla Link

Currently Tycho doen't support the usage of Eclipse path variables like ${workspace_loc} in Target Files when using file based locations. This would be a handy feature.

Adding more stages to the test story has shown that the test-fragment packaging is too strict and does not scale well (e.g. has hard dependency to additional.bundles feature that should be generalized in #53) as this is not released/used in the wild we better discard this now before there are consumers of this feature.

The following should replace this feature:

• #53 replace the support for additional-bundles
• #37 replace the support for loading additional classes from test-classpath
• dev.properties already cover the case of test-classes to be loaded from test-source folders

We are trying latest version(2.4.0-SNAPSHOT) of Tycho in our build.

We are getting the following errors while running surefire tests

!ENTRY org.eclipse.ecf.provider.filetransfer 4 0 2021-04-20 07:55:30.072
!MESSAGE org.eclipse.core.runtime.Status[plugin=org.eclipse.ecf.provider.filetransfer;code=4;message=Warning: Platform proxy API not available;severity2;exception=java.lang.NoClassDefFoundError: org/eclipse/core/net/proxy/IProxyService;children=[]]
!STACK 0
java.lang.NoClassDefFoundError: org/eclipse/core/net/proxy/IProxyService
at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.setupProxies(AbstractRetrieveFileTransfer.java:956)
at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:886)
at org.eclipse.ecf.provider.filetransfer.retrieve.MultiProtocolRetrieveAdapter.sendRetrieveRequest(MultiProtocolRetrieveAdapter.java:148)
at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.sendRetrieveRequest(FileReader.java:454)
at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.readInto(FileReader.java:384)
at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.download(RepositoryTransport.java:107)
at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.download(RepositoryTransport.java:166)
at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.handleRemoteIndexFile(AbstractRepositoryManager.java:730)
at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadIndexFile(AbstractRepositoryManager.java:724)
at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:666)
at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:110)
at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:105)
at org.eclipse.pde.internal.core.target.P2TargetUtils.getQueryableMetadata(P2TargetUtils.java:976)
at org.eclipse.pde.internal.core.target.IUBundleContainer.getRootIUs(IUBundleContainer.java:766)
at org.eclipse.pde.internal.core.target.P2TargetUtils.getRootIUs(P2TargetUtils.java:1439)
at org.eclipse.pde.internal.core.target.P2TargetUtils.resolveWithPlanner(P2TargetUtils.java:1003)
at org.eclipse.pde.internal.core.target.P2TargetUtils.synchronize(P2TargetUtils.java:827)
at org.eclipse.pde.internal.core.target.TargetDefinition.resolve(TargetDefinition.java:403)
at org.eclipse.pde.api.tools.internal.ApiAnalysisApplication.setBaseline(ApiAnalysisApplication.java:247)
at org.eclipse.pde.api.tools.internal.ApiAnalysisApplication.start(ApiAnalysisApplication.java:124)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203)
at org.eclipse.equinox.internal.app.AnyThreadAppLauncher.run(AnyThreadAppLauncher.java:30)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.ClassNotFoundException: org.eclipse.core.net.proxy.IProxyService cannot be found by org.eclipse.ecf.provider.filetransfer_3.2.601.v20201025-0700
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:519)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:171)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
... 23 more

This particular service is provided by https://download.eclipse.org/eclipse/updates/4.20-I-builds/I20210418-1800/plugins/org.eclipse.core.net.linux.x86_64_1.2.400.v20190924-1023.jar

There is a problem in resolving this.

Job link https://ci.eclipse.org/jdt/job/eclipse.jdt.core-Gerrit/4521/

.log file: https://bugs.eclipse.org/bugs/attachment.cgi?id=286173

As mentioned here it would be cool if the git-timestamp provider could provide tycho with a meaning of "what needs rebuild" and only schedules projects for build if the git-timestamp shows any change in that folder.

This might be then combined with e.g. jenkins that records a "last build commit" build variable to allow a successive build to only touch the (bundle)projects that have changed.

Bugzilla link: https://bugs.eclipse.org/bugs/show_bug.cgi?id=571623

Behavior has not changed with Tycho 2.4.0-SNAPSHOT. Attaching updated versions of the files in Bugzilla:

• stack trace: bug571623_stack.txt
• example: bug571623_example.zip

BugZilla issue 561294 contains the issue discussion. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=561294

Tycho correctly handles features that use a shared license feature, in that feature.properties content is copied/appended, and extra files in build.properties are copied.

However, the tycho-buildtimestamp-jgit doesn't take changes to the shared license feature into account when determining the qualifier of the feature that uses the shared license feature. That is, when the feature.properties or any of the additional files of the shared license feature are changed, the shared license feature qualifier is properly updated to reflect this. However, the other features that use the shared license feature keep their old qualifiers and are not updated as expected.

To build RCP appliations with use the org.eclipse.platform.sdk feature in our target platform. But if I try to mirror that with the tycho mirroring task, the whole update site is downloaded as if no restrictions are defined:

Example pom:

If I use only the currently commented org.eclipse.equinox.sdk.feature.group it works as expected. So I guess something is not right with the platform.sdk feature or the Tycho mirroring tasks. As the sdk feature work fine in the target platform and is used in the Eclipse SDK build I assume it is the Tycho mirroring task.

4.0.0
Mirror Update Site

<prerequisites>
    <maven>3.0</maven>
</prerequisites>



<groupId>com.vogella.p2.mirror</groupId>
<artifactId>mirror</artifactId>
<version>3.5.0-SNAPSHOT</version>
<packaging>pom</packaging>
<properties>
    <tycho.version>2.3.0</tycho.version>
    <tycho-extras.version>2.3.0</tycho-extras.version>
</properties>


<build>
<plugins>
    <plugin>
        <groupId>org.eclipse.tycho.extras</groupId>
        <artifactId>tycho-p2-extras-plugin</artifactId>
        <version>${tycho.version}</version>
        <executions>
            <execution>
                <phase>prepare-package</phase>
                <goals>
                    <goal>mirror</goal>
                </goals>
            </execution>
        </executions>

        <configuration>
            <source>
                <!-- source repositories to mirror from -->
                <repository>
                    <url>http://download.eclipse.org/releases/latest/</url>
                    <layout>p2</layout>
                    <!-- supported layouts are "p2-metadata", "p2-artifacts", and "p2" (for joint repositories; default) -->
                </repository>

            </source>

            <!-- starting from here all configuration parameters are optional -->
            <!-- they are only shown here with default values for documentation purpose -->

            <!-- List of IUs to mirror. If omitted, allIUs will be mirrored. -->
            <!-- Omitted IU version element means latest version of the IU -->

           	<ius>
               <!--
                <iu>
					<query>
						<expression>id == $0 &amp;&amp; version == $1</expression>
						<parameters>org.eclipse.platform.sdk,4.19.0.I20210303-1800</parameters>
					</query>
				</iu>
               
				<iu>
					<id>org.eclipse.equinox.sdk.feature.group</id>
				</iu>

                -->
                <iu>
                    <id>org.eclipse.platform.sdk</id>
                </iu>
			</ius>


            <!-- The destination directory to mirror to. -->

            <destination>${project.build.directory}/repository</destination>
            <!-- Whether only strict dependencies should be followed. -->
            <!-- "strict" means perfect version match -->

            <followStrictOnly>false</followStrictOnly>
            <!-- Whether or not to follow optional requirements. -->
            <includeOptional>true</includeOptional>
            <!-- Whether or not to follow non-greedy requirements. -->
            <includeNonGreedy>true</includeNonGreedy>

            <!-- Filter properties. E.g. filter only one platform -->

            <filter>
                <osgi.os>linux</osgi.os>
                <osgi.ws>gtk</osgi.ws>
                <osgi.arch>x86_64</osgi.arch>
            </filter>

            <!-- Whether to filter the resulting set of IUs to only -->
            <!-- include the latest version of each IU -->

            <latestVersionOnly>false</latestVersionOnly>
            <!-- don't mirror artifacts, only metadata -->
            <mirrorMetadataOnly>false</mirrorMetadataOnly>

            <!-- whether to compress the content.xml/artifacts.xml -->

            <compress>true</compress>
            <!-- whether to append to the target repository content -->
            <append>true</append>

        </configuration>
    </plugin>
</plugins>

We are already compiling test-sources with the TestCompileMojo. Eclipse contains a "hidden" feature (at least for me) to even mark class path container as "test":

We should support/respect this property as soon as the classpath-container support is ready.

This will allow users to clearly separate test from compile scoped code.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=572446

In my tycho build I'm using tycho.localArtifacts=ignore.

I have a bundle which still gets included from my local Maven repository instead of using the locally build bundle which is present as a module in the build. I can see that the bundle is created, but the product ends up using an old one from 2020 with the same version number (non snapshot).

I'm trying to reproduce the issue. Is there any debugging flag which I can turn on, which might give some insight into whats happening here?

-X and -Dtycho.debug.resolver=true don't seem to tell me whats going wrong. I tried that. It is only listing the local artifacts from the build and not those from the repository.

It is not possible to override the Eclipse project compiler settings on the command line using <compilerArgs> in the tycho-compiler-plugin configuration. According to the Eclipse batch compiler documentation this is possible, e.g. by passing

<configuration>
  <arg>-err:-nullAnnot</arg>
</configuration>

However, the complete command line generated by Tycho looks as follows:

[DEBUG] JDT compiler args: [-err:-nullAnnot, -warn:-nullAnnot, -properties, /.../.settings/org.eclipse.jdt.core.prefs, -s, ...]

The manually provided compiler arguments are always put at the front of the argument list. However, according to the batch compiler documentation the last argument determines the effective settings which would be the project configuration. This means it's impossible to override it on the command line.

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=568070

Currently we can generate sources for bundles and sources for features but repositories must be configured manually.

It seems logical to add a plugin (or option) that automatically adds required .source featues/plugins to category.xml

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=572602

Christoph Laeubrich CLA Friend 2020-12-28 01:44:33 EST

OSGI has a native repository format [1], we should support building this with tycho as an alternative to the eclipse-repository format.

[1] https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.repository.html
[2] https://github.com/osgi/bindex/tree/885fa197903fe981c10038f69c0dc9a4260ebac6
[3] https://bnd.bndtools.org/chapters/250-resolving.html

[tag] [reply] [−] Comment 1 Christoph Laeubrich CLA Friend 2020-12-28 01:48:16 EST

[4] https://felix.apache.org/documentation/subprojects/apache-felix-osgi-bundle-repository.html

[tag] [reply] [−] Comment 2 Mickael Istria CLA Friend 2021-01-04 08:42:12 EST

Tycho is for building Eclipse artifacts. Before working on publishing to this format, we should work on making Eclipse IDE able to install content from such OBR repositories, and that is more something for p2. Please consider reopening bug 393648 and adding support for OBR in p2 first.

[tag] [reply] [−] Comment 3 Christoph Laeubrich CLA Friend 2021-01-04 08:52:01 EST

From your mentioned bug-report it seems it is not directly related to P2 but to PDE to support this in a target file right?
Supporting it in P2 would be just to resolve dependencies from other P2 Units and even though that's clearly possible it sounds a bit uncommon to me?

BTW Tycho supports some features that PDE/Eclipse won't (multiple target files, special entries in category.xml, ...) so it seams that at least in the past it was okay to have tycho support other things first :-)

Its also a bit of a chicken-egg problem, if we can't produce OBR how would someone want to use it? But of course I think for a real solution there will be needs to support it in tycho and in the IDE!

[tag] [reply] [−] Comment 4 Mickael Istria CLA Friend 2021-01-04 09:09:08 EST

(In reply to Christoph Laeubrich from comment #3)

From your mentioned bug-report it seems it is not directly related to P2 but
to PDE to support this in a target file right?
Supporting it in P2 would be just to resolve dependencies from other P2
Units and even though that's clearly possible it sounds a bit uncommon to me?

It was initially about P2 being able to consume OBR bundle, so it would automatically cascade to Tycho and PDE and others having this feature.
However, you may be right, a dev-time only feature (eg support in .target) could be enough. I'm just not sure having it in Tycho and PDE is in the end easier than having it directly in p2.

BTW Tycho supports some features that PDE/Eclipse won't (multiple target
files, special entries in category.xml, ...) so it seams that at least in
the past it was okay to have tycho support other things first :-)

That's right.
I think what makes a difference here is that OBR is not a technology that has been necessary for Eclipse-based development for a long time. So adding support for it seems to widen the scope of Tycho; and the wider the scope is the more difficult it's to maintain the project.

Its also a bit of a chicken-egg problem, if we can't produce OBR how would
someone want to use it?

What's the actual use-case here? If there are no pre-existing OBR repos, why even trying to support and produce them when p2 does the job?
I see this as a nice-to-have feature; but I'm curious about actual user-stories that can make the effort profitable both on short and long term.

[tag] [reply] [−] Comment 5 Christoph Laeubrich CLA Friend 2021-01-04 11:32:41 EST

(In reply to Mickael Istria from comment #4)

It was initially about P2 being able to consume OBR bundle, so it would
automatically cascade to Tycho and PDE and others having this feature.
However, you may be right, a dev-time only feature (eg support in .target)
could be enough. I'm just not sure having it in Tycho and PDE is in the end
easier than having it directly in p2.

AFAIK OBR does not really has the concept of "units" instead it uses filter expressions to reference items to install, I'm not sure if this maps well to the P2 concepts.

I think what makes a difference here is that OBR is not a technology that
has been necessary for Eclipse-based development for a long time. So adding
support for it seems to widen the scope of Tycho; and the wider the scope is
the more difficult it's to maintain the project.

Its a bit a matter of a self fulfilling prophecy, if there is no support for it people won't use it and because people don't use it we won't add support for it :-)

What's the actual use-case here? If there are no pre-existing OBR repos, why
even trying to support and produce them when p2 does the job?
I see this as a nice-to-have feature; but I'm curious about actual
user-stories that can make the effort profitable both on short and long term.

For my use-case there are two major problems with P2:

1. P2 is a complete dependency mess (it requires ~40 bundles to be added to a plain RCP application to work) the UI is so tightly coupled to Eclipse E3 that makes it impossible to reuse it outside a fully-fledged Eclipse IDE
2. It is proprietary to eclipse and thus limits its use in other platforms/frameworks e.g. the felix-bundle-plugin generates an OBR index file for bundles installed into local maven repo, if tycho would reuse this instead of creating proprietary p2 metadata interaction between those would be much more easy

because of that for years I have used the approach to build a repository and generate an OBR from the "plugins" folder using bindex command-line tool, that works but of course is far away from a nice solution.

These repos are then used inside the application to support a very slim updater for an RCP Application.

[tag] [reply] [−] Comment 6 Mickael Istria CLA Friend 2021-01-04 12:22:57 EST

So the goal is to make Tycho artifacts more easily consumed by Felix?

[tag] [reply] [−] Comment 7 Christoph Laeubrich CLA Friend 2021-01-04 14:17:46 EST

Or any OBR compatible implementation, BND also supports OBR repositories, also karaf.

[tag] [reply] [−] Comment 8 Mickael Istria CLA Friend 2021-01-04 14:24:04 EST

And can't we already use some already existing BND plugin to produce those OBR repository?

[tag] [reply] [−] Comment 9 Christoph Laeubrich CLA Friend 2021-01-04 14:46:31 EST

There is a command line utility [1] and bnd lib contains a utility class for creating such indexes that could be reused here.

[1] https://bnd.bndtools.org/commands/index.html
[2] https://github.com/bndtools/bnd/blob/a33a1a0a42ba70bae26226058ca81a5d69f6c0a8/biz.aQute.bndlib/src/aQute/bnd/osgi/repository/SimpleIndexer.java

[tag] [reply] [−] Comment 10 Mickael Istria CLA Friend 2021-01-04 15:03:48 EST

(In reply to Christoph Laeubrich from comment #9)

There is a command line utility [1] and bnd lib contains a utility class for
creating such indexes that could be reused here.

Good. Have you investigated using the maven-antrun-plugin or the exec-maven-plugin or any other executor plugin with bnd in the classpath to invoke java aQute.bnd.main.bnd index ... as part of the reactor ?

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=569937

As mentioned in https://www.eclipse.org/tycho/sitedocs/tycho-surefire-plugin/test-mojo.html extra requirements are only meaningful to the tycho-surefire-plugin but are instead configured in the target-platform-configuration.

We should do the following:

1. add support to configure this in the tycho-surefire-plugin instead
2. add a big warning that this has changed and will be removed in the next release
3. remove it from the target-platform-configuration

Currently the P2Resolver API do read the root units from the project, in some circumstances it is desirable to perform a resolution of units based on a different set.

Use-case is for example I have a mojo and like to fetch a unit from a target-platform including its dependencies.

Currently one can archive this indirectly by creating a dummy project, and use the deprecated P2Resolver.collectProjectDependencies method.

In complex setups its often necessary to make deeper investigations for class-loading problems.
Currently one can only enable the "showEclipseLog" what enables implicitly -debug but it would be better to have the opportunity to supply an option file.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=571434
https://bugzillaattachments.eclipsecontent.org/bugs/attachment.cgi?id=285635

Currently most (all?) tycho Mojos synchronize on a static lock, effectively allowing only different goals to run in parallel.
Especially the (relatively) long-running compile and package mojos spend more time waiting for the lock than doing actual work in a build with 32 threads.

Maven only recommends that pessimistic lock pattern "if a mojo uses a known-non-threadsafe external dependency" [1].
AFAICS that's not the case. Removing the locks speeds up a mvn clean package -T 2C (=32) a lot: 18min vs 1h before.
See the attached comparison.

[1] https://cwiki.apache.org/confluence/display/MAVEN/Parallel+builds+in+Maven+3

Copied from: https://bugs.eclipse.org/bugs/show_bug.cgi?id=571751

I have been attempting to introduce Maven CI-friendly versions to a Tycho multi-module project.

With a version like this:

<version>${revision}${changelist}</version>

and two additional properties in parent POM:

<revision>1.0.0</revision>
<changelist>-SNAPSHOT</changelist>

A regular mvn clean install works as expected, as the version defaults to 1.0.0-SNAPSHOT. However, if a release version is to be created, by clearing the changelist, the Bundle-Version does no longer match, as it bears the .qualifier.

Bundle-Version: 1.0.0.qualifier

This is - correctly - detected by tycho-packaging-plugin:

mvn org.eclipse.tycho:tycho-packaging-plugin:2.2.0:validate-version -Dchangelist=
[ERROR] Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:2.2.0:validate-version (default-cli) on project tycho.demo.itp01: Maven version 1.0.0 must have -SNAPSHOT qualifier for SNAPSHOT builds -> [Help 1]

Usually, one would use tycho-versions-plugin to automatically sync versions. However, this does not work as expected:

mvn org.eclipse.tycho:tycho-versions-plugin:2.2.0:update-eclipse-metadata -Dchangelist=
[ERROR] Failed to execute goal org.eclipse.tycho:tycho-versions-plugin:2.2.0:update-eclipse-metadata (default-cli) on project parent: Execution default-cli of goal org.eclipse.tycho:tycho-versions-plugin:2.2.0:update-eclipse-metadata failed: Invalid version: 
[ERROR]   Version ${revision}${changelist} is not valid for /home/chrhuff/git/org.eclipse.tycho-demo/itp01/tycho.demo.itp01/META-INF/MANIFEST.MF
[ERROR] -> [Help 1]

This can be reproduced using the Tycho Demo project (org.eclipse.tycho-demo/itp01), from my public GitHub repository.

It appears to me that tycho-versions-plugin does not evaluate project.version properly, whereas tycho-packaging-plugin does.

A potential, but clumsy (and untested) workaround is to
a) configure validate-version to not break the build
b) use flatten-maven-plugin to create .flattened-pom.xml files (which is required if you want to deploy artifacts, anyway, as documented by 1)
c) invoke tycho-versions-plugin using -f .flattened-pom.xml on each individual module
d) repeat the build (without -f)

A long-term solution could also decouple the source from the build target version in target/MANIFEST.MF, so the dynamically resolved version from Maven is used, regardless of the version in META-INF/MANIFEST.MF and other eclipse-related files.

I always wondered if there is a logo image for Tycho?

The project page only shows a default eclipse-icon, also the Github Readme do not contain one.

Even though Tycho being a command-line tool I think something that visually represents tycho would be cool (and handy should I ever get the time to work on tycho-eclipse tooling in the future). It might also be nice for people writing articles / blog post about tycho and it would make the overall appearance of the Github-Readme more appealing.

I have seen that sometimes there is an art-contest or something for projects, does anyone knows how to apply for such a thing at eclipse-foundation? I think tycho defiantly deserves one 👍

If I run tycho-snapshots I get the following error after the build succeeds (!)

[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  15.580 s
[INFO] Finished at: 2021-04-20T06:54:28+02:00
[INFO] ------------------------------------------------------------------------
Exception in thread "Thread-1" java.lang.NoClassDefFoundError: org/eclipse/sisu/equinox/embedder/internal/DefaultEquinoxEmbedder$2$1
	at org.eclipse.sisu.equinox.embedder.internal.DefaultEquinoxEmbedder$2.run(DefaultEquinoxEmbedder.java:207)
	at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.ClassNotFoundException: org.eclipse.sisu.equinox.embedder.internal.DefaultEquinoxEmbedder$2$1
	at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
	at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
	at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
	at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
	... 2 more

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=571835

https://bugs.eclipse.org/bugs/show_bug.cgi?id=537320

We are migrating the project from java8 to java11. Earlier we were using tycho version 1.0.0 and could build the project with an entry like this under

Bundle-ClassPath : external:$user.dir

On switching to jdk11, we have to upgrade tycho version to 1.3.0 since Tycho 1.0.0 does not support jdk11. But with new version the build is getting failed with the error message : "Fatal error compiling: Illegal char <:> at index 94"

We are using eclipse 4.16 and I believe the issue is still not resolved in latest release of eclipse.

Note: I have tried working with 2.4.0-SNAPSHOT , but the error still occurs with same Caused by: org.codehaus.plexus.compiler.CompilerException: Illegal char <:> at index 93: D:\Git\com.test.build\external:$user.dir$\test\lib\jdmktk.jar

When we tried building platform with tycho 2.4.0 we are getting the comparator errors indicating those files are not getting packaged. Log is attached buildtimeComparatorUnanticipated.log.txt

I have modified platform aggregator job to use tycho 2.4.0-SNAPSHOT. This can be used for testing.

Please look out for similar errors as given below in the console log. These warnings should not appear.
[INFO] --- tycho-p2-plugin:2.4.0-SNAPSHOT:p2-metadata-default (default-p2-metadata-default) @ org.eclipse.ant.core ---
[WARNING] MavenProject: org.eclipse.ant:org.eclipse.ant.core:3.6.0-SNAPSHOT @ /home/jenkins/agent/workspace/eclipse-aggregator-master/eclipse.platform/ant/org.eclipse.ant.core/pom.xml: baseline and build artifacts have same version but different contents
no-classifier: different
org/eclipse/ant/internal/core/InternalCoreAntMessages.properties: present in baseline only

[INFO] MavenProject: org.eclipse.ant:org.eclipse.ant.core:3.6.0-SNAPSHOT @ /home/jenkins/agent/workspace/eclipse-aggregator-master/eclipse.platform/ant/org.eclipse.ant.core/pom.xml
The main artifact has been replaced with the baseline version.
The following attached artifacts have been replaced with the baseline version: [sources]

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=562886

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=380152

The bug is still occurring. Due to an architectural change in Maven 3.2.1 in the Reactor, Tycho can no longer compute the dependencies if the input modules are filtered with options like -pl. Therefore, options like -am, -amd and -rf do not work.

See the original BugZilla issue for details and also see https://bugs.eclipse.org/bugs/show_bug.cgi?id=494760 which is likely caused by the same problem.

Pascal Rapicault CLA Friend 2012-05-21 10:29:58 EDT

Created attachment 215967 [details]
Test projects

Running maven with -amd or -rf will cause the build to fail because of the artifacts that are normally part of a full reactor build can't be found as they are not being built.

For example, in the following projects (see attachment)

• testA (bundle)
• testB (bundle, depends on A)
• testFeature (include testA and testB)

executing mvn clean install -amd -pl net.rapicault.demo:testB
will fail with the following error message.

[ERROR] Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:0.14.1:package-feature (default-package-feature) on project testFeature: Execution default-package-feature of goal org.eclipse.tycho:tycho-packaging-plugin:0.14.1:package-feature failed: net.rapicault.demo:testA:eclipse-plugin:1.0.0-SNAPSHOT does not provide an artifact with classifier 'null' -> [Help 1]

I tried various tricks like adding a p2 repository that would include the artifacts from a previous successful build but again, no luck here.

[tag] [reply] [−] Comment 1 Tobias Oberlies CLA Friend 2012-05-23 12:17:38 EDT

I wouldn't consider this a bug - I don't believe that Tycho was ever meant to work with this option. We can keep this bug as enhancement request though.

[tag] [reply] [−] Comment 2 Pascal Rapicault CLA Friend 2012-05-23 12:27:05 EDT

What about the -rf option?

[tag] [reply] [−] Comment 3 Tobias Oberlies CLA Friend 2012-05-29 03:06:53 EDT

I don't know enough about these options to say if it would make sense to support these in Tycho.

Maven experts: What do you think?

[tag] [reply] [−] Comment 4 Tobias Oberlies CLA Friend 2012-10-04 13:14:37 EDT

This is what seems to happen in Maven: With --projects (and probably similarly with -rf), Maven scans all projects aggregated by the entry point POM, but then only executes the build for some of the projects.

In Tycho, this means the following:

• The dependency resolution is done for all projects because Tycho listens to the afterProjectsRead Maven event that is fired for all aggregated projects. This cannot be changed, because Tycho currently uses its dependency resolution to determine the build order.
• The dependency resolution result then contains references between reactor projects. Unlike with a full build, it is not guaranteed that upstream reactor artifacts have been built, leading to the described error.

To fix this, we'd need to recompute the target platform at the beginning of a module build (from a regular mojo) and either re-do dependency resolution or amend the previous dependency resolution result. All this is close to what needs to be done for bug 353889, so I don't think that this will be implemented independently of that major restructuring.

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=572411

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=571951

Add new JavaSE profile and associated code/tests in Tycho for JavaSE-17.

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=573159 .

This issue has originally been reported on the tycho-user mailing list.

Replacing tycho-source-feature-plugin:source-feature with tycho-source-plugin:feature-source (versions 2.1.0, 2.2.0 and 2.3.0) fails the build during dependency resolution, although this should be a drop-in replacement according to the release notes:

[ERROR] Cannot resolve project dependencies:
[ERROR]   Software being installed: update-site raw:0.0.1.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):0.0.1-SNAPSHOT
[ERROR]   Missing requirement: org.example.feature.source.feature.group 0.0.1.202104201129 requires 'org.eclipse.equinox.p2.iu; org.example.feature.feature.group [0.0.1.202104201129,0.0.1.202104201129]' but it could not be found
[ERROR]   Cannot satisfy dependency: update-site raw:0.0.1.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):0.0.1-SNAPSHOT depends on: org.eclipse.equinox.p2.iu; org.example.feature.source.feature.group 0.0.0

Will create a reproducer project and report back here.

Updating tycho from version 2.2.0 to 2.3.0 I get the following error:

[DEBUG] Toolchain JDK[D:/dev/software/jdk14.0.2] doesn't match required property: id
[DEBUG] Toolchain JDK[D:/dev/software/jdk15.0.2] doesn't match required property: id
[DEBUG] Toolchain JDK[D:/dev/software/jdk16.0.0] doesn't match required property: id
[ERROR] Internal error: org.eclipse.tycho.core.ee.UnknownEnvironmentException: Unknown OSGi execution environment: 'JavaSE-14' -> [Help 1]
org.apache.maven.InternalErrorException: Internal error: org.eclipse.tycho.core.ee.UnknownEnvironmentException: Unknown OSGi execution environment: 'JavaSE-14'
    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 jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:564)
    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: org.eclipse.tycho.core.ee.UnknownEnvironmentException: Unknown OSGi execution environment: 'JavaSE-14'
    at org.eclipse.tycho.core.ee.ExecutionEnvironmentUtils.getExecutionEnvironment (ExecutionEnvironmentUtils.java:95)
    at org.eclipse.tycho.core.osgitools.OsgiBundleProject.applyBestOfCurrentOrConfiguredProfile (OsgiBundleProject.java:577)
    at org.eclipse.tycho.core.osgitools.OsgiBundleProject.readExecutionEnvironmentConfiguration (OsgiBundleProject.java:547)
    at org.eclipse.tycho.core.resolver.DefaultTychoResolver.setupProject (DefaultTychoResolver.java:103)
    at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead (TychoMavenLifecycleParticipant.java:99)
    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)
    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 jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:564)
    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)

Further interesting debug log entries:

Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Java version: 14.0.2, vendor: Azul Systems, Inc., runtime: D:\dev\software\jdk14.0.2
Default locale: de_CH, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
[DEBUG] Reading global toolchains from D:\dev\software\apache-maven\bin\..\conf\toolchains.xml
[DEBUG] Reading user toolchains from C:\Users\USERNAME\.m2\toolchains.xml

C:\Users\USERNAME.m2\toolchains.xml toolchain looks like this:

<toolchains>
  <!-- JDK toolchains -->
  <toolchain>
    <type>jdk</type>
    <provides>
      <version>14</version>
	  <id>JavaSE-14</id>
    </provides>
    <configuration>
      <jdkHome>D:/dev/software/jdk14.0.2</jdkHome>
    </configuration>
  </toolchain>
  <toolchain>
    <type>jdk</type>
    <provides>
      <version>15</version>
	  <id>JavaSE-15</id>
    </provides>
    <configuration>
      <jdkHome>D:/dev/software/jdk15.0.2</jdkHome>
    </configuration>
  </toolchain>
  <toolchain>
    <type>jdk</type>
    <provides>
      <version>16</version>
	  <id>JavaSE-16</id>
    </provides>
    <configuration>
      <jdkHome>D:/dev/software/jdk16.0.0</jdkHome>
    </configuration>
  </toolchain>
</toolchains>

Reverting back to 2.2.0 there is an interesting difference in the log:

2.2.0:

[DEBUG] Toolchain JDK[D:/dev/software/jdk14.0.2] doesn't match required property: id
[DEBUG] Toolchain JDK[D:/dev/software/jdk15.0.2] doesn't match required property: id
[DEBUG] Toolchain JDK[D:/dev/software/jdk16.0.0] doesn't match required property: id
[DEBUG] Toolchain JDK[D:/dev/software/jdk15.0.2] doesn't match required property: id
[DEBUG] Toolchain JDK[D:/dev/software/jdk16.0.0] doesn't match required property: id
CONTINUES....

2.3.0:

[DEBUG] Toolchain JDK[D:/dev/software/jdk14.0.2] doesn't match required property: id
[DEBUG] Toolchain JDK[D:/dev/software/jdk15.0.2] doesn't match required property: id
[DEBUG] Toolchain JDK[D:/dev/software/jdk16.0.0] doesn't match required property: id
[ERROR] Internal error: org.eclipse.tycho.core.ee.UnknownEnvironmentException: Unknown OSGi execution environment: 'JavaSE-14' -> [Help 1]

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=572570

Was: https://bugs.eclipse.org/bugs/show_bug.cgi?id=571533

Hi all!

I have a bundle that uses JAXB, i.e. the javax.xml.bind packages that came with Java up until their removal in Java 11.

The build itself runs Java 11 and Maven 3.6.3.

The tycho-compiler-plugin is configured to useJDK=BREE, and the plugin BREE is Java 8. I have toolchains set up for JDK 8 and JDK 11.

At Tycho 2.1.0, this build succeeds. However, upgrading to Tycho 2.2.0, the build now fails - error at the bottom. It looks like it may be attempting to find the class in JDK 11 instead of JDK 8.

There's a minimal reproduce of this bug at:

https://github.com/ind1go/tycho.bug.reproduce.1/tree/with-tycho-2.1.0 (the working case)
vs
https://github.com/ind1go/tycho.bug.reproduce.1/tree/with-tycho-2.2.0 (the failure case)

The only thing I've changed is the Tycho version (comparison at ind1go/tycho.bug.reproduce.1@with-tycho-2.1.0...with-tycho-2.2.0).

Error:

[ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:2.2.0:compile (default-compile) on project tycho.bug.reproduce.1: Compilation failure: Compilation failure:
[ERROR] .../tycho.bug.reproduce.1/src/main/java/dev/bencox/tychobugreproduce1/ClassUsingJAXB.java:[3]
[ERROR] import javax.xml.bind.JAXBException;
[ERROR] ^^^^^^^^^^^^^^
[ERROR] The import javax.xml.bind cannot be resolved
[ERROR] .../tycho.bug.reproduce.1/src/main/java/dev/bencox/tychobugreproduce1/ClassUsingJAXB.java:[9]
[ERROR] new JAXBException("Constructing this exception purely so there's a usage of javax.xml.bind in this class.");
[ERROR] ^^^^^^^^^^^^^
[ERROR] JAXBException cannot be resolved to a type

Still the case trying with 2.4.0-SNAPSHOT today.

I have a Plug-in Project with the following .classpath:

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
	<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.management,java.xml"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/>
	<classpathentry kind="src" path="src"/>
	<classpathentry kind="output" path="target/classes"/>
</classpath>

Note the limit-modules, which reduces the JDK modules available, to prevent a JDK module and a plug-in dependency from both providing the same package. This makes sure that I don't have any compile errors in Eclipse when JDT compiles the Java code.

However, for the Maven/Tycho build, it failed again due to a package being provided by both a JDK module and a plug-in dependency.

I had to add the following to the pom.xml to resolve this:

    <build>
        <plugins>
            <plugin>
                <groupId>org.eclipse.tycho</groupId>
                <artifactId>tycho-compiler-plugin</artifactId>
                <version>${tycho.version}</version>
                <configuration>
                    <compilerArgs>
                        <arg>--add-modules</arg>
                        <arg>java.base,java.management,java.xml</arg>
                        <arg>--limit-modules</arg>
                        <arg>java.base,java.management,java.xml</arg>
                    </compilerArgs>
                </configuration>
            </plugin>
        </plugins>
    </build>

Essentially this has the same information as in .classpath (java.base is omitted there as it is a dependency of one of the other modules).

I'm no expert on how Tycho works under the hood. I think it would be good for Tycho to honor the limit-modules information from the .classpath file.

It seems that currently no notification mail is send if a PR build fails.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=567913

Stephan Wahlbrink 2020-10-15 13:43:27 EDT

The package 'junit.runner' is missing in tycho surefire environment for JUnit 5 (Jupiter) tests since Tycho 1.7:

java.version=11.0.8
java.vendor=AdoptOpenJDK
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=de_DE
Framework arguments: -application org.eclipse.tycho.surefire.osgibooter.headlesstest -testproperties C:\eclipse.statet_build\org.eclipse.statet-commons\jcommons\org.eclipse.statet.jcommons.util-tests\target\surefire.properties
Command-line arguments: -data C:\eclipse.statet_build\org.eclipse.statet-commons\jcommons\org.eclipse.statet.jcommons.util-tests\target\work\data -application org.eclipse.tycho.surefire.osgibooter.headlesstest -testproperties C:\eclipse.statet_build\org.eclipse.statet-commons\jcommons\org.eclipse.statet.jcommons.util-tests\target\surefire.properties

!ENTRY org.eclipse.tycho.surefire.junit56 2 0 2020-10-15 19:30:30.591
!MESSAGE Could not resolve module: org.eclipse.tycho.surefire.junit56 [109]
Unresolved requirement: Import-Package: org.junit.runner; version="[4.12.0,5.0.0)"; resolution:="optional"
Unresolved requirement: Import-Package: org.junit.runner.manipulation; version="[4.12.0,5.0.0)"; resolution:="optional"
Unresolved requirement: Import-Package: org.junit.runner.notification; version="[4.12.0,5.0.0)"; resolution:="optional"
Unresolved requirement: Import-Package: org.junit.runners.model; version="[4.12.0,5.0.0)"; resolution:="optional"
Unresolved requirement: Import-Package: org.junit.experimental.categories; version="[4.12.0,5.0.0)"; resolution:="optional"
Unresolved requirement: Import-Package: org.junit.internal.builders; version="[4.12.0,5.0.0)"; resolution:="optional"
Unresolved requirement: Import-Package: org.junit; version="[4.12.0,5.0.0)"; resolution:="optional"
Unresolved requirement: Import-Package: junit.runner

!ENTRY org.eclipse.osgi 4 0 2020-10-15 19:30:30.592
!MESSAGE Application error
!STACK 1
org.apache.maven.surefire.util.SurefireReflectionException: java.lang.ClassNotFoundException: org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
at org.apache.maven.surefire.util.ReflectionUtils.loadClass(ReflectionUtils.java:249)
at org.apache.maven.surefire.util.ReflectionUtils.instantiateOneArg(ReflectionUtils.java:133)
...

See also: https://www.eclipse.org/lists/tycho-user/msg08602.html

Current workaround: https://www.eclipse.org/lists/tycho-user/msg08615.html

Reproducible in: 1.7.0 - current 2.1.0-SNAPSHOT

Still reproducible in 2.4.0-SNAPSHOT

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=572427

Current state:
The performance problems of the DependencyComputer is fixed in Tycho by caching the org.eclipse.osgi.container.ModuleWires of each org.eclipse.osgi.container.ModuleWiring. The root of the problem has been reported to the Equinox-Framework bug-tracker and a fix is under development.
So if everything works as expected and the performance improvements meet the expectations the fix in Tycho can be reverted once the improved version of org.eclipse.osgi is available for Tycho.

See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=571065
The below error is visible in Tycho 2.4.0-SNAPSHOT as well. Could you please conisder this on priority.

While adding multiple execution block for mirroring p2 update sites separately, the maven build is getting failed with below error. Is there any possibility that we can mirror two separate p2 sites without actually combing them?
I have attached the pom file snippet for your reference.

MinimalPom.xml

[ERROR] Failed to execute goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:2.2.0:mirror (artifcatid) on project Projectname: Error during mirroring: Mirroring failed: Unable to read repository at mvn:groupid:artifactId:20.5.300.30:zip/content.xml. NullPointerException -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:2.2.0:mirror Error during mirroring at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:215) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105) 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: org.apache.maven.plugin.MojoExecutionException: Error during mirroring at org.eclipse.tycho.plugins.p2.extras.MirrorMojo.execute(MirrorMojo.java:263) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210) ... 20 more Caused by: org.eclipse.tycho.p2.tools.FacadeException: Mirroring failed: Unable to read repository at mvn:groupid:artifactId:20.5.300.30:zip/content.xml. at org.eclipse.tycho.p2.tools.mirroring.MirrorApplicationServiceImpl.mirrorStandalone(MirrorApplicationServiceImpl.java:82) at org.eclipse.tycho.plugins.p2.extras.MirrorMojo.execute(MirrorMojo.java:260) ... 22 more Caused by: org.eclipse.equinox.p2.core.ProvisionException: Unable to read repository at mvn:groupid:artifactId:20.5.300.30:zip/content.xml. at org.eclipse.equinox.internal.p2.repository.CacheManager.createCache(CacheManager.java:247) at org.eclipse.equinox.internal.p2.metadata.repository.SimpleMetadataRepositoryFactory.getLocalFile(SimpleMetadataRepositoryFactory.java:69) at org.eclipse.equinox.internal.p2.metadata.repository.SimpleMetadataRepositoryFactory.load(SimpleMetadataRepositoryFactory.java:89) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.factoryLoad(MetadataRepositoryManager.java:63) at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:775) at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:676) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:110) at org.eclipse.equinox.p2.internal.repository.tools.AbstractApplication.addRepository(AbstractApplication.java:143) at org.eclipse.equinox.p2.internal.repository.tools.AbstractApplication.initializeRepos(AbstractApplication.java:124) at org.eclipse.equinox.p2.internal.repository.tools.MirrorApplication.run(MirrorApplication.java:196) at org.eclipse.tycho.p2.tools.mirroring.MirrorApplicationServiceImpl.mirrorStandalone(MirrorApplicationServiceImpl.java:78) ... 23 more Caused by: java.lang.NullPointerException at org.eclipse.tycho.osgi.configuration.MavenDependenciesResolverConfigurer.resolve(MavenDependenciesResolverConfigurer.java:61) at org.eclipse.tycho.osgi.configuration.MavenProtocolHandler$MavenURLConnection.connect(MavenProtocolHandler.java:96) at org.eclipse.tycho.osgi.configuration.MavenProtocolHandler$MavenURLConnection.getInputStream(MavenProtocolHandler.java:110) at org.eclipse.ecf.provider.filetransfer.browse.URLFileSystemBrowser.runRequest(URLFileSystemBrowser.java:120) at org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser$DirectoryJob.run(AbstractFileSystemBrowser.java:71) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) [ERROR] [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:

additional.bundles dependencies are not properly resolved

this issue is initially reported here: https://www.eclipse.org/lists/tycho-user/msg09020.html
besides the xtext-eclipse and xtext-xtend tests builds with tycho 2.4.0-SNAPSHOT
i can also see the problem with
https://github.com/cdietrich/tych24ddBundlesBug

[ERROR] Internal error: java.lang.RuntimeException: org.osgi.framework.BundleException: Bundle org.xtext.example.mydsl.ide cannot be resolved:org.xtext.example.mydsl.ide [109]
[ERROR]   Unresolved requirement: Require-Bundle: org.xtext.example.mydsl
[ERROR]     -> Bundle-SymbolicName: org.xtext.example.mydsl; bundle-version="1.0.0.qualifier"; singleton:="true"
[ERROR]        org.xtext.example.mydsl [108]
[ERROR]          Unresolved requirement: Require-Bundle: org.eclipse.xtext.xtext.generator
[ERROR] -> [Help 1]
org.apache.maven.InternalErrorException: Internal error: java.lang.RuntimeException: org.osgi.framework.BundleException: Bundle org.xtext.example.mydsl.ide cannot be resolved:org.xtext.example.mydsl.ide [109]
  Unresolved requirement: Require-Bundle: org.xtext.example.mydsl
    -> Bundle-SymbolicName: org.xtext.example.mydsl; bundle-version="1.0.0.qualifier"; singleton:="true"
       org.xtext.example.mydsl [108]
         Unresolved requirement: Require-Bundle: org.eclipse.xtext.xtext.generator

org.eclipse.xtext.xtext.generator is part of xtext.sdk here in the tp https://github.com/cdietrich/tych24ddBundlesBug/blob/7e0dbd51eed5802857b45b4db499041457c4eb5c/org.xtext.example.mydsl.target/org.xtext.example.mydsl.target.target#L18

interestingly i can also find this in the log

[INFO] Fetching org.eclipse.xtext.xbase_2.25.0.v20210301-0909.jar from https://ftp.snt.utwente.nl/pub/software/eclipse/releases/2021-03/202103171000/plugins/ (2,46MB)
[INFO] Fetching org.eclipse.xtext.xtext.generator_2.25.0.v20210301-0843.jar from https://ftp.snt.utwente.nl/pub/software/eclipse/releases/2021-03/202103171000/plugins/ (969,17kB)
[INFO] Fetching org.eclipse.equinox.launcher.win32.win32.x86_64_1.2.100.v20210209-1541.jar.pack.gz from https://mirror.dkm.cz/eclipse/releases/2021-03/202103171000/plugins/ (81,75kB)

also the problem is on the ide project, whilst die add. bundles are on the mydsl project

[INFO] Computing target platform for MavenProject: org.xtext.example.mydsl:org.xtext.example.mydsl:1.0.0-SNAPSHOT @ /Users/cdietrich/eclipse-workspaces/es2103/org.xtext.example.mydsl.parent/org.xtext.example.mydsl/pom.xml
[INFO] Resolving dependencies of MavenProject: org.xtext.example.mydsl:org.xtext.example.mydsl:1.0.0-SNAPSHOT @ /Users/cdietrich/eclipse-workspaces/es2103/org.xtext.example.mydsl.parent/org.xtext.example.mydsl/pom.xml
[INFO] Resolving class path of MavenProject: org.xtext.example.mydsl:org.xtext.example.mydsl:1.0.0-SNAPSHOT @ /Users/cdietrich/eclipse-workspaces/es2103/org.xtext.example.mydsl.parent/org.xtext.example.mydsl/pom.xml
[INFO] Fetching 202103171000&countryCode=de&timeZone=1&format=xml from http://www.eclipse.org/downloads/download.php?format=xml&file=/releases/2021-03/

.... tons of more fetches
[INFO] Computing target platform for MavenProject: org.xtext.example.mydsl:org.xtext.example.mydsl.ide:1.0.0-SNAPSHOT @ /Users/cdietrich/eclipse-workspaces/es2103/org.xtext.example.mydsl.parent/org.xtext.example.mydsl.ide/pom.xml
[INFO] Resolving dependencies of MavenProject: org.xtext.example.mydsl:org.xtext.example.mydsl.ide:1.0.0-SNAPSHOT @ /Users/cdietrich/eclipse-workspaces/es2103/org.xtext.example.mydsl.parent/org.xtext.example.mydsl.ide/pom.xml
[INFO] Resolving class path of MavenProject: org.xtext.example.mydsl:org.xtext.example.mydsl.ide:1.0.0-SNAPSHOT @ /Users/cdietrich/eclipse-workspaces/es2103/org.xtext.example.mydsl.parent/org.xtext.example.mydsl.ide/pom.xml

Since d9a5824 , one cannot use -Dtest=... flag any more on CLI as it will make regular eclipse-plugin build fail with "No tests found".
This use-case seems to be relatively commonly used, so this is a regression that should be mitigated.

To assist users in providing good reproducers we should have some kind of "integrationtest-template".

Ideally I could run some maven magic are asked for a <name> and get with:

1. a new folder in tycho-its/projects/<name>
2. the folder contains one bundle one feature one test project
3. a new test in tycho-its/src/test/java/org/eclipse/tycho/test/<name>Test that creates a verifier for that project and simply verifies an error free log.

This is a split from #49

Currently P2MetadataProvider can only supply either seed or resolve units. But JDT/PDE/P2 sometimes express a requirements on a more abstract level (e.g. additional bundles, test-container, ...). These requirements are not matching into the current categories and are best expressed as e.g. a compile-time dependency rather than a unit (e.g. concrete bundle or feature).