How to deploy only the r-code(and resx) of cls files?

Are you using OEA's build destination (project setting) to indicate the compile location?

You're code doesn't contain any USING src.* ?

Is it possible that your 'src' directory is *not* in your OEA PROPATH?

In our development enironment we *are* currently using the OEA 'Build' destination but it points to a directory *outside* the project tree.

Therefore we have *not* created an 'src' and 'bin' subtree in our project and therefore our paths are the same at developement and runtime.

The reason for this setup was that it is easier to use svn on the entire project (you don't want your objects in svn).

However, we are also not completely happy with this situation since we have to exclude most stuff in the root directory for svn. So in that respect it might be better to somehow svn just the src directory. But how?

Also, the OEA default seems to be to create an 'src' and 'bin' directory in your project. I am not sure what the reasoning behind that is. But if you don't do it you cannot specify the build directory outside the project tree when creating a new project from svn and hence that results in the creation of r-code in the source directories at that point in time. We manually have to remove these .r files after specifying the real build location at a later stage. This is a dangerous step that can get you into trouble when not performed properly.

Is there anyone who can follow this and comment on the best way to set up yoru projects in OEA with svn?

rbf schrieb:
The reason for this setup was that it is easier to use svn on the entire project (you don't want your objects in svn).

Hi Peter,

I can't exactly tell you how it's done (I'm just sporadically using SVN for two customers, I prefer Perforce), but you can define an exclude file mask - I guess in SVN folder properties.

I usually set *.r and Thumbs.db etc. to that list.

Mike

Select a .r in the top level folder, right-mouse click.

Choose Team->svn:ignore

add the *.r pattern recursively

do this for all files you don't want to show as unversioned.

Julian

I am quite aware about how to do svn ignore, but my question is: considering all of the above, what is the best configuration for your project? I am not convinced that subfolders 'src' and 'bin' in each project are the way to go. Refer to the original question in this thread.

A little touchy today, Peter ?

I don't have any project that has a src and bin directory. I keep all the .r in the same source directory, and when it comes to deployment, have written a little script that duplicates the directory structure, copies all non-source files into the structure, and then builds a .pl from all the .r files. When it comes to testing, we have linked a little build program into the mantis bug system which have also linked into svn, so when we check in file it records the changed files into mantis. Our build program scans the notes from mantis and then compile the affected programs, moving them into the test directory structure.

A little touchy today, Peter ? 

It was not meant lilke that at all. Sorry if it came across that way.

I don't have any project that has a src and bin directory. I keep all the .r in the same source directory, and when it comes to deployment, have written a little script that duplicates the directory structure, copies all non-source files into the structure

This is exactly what Build does for you if you set the Static file destination to the same directory as the Build destination.

The only downside is, again, that it includes the contents of the root directory.

 and then builds a .pl from all the .r files.

I don't really need that in the development environment, but it would be nice if Build would support that as well.

 When it comes to testing, we have linked a little build program into the mantis bug system which have also linked into svn, so when we check in file it records the changed files into mantis. Our build program scans the notes from mantis and then compile the affected programs, moving them into the test directory structure.

Well that is another question: I would like the snv server to build everything that is checked in to the test directory structure. Are there other ways to achieve this (if you don't use Mantis)?

In the test directory we don't need .pl files as well, but how do you create those there.

The real build, obviously, occurs after checking out a tagged version but that is outside the scope of OEA I would think.

OEA workspace is fine. It is when we move the r-code to a different folder (we are using RoundTable by the way and the Task just points to the workspace). We use full name for our custom ABL class. We only use USING for the .NET classes.

Note that we dropped the 'src' from the class name since that part is no longer valid for the r-code that are to be deployed. Obviously, the 'r-code' will be in the PROPATH with our deployed code. What forcing Progress run-time to look at 'r-code/src' is something that we want to understand?

Also. can you turn that off class name and path name checking?

-----------------------------------

We found our problem. It was sending the .r one folder deeper than we expected, and the .r codes on the expected location were actually old.

Subversion should be ignoring the r-code.  The OEA builder flags the r-code as "derived" which means that any team system (including rountable) should not even offer to check in the r-code.  You can also manually mark the "bin" directory of your project (or any other resource) as derived in the resource properties dialog.

mbaker wrote:
Subversion should be ignoring the r-code.  The OEA builder flags the r-code as "derived" which means that any team system (including rountable) should not even offer to check in the r-code.  You can also manually mark the "bin" directory of your project (or any other resource) as derived in the resource properties dialog.

Aha that is interesting.

Before I start experimenting with this, can you tell me if it is wise to divide your project into an src and a bin directory? I suppose this means every project in svn will always have single 'src' root directory?

How do you prevent 'src' from appearing in your packages names?

How do you prevent 'src' from appearing in your packages names?

I don't have that in any of my "new" (mainly OO based) projects.

When creating the project using the wizard, choose "Use project root directory ..." for the project layout.

Source directories in OEA are "special" PROPATH entries.  In the new project wizard you can choose to create an 'src' directory as part of the project.  Or you can add one from the PROPATH properties page of the project (second tab).

They are considered root directories of source trees so any class or file created using the wizards will not have the 'src' path created as part of the package name.  The OEA builder also knows how to put the r-code in the right place. If there are no source directories specified for a project the project directory itself is used as the default source directory.  You can have as many source directory entries in your project as you want.  The only restriction is they cannot be nested.

You can have source directories without specifying a build destination.  So you can choose to have a single rcode directory, one for each source directory, or not specify one at all.  If not specified rcode just ends up next to the source file in the same directory.

Before I start experimenting with this, can you tell me if it is wise to

divide your project into an src and a bin directory?

I think the strongest reason for doing so is that it can make deployment easier: you just have to deploy the bin folder once the project/product is built, and not have to go scrounging around the source folder for stuff to deploy (of course, your build scripts will need to do this).

It also allows you to build for different target architectures. For instance, $DLC/tty and $DLC/gui are both built from $DLC/src.

I suspect there are also other tools out there that don't do a good job of filtering out or ignoring r-code or built objects, and so it makes your source folder cleaner.

-- peter

2 Ways.

1. Accept the default package name then remove the src. from your class name later.

2. Remove the src. from the package name then move the class to the desired location.

It would be nice if you can just give the folders right underneath the project a default Package Name instead of always using the path name.

2 Ways.
1. Accept the default package name then remove the src. from your class name later.
2. Remove the src. from the package name then move the class to the desired location.
It

would be nice if you can just give the folders right underneath the

project a default Package Name instead of always using the path name.

You don't need to do either.  If you use (or not use) source directories, the wizards will figure it out.  The new class wizard has a "package root" field.  This is the source directory.  It also has a package field.  The package field will not include the 'src' directory.  If you don't have a source directory then the project will be used as the package root.  When you create the class the wizard will take the package root + package + class + (.cls extension) and that becomes the name of the file resource.  But internal to the class the class name is just package + class.

For example:

1) Create a project named "p1"

2) create a directory in it named "src"'

3) Create a folder under 'src' named "package"

4) In the project properties add the "src" directory as a source directory.

