OE Studio / GitHub integration

[Tarby777]

Hi all,

I'm running OE Studio 12.7. I have a couple of OE projects in GitHub that I currently access via SourceTree, which is a GUI wrapper around GitHub. I'm keen to import these projects into OE Studio and do the checkins / checkouts from there instead of using SourceTree. Having searched the PKB, it seems like the EGit plugin for Eclipse is a good way to achieve the integration that I want. Has anyone been down this route?

TIA
Tarby

 

[Ashwani Mishra]

We use Azure to host out openedge repos. These projects are cloned using git bash. We do use Progress development studio (PDS) with egit plugin (4.9.0.xxxx) in progress version 11.7. Should work with 12.x I guess.

Once you install plug-in, you have to follow some steps as mentioned in below link.

Progress Customer Community

community.progress.com

Spending some time on git CLI commands is worth. Try and let me know how it goes.

I might have some documentation which I can try to share.

 

[Stefan]

PDSOE 12.x with EGit works.

PDSOE / EGit can be somewhat frustrating when doing Git stuff. PDSOE often jumps onto files to compile them, locking them resulting in EGit failing due to locked files, leaving a mess in your working tree. When your working tree was clean before you started you can generally (hard) reset the branch with a few tries, if it was not, beware that you do not lose work.

Often, when working on branches with larger code changes, I find it safer to close PDSOE, change branch from Git CLI and then restart PDSOE.

 

[Rob Fitzpatrick]

It looks to me like PDSOE is not the future for OE development. It isn't completely abandoned, like OE Studio, but in my view the writing is on the wall. In Progress' roadmap talks, they talk about supporting Language Server Protocol, which will ultimately allow you to use your IDE of choice rather than being tied to their dev tools, and thus to the Eclipse plug-in ecosystem.

I still use PDSOE for some things, mainly because it is more familiar to me at this point. But for Git integration, comparing commits, examining file history, seeing line-by-line change info, VS Code is so much better for me. And it has a great extension community, so you can add support for just about whatever you need. I use extensions for Git, OpenEdge (OpenEdge ABL from Riverside Software), WSL, remote editing over ssh, hex editing, and more.

I believe that in the near future, I will use VS Code exclusively for ABL development. Years ago, I was behind the curve in moving from OE Studio to PDSOE. I'm not going to make the same mistake this time.

 

[Tarby777]

Thanks all. I really must work on my initialisms. I meant PDSOE when I said OE Studio, but I think you all worked it out

 

[Tarby777]

PDSOE 12.x with EGit works.

PDSOE / EGit can be somewhat frustrating when doing Git stuff. PDSOE often jumps onto files to compile them, locking them resulting in EGit failing due to locked files, leaving a mess in your working tree. When your working tree was clean before you started you can generally (hard) reset the branch with a few tries, if it was not, beware that you do not lose work.

Often, when working on branches with larger code changes, I find it safer to close PDSOE, change branch from Git CLI and then restart PDSOE.

Thanks Stefan. Can that auto-compilation be avoided if you uncheck all the 'build automatically' / 'compile on save' (etc) settings in the project?

 

[Stefan]

Thanks Stefan. Can that auto-compilation be avoided if you uncheck all the 'build automatically' / 'compile on save' (etc) settings in the project?

Eclipse General / Workspace preference 'Refresh using native hooks or polling' combined with build automatically is a major file locker, but this stuff is useful for normal work, it can just get awfully in the way when changing branches.

With 12.5+ there is even more tooling building models of your code.

 

[peterjudge]

In general terms, I don't use Eclipse's SCM plugins. They always seems to clash with each other (SVN and ClearCase in particular). I use a standalone tool for SCM and Eclipse for coding.

With VS Code the integration seems better thought-out and/or implemented, and SCM seems more of a first-class citizen in taht IDE>