| New Requirement - Query local TASK URL [message #57055] |
Tue, 02 September 2008 12:01  |
Eclipse User |
|
|
|
Currently, the TASK URL is associated with the repository. The assumption
is that the same URL can be used to retrieve any task.
The forge I have to use has two types of tasks, TRACKER items, and TASK
items. TRACKER items are typical bugs and feature requests. TASKS are
individual work assignments. The URL required to retrieve a TRACKER is very
different than the URL to retrieve a TASK.
Given the current Mylyn implementation, it is necessary to define two
repositories, each with a different TASK URL. Unfortunately, since they
have the same host address, Mylyn rejects the request. It seems you can
only have a single instance of a repository. Understandable.
My current configuration specifies the TASK URL used to retrieve TRACKER
items (bugs and feature requests.) In order to define a TASK URL that
retrieves TASK items from the forge, I have to define a second repository
for the same forge (which mylyn objects to). To get around this problem, I
could
a) define a new repository using IP address instead of host name, mylyn
seems to allow this
b) define a new repository that specifies port 80 (http://host:80/...), this
also seems to get around the mylyn restriction.
A better solution would be a query specific TASK URL. Since I am able to
build a query that retrieves the list of TASK elements, using a custom QUERY
URL, it seems reasonable that I should be able to specify a custom TASK URL
associated with the query.
If this is already possible, please explain or point me to docs. Otherwise,
should I submit a feature request?
Michael
|
|
|
|
| Re: New Requirement - Query local TASK URL [message #57476 is a reply to message #57055] |
Tue, 09 September 2008 13:39  |
| Eclipse User |
|
|
|
I am not sure if this can be supported with the current model. Please file a
new feature request and provide an example of the URL used to fetch TRACKER
items and TASK items.
Steffen
Michael Giroux wrote:
> Currently, the TASK URL is associated with the repository. The assumption
> is that the same URL can be used to retrieve any task.
>
> The forge I have to use has two types of tasks, TRACKER items, and TASK
> items. TRACKER items are typical bugs and feature requests. TASKS are
> individual work assignments. The URL required to retrieve a TRACKER is
> very different than the URL to retrieve a TASK.
>
> Given the current Mylyn implementation, it is necessary to define two
> repositories, each with a different TASK URL. Unfortunately, since they
> have the same host address, Mylyn rejects the request. It seems you can
> only have a single instance of a repository. Understandable.
>
> My current configuration specifies the TASK URL used to retrieve TRACKER
> items (bugs and feature requests.) In order to define a TASK URL that
> retrieves TASK items from the forge, I have to define a second repository
> for the same forge (which mylyn objects to). To get around this problem,
> I could
>
> a) define a new repository using IP address instead of host name, mylyn
> seems to allow this
> b) define a new repository that specifies port 80 (http://host:80/...),
> this also seems to get around the mylyn restriction.
>
> A better solution would be a query specific TASK URL. Since I am able to
> build a query that retrieves the list of TASK elements, using a custom
> QUERY URL, it seems reasonable that I should be able to specify a custom
> TASK URL associated with the query.
>
> If this is already possible, please explain or point me to docs.
> Otherwise, should I submit a feature request?
>
> Michael
|
|
|
|
| Re: New Requirement - Query local TASK URL [message #593043 is a reply to message #57055] |
Mon, 08 September 2008 11:38 |
| Eclipse User |
|
|
|
Would it be possible for someone from the Mylyn team to comment on this? Am
I all wet here? Or is this a candidate for a feature requrest?
I would argue that the generic web connector needs to be as flexible as
possible since its goal is to be generic and cannot anticipate all possible
repository implementations. If the repository manager will only allow a
single instance of a repository, then I think we need more flexability in
the generic connector.
Michael
|
|
|
| Re: New Requirement - Query local TASK URL [message #593120 is a reply to message #57055] |
Tue, 09 September 2008 13:39 |
| Eclipse User |
|
|
|
I am not sure if this can be supported with the current model. Please file a
new feature request and provide an example of the URL used to fetch TRACKER
items and TASK items.
Steffen
Michael Giroux wrote:
> Currently, the TASK URL is associated with the repository. The assumption
> is that the same URL can be used to retrieve any task.
>
> The forge I have to use has two types of tasks, TRACKER items, and TASK
> items. TRACKER items are typical bugs and feature requests. TASKS are
> individual work assignments. The URL required to retrieve a TRACKER is
> very different than the URL to retrieve a TASK.
>
> Given the current Mylyn implementation, it is necessary to define two
> repositories, each with a different TASK URL. Unfortunately, since they
> have the same host address, Mylyn rejects the request. It seems you can
> only have a single instance of a repository. Understandable.
>
> My current configuration specifies the TASK URL used to retrieve TRACKER
> items (bugs and feature requests.) In order to define a TASK URL that
> retrieves TASK items from the forge, I have to define a second repository
> for the same forge (which mylyn objects to). To get around this problem,
> I could
>
> a) define a new repository using IP address instead of host name, mylyn
> seems to allow this
> b) define a new repository that specifies port 80 (http://host:80/..),
> this also seems to get around the mylyn restriction.
>
> A better solution would be a query specific TASK URL. Since I am able to
> build a query that retrieves the list of TASK elements, using a custom
> QUERY URL, it seems reasonable that I should be able to specify a custom
> TASK URL associated with the query.
>
> If this is already possible, please explain or point me to docs.
> Otherwise, should I submit a feature request?
>
> Michael
|
|
|
|
Powered by
FUDForum. Page generated in 0.04741 seconds
Home