Anyone Using 3rd Party Plugins with OEA - Forum - OpenEdge Development - Progress Community

Anyone Using 3rd Party Plugins with OEA

 Forum

Anyone Using 3rd Party Plugins with OEA

  • Is anyone using third party plugins with OpenEdge Architect? This might be anything from the JDT to a hex editor plugin.

  • Yes, ProRefactor, at least experimentally.

    What is your question?

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Yes, we use Subclipse for Source Control Management. We had no problems so far.

    Easy to install and easy to use.

    Subclipse is the Eclipse Plugin for Subversion.

    It's mostly the same as CVS.

  • Hi Matt,

    a very general question...

    I have successfully used OEA with the Eclipse Plugins for the Perforce SCM System (P4WSAD or P4Eclipse). XML Spy comes with great edit and visualization plugins for all types of XML documents including XSD, WSDL.

    I have used the JDT and PDE and developed simple plugins that communicate with the 4GL runtime on my own (display session information, persistent procedures like in ProTools).

    Mike

  • Additional questions:

    Has anyone had any issues mixing OpenEdge Architect with 3rd party plugins? Either putting the OpenEdge plugins into their own environment or adding things such as the JDT or PDE into the OpenEdge environment.

    Does anyone have any advice for someone who might be trying to do this, or perhaps a set of suggestions of things to look out for? I would hazard a guess that there would be ABL developers out there who would who like some additional functionality that doesn't come in the box, but is available in the general Eclipse community. Eclipse is a large product, and we only ship the basic pieces of it.

  • Feedback from my experience during this really cold sunday :

    I'm using Eclipse since version 2, so long before OEA was released, and always kept up to date in order to use WTP plugin (web tools platform, used for JSP and Faces development) and a few others (mainly Mylar and Subclipse).

    I'm currently using Eclipse 3.2 with JRE 1.5, and I wanted to integrate OEA in this. Had to hack a few things, which I will summarize later.

    One of my issues is to be able to upgrade plugins and revert to previous version if it's too buggy (mainly for WTP, as there's a lot of development and releases aren't always stable). So here are my steps to install (Win32) :

    • Create dirs : C:\Eclipse which will hold eclipse core, and C:\EclipsePlugins which will hold external plugins (one dir for every plugin)

    • Unzip Eclipse SDK in C:\Eclipse

    • Unzip Mylar in C:\EclipsePlugins

    • Create dir C:\Eclipse\links, and create a file in this dir called 01-Mylar.link

    Only one line in this file : path=C:
    EclipsePlugins
    Mylar

    At this stage, directory structure should be like this :

    - C:\Eclipse

    -- features

    -- Many dirs and files here...

    -- links

    -- 01-Mylar.link

    -- Add other files here

    -- plugins

    -- Many dirs and files here...

    - C:\EclipsePlugins

    -- Mylar

    -- Eclipse

    -- features

    -- plugins

    -- Any plugin

    -- Eclipse

    -- features

    -- plugins

    Start C:\Eclipse\eclipse.exe and watch your plugins loaded

    Changing a plugin's version is just a matter of seconds, as you only need to change the path in *.link files.

    And now the OEA part :

    • Create a C:\EclipsePlugins\OEA dir, with correct structure, and copied every com.openedge.* dirs from %DLC%\oeide\eclipse

    • Add a file called OpenEdge.link in C:\Eclipse\links

    • Start Eclipse : everything is OK, except for one thing : openedge properties for a project can't be saved, as there's a problem with DomBuilder class not found (class not present in JRE 1.5).

    • Here comes the hack : I decompiled com.openedge.pdt.text.project.ProjectPropath and modified convertEntriesToDoc method so that it doesn't use DomBuilder object. Compiled again, deployed in progresside.jar and now everything is fine !

    So back approximately on the topic : I'm using OEA in an outside Eclipse 3.2 instance without any problems. I sometimes get OutOfMemory problems, but I can't say if they come from OE and any other installed plugin.

    One suggestion : check compatibility with JRE 1.5 and Eclipse 3.2 It would be nice to be able to drop the plugin and have it work without tweaking classes

    Regards,

    Gilles QUERRET

    PS : I just saw this thread ( http://www.psdn.com/library/thread.jspa?threadID=2122&tstart=0 ), which is more or less what I'm talking about.

    PS2 for Matt Baker : a long time ago, it was perhaps planned to integrate PCT (progress plugin for Ant) within OEA. Is it still planned or completely dead ? You still have your write access to the repository

  • I solved my out of memory problems by adding

    -vmargs -Xmx1024m -Xss2M

    to the shortcut.

    I decompiled com.openedge.pdt.text.project.ProjectPropath and modified convertEntriesToDoc method so that it doesn't use DomBuilder object. Compiled again, deployed in progresside.jar and now everything is fine !

    Can you tell me more about this? I had a problem a while back where I couldn't modify the PROPATH on a project without getting a DomBuilder error. That was fixed by doing a fresh install. Now I have done a fresh install again and moved to SP02 and the problem is back. I have opened a tech support call on it, but haven't heard from them yet.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • I solved my out of memory problems by adding

    -vmargs -Xmx1024m -Xss2M

    to the shortcut.

    Already done this. I suspect a memory leak in a plugin, but as I'm using many plugins, I don't want to spend time to isolate the faulty plugin

    DomBuilder is an implementation specific class which shouldn't be used by external classes. Especially, DomBuilder is present in JRE 1.4 and was removed in JRE 1.5. I replaced the code of convertEntriesToDoc(List) method to use implementation-independant code.

    Drop me a mail at g.querret AT gmail.com if you want the corrected jar (don't know if PSC would be happy to see different versions around the net...)

    Gilles QUERRET

  • Gotta love the fact that java is so easy to uncompile. What tool did you use?

  • Giles, your version seems to fix the problem! Thanks. Now if we can only get PSC to figure it out.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • I have OE Arch running with a whole gaggle of 3P plug-ins, some of which I lightly use and many of which I haven't used at all yet:

    JDT

    CVS

    Subclipse

    Data Tools Platform

    FTP and WebDAV support

    J2EE Standard Tools

    C/C++ Development Tools

    JavaServer Faces

    JUnit

    Orangevolt XSLT

    TPTP Monitoring Tools

    UML2

    WST

    XForms (from IBM alphaWorks)

    Ruby Development Tools

    Mozilla Rhino

    Sonic Workbench 7.0.1

    So far, no known problems except that after I installed Sonic WB, I had to reset the defaults for the OE Editor perspective for some reason. Also, occasionally the Eclipse JVM refuses to start and raises a dialog box, but after several more tries it works. I don't know if this is due to the presence of 3P plug-ins or other factors.

    However, in response to warnings from the PSC Product Managers about mixing OE Arch with other plug-ins, I installed OE Arch as an Eclipse extension relative to my separate, primary Eclipse 3.2.1 installation. (The Eclipse Help describes how to do this.) Then, I can either use OE Arch with my main Eclipse environment, or start it from the OpenEdge menu separately as shipped by PSC. Best way to 'have your cake and eat it too', I would say. PSC should say this in their documentation.

  • Gotta love the fact that java is so easy to uncompile. What tool did you use?

    Java decompiler : http://www.kpdus.com/jad.html

    Using JadClipse ( http://jadclipse.sourceforge.net/wiki/index.php/Main_Page ) you can decompile on the fly in your favorite IDE !

    BTW, there are obfuscators out there, which unlike xcode don't encode source files, but obfuscate class and variable names so that it's really hard to understand anything. But I'm sure PSC wouldn't have any interest in using them...

  • Giles, your version seems to fix the problem! Thanks. Now if we can only get PSC to figure it out.

    Nice to see it works ! I only have access to the corrected source code at home, so I'll post it on my website this evening if PSC is interested (but correcting it by yourself is a matter of minutes).

  • Not sure if PSC still requires your fix...

    AFAIK OpenEdge Architect in OE10.1B (December 2006) will be based on Eclipse 3.2

  • AFAIK OpenEdge Architect in OE10.1B (December 2006) will be based on Eclipse 3.2

    It's a JRE 1.5 problem, not an Eclipse 3.2 problem.