Community
Participate
Working Groups
I try to build a RCP-application based on plugins/bundles. So I have a .product-file with listening the required plugins and fragments. There are also some OS-specific fragments like SWT-stuff. I get some errors from tycho, when I try to build the application. If I add the informations about os, ws and arch, all is ok. But the graphical editor from Eclipse-IDE removes this additional informations from the .product-file. Is there any possibility, that tycho can try to generate the information from the plugin/fragment-id (e.g. for swt.win32_x86 the os=win32, ws=win32, arch=x86)? Some more problem is, that tycho analyzes the .product-file very early on the build-process (in the tycho-own lifecycle). So I can not patch the .product-files with a normal maven-plugin on one of the regular maven-phases. How can we integrate our own patching-plugin (Mojo) in the tycho-based build-process?
I don't think that pre-processing is the right solution. What we actually want is that Tycho automatically filters bundles/fragments listed in products based on the OS specified in the bundle or fragment. This information is available in the p2 metadata and should be used. I think this is also the approach taken by the PDE (which would explain why they don't specify OS filters in the product file). We should get rid of Tycho's special product file format, which repeatedly causes confusion (see e.g. [1]). [1] https://issues.sonatype.org/browse/TYCHO-510
(In reply to comment #1) > I don't think that pre-processing is the right solution. What we actually want > is that Tycho automatically filters bundles/fragments listed in products based > on the OS specified in the bundle or fragment. This information is available in > the p2 metadata and should be used. > > I think this is also the approach taken by the PDE (which would explain why > they don't specify OS filters in the product file). We should get rid of > Tycho's special product file format, which repeatedly causes confusion (see > e.g. [1]). > > [1] https://issues.sonatype.org/browse/TYCHO-510 I fully agree with you, a correct filtering of fragment based on the target-platform would be the best. But how can I achieve this? On which module or class should I start with patching? Are there any time-plans for resolution of this problem?
After having looked at the issue, I figured out that an implementation for this should be easy. I'm working on a fix. Thanks for offering your help though.
Created attachment 194476 [details] mylyn/context/zip
Unfortunately the problem turns out to be harder than expected. Tycho currently needs the information about the os filter of fragments during dependency resolution, but at that point in time, this information is not available - at least not for projects from the same reactor. Therefore my idea to resolve this problem does not work. (The idea was to change org.eclipse.tycho.p2.impl.publisher.ProductDependenciesAction.getRequiredCapabilities() to search for the fragment IUs like in org.eclipse.equinox.p2.publisher.eclipse.ProductAction.versionElements(...).) This leaves the following alternative solutions: 1) Make my initial idea work by controlling the order in which the depencency publishers run for the reactor, i.e. publish all bundles first and then provide that results as context to the product dependencies publisher. I'm not sure I would like such a solution though - it seems to be quite fragile. 2) Teach the p2 planner to do multi-platform plans. The Tycho dependency resolution currently has to execute the planner once for every platform, and the plan fails a fragment is required that doesn't apply for to platform. I feel that this would be the best solution, but we would need to check with the p2 guys if they are willing to support this. @Igor: Have you requested this from p2 before? Is there anything to link to? 3) Have Tycho not use the planner for dependency resolution of products, but use the allowConflictingDependencies mode instead. We would have to think this through if this can work though.
I think I found an even better solution, and it not be too much effort to implement: 4) Make all dependencies of products optional during dependency resolution. Then, the dependencies would be automatically be filtered out during dependency resolution if the referenced bundle is not applicable for an environment. When the real product publisher is executed later during the build, the included bundles are available in the context repository, and hence the dependencies are automatically annotated with the right filter. (This is the normal behaviour of the product publisher action, and available today.) The only thing that is missing in the product publisher is that the build fails when an included bundle is missing in the context. This could be detected easily in ProductAction.versionElements(Collection<IVersionedId>, String)), but since the ProductAction needs to stay compatible, we can't just throw an exception there. A warning status with a well-defined code could work, but in the end this needs to be agreed on with the p2 team.
I kind of would like to implement my proposal 4, but this requires to be able to develop Tycho and p2 in parallel.
This problem would also go away with what I want to do for bug 353889: With that idea implemented, we can first completely compute the target platform and then resolve dependencies, checking the target platform for the right ws/os/arch filters. I am no longer pursuing a solution separate from bug 353889.
Can you elaborate how deferring target platform resolution to a later build stage affects filtering native fragments?
This problem simply disappears when the target platform is available when publishing the product (because then the applicable filters can just be looked up from the IU in the target platform). The problem with the current structure is that the dependency-only publisher cannot get the full target platform, because at least the reactor is missing. With bug 353889 implemented, the publisher call could be done at a point in time when the full target platform is available, because the referenced modules from the reactor already would have been built and published (see also [1]). [1] http://wiki.eclipse.org/Tycho/Ideas/Deferring_Dependency_Resolution#Target_platform
(In reply to comment #10) > This problem simply disappears when the target platform is available when > publishing the product (because then the applicable filters can just be looked > up from the IU in the target platform). The problem with the current structure > is that the dependency-only publisher cannot get the full target platform, > because at least the reactor is missing. > > With bug 353889 implemented, the publisher call could be done at a point in > time when the full target platform is available, because the referenced modules > from the reactor already would have been built and published (see also [1]). > > [1] > http://wiki.eclipse.org/Tycho/Ideas/Deferring_Dependency_Resolution#Target_platform when you are ready, make sure to post complete proposal to tycho-dev.
I'm having the same problem as Alexander. I noticed that there is only little progress going on regarding bug 353889. Do you know when this issue here will be resolved? As far as I know, when building a product from a plugin-based product file, PDE simply ignores all non-existent fragments. Would this be a reasonable quick-fix?
(In reply to comment #12) > As far as I know, when building a product from a plugin-based product file, PDE > simply ignores all non-existent fragments. Would this be a reasonable quick-fix? I don't think that silently ignoring errors is an option - there needs to be some checking that the fragments are present. This would be option 4 described in comment 6. The main effort for this is to extend the p2 publishers to do these checks and to report the results in a way that allows Tycho to treat them as fatal (bug 351056). Once this is done, we could also fix this independently of bug 353889.
This is fixed for 0.16.0 [1]. You no longer need to specify os/ws/arch attributes for fragments included in products for Tycho, i.e. Tycho works out of the box with the product files created by the PDE product editor. The os/ws/arch attributes in plugin inclusions are now completely ignored. [1] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=dc338d82d871dcc34b18c4f4c0f4620291ac7194
I also get the error with Tycho 0.16.0: Included element org.eclipse.swt.motif.aix.ppc 0.0.0 is missing Sure, I compile indeed only for <environments> <environment> <os>win32</os> <ws>win32</ws> <arch>x86</arch> </environment> </environments> Must the entire delta pack in the target platform?
(In reply to comment #15) > I also get the error with Tycho 0.16.0: > > Included element org.eclipse.swt.motif.aix.ppc 0.0.0 is missing > > Sure, I compile indeed only for > > <environments> > <environment> > <os>win32</os> > <ws>win32</ws> > <arch>x86</arch> > </environment> > </environments> This error is expected: How is Tycho supposed to know that org.eclipse.swt.motif.aix.ppc is a fragment which is not applicable for your target environments? If you don't intend to build for AIX, remove the entry from the target file. (Note that you only get this problem for plug-in based products. This is why we recommend a feature-based product in [1].) > Must the entire delta pack in the target platform? Everything that you reference in the product must be in the target platform. [1] https://github.com/jsievers/tycho-demo
