I am unable to find much documentation in the way of PASOE "modules".
When I create a PASOE project I get a new option in my project management properties. It allows me to manage "modules". See highlight below. This seems to refer to a subset of the project that contains ABL source code.
There is also a readme that is created within a new PASOE project:
Folder structure of this project:
/Source
- Hosts the ABL code.
The ABL code in this folder has the potential to be deployed to the publish folder of ABL application in the PAS for OpenEdge server.
This ABL code is for common business logic and will be shared by all the ABL Services deployed on the same ABL application.
...
I'm not certain exactly how the "modules" should be treated insofar as compilation and deployment are concerned. There aren't a lot of docs about how to compile and deploy them.
Here is one of the few:
It describes the use of PDSOE for managing the modules. But lets say I want to automate the deployment of the module, what is the procedure for that? All I can find is a PDF: http://pugchallenge.org/downloads2019/516_BeyondTheCode.pdf
It isn't totally self-explanatory.
My impression is that I need to compile the "module" and deploy it somewhere on the PASOE server and add it into the PROPATH of the relevant ABL application. Is that right?
By poking around the project, I've found a ".settings" folder and a metadata file of some kind - "pasoe.appserver.settings.xml". I'm assuming that before a deployment I would need to compile the ABL "resources" identified by
/module-content/module/resource[@path]
While I'm compiling, I'm assuming I also need to change my working directory so that all the code is relative to that path. Otherwise I get errors when I'm compiling classes.
Does this make sense? Can anyone describe their strategy for automatically building and deploying their "modules"? I had a strategy at one point but it isn't working well now that I'm being forced to COMPILE code with the SAVE INTO option. If I'm on the right track, I would expect to see google hits for the file, "pasoe.appserver.settings.xml". But there are none.
Does PCT handle the compilation of these types of projects (PASOE projects with "modules")? If so then maybe I'll review their approach.
I poked around in PCT and don't see anything in there that indicates it has special understanding of PASOE projects or modules.
I found a PCT test for "restgen" but that doesn't appear to be related to ABL compilation:
tests\RestGen\test1
>> Modules in PDSOE are deployment things, not compilation things.
In my screenshot, the "Source" folder is considered a "module" and it also happens to be the only part of the project that consists of ABL code so it seemed like a direct correlation. I think I renamed that folder from it's original name (which was "AppServer" as I recall).
I was using the "module" metadata in the ".settings" folder to identify what needed to be compiled, but it sounds like that was misguided.
It sounds like you are saying that the "module" is not necessarily ABL code, although it could be.
I noticed that my "Source" folder is also part of the project's PROPATH. And the ".propath" file seems to be the only remaining clue that might tell me where the ABL source code lives which needs to be compiled. I suppose I could be parsing the ".propath" but that file seems quite messy and noisy.
OK, thanks.
It sounds like there is nothing about the "modules" that tells a compiler toolchain what needs to be *compiled* in this type of project. The "module" metadata in the ".settings" folder was pointing at my ABL source, but it sounds like that was somewhat coincidental.
Is there any compiler tooling out there that knows how to build these types of projects? PCT? gradle? I haven't found anything yet. I'd like to see how others tackle the problem of identifying ABL code and then compiling it. I'm not that interested in third-party products for purchase. Just want a way to compile and package my ABL for deployment. It seems to me that compiling shouldn't cost an additional premium.
Sorry for the late response,
For project compilation settings, you should use project properties -> Build -> Source tab. All this information is persisted in the .propath file. PCT doesn't understand .propath yet. With gradle plugin, upcoming in 12.2, we are adding support to understand this file in a similar way that PDSOE does. So, in general you can have multiple source folders with different output destination (SAVE INTO) per source folder. Example one for source and one for tests.
As Peter said, Module is a eclipse server concept, and is deployment related, not compile. It shows up in the "Add and Remove" dialog in the servers view. By default, PDSOE publishes all Openedge compiled code to $PAS_INSTANCE_HOME/openedge folder. This is not ideal and we intend to change it to adapt to better packaging structures like ABL app (oear) upcoming in 12.2
Thanks for the response. Is the "gradle plugin" going to be open source, so we can see how it handles .propath? There are some really unusual things that are accomplished with that PDSOE file. For example it supports the ability to exclude certain programs from being compiled within a project, even though they are named with a ".p" extension.
I'm unfamiliar with gradle. You call your component a "plugin" but that implies a plugin to gradle, not a plugin to PDSOE. Right? I'm assuming this plugin would be able to be used in an automated compiler toolchain, that had nothing to do with PDSOE, right?
On another note, PASOE projects have been around for quite a while (11.5?). I'm curious how Progress intends for customers to compile and deploy these projects today (in versions 11.7.x). Is the expectation that everyone would do this type of work interactively, via the PDSOE user interface?
Gradle is a build automation tool like ANT. It uses Groovy or Kotlin as the language for writing the build scripts. So, unlike ANT, which uses XML to write logic like copy files, change properties, update configuration etc, you can use make use of a full fledged programming language to write logic. Gradle also has other benefits like repository integration, dependency management etc.
Gradle has a notion of plugins (much like eclipse) to add additional features to the build process. The gradle plugin we are planning to ship with 12.2 will not be open source. It is not an eclipse/PDSOE plugin. We want the customers to use this in the CI environment. Eventually, PDSOE also will use the same Gradle plugin for compiling source code. In 12.2, PDSOE will make use of the same builder as it used in 12.1 & before releases. However, in 12.2, PDSOE will read the build configuration from a configuration file (which is separate from .propath) and this configuration file along with .propath will be understood by PDSOE and the Gradle plugin in a similar way. We will post a sprint demo recording in CVP so that you can get some better idea.
With respect to how the PASOE projects should be compiled and packaged, [mention:9e4ee96fac634b8f91b580e1fb4f7e71:e9ed411860ed4f2ba0265705b8793d05] did a talk in last year PUG/Next. We are in the process of implementing these changes both by PASOE to understand these packaging structures and deploy them and PDSOE/OEM to provide tooling support. Our vision is that the build/packaging should be run in the same way in dev/CI environments. These changes are being done in 12.x releases only.
For 11.7.x, for compilation (and packaging as PL), outside PDSOE, PCT can be used. PDSOE also exposed couple of ANT tasks which can be used for packaging outside PDSOE. However, the packaging support is only for Web applications and custom scripts should be written for packaging ABL applications.
+1 for moving to Gradle. Working with Ant is just awful.
For PASOE compilation & deployment with a .war file in 11.7.x, I have gotten mixed responses on exactly how to use those Ant tasks. The documentation seems to indicate they can run independently of PDSOE, but in my experience it doesn't work properly without some of the output from point-and-click PDSOE. Others have said the output of PDSOE is meant to be the input of the Ant tasks, but I haven't gotten any answers on specifics for that - would you be able to shed some light on this?
Regarding the move toward Gradle, is this meant to replace the PCT build tool? Or will PCT be used inside the Groovy scripts? How will this impact CABL SonarQube builds? I know there is specific output the scanner looks for that PCT generates like listing, debug, xref, etc.
Thanks for the reply. I see that PCT is a really important bridge for customers still using 11.7.x.
Thanks for all the information about gradle. It seems like that will be something of a learning curve. I may hold off on learning PCT for now (and I was already dragging my feet in the first place). It seems like PCT might not be relevant anymore, after Progress starts guiding everyone to use gradle.
It is really unfortunate that you aren't planning on open sourcing your gradle plugin. I don't understand how Progress can piggyback on the massive benefits of open source technologies (Java, Eclipse, tomcat, gradle) and then turn around and decide not share some the pieces of plumbing that relate to the compilation of ABL. Consider, for example, the parsing of the build configuration file in an OE project ... that really doesn't seem like a sensitive trade secret to me! (Or at least it shouldn't be).
Will the gradle plugin be bundled with PDSOE or will there be an additional cost? Are you going to be charging an extra fee to use the plugin *outside* of the PDSOE in automated CI/CD procedures? I suppose the answers to these questions may explain your desire to not open source. Even then I still cannot quite understand the logic ... the compiling of ABL source shouldn't be a premium feature.
[quote user="hutcj"]+1 for moving to Gradle. Working with Ant is just awful.
[/quote]
Thank you!
[quote user="hutcj"]
For PASOE compilation & deployment with a .war file in 11.7.x, I have gotten mixed responses on exactly how to use those Ant tasks. The documentation seems to indicate they can run independently of PDSOE, but in my experience it doesn't work properly without some of the output from point-and-click PDSOE. Others have said the output of PDSOE is meant to be the input of the Ant tasks, but I haven't gotten any answers on specifics for that - would you be able to shed some light on this?
[/quote]
I am aware of some of the queries raised regarding the flow and I agree that our documentation has some gaps to fill. I am afraid I don't know the answers to your queries of the top of my head. I will work with the team to get proper steps to follow for 11.7.x in next week.
[quote user="hutcj"]
Regarding the move toward Gradle, is this meant to replace the PCT build tool? Or will PCT be used inside the Groovy scripts? How will this impact CABL SonarQube builds? I know there is specific output the scanner looks for that PCT generates like listing, debug, xref, etc.
[/quote]
Gradle plug-in will use PCT under the covers for compilation. We didn't want to rewrite what PCT is already doing and doing it well. We added extra functionality on top of it for compile/build task. However it may not be the case for other tasks we intend to add in future. But the thing to note is that PCT interface goes away. User will define the configuration and the build flow logic as Gradle tasks, there won't be any need for writing XMLs. CABL integration with the Gradle plug-in need to be worked out yet. Thanks for pointing it out.
[quote user="dbeavon"]
It is really unfortunate that you aren't planning on open sourcing your gradle plugin. I don't understand how Progress can piggyback on the massive benefits of open source technologies (Java, Eclipse, tomcat, gradle) and then turn around and decide not share some the pieces of plumbing that relate to the compilation of ABL. Consider, for example, the parsing of the build configuration file in an OE project ... that really doesn't seem like a sensitive trade secret to me! (Or at least it shouldn't be).
[/quote]
I will leave the business aspects of the decision to @Oleg but one of things that we considered for our decision to open sourcing is the interest and willingness of people other than progress in contributing to the development of the Gradle plug-in. Since it is the very first release, we chose not to go with open source. Your feedback is always welcome.
[quote user="dbeavon"]
Will the gradle plugin be bundled with PDSOE or will there be an additional cost? Are you going to be charging an extra fee to use the plugin *outside* of the PDSOE in automated CI/CD procedures? I suppose the answers to these questions may explain your desire to not open source. Even then I still cannot quite understand the logic ... the compiling of ABL source shouldn't be a premium feature.
[/quote]
Gradle plug-in is not bundled with pdsoe. It will be a plug-in in Gradle central. It gets downloaded automatically on first use. However it can be used only if you have 4gl development license and works across all openedge supported platforms. It is not priced extra in 12.2.