Cannot Check Syntax in OE 12.2

Jeff,

Check out this CVP link (video + discussion). This is from a month ago, so there may be some updates since then.

community.progress.com/.../61529

Tim

Okay. I remember seeing that now. I did not realize that it would be forced upon us.

Hi Jeff,

The configuration file is added to each project as a first step to change the project builder in PDSOE and provide a integration point between development and CI environment. Any PDSOE project with this configuration file can be build by a gradle plugin (we'll be releasing soon) as-is, eliminating the need to maintain separate configurations and ensuring similar outcome whether building on a developer machine or CI server.

This addition of this file should not disrupt any existing behavior, in fact there a couple of secondary benefits of this configuration file,

1. The project configuration is now stored as part of project and can be checked-in in source repository. Earlier configurations were stored at workspace level and only way to sustain the configuration was by exporting and then importing worksapce configuraiton,

2. Apart from the compiler options that can be configured through UI, you can specify other options.

This file is just a model of all project specific configurations and is mapped to project specific UI options, you can read more about it at docs.progress.com/.../UBPF-configuration-parameters.html

Let me know if you are experiencing issues due to this, I'll try my best to address any concerns.

First off, I am very excited about this change.

However, taking a closer look, it appears that this change is going to seriously disrupt my ability to push my customers into faster upgrades, because it seems to embed version specific information into the workspace now. It also seriously disrupts my ability to participate in the CVP due to the fact that I now have disruptive configuration in the project space.

The project/source control environment needs to be version agnostic (or at least should be able to) and should get that type of information from somewhere else, where it can be configured once. And PLEASE, no environment variables! (Unless maybe if they can be defined on the workspace level.)

For advocates of the newest releases like me, it is of cardinal importance that the tooling gets its version specific information from the workspace and not the project. In other words, I need to be able to override project specific settings like these outside the source controlled environment, or we risk disrupting entire development teams.

I would have no problem with keeping a small, custom, version specific project in each workspace where I can keep overrides for these files without disrupting the project for those with no overrides.

In fact, where ever I had a say in the design, the build pipelines and configuration always lives in a separate (general, non-OpenEdge) project which quickly stabilize once a version change is adopted. Branching that is normally risk free, because none of its content is intermingled with the day-to-day work being performed.

When I get a preview release or a new version. I set up new work spaces but I import the existing projects. That way I can work and test on the new version while keeping my delivery commitments. When I find any problems, I can easily switch between the work spaces, with the only drawback that I need to do a full build between the versions. This makes it easy to confirm if a problem exists on both versions, if a newer version introduce regression or if a newer version fixed a problem. It also makes it easy to demonstrate cool enhancements in a newer release version to my fellow developers on their own code base, providing practical use cases that are used to increase pressure on their management to upgrade.

The build pipelines, being configured for the correct release, catch me out if I inadvertently use new functionality that is not compatible with the older versions.

After a while, I start pushing for the use of the new version actively. When people have doubts about compatibility and stability, I normally point out that I have been coding and dev testing on the new version since its release already and that much of that code is in production. Bonus for them is that I normally already branched and adapted the build project at no cost to them. :-)

Hi. For me, this file is in my way - I don't need it and have to mark it as derived so it doesn't show up a new artifact. I have a build/compile tool in place already (Roundtable) where my compile information and configurations are stored.

[quote user="Jeff Ledbetter"]

Hi. For me, this file is in my way - I don't need it and have to mark it as derived so it doesn't show up a new artifact. I have a build/compile tool in place already (Roundtable) where my compile information and configurations are stored.

[/quote]

In your case, please consider this as a mandatory file that you need to checkin to your Source Control System along with other files like (.propath, .settings folder etc). It will not come in your way, if you use any other build/compile tool.

Hi. Well, that's the thing. We don't have to check in . propath, .settings. etc. because all of that is already stored and managed by Roundtable. However, those can be ignored easily. It would be great if creating this file were optional.

[quote user="Simon L. Prinsloo"]

First off, I am very excited about this change.

However, taking a closer look, it appears that this change is going to seriously disrupt my ability to push my customers into faster upgrades, because it seems to embed version specific information into the workspace now. It also seriously disrupts my ability to participate in the CVP due to the fact that I now have disruptive configuration in the project space.

[/quote]

This is very concerning. This file is similar to the .propath file in the project. We would like to understand more on why the introduction of a project configuration file would break your way of doing this. We would like to setup a call with you, if you don't mind?

[quote user="Jeff Ledbetter"]