5) In the resources view select the project and open the new class wizard.

You will see the package root should be set to "\p1\src".  Then package will be blank.  Select the 'browse' button on the package field and you will see it only suggests "package".

If you finish the wizard the class name will be "package.class". But the file name will be "p1\src\package\class.cls".

If you skip step 3 you would see the package root field set to "p1" which is the project.  You would also see that that the package selection dialog would suggest "src.package" instead of "package".

In this case, if you finish the wizard, the class name will be "src.package.class".  But the fie name will be the same as above with "p1\src\package\class.cls".

So in both cases the physical file name is the same, but the internal name of the class is different.

So using source directories you can keep source source separate from the r-code, along with keeping it separate from other stuff in your project such as templates or config files or whatever; and at the same time the wizards understand where the source code of your project starts so it suggests the right package names.

The include file and procedure wizards will do the same thing, but in this case it is named "container" instead of "package root" since .p files don't have packages.

mbaker wrote:
4) In the project properties add the "src" directory as a source directory.

For the life of me I can't figure out where to do this.

For the life of me I can't figure out where to do this.

Don't be so careless about your life, rather check page 2 of the Propath editor dialog...

mikefe wrote:
For the life of me I can't figure out where to do this.
Don't be so careless about your life, rather check page 2 of the Propath editor dialog...

Thanks! This is well hidden indeed! I never noticed that tab (maybe the first time I used OEA and did not know what to do with it).

I have asked this many times before, even to TS, but where the heck am I supposed to find documentation fot the kind of stuff explained in this thread?

Sources seem a good option. However if you have multiple sources, OEA always defaults to the first one regardless of what is currently highlighted.