Community
Participate
Working Groups
I was wondering about an easier way to manage version ranges (on Import-Package and/or Require-Bundle) across a set of bundles. I think a nice approach could be to specify constraint patterns in target definition files. An operation could be provided by Tycho which scans all the manifests and applies these patterns.
Doesn't filtering fix this use-case? http://wiki.eclipse.org/Tycho/Target_Platform#Filtering
(In reply to comment #1) > Doesn't filtering fix this use-case? > http://wiki.eclipse.org/Tycho/Target_Platform#Filtering From my understanding this restricts the "availability" (visibility?) of content _from_ a target definition. What I'd like to do is to define something like this: <pattern> <when-dependency-is> <type>java-package</type> <id>javax.persistence</id> </when-dependency-is> <update-any-manifest.mf-using-dependency> <versionRange>[2.1,3.0)</versionRange> </update-any-manifest.mf-using-dependency> </pattern> (syntax just made up)
There should really be better tooling to maintain the version ranges in dependency declarations in manifests. However my first idea (see bug 392410 proposal 1) was to make this change not on the fly but rather have the version ranges generated into the sources. Then this goal would be typically executed and the result is submitted to the SCM (similar to the tycho-versions-plugin). @Gunnar: Would this be an option for you?
(In reply to comment #3) > However my first idea (see bug 392410 proposal 1) was to make this change > not on the fly but rather have the version ranges generated into the > sources. Then this goal would be typically executed and the result is > submitted to the SCM (similar to the tycho-versions-plugin). @Gunnar: Would > this be an option for you? Yes, this would be a nice option. The lower part can be determined from the target platform. The upper part is a bit more tricky, though.
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.
