Community
Participate
Working Groups
When writing a new Mojo (e.g. in tycho-extras), one will typically want to test the Mojo with a test derived from AbstractTychoMojoTestCase. However these kind of tests fail if the Tycho OSGi runtime artifacts are not yet in the local Maven repository. (They are only downloaded at test runtime, and at that point only Maven central is queried.) A workaround is to add the Tycho CI repository to the test project POM, but this has two drawbacks: - It doesn't help if you need proxy settings - Repeating the CI repository URL in (multiple) tests is not a good idea Another workaround is to declare test dependencies in the Mojo project to make sure that the runtime artifacts are already in the local Maven repository. Again, this is a bad idea, because the list of runtime artifacts needs to be repeated in every test. The pains of both workarounds could be eased by referencing a POM that contains the information that needs to be repeated otherwise. But it remains a workaround. The solution would be to not have these "runtime" dependencies outside of the POM model. What's the use case for this complexity?
Created attachment 197395 [details] Test failure if Tycho not in local repository Steps to reproduce: 0a) Ensure that you don't have Internet access without proxy configuration - or - 0b) Make tycho-extras build against 0.13.0-SNAPSHOT (unless already done centrally; see bug 347968) 1) Remove Tycho from your local artifact repository in the version referenced by tycho-extras 2) Build only tycho-p2-extras-plugin; the test PublishFeaturesAndBundlesMojoTest fails
(In reply to comment #0) > The solution would be to not have these "runtime" dependencies outside of the > POM model. What's the use case for this complexity? I am not sure I understand the question. This is a general problem/limitation of running full maven build as part of integration tests and is not limited to tycho artifacts afaik. Even if all tycho runtime dependencies were listed in tycho-maven-plugin (and others) pom.xml <dependencies/> section, we'd still need to make these dependencies available from repository visible to the forked maven build.
> Even if all tycho runtime dependencies were listed in > tycho-maven-plugin (and others) pom.xml <dependencies/> section, we'd still > need to make these dependencies available from repository visible to the forked > maven build. The explicit dependencies are already downloaded when the Mojo is compiled against them. So when the Mojo tests are executed, the artifacts are already present in the local Maven repository. Unlike other Maven components, Tycho has run time dependencies that are not compile time dependencies. Listing the Tycho OSGi runtime also as compile time dependencies should make the problem disappear.
It is not possible add compile dependencies without polluting runtime classpath.
(In reply to comment #4) > It is not possible add compile dependencies without polluting runtime classpath. scope=provided? But back to the original question: In tycho-extras, I have modified [1] the tycho-p2-extras-plugin build so that it is possible to build only that project (i.e. in particular without building tycho-emma before) even if Tycho is not yet in the local Maven repository. The limitation is still that your settings mustn't redirect the access to central to a mirror (which is typically the case in corporate environments). The root cause of the problem is that the Maven build executed as part of the test uses an empty settings.xml, which prevent access to central if you are behind a proxy (again: corporate environment). @Igor: Is there a reason why we don't just use the default settings.xml in inner builds (integration test or Mojo test)? Or even better: the same settings as used in the outer build. Do you happen to known if it possible to obtain the used settings file through the org.sonatype.plugins:maven-properties-plugin:filter-file goal? [1] https://github.com/sonatype/tycho-extras/commit/2bec4fcd3931219aead00dbd3833054a2400b964
I've discussed the "use the outer settings.xml" idea with Benjamin Bentman, and he recommended the following approach: - Write the effective settings in the outer build to a file from a new Mojo. (The Maven APIs expose the settings, but not the file they were read from.) We could either create a new plugin for that, or contribute it to the maven-invoker-plugin. There is a feature request for a similar use case in the maven-invoker-plugin [1]. - Pass the written settings.xml file to the inner Maven build. [1] http://jira.codehaus.org/browse/MINVOKER-97
(In reply to comment #6) > I've discussed the "use the outer settings.xml" idea with Benjamin Bentman, and > he recommended the following approach: > - Write the effective settings in the outer build to a file from a new Mojo. ${session.request.userSettingsFile} should give you the path to the settings file used. IIRC we use this in an internal project to solve the same problem. Put that in a properties file and use maven resource filtering; no need for a custom mojo here I think.
https://git.eclipse.org/r/#/c/8527/
Jan, how far did you get towards making this work?
(In reply to comment #9) > Jan, how far did you get towards making this work? I was able to make it work with -Dtycho.testSettings=Tpath/to/settings.xml locally with a settings.xml that has http proxies configured and an empty local repo. For some reason it did not work on hudson.eclipse.org (proxy configured but connection timeout). Not sure why so I had to add artificial test scoped dependencies to fill the local repo with artifacts required by tycho
Is this still relevant now that tycho+tycho.extras are merged into one repository/build reactor?
Eclipse Tycho is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse/tycho/issues/ instead. If this issue is relevant to you, your action is required. 0. Verify this issue is still happening with latest Tycho 2.4.0-SNAPSHOT if issue has disappeared, please change status of this issue to "CLOSED WORKFORME" with some details about your testing environment and how you did verify the issue; and you're done if issue is still present when latest release: * Create a new issue at https://github.com/eclipse/tycho/issues/ ** Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience) ** In the GitHub description, start with a link to this bugzilla ticket ** Optionally add new content to the description if it can helps towards resolution ** Submit GitHub issue * Update bugzilla ticket ** Add to "See also" property (up right column) the link to the newly created GitHub issue ** Add a comment "Migrated to <link-to-newly-created-GitHub-issue>" ** Set status as CLOSED MOVED ** Submit All issues that remain open will be automatically closed next week or so. Then the Bugzilla component for Tycho will be archived and made read-only.
