Evolution (or the lack thereof) and future of the OpenEdge ABL - Forum - OpenEdge Development - Progress Community

Evolution (or the lack thereof) and future of the OpenEdge ABL

 Forum

Evolution (or the lack thereof) and future of the OpenEdge ABL

  • Regarding package management, this is typically taken care of as part of a build pipeline. Almost all pipelines that are likely to adopt whatever package management any one offers at this point uses ant with PCT.

    PCT has Apache Ivy to take care of this. We have implemented this locally and it works fine (we use Sonartype's nexus as repository which is basically a maven repo, but it contains zip files with abl r files in our case). The build pipeline pulls in a zip file for each dependency and flattens the various dependencies into a single tree for the actual run time.

    Basically all that's needed is adding <target name="get-dependencies"><get-dependencies/></target> and xmlns:ivy="antlib:org.apache.ivy.ant" to build.xml and create an ivy.xml file that lists the dependencies:

    <ivy-module version="2.0">

    <info organisation="com.tvh" module="ms-whatever" revision="1.0"/>

      <publications>

      <artifact name="ms-whatever" type="zip" ext="zip"/>

      <artifact name="ms-whatever-full" type="zip" ext="zip"/>

    </publications>

      <dependencies>  

        <dependency org="com.consultingwerk" name="scl" rev="1.0">  

          <artifact name="scl" type="zip" ext="zip"/>  

    </dependency>  

      </dependencies>

    </ivy-module>

    No coding is needed for this, no changes to .pl files, no significant change in the way people work with building,...

    If someone were to set up/host a public repo and write some tutorials it could be a problem from the past. I must admin though that it is not something I am volunteering to do.

  • hehe, get-dependencies is a macro, it takes slightly more but not that much:

               <ivy:settings file="ivysettings.xml" />

               <ivy:cleancache />

               <ivy:resolve/>

                <unzip-dependencies source-dir="@{target-dir}" target-dir="@{target-dir}"/>

    where unzip-dependencies is a macro that does this:

                <unzip dest="@{target-dir}">

                   <fileset dir="@{source-dir}">

                       <include name="**/*.zip"/>

                   </fileset>

               </unzip>

  • +100

  • Personally, I've always liked pretty much everything about Progress and not really fussed about whether it has bolt-on's to be similar to modern languages - its about the speed and ease at which the application can be developed.

    The biggest problem with Progress is purely to do with integration.  Whilst in the past Progress could live in its own world and companies only had one main application to support their business, its a whole inter-connected world out there.  When doing any integration, Progress has always been a sore point.  You can get all other database vendors into a room for applications to integrate with each other, but there will always be a separate 'How does Progress do it' meeting.

    Whether its ODBC, SOAP, REST, SSL, whatever, Progress will not integrate reliably to the same level as other technologies such that you need to look for workarounds which then wipe out the advantages of using Progress to build the application at pace.  

    bprowsdldoc hangs on many WSDLs and the -show10style option needs to be used to get a basic wsdl.  Code pages not supported.  Cipher suites not supported.  All these things make it so that even if you get code working in one instance, a change at the target end and you're looking for workaround solutions - often with other technologies.

    For any kind of capability in the integration area, Progress needs a programme called 'Challenge Progress' or something where you send the endpoints you need to integrate with and either they get it working or they patch it so that it works in the next version.

  • Hi Shao Can,

    Agreed. For example: I've logged a request for a problem in the WRITE-JSON and am waiting for over a year now... such a long waiting time pretty much forces a person away from ABL and into other techniques. Which is a shame.

    Another example is in calling out to a SOAP-service. It has client-side certificates; which is not supported properly in ABL. We have written our own in-between service in JavaScript for this.

  • Hi Shao Can,

    Agreed. For example: I've logged a request for a problem in the WRITE-JSON and am waiting for over a year now... such a long waiting time pretty much forces a person away from ABL and into other techniques. Which is a shame.

    Another example is in calling out to a SOAP-service. It has client-side certificates; which is not supported properly in ABL. We have written our own in-between service in JavaScript for this.

  • Hi onnodehaan.  Yes, that's exactly the kind of thing I'm talking about.  They need to get things like mutual authentication working, good integration with the leading JMS (RabbitMQ) and/or integration via AMQP to messaging brokers.  They need to analyse integration technology platforms in the cloud and ensure that if a Progress system is on one end of the integration, there are options open for integration without workarounds.  All this is the real important stuff.  Without it, there is simply no point unless you're creating isolated standalone applications.

  • I recognize your point about "'How does Progress do it' meeting". That is in fact very true. We have a large customer (hundreds if not thousands of users, 300GB+ database) that uses 5 different ERP-systems within the conglomerate. Granted.. 1 of those systems is very old, but the other 3 are way ahead of Progress in connectivity. That sometimes forces them away from modules in our ERP into the hands of competing ERP-system. In the long run, that's not a sustainable situation. Currenlty its impossible to address those issues with ABL, and unfortunately PSC seems unaware of this problem.