Support to build eclipse repositories with patch features #893
Comments
|
The problem with feature package workaround is, the generated update site doesn't have grouping. So you have to remove the group items by category. |
|
I think provide an integration-test to demonstrate the issue would be the best bet for preserving that feature or showing a missing feature. |
|
@laeubi , Kindly try this reproducer.zip. You will see that site is created in feature successfully on setting |
|
Is there any plan for fixing this issue? I'm stuck on Tycho 2.7.5 since groovy-eclipse patches JDT Core. I can change |
|
Well it seems groovy-eclipse is the only one that needs to use patch features (not sure why) so it seems quite unlikely without someone is starting hacking into this or funding such development otherwise, see for example here for dedicated support options for Tycho: |
|
By the way the replacement for deployableFeature option should be: |
|
Any chance this could get some attention? I can no longer build against M2E due to requirement of Even if feature patches are not recommended practice, they are supported by eclipse feature and PDE. I'm stuck on To recap, Alternative: Could I get a Tycho 2.7.x release that supports <plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-p2-publisher</artifactId>
<version>${tycho-version}</version>
<configuration>
<profileFile>JavaSE-21.profile</profileFile>
</configuration>
</plugin>JavaSE-21.profile |
|
@eric-milles if it is crucial to your business you can find dedicated support options for Tycho here: |
|
I am wondering about the The generated <units size='2'>
<unit id='org.codehaus.groovy.jdt.patch.feature.group' version='5.6.0.v202412161916-e2103' singleton='false'>
<patchScope>
<scope>
<requires size='1'>
<required namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.jdt.feature.group' range='[3.18.700.v20210303-1800,3.18.700.v20210303-1800]'>
<filter>
(!(org.eclipse.equinox.p2.exclude.import=true))
</filter>
</required>
</requires>
</scope>
</patchScope>
...
</unit>
</units>When I specifically add this feature back to the next <feature id="org.codehaus.groovy.headless.feature"
label="%featureName"
version="5.6.0.qualifier"
provider-name="%providerName">
...
<includes id="org.codehaus.groovy.jdt.patch" version="0.0.0"/>
<includes id="org.eclipse.jdt" range="[3.18.700,3.20.0]"/><!-- I added this as a test -->
...
</feature> |
|
I'm debugging -- it's slow going -- but I think this is where the patched feature is dropped from the target platform: |
|
I tried setting <feature id="org.codehaus.groovy.headless.feature"
label="%featureName"
version="5.6.0.qualifier"
provider-name="%providerName">
...
<includes id="org.codehaus.groovy.jdt.patch" version="0.0.0"/>
<!-- see https://github.com/eclipse-tycho/tycho/issues/893 -->
<requires> <import feature="org.eclipse.jdt" version="0.0.0"/> </requires>
...
</feature>This is enough to get my I tried adding |
|
My understanding of what is going on in a normal patch feature is that the patched feature gets marked non-greedy in the p2 metadata. The next feature or repository to include the patch feature gets the patched IU removed from its requirements by From what I can tell, this is what was described in the original bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=389698#c13 As noted above, I can add the patched feature back with However, as noted above, these changes create a greedy requirement for the patched feature and so it ends up as part of the repository. |
|
If I change protected void processIU(IInstallableUnit iu) {
iu = iu.unresolved();
Map<Version, IInstallableUnit> iuSlice = slice.computeIfAbsent(iu.getId(), i -> new HashMap<>());
iuSlice.put(iu.getVersion(), iu);
if (!isApplicable(iu)) {
return;
}
Collection<IRequirement> reqs = getRequirements(iu);
for (IRequirement req : reqs) {
/* CHANGE start
if (isApplicable(iu, req) && isGreedy(iu, req)) {
*/
if (isApplicable(iu, req) && (isGreedy(iu, req)
|| (iu instanceof IInstallableUnitPatch iup && req.equals(iup.getLifeCycle())))) {
// CHANGE end
expandRequirement(iu, req);
}
}
}Then all the builds succeed, but the result is much the same as directly adding the Note: This change was first described here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=389698#c21 Update: The resulting eclipse repository (update site) was not installable due to missing patched feature. |
|
@eric-milles great to see you are looking into this and making your way through the Tycho code-base. Do you like to created a PR with your changes and include an integration-test to demonstrate the issue. If you make changes to any "copiedfromp2" class then you probably want to propose a similar change to P2 as well. |
|
@laeubi I was hoping some of this might provide some insight. If I make an explicit includes or requires of "org.eclipse.jdt" feature, it ends up in the p2 repository. Do you know of a way to satisfy the implication requirement of the Projector without triggering all the greedy inclusion of artifacts? Or do you know how to tell I'm trying <repositoryReferenceFilter>
<addOnlyProviding>true</addOnlyProviding>
<exclude>https://download.eclipse.org/**</exclude>
</repositoryReferenceFilter>but the hard requirement is still included (as alluded to in the notes for these options). I have a working update site (p2 repository) but it includes JDT Core jars from Eclipse. I can manually remove them and the install seems to work okay, but they are still mentioned in the artifacts/content metadata. |
|
The slicer is the right place to adjust, but you probably want first make sure that the patch feature can be build and fix the update-site problem later. the |
|
With no changes, the patch feature project builds properly. At that point in the process, the patched feature is required and so it is part of the normal resolved dependencies. The next feature down the line that imports the patch feature (excerpt here) sees the patched feature dropped from the dependencies because it is indicated as non-greedy in the metadata of the patch feature. I tried including the patched feature with my change above within I tried ensuring that the patched feature ends up in I'm not sure if I have any avenues left on the side of filling out required and non-greedy dependencies / installable units. It is difficult to know if adding something into the model on the Slicer side is the logical thing to do. From a metadata standpoint, the patched feature is transformed to a non-greedy requirement. So the non-optional dependency seems like a mistranslation. But I can't quite pin down where that is setup in Projector. Adding a hard (greedy) requires for the patched feature to force dependency resolution is a workaround. I'm thinking that an optional dependency for the patched feature jives with the p2 metadata. And it should not result in JDT Core jars (in my case) being included in the p2 repository. |
|
I was able to narrow down to So, one possibility is to return early from Another possibility may have to do with |
This issue is based on https://bugs.eclipse.org/bugs/show_bug.cgi?id=389698
The feature patches are not a good way to introduce new features, But there are certain products that really needs it such as
If its only for patching a feature, we could generate the update site for a deployable feature using
https://www.eclipse.org/tycho/sitedocs/tycho-packaging-plugin/package-feature-mojo.html#deployableFeature
But if this feature is planned to remove as well like the update site package type, then there will be not support available to use tycho for building eclipse patches. A pure feature patch (Not like Groovy) could be to introduce new feature like the new Java features to an old release.
Please consider providing support for feature patching.
The text was updated successfully, but these errors were encountered: