We are using .INI files to set the PROPATH because we can maintain those centrally and can use them both inside and outside of OEA.
However, when setting the -INI startup parameter for this in OEA it works for RUN commands but not for the 'edit' session. The 'edit' session uses the PROPATH defined in OEA, whether I like it or not. Is there a way around this?
Or perhaps we should forget about both options and start setting the PROPATH programmatically?
All the tooling in OEA relies on the data from the .propath file. If you set the PROPATH programmatically then stuff won't work right. Context assist, file open (ctrl-click on include reference), outline view, quick outline, source directories, build destinations, and lots other stuff all get their path information from this one file.
The .ini does not have a rich enough data structure to supply all the information needed by the development environment.
There is no way around this for the OEA project environment. You could write a small script that converts the PROPATH in the .ini to a .propath file. There is a schema file for it in the com.openedge.pdt.text_/schema/ directory.
Well if that is the case I can live with that. So we can and should get rid of the .INI files altogether, since they exist mainly for the purpose of setting the PROPATH at the moment. Too bad we still need them outside OEA.
The question that remains is: how can we centralize maintenance of the .propath file? The same question applies to the .dbconnection file. I am assuming that each developer needs to have a private workspace.
The question that remains is: how can we centralize
maintenance of the .propath file? The same question
applies to the .dbconnection file. I am assuming that
each developer needs to have a private workspace.
Use the SCM tool of your choice to distribute .propath, .dbconnections and project.xml.