Community
Participate
Working Groups
Tycho currently does the target and dependency resolution for all modules right at the beginning of the build, before the start of the normal build. This has various disadvantages: - p2 repository are read and resolution is done even when this is not necessary, e.g. for @mvn clean@ - In case of resolution problems, the build breaks globally rather than in the affected module. More generally, all the things done at the beginning are very intransparent and hard to understand - Extending Tycho is hard to impossible, and this is hard to fix with the current structure. Tycho should defer the time-consuming target & dependency resolution to the normal build. This would require a new implementation of the build order computation, but this should be mostly doable. I have written up my implementation ideas on a wiki page [1]; feedback is welcome. [1] http://wiki.eclipse.org/Tycho/Ideas/Deferring_Dependency_Resolution
*** Bug 360788 has been marked as a duplicate of this bug. ***
*** Bug 362156 has been marked as a duplicate of this bug. ***
Reclassifying as bug (instead of enhancement) because this ticket covers problems which I would accept as performance/usability bugs, like that dependency resolution is performed when mvn clean is called (see duplicates). A workaround is to set the property -Dtycho.mode=maven, which disables the Tycho dependency resolution.
I have a prototype which does dependency resolution as part of the normal mojo build [1]. It has a new mechanism to calculate the build order (and all mojo tests are adapted to this), but other than that the afterProjectsRead code is still a big chunk (called from an AfterProjectsReadMojo :-) So there is nothing gained yet in terms of making Tycho more extendable and understandable, but from here I can start the refactorings to separate the different concerns (target platform calculation, dependency resolution, build path computation) into separately usable classes. I'm planning to do these refactorings (mostly) in master, and only use the prototype to find out when I'm done, i.e. when each concern really can be called from a separate mojo. The prototype code itself is still pretty far from being merged into master - first, there needs to be a real benefit for the Tycho user, and we need to be reasonably sure to not introduce regressions. (I like to call this project "Tycho 2.0" ;-) [1] https://github.com/oberlies/tycho/tree/bug353889_defer_resolution
It turns out that, in order to address problems in the current Tycho version, we also need to better represent the "target platform" concept in the Tycho code. This is tracked as bug 364134. Once this is done, this "project" will also be a big step closer to completion.
*** Bug 377363 has been marked as a duplicate of this bug. ***
I've just rebased and updated my POC (and pushed it to Gerrit [1]), and it already looks pretty good: There are no unit test failures, and only four integration tests failing. The integration tests show the following points that still need to be resolved: - The duplicate IU check needs to be refined (because the target platform is always computed on the full metadata of previously built projects) -> bug 392320 - License feature are not yet supported by the new build order mechanism. This simply needs to be implemented. - p2.inf-based depencencies don't affect the build order yet. This probably should also be implemented. In any case, it would be good to have a mechanism that prevents the use of artifacts from the target platform if the same ID is built in the reactor. (We have such a mechanism in place today.) With the deferred dependency resolution, we are no longer able to prevent the use of a different version (from the target platform) of an artifact that has not yet been build - but we should detect the problem when we build the "used" artifact and fail the build. - The build order mechanism (currently) ignores mandatory attributes on import-package, and hence creates a cycle in this integration test [2]. The use case of that test seems valid, and if we want to support it, I think we'll need to refine the matching done for the build order to include attributes. [1] https://git.eclipse.org/r/#/c/8937/ [2] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-its/projects/363331_extraTargetPlatformRequirements/import-package-directives
We need this because it blocks 393978 which is a complete show-stopper for us since we may not (and do not want to) commit libraries into our version control. Would you please consider changing importance to at least p2 critical? Can you give us an idea on when you plan to release this? Is there any way we can help to speed things up?
(In reply to Jörg Sesterhenn from comment #8) > We need this because it blocks 393978 which is a complete show-stopper for > us since we may not (and do not want to) commit libraries into our version > control. > > Would you please consider changing importance to at least p2 critical? I don't see it as critical. bug 393978 has a workaround, and it only depends on this one if you insist on using the copy-dependencies goal and choose to ignore the workaround proposed. This is a major refactoring with no ETA as of now.
(In reply to Tobias Oberlies from comment #0) > Tycho currently does the target and dependency resolution for all modules > right at the beginning of the build, before the start of the normal build. > This has various disadvantages: For the record, another disadvantage is IMHO that you cannot modify (e.g., with the org.jboss.tools.tycho-plugins:target-platform-utils:flatten-target mojo) an eclipse-target-definition in the same reactor in which it is needed by latter eclipse-plugin projects. As these latter projects do not consume the .target file that was *built* (and placed in ${project.build.outputDirectory}) by the earlier eclipse-target-definition project but rather its original input (sitting below ${basedir} rather than the output directory), generating .target files on the fly is currently impossible. :-(
As a workaround to e.g. clean project without invoking tycho its possible to run: mvn clean -Dtycho.mode=maven that skips the resolver. HTH
+1 for the Jan issue: I have the exact same, and it really do not play well within pipelined CI. Also, this kind of behavior completely forbids the use of the bnd-maven-plugin, or any of the maven-bundle-plugin, which could be a real booster for Eclipse dvlpt. These two issues (the tp-utils and the bnd one) are blocking the use of the maven-release-plugin which is the only good way to perform a release in the maven world (the tycho-version-plugin isn't at the level). I'm also pretty sure it would break some of the mvn site phase.
I also looked at this problem. We try to use different 'branches' for nightly, integration and release builds. Each branch has separate target sites to use. It would be nice to have 'dynamic' target files depending on the choice of branch generated from some 'template target file' in which some URL's are replaced. I found that it can be done by creating a lifecycle plugin for mvn and provide it as a extra jar file with your maven setup, these plugins get loaded before the tycho lifecycle hook. This way you can do some actions before tycho kicks in. It is by far a perfect solution and I have not worked it out any further but it can be done. The downside is that is probably does not play nice with any mvn plugin and that it can only be used to tackle a limited set of very specific problems. Also the context available to work with in the plugin at this point is not very powerful.
I also suspect some classpath issue with aggregator build and regular maven-surefire-plugin. We have a scenario as such: Maven module root/ : Builds a/ b/ Maven module a/ : with Packaging "eclipse-plugin" Maven module b/ : with Packaging "war" We have the effect, that classpath of a/ is exposed to b/ when running "test". As an example our checks within Unit Tests of b/ would yield: Found MULTIPLE classes/resources for 'Guava API' 1. Found in [jar:file:/opt/jenkins/.m2/repository/p2/osgi/bundle/com.google.guava/18.0.0/com.google.guava-18.0.0.jar!/com/google/common/collect/Sets.class] 2. Found in [jar:file:/opt/jenkins/.m2/repository/com/google/guava/guava/18.0/guava-18.0.jar!/com/google/common/collect/Sets.class] 3. Found in [jar:file:/opt/jenkins/.m2/repository/.cache/tycho/org.eclipse.wb.core.lib-1.8.0.r45x201506110820.jar/lib/guava-13.0.1.jar!/com/google/common/collect/Sets.class] This effect was observed with Tycho 0.21 and Maven 3.3.9 - we had not observed this effect with Maven 3.0.5. Sorry, we haven't had the chance to upgrade Tycho - we will try to verify this with a higher Tycho version ASAP.
There is even another effect: building a multi-module project that contains a javadoc goal with <includeDependencySources>true</includeDependencySources> the javadoc plugin tries to download all sources of p2 dependencies. Im am having the impression that this was not the case with earlier versions of maven/tycho (using maven 3.3.9 / tycho 1.0.0)
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.
Tycho issue have been moved to Github. Please reopen at https://github.com/eclipse/tycho/issues if this issue is still relevant.
