I am starting out with PASOE and its integration with PDSOE, so forgive me if this has been asked & answered before:
I have set up a local PASOE instance with a sports2000 db. It lives in C:\OpenEdge\WRK11\s2k (= ${catalina.base}
I have set up a server project in PDSOE that uses this sports2000 PASOE instance, and publishes from <project root>\AppServer to C:\OpenEdge\WRK11\s2k\openedge.
Under my <project root>\AppServer folder, I have sub-folders \bl, \da, and \utils
The \bl and \da folder have further com\dandh\sports2000 subfolders to correspond to OOABL package names.
My project PROPATH looks like this:
@{ROOT}
@{ROOT}\AppServer
@{ROOT}\AppServer\bl
@{ROOT}\AppServer\da
@{ROOT}\AppServer\utils
etc.
When I publish to PASOE, though, it dumps all the code from \bl, \da, and \utils directly into the ${catalina.base}\openedge folder, and creates a com\dandh\sports2000 folder directly in that folder.
I would like it to create the \bl, \da, and \utils folders and deploy code to there instead - i.e. mirroring my project folders in the openedge folder.
Am I missing something?
I can't comment on the PASOE aspect, but I have to say that I really hate propaths like this where both a top level and subdirectory are both on the propath. And, here you have two levels! This way, you have no idea when you say RUN X.p what level that means ... indeed, it is quite possible to have an X.p at three different levels in your structure. I.e., I find it unsurprising that it gets confused.
When you create a server project in PDSEO, it automatically starts you with @{ROOT} and @{ROOT}\AppServer, if you accept the project defaults.
Ultimately though it doesn't seem to matter how I construct my PROPATH in either PASOE or my PDSOE project, when I publish to PASOE, the folder structure is completely ignored with the exception of creating the folder structure for my OOABL package names. I get all the code dropped into the root publish folder on the PASOE instance.
What you describe sounds like logical collapsing of the propath into a single directory. I.e., read and copy everything from the first directory, then read and copy everything from the second directory with no overwrite, etc. E.g., I used to set up my systems with a run directory for r code, a src directory for standard release source code, and cus directory for customer specific source code with a propath of run, cus, src. That way, it normally grabbed the .r, but if there was no .r then it would get the customer specific source, if any (quite rare in practice), and then look for standard release source code. Within each, there were top level directories for each module like AR and AP and within each of those package directories. If what you describe were done to this organization, one would have a perfectly sensible unified copy with the .r and the .ps in the same directories and cus source replacing any equivalent standard release source. Perfectly sensible, if that is the way it works.
I think your problem is the propath structure. My default expectation would be that you would end up with three copies of everything, one in the root, one in AppServer, and one in AppServer/xx, but maybe it is clever enough to get rid of the duplicates and just keeps the first one.