User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0
So here is $42 question, what's the correct way to check out the
code to work on it?
Is there a how to start working on mylyn document somewhere?
mylyn.all@master with submodules doesn't work, missing modules of
modules
The modules seem to have different tags/branches so which if I check
each one out individually, which version do I choose?
Thanks
George
On 2022-12-23 10:56, George Lindholm
wrote:
Hi
Wim,
not really. I've picked up some of while working on my
connector.
If I'm able to build Mylyn from the new repository I can use my
connector to test it.
George
On 2022-12-23 03:52, Wim Jongman
wrote:
Do you have Eclipse plugin development experience?
In very short: Make changes to the PersonProposalProvider
logic. Then create a run configuration to launch a new
Eclipse from Eclipse and test your changes.
I tried the first launch
option got this error: <hvUwDwQrKJEHzR3o.png>
George
On 2022-12-19 13:11, George
Lindholm wrote:
Hi,
the first one is an easy
fix. I'll do that
The point about the 'id'
requires a new design since
the interface between
PersonProposalProvider and the
connector is
through a Map<String,
String>, when probably
should be a
List<IRepositoryPerson>
George
On 2022-12-19 09:33, Alexander
Fedorov wrote:
Hi,
If you already know the exact
code to fix why not to make
the next step?
Would you mind to create an
issue so we can discuss the
proposed changes in details?
If it could be followed by PR
then it would be fantastic.
Do you mean in an
existing connector or
in a connector that
you are going to make
yourself.
In general, but at the
moment for my jira
connector.
There are some problems with
PersonProposalProvider that
I would like to address.
The one that is affecting me
the most at the moment is
'matchesSubstring()' which
is doing 'startsWith()'
instead of 'contains()'
Other problems that I'm able
to work around, but is ugly,
is the assumption that the
'id' is has human attributes
associated with it.
This is fine when the id is
an account which, most/some
of the time, can be directly
associated with a person,
but with
Jira Cloud the id is a
random string of characters,
and offering them as an
select option is
meaningless.
'getPrettyName()' also
suffers from this
assumption.