Yea I think it'll be easier to focus on other bugs if we close this one as the main issue for this one has been resolved.

Thanks!

I agree that we should dedicate new bugs for newer issues, for instance, thanks to your instructions I was able to identify that one API call got an error 500 (see art #9426).

Maybe shall we close this ticket as the primary issue (not having a version of the connector compatible with Mars & Neon) is done. What do you think ?

I'm using it for our internal tuleap sever here @ Ericsson. Maybe I could start looking at the list of current bugs opened in the tracker?

You can try testing it with tuleap.net, should we open new bugs outside of this one in the Mylyn Tracker? I think it's going to be easier for me to look at them this way.

Also the error view is (I think) not opened by default on Eclipse, so sometimes there are errors but they're not explicitly shown to the user. To display them, just open the Error view (ctrl-3 -> Error Log). For instance right now there are a lot of warnings about tracker fields not being supported. I assume those are new fields that were added after the last release of the plugin?

How can we test on our end ?

How are your using it ?

Thanks for the update @vaceletm !

I'll see what I can do for the bug you mentionned, I really haven't tested all the features so it's possible some might not work at all.

@epatpol the update site now updated \o/ and you have the permission to trigger new build in the dedicated job

For the time being, it takes 'master' and publish it to 'update', please tell us if you want more flexibility (defining tags, different targets, some automation, etc).

However, I was not able to retrieve a task list from this server (I would have loved to update this ticket from eclipse). I don't get any error (Version: Neon Release (4.6.0) Build id: 20160613-1800)

Hi Patrick, sorry for the delay.

We modified the docker image to build the release and set-up the job on Jenkins but we get a failure on master:

[ERROR] Cannot resolve project dependencies:
[ERROR]   Software being installed: org.tuleap.mylyn.task.repository raw:2.0.0.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):2.0.0-SNAPSHOT
[ERROR]   Missing requirement: org.tuleap.mylyn.task.repository raw:2.0.0.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):2.0.0-SNAPSHOT requires 'org.tuleap.mylyn.task_feature.feature.group [2.0.0,2.0.1)' but it could not be found
[ERROR]
[ERROR] Internal error: java.lang.RuntimeException: No solution found because the problem is unsatisfiable.: [Unable to satisfy dependency from org.tuleap.mylyn.task.repository raw:2.0.0.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):2.0.0-SNAPSHOT to org.tuleap.mylyn.task_feature.feature.group [2.0.0,2.0.1).; No solution found because the problem is unsatisfiable.] -> [Help 1]
org.apache.maven.InternalErrorException: Internal error: java.lang.RuntimeException: No solution found because the problem is unsatisfiable.: [Unable to satisfy dependency from org.tuleap.mylyn.task.repository raw:2.0.0.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):2.0.0-SNAPSHOT to org.tuleap.mylyn.task_feature.feature.group [2.0.0,2.0.1).; No solution found because the problem is unsatisfiable.]
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:121)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: java.lang.RuntimeException: No solution found because the problem is unsatisfiable.: [Unable to satisfy dependency from org.tuleap.mylyn.task.repository raw:2.0.0.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):2.0.0-SNAPSHOT to org.tuleap.mylyn.task_feature.feature.group [2.0.0,2.0.1).; No solution found because the problem is unsatisfiable.]
    at org.eclipse.tycho.p2.resolver.AbstractResolutionStrategy.newResolutionException(AbstractResolutionStrategy.java:98)
    at org.eclipse.tycho.p2.resolver.ProjectorResolutionStrategy.resolve(ProjectorResolutionStrategy.java:88)
    at org.eclipse.tycho.p2.resolver.AbstractResolutionStrategy.resolve(AbstractResolutionStrategy.java:63)
    at org.eclipse.tycho.p2.impl.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:134)
    at org.eclipse.tycho.p2.impl.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:87)
    at org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.doResolvePlatform(P2TargetPlatformResolver.java:369)
    at org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.resolveDependencies(P2TargetPlatformResolver.java:345)
    at org.eclipse.tycho.core.resolver.DefaultTychoDependencyResolver.resolveProject(DefaultTychoDependencyResolver.java:109)
    at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:75)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:266)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
    ... 11 more
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/InternalErrorException

