The tutorial does not cover configuration issues.
Java service development is idential on Windows vs. UNIX servers except for obvious OS-specific things like pathnames.
If you started developing your empList service in another folder and then renamed or moved it, you might be confusing things.
You might also want to follow a more standard naming convention for folders. It is not a best practice to put flows, java services, adapter services, doc type defns, etc. into one top level folder.
I usually make a folder for each type of IS compenent under some reasonably clear folder/subfolder structure that identifies the functional domain of the package.
PackageName: = AcmeCoHR
|— adapterServices (for JDBC, JMS, etc.)
|— adapterNotifications (for JDBC, JMS, etc.)
|— docs (document type definitions specific to this package)
|— flows (Flow services)
|— java (Java services)
|— triggers (IS triggers)
I’m sure others have their preferred method of naming folders. The main thing is to pick a logical structure, document it and follow it consistently.
One downside of my approach is that the source file that gets created from java services get called “java.java” which is a bit goofy. I supposed one could add addiitonal sub-folders under the “java” sub-folder to fix this side effect.