Compiling a PDSOE project or program from command line

Posted by dbeavon on 08-Jan-2018 12:36

When I create a project in PDSOE, it may result in a sophisticated PROPATH. 

For example, a simple REST service will result in a .propath file with the following contents.  One of the more interesting pieces to me is the PROPATH entry that was created for the "AppServer" folder (last thing in the sample below).  

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<propath version="11.7" xmlns:xsi="www.w3.org/.../XMLSchema-instance" xsi:noNamespaceSchemaLocation="schema/propath.xsd">
<propathentry env="all" kind="src" output="@{ROOT}\PASOEContent\WEB-INF\openedge" path="@{ROOT}\PASOEContent\WEB-INF\openedge" platform="All"/>
<propathentry env="all" excluding="@{ROOT}/PASOEContent/static" kind="src" path="@{ROOT}" platform="All"/>
<propathentry env="all" kind="dir" path="@{WORK}" platform="All"/>
<propathentry env="gui" kind="con" path="com.openedge.pdt.text.GUI_LIBRARIES" platform="All"/>
<propathentry env="tty" kind="con" path="com.openedge.pdt.text.TTY_LIBRARIES" platform="All"/>
<propathentry env="all" kind="con" path="com.openedge.pdt.text.DLC_PATHS" platform="All"/>
<propathentry env="web" kind="con" path="com.openedge.pdt.text.WEB_LIBRARIES" platform="All"/>
<propathentry env="all" kind="dir" path="@{ROOT}\AppServer" platform="All"/>
</propath>

This "@{ROOT}\AppServer" propath entry is created automatically, and is apparently needed for the "facet" (whatever that is) of the project related to ABL.

My ABL programs within the "AppServer" folder are able to reference each other without explicitly specifying the "AppServer" folder name in the RUN or include statements.  This is apparently because of the way the project uses that .propath file.

How do I go about writing an ABL compilation command or script that compiles from the command line with the same .propath entries as used by PDSOE?  I am getting the following error: ** "MyInclude.i" was not found. (293)

Presumably this is because my compilation from the command line doesn't respect this propath data found in ".propath" .

<propathentry env="all" kind="dir" path="@{ROOT}\AppServer" platform="All"/>


I haven't found any way to tell the COMPILE statement to use the ".propath" of the project in order to resolve unknown source references.

Any help would be appreciated. I'm looking for a solution that is built on the Progress product (not PCT or something like that). I'd also prefer an approach that abstracts away the implementation of the ".propath" file so that I don't have to parse and interpret it myself (ie. let progress do that for me).

Posted by Matt Baker on 10-Jan-2018 10:50

you won't be able to use those classes outside of eclipse.  PDSOE resolves the classpath when the project is opened (or the file is changed), based on knowledge it gathers from eclipse.  PDSOE plugins don't track file locations, but rather resource references.  those are then resolved to absolute files as needed.

the file format is quite simple.  But the locations they refer to can be anywhere as they refer to resource names, not file names.

You need to write your own build.xml file, using PCT tasks if you desire.  Reading the .propath is probably a non-starter unless  you want to create a mapping file that tracks the references for you.

All Replies

Posted by dbeavon on 08-Jan-2018 12:52

Basically, I'm looking to do something like what is described in the following article.  

knowledgebase.progress.com/.../P19325