https://ci.tuleap.org/jenkins/job/Tuleap%20Mylyn%20Release/5/console

Can you check ?

 

Any updates on having a job that would update http://eclipse.tuleap.net/mylyn.tasks/update/ ?

Thanks

Thanks @vaceletm , I think we should focus on releasing the Mylyn connector first without the agile planner, so that people can install and give feedback early. Right now the master branch should be working, all that's left to do is a job that can "mvn clean package" in the tuleap-eclipse/org.tuleap.mylyn.task.repository folder like I mentionned above.

I think we might get feedback on the plugin much earlier than we think as people were discussing moving away from Bugzilla to Tuleap in the eclipse development mailing lists :)

Hi Patrick,

I mirrored the repo here: https://gerrit.tuleap.net/#/admin/projects/tuleap-eclipse-agile-planner

I think we can automate this building & pushing of release, I'll study that.

Is this repo also on the Tuleap gerrit? I can't find it at the moment, but it's a dependency for the agile planner

Thanks Manuel, As for the package publication, I think there should be a job that we can trigger manually for releasing that would mvn package the repository plugin. We could then simply push the target/repository files to http://eclipse.tuleap.net/mylyn.tasks/update/ to update the plugin in the marketplace (it redirects to that url anyway). I just need to merge this and then the codebase would be good for a working plugin.

Once that is done I was thinking I could start looking at the agile planner version of the plugin. I don't know how much everything changed on your side for this one, but maybe it's possible to resurrect this one as well.

I don't think there was one.

Feel free to bump to 2.2.

BTW, did you have any progress on how we should publish the package ?

The old version was 2.1, was there a specific versioning system used? I was thinking about simply bumping it to 2.2 (while tagging the current code with 2.2).

Thanks @tgerbet !

Problem solved. A part of the configuration was missing.

Hi,

We have upgraded both our Gerrit and Jenkins instance these last days so maybe something broke in the process. I will take a look and fix the issue.

Any problems with jenkins right now? Or you changed the job?

https://ci.tuleap.org/jenkins/job/mylyn_tests/10/consoleFull This trigger worked some weeks ago and this one is failing
https://ci.tuleap.org/jenkins/job/mylyn_tests/11/console

Thanks!

@Manuel,

I know using Ubuntu is now fine but just to give a heads up I found some info on why it didn't work on Alpine (see https://dev.eclipse.org/mhonarc/lists/platform-swt-dev/msg07946.html). Essentially SWT (which is required by Eclipse applications) is simply broken on at the moment on Alpine.

