Any interest in contributing this to eclipse foundation for use in base Eclipse IDE ?

[maxandersen]

Hey, any interest in contributing this to eclipse foundation so we can use it in base Eclipse IDE ?

We got a new json editor for Mars - would be great to see a yaml editor too.

[jgangemi]

not to thread jack, but where can one find this json editor for mars?

[oyse]

What would be required to contributing this to the Eclipse foundation?
11. mar. 2016 09:15 skrev "Max Rydahl Andersen" notifications@github.com:

Hey, any interest in contributing this to eclipse foundation so we can use
it in base Eclipse IDE ?

We got a new json editor for Mars - would be great to see a yaml editor
too.

—
Reply to this email directly or view it on GitHub
#37.

[maxandersen]

@jgangemi it is in Eclipse WTP for Neon (https://bugs.eclipse.org/bugs/show_bug.cgi?id=471820)

@oyse basically, find which project at eclipse it makes sense to have it in - my first suggestion would be in WTP, you sign the CLA for Eclipse (it is a click of a button), then you open a bug outlining the contribution to see if interest, submit it as a gerrit patch set and we open a so called CQ to get it cleared by Eclipse legal team. You only have 4 people listed on contributor list thus assuming they can be identified as having donated the work under EPL I believe all should be fine for the main source code.

Its only if there should be problems with any of your third party dependencies it might be tricky - but snakeyml is under ASL so assuming they are good we should be fine there too.

The biggest hurdle is to make sure it isn't just dumped and everyone leaving the project unmaintained afterwards ;)

[mickaelistria]

@oyse I'd like to add more concrete technical actions, additionally to what @maxandersen says. To get started, it's just a matter of pushing a patch and make it "good enough", then all the IP stuff and other will be taken care of by other contributors.
To do so, the simplest may be to install the EGit/Gerrit plugins for Eclipse IDE, but I don't use the Gerrit one much, so I'll give you more CLI-oriented steps:

1. Go to https://git.eclipse.org/r/#/admin/projects/sourceediting/webtools.sourceediting and login using your Eclipse community account.
2. Clone the webtools.sourceediting repo using URL (https or ssh) seen on the page.
3. Put your stuff in, mimicking similar components such as json editor
4. Push it to gerrit using git push origin HEAD:refs/for/master.

Then a conversation will start with the project maintainers. Please share the URL of the review on this GitHub issue when Gerrit review is created so other interested parties can get into the conversation to provide more guidance.

Thanks in advance!

[kdvolder]

but snakeyml is under ASL so assuming they are good we should be fine there too.

And it is already in orbit as well.

On Mon, Mar 14, 2016 at 3:49 AM, Mickael Istria notifications@github.com
wrote:

@oyse https://github.com/oyse I'd like to add more concrete technical
actions, additionally to what @maxandersen
https://github.com/maxandersen says. To get started, it's just a matter
of pushing a patch and make it "good enough", then all the IP stuff and
other will be taken care of by other contributors.
To do so, the simplest may be to install the EGit/Gerrit plugins for
Eclipse IDE, but I don't use the Gerrit one much, so I'll give you more
CLI-oriented steps:

1. Go to
   https://git.eclipse.org/r/#/admin/projects/sourceediting/webtools.sourceediting
   and login using your Eclipse community account.
2. Clone the webtools.sourceediting repo using URL (https or ssh) seen
   on the page.
3. Put your stuff in, mimicking similar components such as json editor
4. Push it to gerrit using git push origin HEAD:refs/for/master.

Then a conversation will start with the project maintainers. Please share
the URL of the review on this GitHub issue when Gerrit review is created so
other interested parties can get into the conversation to provide more
guidance.

Thanks in advance!

—
Reply to this email directly or view it on GitHub
#37 (comment).

[oyse]

Some questions:

• How is the release process after being included as part of an Eclipse project? Is it focused on the yearly release or could releases be quicker than that?
• How is the infrastructure for pull requests when being part of an Eclipse project? A good thing with hosting on Github is that the barrier of entry for contributors is quite low.
• What is the mentoring capacity of the Eclipse project to bring the project up to a higher level of quality? Especially in terms of setting up a good build process, dependency management etc.

[kdvolder]

Question from someone already consuming YEdit as a dependency (at Pivotal we are using it in STS to support spring-boot yaml properties editor and cloudfoundry manifest.yml editor).

How will this rebundling YEdit into WTP affect existing consumers? I hope care will be taken not to make installing WTP a requirement to consume YEdit as dependency. I hope it can retain its 'identity' as a separate bundle with no dependencies on WTP infrastructure (even if it becomes 'officially' a part of WTP).

The editor is useful all by itself and really not specific to 'web tools'. Many formats are based on yml and not all of them are 'webby' things. Forcing people to install WTP to get the editor would not be a good thing I.M.O.

To be honest I'd be more comfortable if Yedit didn't become part of the 'WTP beast' and remained a small independent project.

[kdvolder]

On the positive side... having YEdit be under eclipse umbrella somehow, would help it become more 'mature' and easier to consume for us in some ways. (E.g. the fact is that right now we build our own version of YEdit because otherwise the artifacts are not signed properly). Eclipse build infrastucture will fix those kinds of issues.

[maxandersen]

@kdvolder WTP already has plenty of small independent separate installable projects. We could still expose an eclipse marketplace entry for it.

About releases - then if you are part of eclipse release train you ship every 2-3 months into the release train.

If you want to do builds more often you can do that - it just won't be in the major release train - but this is something we are working on improving, or at least make an option for projects.

How often do you want to release ? looking at release tags it seems you are doing about the same.

Note, WTP is just one possible place - its just my preference since then we don't need to setup a new build process or release engineering - it just takes part of existing 'machinery' so to speak.

[maxandersen]

@kdvolder btw. we are also consuming yedit, actually currently through our usage of springIDE - we would prefer to get it from an actual shared install rather than pivotal custom built one :)

