Community
Participate
Working Groups
Created attachment 254886 [details] Example Project Our (Oomph) build contains some Windows-specific native fragments (different ones for 32 bit and 64 bit). Unfortunately the build always fails if one (and not all) environments are being built: [ERROR] Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:0.23.0:package-feature (default-package-feature) on project org.eclipse.oomph.setup.core: Execution default-package-feature of goal org.eclipse.tycho:tycho-packaging-plugin:0.23.0:package-feature failed: eclipse-plugin artifact with ID "org.eclipse.oomph.jreinfo.win32.x86" and version matching "0.0.0" was not found in the target platform -> [Help 1] The feature that pulls in the two fragments and the fragments themselves (both in MANIFEST.MF and pom.xml) specify the correct environment filters. So I looked at org.eclipse.tycho.packaging.FeatureXmlTransformer.expandReferences(Feature, TargetPlatform) and to me it seems that methods like pluginRef.getArch() are not called to determine whether the plugin reference applies to the current environment or not. I attached a minimalistic example project that demonstrates the problem. All works well if you run mvn clean install and under example/sites/org.eclipse.oomph.site/target/repository/plugins you'll find both fragments: org.eclipse.oomph.jreinfo.win32.x86_1.1.0.201507011356.jar org.eclipse.oomph.jreinfo.win32.x86_64_1.1.0.201507011356.jar BUT if you run mvn -Denv=win64 clean install the build fails as described above. BTW., when you export that feature with PDE you also end up with just one fragment for the current environment and it doesn't fail.
thanks for the sample project, this helps to focus the discussion. the way multi-platfrom features are implemented in Tycho as of now: we make sure all included bundles/fragments are actually available. I see your point to only build for one environment occasionally. The argument against this would be that you want the build to produce the artifacts which have been specified to be included in feature.xml. I don't know if we can loosen this up but if we do, we would have to remove all but the matching fragment references from feature.xml, otherwise somone installing from the build result on a non-matching environment will get an error. Not sure if this is doable as p2 dependency resolution happens at the very start of the build, before any changes can be done to feature.xml. @Igor,Tobias opinions?
What is the expected/desired output of a build for one environment only? Do you expected Tycho to completely ignore the other environment fragments and all references to athese fragments? Do you expect Tycho to use "other" fragments from p2 repositories, if they are available? How do you expect Tycho to package update site, ignore "other" fragments?
(In reply to Igor Fedorenko from comment #2) > What is the expected/desired output of a build for one environment only? All I would expect is that Tycho ignores included plugins when their platform filters don't match the current build environment. I guess that should in/near FeatureXmlTransformer.expandReferences(). > Do you expected Tycho to completely ignore the other environment fragments and > all references to athese fragments? If by "other fragments" you mean those that specify a Platform-Filter in their manifest but their including feature doesn't specify the same filter on the *inclusion* (you call it PluginRef) then no. That should result in an error. Exactly like at run-time. I'm really only concerned that the specified filters on the *inclusion* are completely ignored by Tycho. > Do you expect Tycho to use "other" > fragments from p2 repositories, if they are available? Not in any special way. > How do you expect > Tycho to package update site, ignore "other" fragments? I think the best way to look at it is the following: If a feature specifies an environment filter on a PluginRef and this filter doesn't match the current build environment, then don't follow that PluginRef. Treat it as if it wasn't declared at all. Does that make sense?
(In reply to Eike Stepper from comment #3) > > Do you expect Tycho to use "other" > > fragments from p2 repositories, if they are available? > > Not in any special way. > > > How do you expect > > Tycho to package update site, ignore "other" fragments? > > I think the best way to look at it is the following: > > If a feature specifies an environment filter on a PluginRef and this filter > doesn't match the current build environment, then don't follow that > PluginRef. Treat it as if it wasn't declared at all. > > Does that make sense? Not sure. This isn't what I expect Maven build to do. I expect site to include all dependencies regardless of what -Dparameters I use. Doing otherwise will be confusing, I think.
(In reply to Igor Fedorenko from comment #4) > Not sure. This isn't what I expect Maven build to do. I expect site to > include all dependencies regardless of what -Dparameters I use. Doing > otherwise will be confusing, I think. What exactly is confusing about building only for the environment that's specified. If you don't explicietly restrict the build environments all the traditional behaviour would kick in. Maybe you can describe your use case in more detail?
Of course a published publicly-available update site should be complete in terms of ensuring that all fragments declared in a feature.xml are actually in the update site. A "normal" build (without an environment filter) does exactly that. But we often do local builds to testing purposes for Oomph, and in that case we, for example, don't need all the products to be built, because we can't even run them on the current os/arch. It takes very long to build all the products that we don't need/want. So our desire is that we don't build them all, but just the one we want. In combination we need to produce an update site that is complete only with respect to that same os/arch. This would all work well, if the build didn't fail. We'd even be fine if fragments we didn't really need were built anyway, but the filter prevents that. So to me the current behavior just seems broken. We want to use a filter to reduce our build time from ~6 minutes to ~2 minutes. We want that to produce only one product and to produce an update site with only enough content to satisfy the filter. It's all we need, it's consistent, and it would work well for our purpose. I see nothing confusing in this. Certainly it would be confusing to end users if we made such an incomplete update site publicly available so the build should fail if there is no filter and there are missing things. But I find it very confusing to argue that even if there is a filter, the things omitted by that filter really must be present, because it's clear the filter is preventing those things from being built. So either the feature should be allowed to be incomplete, or the thing (filtered fragment) you insist must be present should be build despite there being a filter.
(In reply to Ed Merks from comment #6) > It takes very long to build all the > products that we don't need/want. So our desire is that we don't build them > all, but just the one we want. If the main factor slowing down your build is the products being installed/archived for all platforms, you could also reduce to one environment in the eclipse-repository module product/org.eclipse.oomph.setup.installer.product/pom.xml only (rather than for the whole reactor in the parent pom). BTW the reason why the product/repository zip creation has become slow may be bug 470074 which is scheduled to be fixed with upcoming Tycho 0.23.1 If I get it right what you want is performance optimization. Looks to me like this bug was opened with the solution rather than the problem.
To me it looks more like the behavior of the filter is inconsistent. While in one place it prevents an artifact from being built, in another place it fails the build because that artifact hasn't been built, and in a place where exactly those filters are also being In a more complex build environment it seems to me entirely desirable that one could build a feature that's valid only with respect to the filter. This would definitely work correctly, but so far the only argument against that I've heard is that it's confusing. I'm not sure I understand your suggestion, but if the suggestion is to change the POM we obviously don't want to change the source code just to do a local build which needs to produce only a result that works on the local machine.
(In reply to Ed Merks from comment #8) > I'm not sure I understand your suggestion, but if the suggestion is to > change the POM we obviously don't want to change the source code just to do > a local build which needs to produce only a result that works on the local > machine. you already have maven profiles which you switch on for local builds only. My suggestion was to configure this profile in the module of the products only. Just trying to be pragmatic and help you speed up your build since I understood this was your motivation for building only one environment in the first place. If that's not the case, feel free to ignore my suggestions.
Thanks, I like pragmatic. :-) Maybe Eike will understand your suggestion so we can give it a try.
I think I do. I have the feeling it's the answer to my not-spoken-out-loud question of why do these environment declarations impact both the TP *and* the built products. I'll try it out tomorrow and report here... I would still think this should be changed in Tycho but it wouldn't be so urgent anymore ;-)
(In reply to Ed Merks from comment #8) > I'm not sure I understand your suggestion https://git.eclipse.org/r/#/c/51466/1
(In reply to Eike Stepper from comment #11) > I think I do. I have the feeling it's the answer to my not-spoken-out-loud > question of why do these environment declarations impact both the TP *and* > the built products. right. that's probably two concerns mixed up. At least not obvious.
(In reply to Jan Sievers from comment #12) > https://git.eclipse.org/r/#/c/51466/1 That's awesome! Thank you so much!! I'll try that out...
(In reply to Jan Sievers from comment #12) > https://git.eclipse.org/r/#/c/51466/1 That works like a charm and I've merged it. Thousand thanks!!
I can confirm this is a regression since 0.22.0 - we can no longer build products, having the same error: [ERROR] Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:0.23.1:package-feature (default-package-feature) on project com.importio.builder.dependencies.feature: Execution default-package-feature of goal org.eclipse.tycho:tycho-packaging-plugin:0.23.1:package-feature failed: eclipse-plugin artifact with ID "org.eclipse.swt.cocoa.macosx" and version matching "0.0.0" was not found in the target platform -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:0.23.1:package-feature (default-package-feature) on project com.importio.builder.dependencies.feature: Execution default-package-feature of goal org.eclipse.tycho:tycho-packaging-plugin:0.23.1:package-feature failed: eclipse-plugin artifact with ID "org.eclipse.swt.cocoa.macosx" and version matching "0.0.0" was not found in the target platform This works with a straight swap of 0.23.1 -> 0.22 - what changed in the resolution between these versions?
(In reply to Matt Painter from comment #16) > > This works with a straight swap of 0.23.1 -> 0.22 - what changed in the > resolution between these versions? Also confirmed broken with 0.24-SNAPSHOT
(In reply to Matt Painter from comment #16) > I can confirm this is a regression since 0.22.0 - we can no longer build > products, having the same error: even though the error looks similar, this doesn't necessarily mean it's the same root cause. Are you sure the only thing you changed is the Tycho version? note that bundle org.eclipse.swt.cocoa.macosx was removed in the Mars release (it was still there in Luna).
Confirming the problem, a switch from 0.23 to 0.22 lets me work with native fragments.
running mvn -Denv=win64 clean install -Dtycho-version=0.22.0 on the sample project shows that it used to work with 0.22.0
(In reply to Matt Painter from comment #16) > I can confirm this is a regression since 0.22.0 - we can no longer build > products workaround is to add all necessary os/ws/arch environments in (parent) pom <plugin> <groupId>org.eclipse.tycho</groupId> <artifactId>target-platform-configuration</artifactId> <version>${tycho-version}</version> <configuration> <environments> <environment> <os>win32</os> <ws>win32</ws> <arch>x86</arch> </environment> <!-- add all required envs here --> </environments> </configuration> </plugin> IIRC if this is not specified, it uses the current environment only.
While there seems to be a general work-around (see comment #9) I think the comments here indicate that a general solution would be good to have and more compliant with common expectations.
*** Bug 488462 has been marked as a duplicate of this bug. ***
Dear All , the problem has been reproduced on 0.23.0 and 0.26.0. For your information, i can install the portable feature (multios) by using tycho-version : 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.
