Community
Participate
Working Groups
Hello, We open this bug as discussed during Mylyn Conference Call of december 2013. We would like to submit the code of our Mylyn Tasks Connector for Tuleap in the eclipse foundation. --- DESCRIPTION OF THE PROJECT --- Tuleap is a 100% open-source ALM web application. We have been developing a Mylyn Tasks connector for Tuleap during the last 18 months. The code of this project has been developed by several Obeo employees. Our company is a strategic member of the Eclipse Foundation, so we shouldn't have any issues with the necessary approval for a contribution agreement. The code has been created under the Eclipse Public License v1.0. The code in question is composed of 3 plugins (core, ui, tests), one feature referencing the core and ui plugins, an update site and a releng project. There are no changes in any existing artifact located in the Mylyn Task repository. We have a build based on Maven and Tycho. This build is currently independant even if our goal is to have our build plugged in the general Mylyn build like the other connectors (with the removal of our own update site project) but we considered that it was simpler for the contribution not to touch existing files in the Mylyn repository. Our build is similar to the Bugzilla or Trac connectors, it uses as a parent the "org.eclipse.mylyn.tasks-parent" pom.xml but we have a dedicated pom.xml that is just launching our build. We have been using continuous integration since the beginning of the project to ensure that our build is working. We use code templates to ensure the presence of a Javadoc header in our source code containing the EPL description and the copyright notice along with the authors of the code. All of our dependencies are composed of plugins from the Eclipse Foundation (Mylyn Tasks, Mylyn Common and the Eclipse platform) and a couple of utility plugins from Orbit (Apache Axis & javax.xml.rpc) We use checkstyle and have a strong set of JDT/PDE compilation rules to maintain a good quality of the code. We do not have any API, 100% of our code is located in internal packages. Those packages are exported with the directive ";x-internal:=true" or ";x-friends:=..." to ensure that if someone want to use our code, it is possible while it stays not recommended. All the user interface labels are internationalized in ".properties" files. We have placed the "about.html" files in the plugins and feature with the content of the EPL license. We are about to start using gerrit. We use a Tuleap appliance in a vm for our integration tests. --- ROADMAP --- Current version is 1.1.2, it is the 5th version of our connector. We currently use SOAP for client/server communication but we plan to use a REST API (currently under development). This should improve performances, and we also take this opportunity to improve the internal architecture of the connector. This will lead to a version 2.0 that we anticipate in Q1 2014. Besides, we plan to make a version 3.0 that should include the support for other Tuleap services beyond trackers, which is the only Tuleap service we support at the moment. --- CONTRIBUTING --- We would like to know how we could contribute this code to Mylyn Tasks. We wurrently have 2 people working on this connector full time and intend to keep this pace. --- LINKS --- Tuleap: http://tuleap.net Tuleap appliance: https://tuleap.net/wiki/?group_id=101&pagename=Installation+%26+Administration%2FHow+to+install
Thanks for the very detailed description! This all sounds very good. The one major concern that I have is the dependency on SOAP. Based on our previous experience SOAP connectors are most costly to maintain than connectors based on other transports (e.g. REST or XML-RPC) particularly as the remove API evolves. Furthermore, we are in the process of removing the SOAP transport layer in Mylyn. I would prefer not add a connector to the code base that is based on SOAP at this point and rather focus efforts on REST based transports. We have for instance already started a new Bugzilla connector that will be solely based on a REST API (bug 414360) and replace the existing connector once it has reached a sufficient level of maturity. Do you think it would be feasible to contribute a REST only version of the Tuleap connector to Mylyn? Another key aspect of reducing connector maintenance is the availability of managed public test repositories. We are using puppet based provisioning for Bugzilla, Trac, Gerrit, Hudson and Jenkins which has proven to be of huge value for testing multiple versions and variants in terms of configuration. Can you provide more details what is available for Tuleap and how the repositories are being managed and would be available to other developers?
(In reply to Steffen Pingel from comment #1) Thanks for the feedback! 1- Getting rid of SOAP Tuleap uses REST for its new features, and is working on a refactoring of existing SOAP API to port it to REST. But it's an ongoing work and we need to rely on the SOAP API to provide a full featured connector. We are working with them on this topic to achieve a full refactoring as soon as possible. We'd like it not to be a blocker for our initial submission and to continue this refactoring directly under the Eclipse process and Eclipse infrastructure, under the umbrella of Mylyn project. So, it could be more transparent with you, and a good way to show how active we are on this connector. 2- Public test repositories I'm not sure what details you want exactly. I don't know Puppet yet, just by name. For the time being, we use a test instance of Tuleap with some projects and trackers in different configurations for testing. This is not publicly available yet, but we are willing to do what is required to ensure the testability of the connector in the eclipse infrastructure. Is there a wiki page or something that describes what exists for other connectors, beyond the code? It has been annouced lately on the Tuleap-dev mailing list that Tuleap is using Chef and Vagrant to ease the deployment of dev instance of Tuleap servers. https://tuleap.net/wiki/index.php?pagename=Development%20environment%2FVirtualBox&group_id=101 Maybe this could be useful to help deploy test Tuleap instances, I don't know, it just seemed related so I mention it. > Thanks for the very detailed description! This all sounds very good. > > The one major concern that I have is the dependency on SOAP. Based on our > previous experience SOAP connectors are most costly to maintain than > connectors based on other transports (e.g. REST or XML-RPC) particularly as > the remove API evolves. Furthermore, we are in the process of removing the > SOAP transport layer in Mylyn. I would prefer not add a connector to the > code base that is based on SOAP at this point and rather focus efforts on > REST based transports. We have for instance already started a new Bugzilla > connector that will be solely based on a REST API (bug 414360) and replace > the existing connector once it has reached a sufficient level of maturity. > Do you think it would be feasible to contribute a REST only version of the > Tuleap connector to Mylyn? > > Another key aspect of reducing connector maintenance is the availability of > managed public test repositories. We are using puppet based provisioning for > Bugzilla, Trac, Gerrit, Hudson and Jenkins which has proven to be of huge > value for testing multiple versions and variants in terms of configuration. > Can you provide more details what is available for Tuleap and how the > repositories are being managed and would be available to other developers?
I think we might have discussed this on the Mylyn call but I forget: is the Tuleap connector using the Mylyn SOAP transport (org.eclipse.mylyn.commons.soap)? This has recently been deprecated and we're planning to remove it entirely from Mylyn (bug 421379).
(In reply to Sam Davis from comment #3) > I think we might have discussed this on the Mylyn call but I forget: is the > Tuleap connector using the Mylyn SOAP transport > (org.eclipse.mylyn.commons.soap)? This has recently been deprecated and > we're planning to remove it entirely from Mylyn (bug 421379). Yes, we do depend on org.eclipse.mylyn.commons.soap. Actually, it's only to set the AbstractWebLocation in the call properties: call.setProperty(SoapHttpSender.LOCATION, this.location); So it seems to me this dependency is very lightweight.
(In reply to comment #2) > 2- Public test repositories > I'm not sure what details you want exactly. I don't know Puppet yet, just by > name. > For the time being, we use a test instance of Tuleap with some projects and > trackers in different configurations for testing. > This is not publicly available yet, but we are willing to do what is required to > ensure the testability of the connector in the eclipse infrastructure. Is there > a wiki page or something that describes what exists for other connectors, beyond > the code? Maybe Steffen can comment more, but I think generally there are publically accessible test repositories in every supported version and there's an easy process to provision new versions and different configurations of the test repositories.
(In reply to comment #5) > (In reply to comment #2) > > 2- Public test repositories > > I'm not sure what details you want exactly. As Sam said, what we need for sure is publicly accessible test infrastructure to run all tests from ci.mylyn.org and the Eclipse.org Hudson and to enable any member of the community to work on the connector. > > I don't know Puppet yet, just by > > name. > > For the time being, we use a test instance of Tuleap with some projects and > > trackers in different configurations for testing. > > This is not publicly available yet, but we are willing to do what is required > to > > ensure the testability of the connector in the eclipse infrastructure. Is > there > > a wiki page or something that describes what exists for other connectors, > beyond > > the code? I'm afraid we don't have any useful documentation. On a high level, we can fully provision the test environment from puppet manifests. That enables us to manage the entire test configuration through git and re-create any test environment in any point in time. It also makes it very easy to modify tests environment and provision local test environments with vagrant. If you want to try it out you can run "vagrant up" (requires vagrant and virtualbox installed) in any of the connector releng projects. That executes the same scripts we run on mylyn.org to setup repositories: http://mylyn.org.
(In reply to comment #4) > (In reply to Sam Davis from comment #3) > > I think we might have discussed this on the Mylyn call but I forget: is the > > Tuleap connector using the Mylyn SOAP transport > > (org.eclipse.mylyn.commons.soap)? This has recently been deprecated and > > we're planning to remove it entirely from Mylyn (bug 421379). > > Yes, we do depend on org.eclipse.mylyn.commons.soap. > > Actually, it's only to set the AbstractWebLocation in the call properties: > > call.setProperty(SoapHttpSender.LOCATION, this.location); > > So it seems to me this dependency is very lightweight. The dependency on the Mylyn SOAP transport is one aspect. Even if that was removed I assume there is still a dependency on the old deprecated Axis 1.x library? The even more so important aspect though is that all contributions that are accepted into Mylyn have to go through a code review and I believe in this case also through an IP review / CQ (since the connector is larger than 250 lines of code and was not created under the supervision of the PMC). Code and IP reviews are significant efforts so if the contribution included the SOAP specific implementation bits we would essentially spent time on code that was already scheduled to be removed. From my experience, supporting multiple transports also complicates connector architecture which also increases effort on the code review. I'd much rather spent the limited time we have available for Mylyn development on moving forward rather than adding code that isn't going to stick around long term. Ideally the initial contribution of the Tuleap connector would only have a REST transport. Even if that connector is missing functionality that is only available through SOAP it would provide value and allow us to accept the contribution faster and have a much more maintainable code base. Can you give us a sense on what the major missing pieces in the REST API are at this point and what the rough time line is until a limited but useful connector would work over REST?
(In reply to Steffen Pingel from comment #7) > (In reply to comment #4) > > (In reply to Sam Davis from comment #3) > > > I think we might have discussed this on the Mylyn call but I forget: is the > > > Tuleap connector using the Mylyn SOAP transport > > > (org.eclipse.mylyn.commons.soap)? This has recently been deprecated and > > > we're planning to remove it entirely from Mylyn (bug 421379). > > > > Yes, we do depend on org.eclipse.mylyn.commons.soap. > > > > Actually, it's only to set the AbstractWebLocation in the call properties: > > > > call.setProperty(SoapHttpSender.LOCATION, this.location); > > > > So it seems to me this dependency is very lightweight. > > The dependency on the Mylyn SOAP transport is one aspect. Even if that was > removed I assume there is still a dependency on the old deprecated Axis 1.x > library? > > The even more so important aspect though is that all contributions that are > accepted into Mylyn have to go through a code review and I believe in this > case also through an IP review / CQ (since the connector is larger than 250 > lines of code and was not created under the supervision of the PMC). > > Code and IP reviews are significant efforts so if the contribution included > the SOAP specific implementation bits we would essentially spent time on > code that was already scheduled to be removed. From my experience, > supporting multiple transports also complicates connector architecture which > also increases effort on the code review. I'd much rather spent the limited > time we have available for Mylyn development on moving forward rather than > adding code that isn't going to stick around long term. > > Ideally the initial contribution of the Tuleap connector would only have a > REST transport. Even if that connector is missing functionality that is only > available through SOAP it would provide value and allow us to accept the > contribution faster and have a much more maintainable code base. > > Can you give us a sense on what the major missing pieces in the REST API are > at this point and what the rough time line is until a limited but useful > connector would work over REST? Yes of course, there is a dependency to Axis. Currently, the Tuleap REST API allows the retrieval of most of the projects and trackers configuration (a few things are missing though), and the retrieval of artifacts by id. On the contrary, querying and updating artifacts is not yet possible. We need to take a closer look at this and discuss with the Tuleap team to build a time line. We'll comment again here as soon as we have a reliable vision of a roadmap.
(In reply to Steffen Pingel from comment #6) > (In reply to comment #5) > > (In reply to comment #2) > > > 2- Public test repositories > > > I'm not sure what details you want exactly. > > As Sam said, what we need for sure is publicly accessible test > infrastructure to run all tests from ci.mylyn.org and the Eclipse.org Hudson > and to enable any member of the community to work on the connector. > > > > I don't know Puppet yet, just by > > > name. > > > For the time being, we use a test instance of Tuleap with some projects and > > > trackers in different configurations for testing. > > > This is not publicly available yet, but we are willing to do what is required > > to > > > ensure the testability of the connector in the eclipse infrastructure. Is > > there > > > a wiki page or something that describes what exists for other connectors, > > beyond > > > the code? > > I'm afraid we don't have any useful documentation. On a high level, we can > fully provision the test environment from puppet manifests. That enables us > to manage the entire test configuration through git and re-create any test > environment in any point in time. It also makes it very easy to modify tests > environment and provision local test environments with vagrant. > > If you want to try it out you can run "vagrant up" (requires vagrant and > virtualbox installed) in any of the connector releng projects. That executes > the same scripts we run on mylyn.org to setup repositories: http://mylyn.org. Thanks for the details. We'll take a look at how other connectors configure their tests environments and try and do it with tuleap.
(In reply to Laurent Delaigue from comment #8) > (In reply to Steffen Pingel from comment #7) > > (In reply to comment #4) > > > (In reply to Sam Davis from comment #3) > > > > I think we might have discussed this on the Mylyn call but I forget: is the > > > > Tuleap connector using the Mylyn SOAP transport > > > > (org.eclipse.mylyn.commons.soap)? This has recently been deprecated and > > > > we're planning to remove it entirely from Mylyn (bug 421379). > > > > > > Yes, we do depend on org.eclipse.mylyn.commons.soap. > > > > > > Actually, it's only to set the AbstractWebLocation in the call properties: > > > > > > call.setProperty(SoapHttpSender.LOCATION, this.location); > > > > > > So it seems to me this dependency is very lightweight. > > > > The dependency on the Mylyn SOAP transport is one aspect. Even if that was > > removed I assume there is still a dependency on the old deprecated Axis 1.x > > library? > > > > The even more so important aspect though is that all contributions that are > > accepted into Mylyn have to go through a code review and I believe in this > > case also through an IP review / CQ (since the connector is larger than 250 > > lines of code and was not created under the supervision of the PMC). > > > > Code and IP reviews are significant efforts so if the contribution included > > the SOAP specific implementation bits we would essentially spent time on > > code that was already scheduled to be removed. From my experience, > > supporting multiple transports also complicates connector architecture which > > also increases effort on the code review. I'd much rather spent the limited > > time we have available for Mylyn development on moving forward rather than > > adding code that isn't going to stick around long term. > > > > Ideally the initial contribution of the Tuleap connector would only have a > > REST transport. Even if that connector is missing functionality that is only > > available through SOAP it would provide value and allow us to accept the > > contribution faster and have a much more maintainable code base. > > > > Can you give us a sense on what the major missing pieces in the REST API are > > at this point and what the rough time line is until a limited but useful > > connector would work over REST? > > > Yes of course, there is a dependency to Axis. > > Currently, the Tuleap REST API allows the retrieval of most of the projects > and trackers configuration (a few things are missing though), and the > retrieval of artifacts by id. > On the contrary, querying and updating artifacts is not yet possible. > > We need to take a closer look at this and discuss with the Tuleap team to > build a time line. We'll comment again here as soon as we have a reliable > vision of a roadmap. Hello, We have been working hard and should be able to deliver a fully-REST connector (i.e. without SOAP) by the beginning of march. It will not be fully functional but it should be significant enough. We have also been working on the testing infrastructure and are still working on preparing VM appliances with correctly configured instances of Tuleap to run our tests. Am I right in saying that all you need is a publicly available URL to retrieve such appliances (from vagrant scripts available in our test plug-ins)?
(In reply to comment #10) > Am I right in saying that all you need is a publicly available URL to retrieve > such appliances (from vagrant scripts available in our test plug-ins)? The optimum is that you can just run vagrant up to provision a test environment locally. That is very useful to anyone working on the connector. To run integration tests and gerrit verification builds we need an actual instance of the VM running that is publicly accessible, i.e. a similar environment to what we have on mylyn.org for Trac, Bugzilla...
(In reply to Steffen Pingel from comment #11) > The optimum is that you can just run vagrant up to provision a test > environment locally. That is very useful to anyone working on the connector. OK, understood. > To run integration tests and gerrit verification builds we need an actual > instance of the VM running that is publicly accessible, i.e. a similar > environment to what we have on mylyn.org for Trac, Bugzilla... I imagined that you would add the Tuleap appliances we would provide to mylyn.org, but now I feel I've been mistaken. So if I get it right, we need to provide a URL where appliances used for verification builds would be available?
(In reply to comment #12) > I imagined that you would add the Tuleap appliances we would provide to > mylyn.org, but now I feel I've been mistaken. > So if I get it right, we need to provide a URL where appliances used for > verification builds would be available? The server is a standard Linux vserver so as long as we can provision Tuleap and as long as mylyn.org has sufficient capacity to run the additional repositories we can do that. We don't have a way to provision full VM images. If that's required or the mylyn.org environment doesn't meet Tuleap's requirements we'd have to find alternatives to host the repository (Eclipse.org offers vserver as well so that could be an option).
Created attachment 240815 [details] Source code of the Mylyn connector for Tuleap As promised, I have attached here the code of the Mylyn connector for Tuleap, now without SOAP and renamed with the "org.eclipse.mylyn.tuleap" namespace. It contains the following projects: 1- org.eclipse.mylyn.tuleap-feature 2- org.eclipse.mylyn.tuleap.core 3- org.eclipse.mylyn.tuleap.core.tests 4- org.eclipse.mylyn.tuleap.doc 5- org.eclipse.mylyn.tuleap.releng 6- org.eclipse.mylyn.tuleap.repository 7- org.eclipse.mylyn.tuleap.server.data 8- org.eclipse.mylyn.tuleap.ui 9- org.eclipse.mylyn.tuleap.ui.tests Both the releng and repository projects would disappear since they are only there in order to build the Tuleap connector without modifications of the existing projects of mylyn. The releng project is just a maven launcher and the repository only contains our feature. I have deactivated the integration tests of the ui.tests project in the pom.xml from the releng project until the Tuleap appliance is ready to be used with Vagrant. We have started to add integration tests using the Tuleap appliance in the ui.tests project. The Tuleap project will improve its Vagrant/Chef support soon to allow us to easily add a Tuleap appliance on mylyn.org (https://github.com/Enalean/tuleap-vagrant). We have worked with Enalean in order to remove SOAP and move fully to REST. We are still tracking the last remaining bugs in the new REST API with Enalean. If you have any questions, don't hesitate. I will also be available next week during EclipseCon NA 2014 if you come there.
Hello, We'd like to know how to move forward to see this code integrated into Mylyn, We've put some effort in moving away from SOAP to RESt and are still working to provide a test appliance of Tuleap. We're at your disposal for any comment or question, any feedback is welcome.
Hi, sorry for the slow response. Is the connector now fully RESTful or does it sill use SOAP for anything?
(In reply to Sam Davis from comment #16) > Hi, sorry for the slow response. Is the connector now fully RESTful or does > it sill use SOAP for anything? Hello, The connector is now fully RESTful and does not use SOAP anymore.
Created attachment 241890 [details] Updated source code of the Mylyn connector for Tuleap Mainly, added attachment and querying support. Requires Tuleap version 6.12
Thanks for attaching the source code. Would you be interested in contributing the connector to Mylyn Incubator? This would make it available on the Mylyn Incubator update site. Mylyn Incubator is not included in Mylyn releases, but we could add the connector to Mylyn Connector Discovery so that it is easy for users to discover and install.
(In reply to Sam Davis from comment #19) > Thanks for attaching the source code. Would you be interested in > contributing the connector to Mylyn Incubator? This would make it available > on the Mylyn Incubator update site. Mylyn Incubator is not included in Mylyn > releases, but we could add the connector to Mylyn Connector Discovery so > that it is easy for users to discover and install. Hello, To be honest, we hoped to join Mylyn tasks directly. Our connector has some history now. We're strongly involved in it and willing to maintain it in the future. We've been reactive to your request of removing SOAP in the connector, which involved quite some work for us and the Tuleap team, work which has been planned as soon as you requested it and performed quickly to provide a convenient connector. We've also been careful about code quality and eclipse standards conformance to provide a high-quality connector. We will definitely continue working on this connector ot make it better and take the community feedback into account. So it seems to me that we meet non-incubation requirements and we'd really appreciate being integrated to Mylyn Tasks directly.
(In reply to Sam Davis from comment #19) > Thanks for attaching the source code. Would you be interested in > contributing the connector to Mylyn Incubator? This would make it available > on the Mylyn Incubator update site. Mylyn Incubator is not included in Mylyn > releases, but we could add the connector to Mylyn Connector Discovery so > that it is easy for users to discover and install. Hi, Is it possible for you to provide feedback this week? Especially, if there are risks for you to accept this contribution into Mylyn Tasks, please let us know which ones so that we can try and mitigate them as much as possible. Our goal is to provide the mylyn community with a new connector and benefit from the feedback of this community, and we're really willing to do what it takes to see this happen :) Thanks in advance!
I appreciate your responsiveness and it does seem like you have good testing processes and standards conformance. The goal of the Tasks project is not to be a collection of connector implementations, but to be a Tasks framework and API with one or two exemplary implementations. Therefore, we are considering moving the Trac connector out of the Tasks project and keeping only the Bugzilla connector in Tasks as the single reference implementation of a connector. In that light, the Tasks project does not seem to be a good fit for the Tuleap connector. Instead, it would make sense for Tuleap to join other connectors in the Mylyn "ecosystem":https://wiki.eclipse.org/Mylyn/Extensions with distribution via the connector discovery mechanism. Having removed the SOAP dependency and given your commitment to maintain it, the Tuleap connector is an excellent candidate for the Connector Discovery listing, and I would be happy to work with you to get it listed. This is a simple process and does not require hosting the connector on Eclipse.org or contributing it to the Mylyn project. However, if you would also like to contribute the connector to Mylyn Incubator we could do that, but I should tell you that I don't foresee the connector being added to Mylyn Tasks as long as Tuleap is not used by the Eclipse project. If you are also interested in making contributions to the Mylyn Tasks framework and working towards commit rights on that project, we would enthusiastically support that and would nominate you once you have made sufficiently many contributions.
Hello, We want to use eclipse.org for all its benefits about process, infrastructure, etc. So, as this connector will be hosted by Eclipse Foundation, and as Mylyn is the Top-Level Project for ALM, what do you propose? Subsidiary question: why didn't you give us this answer about the scope of Mylyn Task when we raised this FR in December? Our main goal has always been to integrate Mylyn Task and we work hard to improve the connector to reach your expectation. Now the connector is ready, and our answer is quite late.
Etienne: We have tried to make the scope of the project and connectors very transparent, listed and linked from the Mylyn Homepage. I apologize if there was some kind of disconnect here. Can you summarize the goals here? We cannot take on the dozens of connectors out there as part of the Mylyn project as that would drown all committer resources in supporting those. This is one of the reasons we created the connecotr install and MPC technology. I could imagine an argument where we could make the Tuleap connector a part of the Incubator. But if we made it part of Mylyn Tasks, we should then also add JIRA, Mantis, etc? We specifically pulled those out as not to drown the project.
(In reply to comment #23) > Hello, > > We want to use eclipse.org for all its benefits about process, infrastructure, > etc. > > So, as this connector will be hosted by Eclipse Foundation, and as Mylyn is the > Top-Level Project for ALM, what do you propose? Please see my previous comment 22. > > Subsidiary question: why didn't you give us this answer about the scope of Mylyn > Task when we raised this FR in December? Our main goal has always been to > integrate Mylyn Task and we work hard to improve the connector to reach your > expectation. Now the connector is ready, and our answer is quite late. I apologise if there was any miscommunication here, but my understanding is that Steffen (who has been away for the last few weeks) discussed with Obeo that Mylyn Incubator was the most likely destination for the connector.
Hi Sam, Mik, Thanks for the feedback and clarifications. 1- We are definitely interested in being available in the Mylyn connector discovery UI. What exactly do you need from us for that? We're absolutely ok to work with you about it and set-up a call if needed. 2- We had imagined that the Tuleap connector would be hosted in eclipse to take advantage of the eclipse infrastructure, processes and so on. We believed that connectors hosted at eclipse were supposed to be in Mylyn Tasks, which we now understand to be erroneous. However, it seems legitimate to want to host a Mylyn task connector within eclipse, and I don't think the appropriate place for such connectors is the Mylyn incubator. Surely there must be a way for a connector provider to host the code in eclipse? Does that involve the creation of a new project? Or sub-project within Mylyn? I'm not saying we are going to do that, I just want to know what are the options if we want to host the code in eclipse, because the Mylyn project looks like the best place to do this. 3- As to making contributions to the Mylyn tasks framework, the need hasn't arisen yet but we're interested and we'll let you know if we have any idea of contribution.
The discovery content is in the org.eclipse.mylyn.discovery-directory project on the org.eclipse.mylyn Git repository. Each connector that is listed just needs to provide a few bits of text such as description and summary, a few screenshots, a web page URL, and an update site URL. Could you take a look at the plugin.xml and push a review to Gerrit which adds content for Tuleap? Let me know if you have any questions. Mylyn connectors could be hosted on eclipse.org without being part of the Mylyn project. An example of such a connector is the GitHub Mylyn connector which is hosted under the EGit project. I am not knowledgeable about the process or requirements for proposing a new Eclipse project but I imagine you can find documentation online.
I pushed review https://git.eclipse.org/r/27299
Thanks. That looks good at a glance; I will give it a proper review later in the week. Once the connector is added to discovery, should we close this bug?
(In reply to Sam Davis from comment #29) > Thanks. That looks good at a glance; I will give it a proper review later in > the week. Once the connector is added to discovery, should we close this bug? Hi Sam, Yes, once the connector is added to discovery, this bug should be closed.
Created attachment 243671 [details] screenshot of discovery listing Here's what it will look like.
The change to add the connector to discovery has been merged. Thanks very much for the contribution!
The connector won't be available from discovery until I publish a new version of the directory, which will happen within the next 2-3 weeks if not sooner.
(In reply to Sam Davis from comment #33) > The connector won't be available from discovery until I publish a new > version of the directory, which will happen within the next 2-3 weeks if not > sooner. Ok, that's great! Thank you very much for your numerous answers and guidance.
Thanks for you patience. I know this was not the outcome you were initially hoping for. If the discovery content (e.g. URLs) ever needs to be changed, please open a bug and push another review.
Thanks. That's a nice solution to target a delivery synchronized with Luna. If we need to go further with contribution inside Eclipse Foundation, we will discuss with you about the best way to do this in another thread. But with this first step in the discovery, we will begin to have feedback from Tuleap and Mylyn communities, and that a good news. For your information, we will announce with Enalean this new connector at ElipseCon France, with demos, poster and press releases.
That sounds great!
Hi, I just tried to install Tuleap in a fresh Luna, and I get a message that the connector is not available. org.eclipse.core.runtime.CoreException: The following connectors are not available: Tuleap (id=org.tuleap.feature.group, site=http://eclipse.tuleap.net/mylyn.tasks/stable) at org.eclipse.mylyn.internal.discovery.ui.PrepareInstallProfileJob.checkForUnavailable(PrepareInstallProfileJob.java:296) at org.eclipse.mylyn.internal.discovery.ui.PrepareInstallProfileJob.computeInstallableUnits(PrepareInstallProfileJob.java:206) at org.eclipse.mylyn.internal.discovery.ui.PrepareInstallProfileJob.run(PrepareInstallProfileJob.java:91) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122) Any idea what the matter is?
I get the same error. Steffen, do you know what would cause this? The update site URL seems to be correct.
I'm not entirely sure if that is still the case but at some point we required a site.xml to be present.
Got it! I gave a wrong ID in my patch to your discovery UI plug-in, which does not match the ID of the feature group we have in our update site. I'll submit a patch to have a correct ID in the discovery UI, and in the meantime I've fiwed the update site by using the ID I used in the patch ("org.tuleap" instead of "org.tuleap.mylyn.task-feature"
It works now, thanks for fixing it!
