Community
Participate
Working Groups
Most connectors rely on an API which is supported only from a certain server version up. Some connectors add this restriction to the connector label shown in the add taskrepository wizard. I think this could be something the framework does though. The connector setting a minimum version, and the framework adding this to the label (and maybe also to the description in the repositorySettingsPage as well).
Created attachment 181309 [details] patch v1 Here is a first stab. I am a bit worried about regressions / messing up existing connector's labels. The getShortLabel method however already seems to assume there could be an additional message in brackets, so by leveraging this method we should be ok. What are other people's thoughts?
Created attachment 181310 [details] mylyn/context/zip
I like the underlying idea of this patch. Most connectors limit support to certain versions and it would be nice to make that available in the API. I would like prefer something other than string though to make that easier to process.
Maybe we could even use org.osgi.framework.Version to represent the version we're dealing with. I'd just be a little careful as we cannot expect that the repositories we're dealing with have concrete versions (current example is version "2010" with internal version 3.x.y). Not sure if we should restrict this to a specific version format as connector developers may want to state "XY (Summer 2010 and later supported)"
Good point Benjamin. I was just lazy but your argument is very compelling. The version displayed is for the user to consume, so we shouldn't assume concrete versions. Steffen, your thoughts? I think if we actually want the framework to support version constraints on a deeper level (getVersion() plus setMin/Max versions) we will need a separate API (and could probably tie a displayName into those version objects for using them in the AddTaskRepository wizard). But I feel that's a bit out of scope and a bigger problem.
Steffen, what are your thoughts on those points raised by Ben?
I'd be great to use OSGi versions but most repositories use custom formats. I am not sure if it's reasonable to expect that these can always be normalized to the OSGi format. Maybe an extensible version class that supports comparison and is adaptable to org.osgi.framework.Version would do the trick. Not sure if it's worth investigating at this point unless there is a concrete driver.
Wonder if, besides API for supported versions, there should also be API that find out the specific version of a given repository. While some connectors will not be able to provide this information, I know about many who could provide this.
(In reply to comment #8) > Wonder if, besides API for supported versions, there should also be API that > find out the specific version of a given repository. While some connectors will > not be able to provide this information, I know about many who could provide > this. Makes sense to me. That information should be part of the repository configuration.
I pushed a draft implementation for this to https://git.eclipse.org/r/#/c/9371/ Steffen, Frank, would love to hear your comments on the idea.
This looks like a nice improvement to me and I'd certainly consume it in the Mantis connector. What I'd add here is that matching rules may be more complicated than a single min/max range. For instance you can have a two separate branches - 1.1.x and 1.2.x which are supported by the Mylyn connector for [1.1.4,1.2.0) and [1.2.2,1.3.0), or you get a version range that is excluded outright because of some bug. One additional feature is that you might want to warn the user of a problem, not block validation altogether. Some of these are implemented in the Mantis connector, should you want to take a look https://github.com/Mylyn-Mantis/mylyn-mantis/blob/master/com.itsolut.mantis.core/src/com/itsolut/mantis/core/RepositoryVersion.java
Marking WONTFIX because we have no current driver for this.