As for the release on the marketplace. we think it'd be best to have a job that builds the packages from master and push them here, overwriting what's actually there (http://eclipse.tuleap.net/mylyn.tasks/update/) as this is the repo that the marketplace points to for the update site.

There are several possible options for this. Either you give us write access to the update site eclipse.tuleap.net and we push the artefacts manually, or we find a way to manually trigger a jenkins job that would build a new version and push it to the repo mirrored by the marketplace. I think it's best if it's all automated on your side as you're already hosting the code and gerrit server, but I don't know how we should manage the versions and the release train if there are further releases that are going to happen...

Hi Manuel, glad to see it's now working correctly with jenkins :)

As for the next steps, I was only mentioning Sonar because I was curious about the analysis it would give on the Java code. To be honest I still haven't messed enough with it to configure it properly, but on some other projects I usually like to start by fixing possible bugs scanned by Sonar as a way to get myself more familiar with the source code itself.

As for the build on master merge, I'll talk to some others about it and get back to you this week or at the start of the week once I have time to check this. I think we will most likely push the packages to the Marketplace. I'm not familiar with the usual process, but there's probably a way to automate that with a jenkins job.

YES you nailed it @epatpol \o/ build is green: https://ci.tuleap.org/jenkins/job/mylyn_tests/8/

No issue with the "fat" image, first make works. When it's time make it fast :)

What are the next steps ?

• Sonar integration (I don't know what you want to configure) ?
• Buld of on master merge + publish packages somewhere ?
• ... other ?

 

I changed the base image to Ubuntu and I can now have the ui tests working. I created a pull request on GH.

I would like to have it working with an Alpine base image, but this would require further investigating to have all the correct libraries and dependencies for SWT. Please tell me if the image size is too big/unoptimized, there's probably stuff that can be improved with that version but for now it would work.

Hi Manuel,

Thank you for you input. I also didn't manage to make it work so far...

I think another option would be to build the connector and run the non-ui tests inside it and run the ui tests with a jenkins job running the xvnc plugin. Most eclipse projects use Jenkins/Hudson for ui testing using the same plugin. I know it would be better to have everything inside one container from one job but right now I have no idea how to run those ui tests inside one. I will investigate with other eclipse devs and see if some projects managed to run ui tests inside docker (or achieve a similar setup).

I made a few tests without luck so far.

I identified a couple of other interesting resources that might help:

• http://fabiorehm.com/blog/2014/09/11/running-gui-apps-with-docker/ (interesting because it says that for netbeans it had to use Oracle JRE instead of OpenJDK)
• https://linuxmeerkat.wordpress.com/2014/10/17/running-a-gui-application-in-a-docker-container/

Maybe there are other ppl in eclipse community that already setup this kind of integration, I don't know where we might find them

I have the code on my Github which is a fork of the repo you posted earlier. This only changes two lines to add pom.xml to the mvn calls. Everything else I've tried isn't really commited as there's nothing working right now. But I did try to hack something like the following : http://stackoverflow.com/questions/16296753/can-you-run-gui-apps-in-a-docker-container

by installing x11vnc@testing and xvfb using the alpine packages. I also had to install gtk+ to get past the SWT library error. I tried using ubuntu as the base image but I ended up with the same error so it's probably display/vnc config at this point... I have a test branch on my fork for my drafts if you want to try but at this point It's unknown terrain so any help would do :)

No I don't have any experience on this topic, at least not in this context but I'm happy to take a look. Could you publish what you got until now so that we can work on the same codebase?

The issue we got here is not directly related to Docker but to any headless box so we should be able to find a solution.

Do you have any experience running ui testing with Docker? I've managed to make the other modules package and test but it fails at ui.tests with the following error : org.eclipse.swt.SWTError: No more handles [gtk_init_check() failed]

I'm assuming this has to do with the fact that there is no display in the container, so I tried setting up Xvfb and the DISPLAY env variable but I don't have much experience with this. If you have any input on this it would be helpful!

Is the best way to do that to use the jenkins vnc/xvfb plugin and use that virtual display to run the ui tests from the guest container?

Thanks!

Thanks Manuel,

@Thomas, we looked at the dockerfile and made some changes to make the feature work, but right now the ui tests still fails. I tried adding a vncserver to the Dockerfile and I'm running that at the moment, I'll make a PR on Github once we manage to get that working.

Patrick,

I added you as editor on the marketplace (we will create an alias eclipse@tuleap.org later to avoir spof)

Hi,

I just created the Jenkins job for the unit tests but it looks like something do not pass:
[INFO] Reactor Summary:
[INFO]
[INFO] org.tuleap.mylyn.task-parent ....................... SUCCESS [ 1.613 s]
[INFO] org.tuleap.mylyn.task.core ......................... SUCCESS [ 2.814 s]
[INFO] org.tuleap.mylyn.task.doc .......................... SUCCESS [ 0.045 s]
[INFO] org.tuleap.mylyn.task.server.data .................. SUCCESS [ 0.067 s]
[INFO] org.tuleap.mylyn.task.ui ........................... SUCCESS [ 0.458 s]
[INFO] org.tuleap.mylyn.task_feature ...................... FAILURE [ 0.029 s]
[INFO] org.tuleap.mylyn.task.repository ................... SKIPPED
[INFO] org.tuleap.mylyn.task.ui.tests ..................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 07:56 min
[INFO] Finished at: 2016-06-27T07:45:09+00:00
[INFO] Final Memory: 102M/452M

The way our infrastructure is deployed, we can't let you a full access to the Jenkins job but it should not be too much of an issue, all our jobs are basically just a Docker image.

You can find the one constructed for the connector here: https://github.com/Enalean/docker-tuleap-mylyn-helper
PRs are welcome.

https://ci.tuleap.org/jenkins/job/mylyn_tests/

@epatpol we already have a sonar instance, if you need some extensions to be installed, feel free to ask https://sonar.tuleap.org/ 

We are close to have something for the build & deploy. Sadly we are blocked because the one who have the credential for marketplace is off for 2 days :) More to come on monday

