Community
Participate
Working Groups
Faced issue during Bug 551486, where repository is not generated properly. Example: Incorrect repository with tycho 1.6 - https://download.eclipse.org/eclipse/updates/4.15-P-builds/P20200122-0550 Correct Repository with tycho 1.4: https://download.eclipse.org/eclipse/downloads/drops4/P20200128-0510/ Probably an issue with org.eclipse.tycho:tycho-p2-repository-plugin:1.6.0:assemble-repository
Can you please explicit what's correct/incorrect, it's not obvious at 1st sight.
(In reply to Mickael Istria from comment #1) > Can you please explicit what's correct/incorrect, it's not obvious at 1st > sight. Incorrect one has extra features for JDT and PDE from master: org.eclipse.jdt_3.18.300.v20200110-0905.jar org.eclipse.pde_3.14.300.v20200110-0905.jar
Would you please create a small reproducer which can be used to debug the issue? P-builds are enough of a hassle on their own to be used to debug tycho.
Created attachment 281764 [details] Smaller reproducible scenario @Alex, @Michael, I hope this smaller reproducible use case will be convenient to reproduce the problem. PDE git repository can also be used instead of pde.ui and pde.build. Thanks Sravan!
(In reply to Sarika Sinha from comment #4) > Created attachment 281764 [details] > Smaller reproducible scenario > > @Alex, @Michael, > I hope this smaller reproducible use case will be convenient to reproduce > the problem. Which command should we run and in which order to see the issue?
mvn clean verify -f eclipse.platform.releng.tychoeclipsebuilder/java14patch415 -Pjava14patch415 -DskipTests=true(In reply to Mickael Istria from comment #5) > (In reply to Sarika Sinha from comment #4) > > Created attachment 281764 [details] > > Smaller reproducible scenario > > > > @Alex, @Michael, > > I hope this smaller reproducible use case will be convenient to reproduce > > the problem. > > Which command should we run and in which order to see the issue? mvn clean verify -f eclipse.platform.releng.tychoeclipsebuilder/java14patch415 -Pjava14patch415 -DskipTests=true if this command gives error in building eclipse.pde.ui or eclipse.pde.build please replace those folders with respective git repos
(In reply to Sravan Kumar Lakkimsetti from comment #6) > mvn clean verify -f > eclipse.platform.releng.tychoeclipsebuilder/java14patch415 -Pjava14patch415 > -DskipTests=true I see [ERROR] The build could not read 1 project -> [Help 1] [ERROR] [ERROR] The project (/home/mistria/sandbox/patch-feature/patch_source/eclipse.platform.releng.tychoeclipsebuilder/java14patch415/pom.xml) has 1 error [ERROR] Non-readable POM /home/mistria/sandbox/patch-feature/patch_source/eclipse.platform.releng.tychoeclipsebuilder/java14patch415/pom.xml: /home/mistria/sandbox/patch-feature/patch_source/eclipse.platform.releng.tychoeclipsebuilder/java14patch415/pom.xml (No such file or directory) Is the pom actually missing or does the command point to wrong location?
I will check tomorrow morning and let you know i think i may have given you wrong command. Basically you need trigger maven command with home/mistria/sandbox/patch-feature/patch_source/eclipse.platform.releng.tychoeclipsebuilder/java14patch415/pom.xml You'll get the repository in eclipse... repository folder inder java14patch415
Here the updated source bundle https://drive.google.com/file/d/1tDVKloLPcWHHwDLx8eqdKUk1sYSmUvSB/view?usp=sharing Once the tar is extraced, you'll find eclipse.platform.releng.aggregator folder > cd eclipse.platform.releng.aggregator/eclipse.platform.releng.tychoeclipsebuilder/java14patch415 > mvn -f pom.xml clean verify -Pjava14patch415 -DskipTests Please check the folders features and plugins in side eclipse.platform.releng.tychoeclipsebuilder/java14patch415/eclipse.releng.repository.java14patch/target/repository/ these folders should have only the jars ending with BETA_JAVA14.jar other jars should not be present If you want to run with tycho 1.4 please modify tycho.version and tycho-extras.version in eclipse.platform.releng.aggregator/eclipse-platform-parent/pom.xml
The behavior changed between Tycho 1.5.1 and Tycho 1.6.0. I actually think it's caused by a change in how p2 specify dependency on patched feature (maybe https://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?id=3d0b351e0d3f340bcc26f7a651f4eebfc817b722 ); the metadata are slightly different, but the "greediness" doesn't seem to change, so it can be unrelated.
Before we spend more effort on this issue, I have a genuine question: what actual usage or integration issue is caused by this one? Hqvibg the pqtched feature in the same repo can actually help as people who don't have previous PDE installed and try to install the patch feature are more likely to be successful.
(In reply to Mickael Istria from comment #11) > Before we spend more effort on this issue, I have a genuine question: what > actual usage or integration issue is caused by this one? Hqvibg the pqtched > feature in the same repo can actually help as people who don't have previous > PDE installed and try to install the patch feature are more likely to be > successful. The problem is that the installation of P build fails on I build because of this change. In P Build we specify the 4.15 M1 build as base, so the patch build installs on this M1 build but if any future I build is taken, PDE fails to install. Whereas the P build built with tycho 1.4, it installs well on all the I builds after M1 also.
So it seems to me it's not a Tycho isuse, but it's exactly that the strategy that's used by JDT P-builds is contrary to goal of bug 350088. I think you'll be able to reproduce it with PDE build or with the Export > Plugin Development > Deployable features wizard. Would it be possible to have this P-Build built against the current I-Build of JDT?
(In reply to Mickael Istria from comment #13) > So it seems to me it's not a Tycho isuse, but it's exactly that the strategy > that's used by JDT P-builds is contrary to goal of bug 350088. > I think you'll be able to reproduce it with PDE build or with the Export > > Plugin Development > Deployable features wizard. > Would it be possible to have this P-Build built against the current I-Build > of JDT? No, this defeats the purpose. Because P build is built after we have the Beta branch in a logical state. And the Marketplace Entry states that this P build can be applied on any build after a certain build. Updating Marketplace entry for each P build will be a manual activity.
(In reply to Sarika Sinha from comment #14) > And the Marketplace Entry states that this P > build can be applied on any build after a certain build. So according to https://help.eclipse.org/2019-12/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Ffeature_manifest.html , this has never been supposed to work: `If "patch" is "true", version must be set. [...] If "patch" is "true", "perfect" is assumed and other values cannot be set. [...] perfect: Dependent plug-in version must match exactly the specified version." and this approach has been abusing a bug that was fixed with bug 350088. > Updating > Marketplace entry for each P build will be a manual activity. I think it's better to have the patch feature built against I-Build, so if someone installs the patch feature from marketplace, they'll get an upgrade to I-Build if the "host" + the patch, and it provides the story you want of being able to use patch feature after a certain build while using a patch.
Is there something more to do in p2? Or is this "user error to rely on old buggy behavior"?
Let's mark it as INVALID as p2 and Tycho are behaving as expected according to the contract defined in the good old feature.xml description.
(In reply to Mickael Istria from comment #17) > Let's mark it as INVALID as p2 and Tycho are behaving as expected according > to the contract defined in the good old feature.xml description. I think the new behavior is similar to setting true to flag "includeAllDependencies" (link: https://www.eclipse.org/tycho/sitedocs/tycho-p2/tycho-p2-repository-plugin/assemble-repository-mojo.html#includeAllDependencies) In our build we don't set this flag. By default this should be set to false. Can you please let us know the importance of this flag?
(In reply to Sravan Kumar Lakkimsetti from comment #18) > I think the new behavior is similar to setting true to flag > "includeAllDependencies" (link: > https://www.eclipse.org/tycho/sitedocs/tycho-p2/tycho-p2-repository-plugin/ > assemble-repository-mojo.html#includeAllDependencies) The results look similar, but the reason is a bit different and lies in p2 publisher: when a feature has a dependency on a specific version of another feature, it's considered as an include and the referenced feature is included. But this is consistent with the patch feature "contract", so neither p2 nor Tycho are much to blame here.
(In reply to Mickael Istria from comment #19) > (In reply to Sravan Kumar Lakkimsetti from comment #18) > > I think the new behavior is similar to setting true to flag > > "includeAllDependencies" (link: > > https://www.eclipse.org/tycho/sitedocs/tycho-p2/tycho-p2-repository-plugin/ > > assemble-repository-mojo.html#includeAllDependencies) > > The results look similar, but the reason is a bit different and lies in p2 > publisher: when a feature has a dependency on a specific version of another > feature, it's considered as an include and the referenced feature is > included. > But this is consistent with the patch feature "contract", so neither p2 nor > Tycho are much to blame here. Ok. Here is the requirement here We need to create a patch repository with the following requirements 1. This repository should have patches for JDT feature and PDE feature 2. should be applicable on specified version range for example we want to apply the patch on a feature whose version falling between [3.18.300.v20200110-0905,3.19.0.v20200610-0905) 3. Should contain only the modified plugins Can you please suggest a way to achieve this?
(In reply to Sravan Kumar Lakkimsetti from comment #20) > We need to create a patch repository with the following requirements > 1. This repository should have patches for JDT feature and PDE feature > 2. should be applicable on specified version range for example we want to > apply the patch on a feature whose version falling between > [3.18.300.v20200110-0905,3.19.0.v20200610-0905) Patch feature cannot be applied on a version range by contract. Your requirement cannot be fulfilled directly by a single patch features. You'll need to have 1 patch feature per version of the feature you want to patch. I suggest you create 1 patch feature for latest milestone + 1 patch feature for the latest I-Build and publish both in the repository. > 3. Should contain only the modified plugins I think this requirement is overkill and you should consider getting rid of it at the moment. What matters isn't really the content of the repo but the metadata. > Can you please suggest a way to achieve this? As mentioned above, as single patch feature cannot work.
Instead of patch features, have you considered using a +0.0.100 feature on the Java14 branches and publishing those "regular" features? They'll be apply-able on a version range.
(In reply to Mickael Istria from comment #22) > Instead of patch features, have you considered using a +0.0.100 feature on > the Java14 branches and publishing those "regular" features? They'll be > apply-able on a version range. So basically using the Y-build update site instead of Patch build. Y-build is a full build with +0.0.50 on modified features
(In reply to Sravan Kumar Lakkimsetti from comment #23) > So basically using the Y-build update site instead of Patch build. Yes, I think that would work and be simpler to grok from maintenance and usage POV. > Y-build is a full build with +0.0.50 on modified features Good.
+0.0.50 is little complicated as the beta branch was initially based on 4.14 but finally it needs to be merged mack to master and then the +0.0.50 will be on 4.16. Lot of API filters associated, basically lot of effort in doing all this multiple times. So if anything can be done for P Build itself, it will really help.
(In reply to Sarika Sinha from comment #25) > So if anything can be done for P Build itself, it will really help. If your requirements for testing can be reduced mostly to testing against * Last M-Build * Last I-Build (ie if you can drop intermediary I-Builds) I think building 2 patch features in the same build is the easiest approach (one with static version for the M-Build, another with 0.0.0 to resolve to latest I-Build). On the long run, it would be great if we can find a productive workflow that gets rid of patch features. Patch features have always brought some complexity here and there that is better when avoided.
