This Question is Assumed Answered

1 "correct" answer available (5 pts) 14 "helpful" answers available (3 pts)
6 Replies Last post: Feb 8, 2008 10:46 AM by phil

When PCURL to include DOC's the mainfest must have the name "manifest.mcurl"

Jan 31, 2008 8:36 AM

Click to view rshiplett's profile MVP rshiplett 29 posts since
Oct 17, 2007

With our many applets, the MCURL manifests have names unique to the project ( yes, the evil edit to the CPRJ file )

{project
version = 1,
manifest-location = "manifest.mcurl",
api-version = "6.0",
compiler-directives = "careful? = true",

But could we lose this INSTALL DOCs restriction and have the script look to what the MCURL contains to which you point when you want to add docs?

In most respects our docs viewer features are so smart ( 6.0 docs viewable for 6.0 project, 5.0 docs viewable for 5.0 project ) and then this little hitch when installing docs created from projects not named project.cprj and with a manifest not named "manifest.mcurl"

The choice of manifests means not having to mess with which packages you have in a project when using such things as QTP

We offer something similar with our choice of build 'target' in that same CPRJ file.

Thanks

Click to view rshiplett's profile MVP rshiplett 29 posts since
Oct 17, 2007
1. Re: When PCURL to include DOC's the mainfest must have the name "manifest.mcurl" Jan 31, 2008 8:42 AM
Also a little odd:

{curl 6.0 manifest}
{manifest PROJECT}
{delegate-to MY.UTIL,
location = "../MY-UTIL/util-manifest.mcurl"
}

does not indicate that the mainifest in use for this project is not called "manifest.mcurl" and the PROJECT is not in a CPRJ named "project.cprj"

This might be handy to add when writing to the CPRJ.LOCAL when the project closes since MCURL files allow arbitrary meta-data in the {manifest} macro.

In my case I must manually add

  • the actual file name of the manifest
  • the actual name of the project CPRJ file for which this is a manifest

thanks
Click to view rshiplett's profile MVP rshiplett 29 posts since
Oct 17, 2007
2. Re: When PCURL to include DOC's the mainfest must have the name "manifest.mcurl" Feb 3, 2008 10:03 AM
in response to: rshiplett

The best example where the name is not manifest.mcurl is in the /Curl/IDE folder itself, where the manifest is named

curl-manifest.mcurl

You might notice that in this {manifest} the PCURL files are not named

"load.pcurl"

but have meaningful names such as

"CURL.IDE.CONTROLS.pcurl"

which is always a good practice especially is you use Eclipse + SVN + ant scripts with {pcurl-file} in XCURL scripts.

Click to view phil's profile Curl phil 28 posts since
Oct 17, 2007
3. Re: When PCURL to include DOC's the mainfest must have the name "manifest.mcurl" Feb 4, 2008 2:09 PM
But could we lose this INSTALL DOCs restriction and have the script look to what the MCURL contains to which you point when you want to add docs?

Right now that would be hard to do since the doc support code doesn't keep track of the names of installed manifest files. "Installing" documentation consists of copying over the directory.

In most respects our docs viewer features are so smart ( 6.0 docs viewable for 6.0 project, 5.0 docs viewable for 5.0 project ) and then this little hitch when installing docs created from projects not named project.cprj and with a manifest not named "manifest.mcurl"

The choice of manifests means not having to mess with which packages you have in a project when using such things as QTP

I'm not sure what project names have to do with this issue, the documentation installer doesn't deal with project files.
Also I don't understand your description of why this would be a useful feature to have, could you provide an example?
Click to view phil's profile Curl phil 28 posts since
Oct 17, 2007
4. Re: When PCURL to include DOC's the mainfest must have the name "manifest.mcurl" Feb 4, 2008 2:18 PM
in response to: rshiplett
rshiplett wrote:
The best example where the name is not manifest.mcurl is in the /Curl/IDE folder itself, where the manifest is named

curl-manifest.mcurl

You might notice that in this {manifest} the PCURL files are not named

"load.pcurl"

but have meaningful names such as

"CURL.IDE.CONTROLS.pcurl"

which is always a good practice especially is you use Eclipse + SVN + ant scripts with {pcurl-file} in XCURL scripts.

Currently the IDE tools are designed to support projects named "project.cprj" and manifest files named "manifest.mcurl". It's true that the IDE uses a non-standard manifest name, but this is mostly for historical reasons, and isn't intended to suggest that this is an OK thing to do for your own projects.

Regarding the pcurl files, you can call your package load files anything you like and they should work OK. In the IDE's case all the files are named "load.scurl". By passing an additional argument to pcurl-file we can produce pcurl files with package names such as CURL.IDE.CONTROLS.pcurl. You can probably do the same thing yourself using ant or Make or whatever build system you choose.
Click to view rshiplett's profile MVP rshiplett 29 posts since
Oct 17, 2007
5. Re: When PCURL to include DOC's the mainfest must have the name "manifest.mcurl" Feb 5, 2008 9:19 AM
in response to: phil
Our projects now rely heavily on this 'feature'

Dozens of files all named "project.cprj", "manifest.mcurl", "load.scurl" and "load.pcurl" is a non-starter when programming-in-the-large as much as using subdirectories to store alternate "start.curl" files would be if we were required to do that.

My most recent example is with automated pcurl'ing of multiple projects in eclipse/SVN/ant because of the inherent weaknesses in our current IDE 'deploy' approach.

By way of analogy, imagine SUN telling java developers that all JAR's will now be called java.jar and known only by their external path ... if you have ever maintained customized JAR's you will know that it is bad enough that all manifests are called MANIFEST.MF and reside in /META-INF ...

Not at all Curl-esque ;-)

Click to view phil's profile Curl phil 28 posts since
Oct 17, 2007
6. Re: When PCURL to include DOC's the mainfest must have the name "manifest.mcurl" Feb 8, 2008 10:46 AM
in response to: rshiplett
I don't think this situation is analogous to jar files.. I would say a .pcurl file (or a .car file) are the closest to java .jar files.

It's better to think about the project's directory as its name instead of the project.cprj file. This is the same way that many other IDEs, such as Eclipse, work. In Eclipse each project is in a different directory and project metadata is stored in a file with a fixed name (".project").

Putting each package in its own directory is also recommended. Most Java compilers & VMs enforce this rule by using the file system tree to look up packages.

It's true that in curl none of these things are required and you are free to name things as you like. But the tools we provide are designed to work with projects that follow our conventions...

Could you describe in more detail what problems you ran into using the IDE's deploy operation to automate pcurling? There are ways to deploy from the command line, if you want to deploy targets as part of an ant/make/etc build script.