@admin_manuel does Tuleap have a SonarQube instance I could use to analyze the plugin's code? If not we can set it up with our own server.

I'm interested in what you called earlier the "debug mode" of the connector. What would you like it to do exactly?

As for the current REST calls, here are the API endpoints being used by the connector, it's always /api/v1 as the prefix:

GET /projects
GET /projects/?id
GET /projects/?id/groups
GET /projects/?id/trackers

POST /tokens

GET /trackers/?id
GET /trackers/?id/artifacts
GET /trackers/?id/tracker_reports

GET /tracker_reports/?id/artifacts

GET /user

GET /user_groups/?id/users

(GET /api/v1)
GET

GET | PUT /artifacts/?id
POST /artifacts

GET /artifacts/?id/changesets

GET /artifact_files/?id

GET | DELETE | PUT /artifact_temporary_files/?id
GET | POST /artifact_temporary_files

No problem Thomas just ping us back when you have time :)

I did not forget you. We are currently a bit short on time on our end. I will do it as soon as possible but it looks quite uncertain for the end of the week.

Would it be possible for us to have access to a Jenkins slave so that we can run the tests and have the +1/-1 gerrit verify hook set up?

Thank you,

Thanks Thomas,

We had to manually add verifying and QueueReview flags to the gerrit project though, as we do not have access to a jenkins instance to build and test it yet (For the +1 verify flag).

Hi,

I have just granted rights on Gerrit, you should be able to integrate/merge code into the repo.

Concerning the development guidelines, please note they are very Tuleap focused and maybe they do not make sense for an external project.

Hi Manuel,

I'm still reading the Tuleap documentation for the development guidelines, but for now the people that need to have write access (integrator) is the following :