The current part that seems to be failing is when a source code resource is not found relative to the working directory (ie. it may be found in another folder referenced within the project's .propath file).

Posted by dbeavon on 09-Jan-2018 12:44

It doesn't look like PCT would respect the .propath file of the project either .  I was hoping to find the parsing code but it looks like PCT uses its own redundant PROPATH definitions in the ANT xml.  

At this point I'm assuming that I'm going to have to re-invent the wheel and parse out the .propath (or possibly another file, pasoe.appserver.settings.xml, in the .settings folder).  I guess this is the only way to tell the compiler what needs to be include in the path.

Posted by Stefan Drissen on 09-Jan-2018 16:22

[quote user="dbeavon"]

It doesn't look like PCT would respect the .propath file of the project either .  I was hoping to find the parsing code but it looks like PCT uses its own redundant PROPATH definitions in the ANT xml.  

[/quote]

Since PCT pre-dates PDSOE I wouldn't call PCT's propath 'redundant'. An enhancement to allow PCT tasks to directly use .propath may be easy.

The following may be of use:

community.progress.com/.../11207

Posted by dbeavon on 09-Jan-2018 17:27

Thanks for the pointer Stefan.  I guess what I was really hoping for was that someone could point me to the API that PDSOE itself uses to create its own internal COMPILE statements.  That would probably be the "authoritative" way to derive a valid PROPATH from the project .propath.  If I'm all on my own then I imagine I have to start digging pretty deep in the PDSOE plugin architecture before I'll find the java classes that do this.  Even then, I doubt Progress will support me if I start using that stuff for my own compilation routines (outside of the context of PDSOE).

I saw the PCT stuff on github and it looks like it is still being maintained.  I was a bit surprised that PCT didn't already make use of .propath.

Thanks, David

Posted by Riverside Software on 10-Jan-2018 01:11

I'm still waiting for the patch from Progress development team to handle .propath !

The problem with .propath is not to parse the file and extract the relevant information, but to solve project references. It only contains the project name, not the project directory name.

Posted by jankeir on 10-Jan-2018 03:00

What progress needs to provide is probably not a patch for PCT, but something like nuget, pip, npm, maven,...  As more and more developing is moving towards microservices and containerization instead of monoliths the need for the ability to wire together some pieces like version n of your framework of choice, version x of some  library you need and the actual application logic at build time is only going to get bigger. Putting everything in a single folder structure is feasible as long as the number of projects is limited, but if you are dealing with many small projects this becomes problematic.

Posted by dbeavon on 10-Jan-2018 08:08

I am in favor of having more tooling.  I am always surprised by how much custom tooling an OpenEdge developer needs to create themselves, because nothing is provided by Progress.  This example (being unable to compile projects from the command line) is just one example of many.  

I think PCT is great, because it is built in the community. I suspect it would be hard for Progress itself to keep up and produce every possible tool that was needed in the OpenEdge development community.  What makes me grumpy is that Progress hasn't yet moved to make a few things open source, and hasn't started taking pull requests.  For example, this .propath file issue shouldn't be such a hang-up.  I suspect there could be a path hint of some kind that points to the location of other projects that are used as dependencies.

Back on the topic of the Java API for parsing the .propath into a PROPATH...  Is there someone who can point me to where that stuff sits in a PDSOE installation so that we can inspect it?  All my inter-project references are easy to find, so that will not be an issue on my end.

Posted by Matt Baker on 10-Jan-2018 10:50

you won't be able to use those classes outside of eclipse.  PDSOE resolves the classpath when the project is opened (or the file is changed), based on knowledge it gathers from eclipse.  PDSOE plugins don't track file locations, but rather resource references.  those are then resolved to absolute files as needed.

the file format is quite simple.  But the locations they refer to can be anywhere as they refer to resource names, not file names.

You need to write your own build.xml file, using PCT tasks if you desire.  Reading the .propath is probably a non-starter unless  you want to create a mapping file that tracks the references for you.

Posted by dbeavon on 10-Jan-2018 14:11

So it sounds to me that using Eclipse (interactively) is the only way that Progress gives us to compile anything (or at least any portion of the code that depends on the project's propath configuration.)

That is a bit disappointing. It seems like Progress is missing an opportunity by not having another, automated mechanism. For one thing, compiling a large project in Eclipse can take a very long time (to say the least).

This KB probably needs to be deleted: http://knowledgebase.progress.com/articles/Article/P19325  . The days are gone when compiling ABL was as simple as they make it out to be in that article...

Posted by jankeir on 11-Jan-2018 02:19

The reason I think PSC needs to provide the npm alternative for OE is that it needs to be integrated with PSDOE by default and it needs to be the default way a project is build. Otherwise adoption isn't going to be what it ought to be (the default for everyone and exceptions only when there is a very good reason) and without massive adoption the tool will not be as useful as it could be.

Extra points if it's implemented by adding ABL support to https://bazel.build/  (although I didn't investigate how feasible that is.)  

This thread is closed