And if yedit was in WTP (or at least eclipse foundation release train) it would be possible from cloudfoundry tooling to provide a yaml editor.

We got similar interest - OpenShift/Kubernetes supports both json and yaml support - and again, springIDE has a different build than the one from yedit updatesite...would be great if we got that into a more consumable/stable place. Win-win for everybody I think!

[mickaelistria]

How is the release process after being included as part of an Eclipse project? Is it focused on the yearly release or could releases be quicker than that?

WTP is traditionally on 1 feature + 2 maintenance yearly release. However, that's something that can be adapted: we could make some WTP components have their dedicated releases schedule and site.

How is the infrastructure for pull requests when being part of an Eclipse project? A good thing with hosting on Github is that the barrier of entry for contributors is quite low.

WebTools uses Gerrit (which is awesome once you tried it, but it requires some learning to do it well; compared to GitHub pull request that require low learning - to usually do it wrong ;).

What is the mentoring capacity of the Eclipse project to bring the project up to a higher level of quality? Especially in terms of setting up a good build process, dependency management etc.

Those are very high, and that's how Eclipse IDE is still there and sustainable. Most of the quality level simply comes by the diversity of the community: more people with different goals/scopes/cultures will follow the development and speak up if there is something that is not good in their standard of quality. The simple fact the people speak up improves things.
About build process and infrastructure, there's Gerrit for code review, Jenkins to run builds and tests on incoming patches and to run "snapshot" tests that allow to deploy snapshot build as soon as code is merged, there's SonarQube to report code quality metrics, dependency management is secured by the IP team so as long as you follow some rules (project mentors can help to teach them) then you're totally "safe" in term of dependency management...

Also, instead of getting into WTP you can consider bootstrapping a new project, independent from WebTools, to get more freedom about infrastructure (Eclipse.org allow projects to be on GitHub and use PRs) and release schedule. But creating a new project requires more effort: there is a proposal to write. I guess people in this conversation would be ready to help and to take a share of the work if you prefer that way.

[oyse]

Thanks for your great input. I will start the process and then we can take it from there.

@kdvolder I share your concern with regards to depending on YEdit means that you need to depend on a big project like WTP, but it seams like this is solvable so that YEdit can become a separate dependency. I think that should be goal in this process.

[oyse]

I have started the process now and lets see how it goes. I have uploaded the changes as a draft for the moment: https://git.eclipse.org/r/#/c/69787/

Let me know if there are any problems with getting access to it. I guess I probably have to add you as reviewers.

I have not uploaded the feature or site part of repository as they might be simpler to just do from scratch.

There are also some things we need to take care of in terms of licensning. Most of the code is written by me, but not every single line. This means that the current change actually does not conform to the Eclipse CLA as I can't sign of on other peoples code. We need to make sure that this is taken care of in a good way so that we do not do quite a bit of work and then run into legal trouble in the end.

[mickaelistria]

Wow, thanks a lot!
As it's a draft, I currently cannot access it. Do you think it would be possible to publish it as a regular review?
What you can do to make sure we don't go too fast with the legal is to put an explicit comment on the Git commit message such as "DO NOT MERGE: requires IP checks".
Also, you could open a bug ( https://bugs.eclipse.org/bugs/enter_bug.cgi?product=WTP%20Source%20Editing ) to track this contribution - organisation, IP, releng, subtasks...-, then send an announce to the wtp-dev@eclipse.org mailing list . I can do it if you're not subscribed.

[oyse]

I have published the changes now. Can you check if you have access?

The releated bug can be found here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=491050

Feel free send out an announcment on the mailing list.