Community
Participate
Working Groups
I have two related requests/proposals. First, introduce new match mode 'versionRange', which will treat dependency plugin/feature version as version range and will allow [1.2.3,4.5.6) syntax. Second, for feature patches respect match attribute if present (but assume match=perfect if match is not specified). I am willing to provide a patch if there is an interest in this.
+1 for having this be addressed. The handling of patches with the current expressiveness of feature.xml is a big limitation since patches can only be created for one precise version of a feature whereas p2 allows for a patch to be applicable on multiple versions of a feature.
Feels like two separate and unrelated topics. Allowing requirements to be expressed with ranges would be great. At some point we should just get rid of the match rules of old and use ranges. The patch thing is interesting. What would the upper bound of the range in a patch be? How can you say that your patch will work with some future version? Or are you saying that the upper bound would be the current version and the lower bound would be something from the past? That seems reasonable. In any event, this should be split into two bug IMO as they would likely be addressed separately/differently.
Created attachment 192405 [details] tentative patch against 3.6.x branch (In reply to comment #2) > Feels like two separate and unrelated topics. Allowing requirements to be > expressed with ranges would be great. At some point we should just get rid of > the match rules of old and use ranges. I thought about this too but decided to add match=versionRange but keep the old behaviour. It is not hard to keep the old match rules and I am sure there would be at least few loudly upset "fans" of the old rules if we removed them. > The patch thing is interesting. What would the upper bound of the range in a > patch be? How can you say that your patch will work with some future version? > Or are you saying that the upper bound would be the current version and the > lower bound would be something from the past? That seems reasonable. I think publisher should not enforce or imply any specific upgrade/patch scenarios but should let the users decide what makes sense for them. Especially because p2 engine's support for patch IUs seems to be quite flexible. My immediate use case is to deliver new versions of Maven runtime to existing and future m2e installations. I control both m2e versions and maven runtime versions, so I will make sure the patch only applies to compatible m2e version. > > In any event, this should be split into two bug IMO as they would likely be > addressed separately/differently. Actually, both patch and version/match logic implemented together, so the two are much easier to implement as one change (see attached *preliminary* patch).
Created attachment 192420 [details] proposed implementation Let me know if attached proposed implementation makes sense or requires more work.
Patch applied
This change completely broke PDE/Build. There are over 100 test failures. Any feature.xml containing a <requires> element will not parse. This is because the hasImports field was change to a final with value false. It is no longer being set in processImport. The #endElement for "requires" enforces that there is at least one import (as required by the feature.xml DTD - http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/feature_manifest.html)