@nazulislam as the integrator (experience with jenkins and eclipse RCP/plugins development/packaging/testing)
@epatpol as the code maintainer (I can do reviews, patches, I'm not sure I need jenkins access, so is there a role for this?)
@empa as lead (needs write access on the repo and jenkins)
@markz3 as jenkins integrator and code reviewer

Maybe there's only one role for everybody, I haven't looked at that yet and it would be fine, but for now that's the early list of people we have.

Don't forget to try to find the marketplace credentials so that a jenkins job can then push and update the plugin once it's been tested and verified.

I'll try to find a list of rest calls that the plugin makes so that a proper test suite can be made for it.

Thanks

\Pat

Hi,

With this change https://gerrit.tuleap.net/#/c/5857/, you should be able to `mvn package` or `mvn install` from the org.tuleap.mylyn.task.parent plugin. This will also build the feature and the update site. We tested here with a local jenkins instance just to make sure.

If you have any questions don't hesitate to ping me!

I pushed the changes to gerrit, I'll keep you up to date with how to build the connector very soon.

I think that for now we just go ahead and build the packages with the patches you have.

Can you push you changes and tell me how to build th connector ?

Hi Manuel,

As I'm not completely familiar with the tuleap development process I can't really answer those questions. However, we do have a lot of expertise here on building and packaging eclipse plug-ins, so we are able to help if you need on that part. We have several contributors to Eclipse projects that are using gerrit/jenkins in their CI flow.

So I pushed the sources here: https://gerrit.tuleap.net/#/admin/projects/tuleap-eclipse

You should be able to push your changes for review

I will need to have more informations on how to build the packages to write the jenkins job.

Interesting questions:

• Who gonna review ?
• Who will be part of the integrator team ?

 

Yeah \o/

I think we should

• Have the sources on https://gerrit.tuleap.net
• Have a jenkins job that build the packages
• deploy on pkg.tuleap.net from jenkins (for marketplace)

I'll keep you updated when I have the first one ready

Manuel,

After several hours of debugging through the old code I found a bug that made the plugin not working with most of our repos. I've fixed it and so far it seems to work locally. I was able to make it work in both Mars and Neon. It's a small 2-line patch. Where should I push it?

I'm also working on updating the help contents of the Eclipse wizard dialogs, as right now clicking on the "?" does nothing as no context file are defined for those.

Hi Manuel,

I'm fine with having Gerrit as the reviewing tool.

Alright we'll stick with the v1 api if there's no need to change that.

Patrick,

We are discussing with the original authors of the connector to see how things can be put together. Personaly I would prefer to have the mylyn connector hosted on tuleap rather than github for better consistency. In term of review, we can use either gerrit if you like it or the -soon to be announce- Tuleap Pull Requests</spoiler>

In term of API, the v1 is not at all deprecated, this is the reference version. Some routes exists in v2 but it's not "official". So definitivly, v1 is the way to go.

Hi guys,

I'm currently evaluating the issues/blockers/bugs that needs to be fixed to have the base connector working on Eclipse mars/neon. I'll try to keep you updated soon. As for the code itself, should we make pull requests on the Github repo or is it somewhere else (gerrit, another Github repo) and if we do pull requests/gerrit patches, is anyone going to review/maintain them? Or maybe you want us to become maintainers of that plug-in? That could also work.

Other questions I have is that from what I've seen by quickly looking at the code, it's using the v1 Tuleap API. I think that is not maintained anymore by the newer Tuleap versions. As we are using the latest Tuleap version here do you think it would be a great idea to start by migrating to the newer api versions? I haven't had the chance to really look at the differences between v1 and v4 for example, so I don't know what's going to break if I try.

Thanks!

Good to ear Gert,

Do you have an idea of what you could be able contribute? there is no small enhancements !

Maybe Patrick-Jeffrey could list a couple of things he already saw that should be fixed ?

Hi Manuel,
We are currently evaluating TuLeap and we would be very interested in a Mylyn plugin. Maybe we can even do some work on it, but for sure we can give feedback.

This is very good news indeed.

On our side what would be perfect would be a set of REST call/payload that are representative of the connector activity so we can add it to our test suite to ensure we don't break the API.

In this spirit, what we lack with the current version of the plugin is a "REST debug" mode to intercept what the plugin tries to send to (or receive from) Tuleap. I think this might be helpful.

I do agree that the base connector is the most important part and be assured that we will help you as much as we can. I don't think there is much documentation than what there is in github repository yet but I will search for it.

Manuel

Hi Manuel, sorry for the late reply.

Yes I think we could help if there's an interest for it. I've forked the current code on Github here and I've built the plug-in for Neon (latest Eclipse release). Right now we are still investigating how much work we need to do in order to make it up to date with the Tuleap API, but yes we very interesting in helping in the maintenance of the connector if it can be done. I know that right now the connector isn't working at all, but I'm trying to amass all the major bugs and blockers that are making the connector unusable. Note that right now we would be focusing all our efforts on the base connector itself (not the agile one, although it could be an option in the future).

If there is any documentation/experts on your side related to the connector itself and its past development, that would be appreciated. Otherwise I think we can still manage.

Again, as we are not fully committed on this yet, I'll keep you updated.

Thank you

\Pat

Great, I'll post a message on the devel-mailing list as well as on other communication channels, to point here more eyeball of potential helpers/contributors.

Hi,

I discussed it a bit with our team here because I know one other team was using it before. We could maintain it ourselves, but first we need to investigate to see if there really is a need for that inside our company. I know more and more teams are using Tuleap here, but I don't know how many would be interested in using the Mylyn connector (or using Mylyn altogether.

We do develop eclipse RCPs and eclipse plug-ins here, but we didn't really look at the code base of the Tuleap connector at the moment, so I can't comment on how difficult/easy it would be for us to update and maintain it to be compatible with Eclipse Mars/Neon.

If there is more development from our side regarding this issue, I'll make sure to update you on this, but for now, we're still investigating.

Thank you :)

\Pat