Hi. Well, that's the thing. We don't have to check in . propath, .settings. etc. because all of that is already stored and managed by Roundtable. However, those can be ignored easily. It would be great if creating this file were optional.

[/quote]

If you are using CheckSyntax feature in PDSOE, then you are using PDSOE way of compiling projects which means you require .propath (and now ubpf.config file) to compile. If you dont have .propath checked in, how can two different developers in two different machines use the same project in their local environment?

Jeff, the .propath file gets created automatically if does not exist also so you can probably handle this new configuration file the same way you do with .propath... just ignore it. 

[quote user="Ravi Sankar"] very concerning. This file is similar to the .propath file in the project. We would like to understand more on why the introduction of a project configuration file would break your way of doing this. We would like to setup a call with you, if you don't mind? [/quote]

My source code can be sent to a variety of machines with different environments (Progress versions, paths, db connection configurations, etc.) This means each machine's development structure has to have it's own set of PDS files. This is why I don't track .project, .dbconnect, or other PDS specific files with the source code.

Tooling-specific files / information should be seperate & distinct from the source code and developers should be able to make it part of the source tree or not as they choose. 

[quote user="Ravi Sankar"] In your case, please consider this as a mandatory file that you need to checkin to your Source Control System along with other files like (.propath, .settings folder etc). It will not come in your way, if you use any other build/compile tool. [/quote] 

If the going-forward plan is to add more files like this, my preference would be to have an optional setting in the .project file which points to a directory where other PDS-related tooling files are stored. 

No panic over here. Marking it as derived accomplishes the goal of making it go away as needed. We handle everything else with regards to compilation.

.dbconnections is not PDS specific, at it only contains aliases, the real DB connection string is defined in your environment

.propath is also not really specific.

.project doesn't contain anything, except linked projects, but not sure if they work reliably with openedge.

[quote user="Simon L. Prinsloo"]

First off, I am very excited about this change.

However, taking a closer look, it appears that this change is going to seriously disrupt my ability to push my customers into faster upgrades, because it seems to embed version specific information into the workspace now. It also seriously disrupts my ability to participate in the CVP due to the fact that I now have disruptive configuration in the project space.

[/quote]

It appears that I was wrong and too quick to comment, as the variables in the file that concern me are not used by PDSOE, but only by the external CI/CD tools.

I want to thank [mention:9205dfd6ccb64168b70598b66f36fa70:e9ed411860ed4f2ba0265705b8793d05] for pointing me in the correct direction.

While my deployments are usually assembled from various projects which can normally be deployed on their own, I do believe that these changes holds exciting possibilities for the future enhancements to our processes.

As [mention:e6e9d01b67bb4afe8fd539ea882df2ea:e9ed411860ed4f2ba0265705b8793d05] said before, the intention of this new configuration file is to pull all the project properties to be part of the project artifacts (instead of workspace level metadata) so that the project becomes more portable across developer machines and a common configuration artifact between development and CI environments. Our intention is not to make it Openedge release specific.

We had a call with [mention:18217590d3fa42cca3661c6d1bc5509d:e9ed411860ed4f2ba0265705b8793d05] and thank you Simon for spending time to explain your concerns. After the call, we reliazed that some properties in the file seem to indicate they need to be specified in PDSOE per project and are specific to an Openedge release. Specifically, dlcHome & tmpDir properties.

1. dlcHome is automatically set by PDSOE which at the workspace level. It is the DLC from which PDSOE is opened. It ignores the value in ubpf.config file. This should have been documented clearly and we will fix the documentation. However when you are running in CI environment using our (yet to be released) gradle plugin, you must set this value. By default, the gradle plugin will pick the value from environment variable "DLC"
2. tmpDir is defaulted to a path in file system. This is a bug. This should also be set to the default wrkDir of the DLC by PDSOE. The gradle plugin should pick from environment variable "WRKDIR" or a value to the property. We will log a bug for this and fix it.

In general, we want this file to be portable across machines (between different developer workstations or between development and CI environments) and hence as such should not have absolute paths. It should use either environment variables or relative paths to the project root

• wrkDir property had an absolute path, which is also a bug that we couldn't address in 12.2 timeframe. We logged a bug and will fix it in future releases

Please let us know if you have any other concerns or comments.

Thanks,

Ravi

[quote user="Tim Kuehn"]

If the going-forward plan is to add more files like this, my preference would be to have an optional setting in the .project file which points to a directory where other PDS-related tooling files are stored.

[/quote]

Thank you for the suggestion. We will keep this in mind.