I made some test sequences and a workspace in TestStand. I want to deploy those sequences and make a MSI based executable. However, I am not sure how can I include the files for Simple or Full Featured UI into the workspace and include it during deployment or call the UI content folder directly during the deployment.
Can anyone please help me?
Just insert folder with custom user interface into workspace https://www.ni.com/docs/en-US/bundle/teststand/page/tsref/infotopics/db_add_file_to_wksp.htm.
Then you will see inserted files in Deployment Utility.
But better practice would be to separate installers of user interface, and sequence itself. Because mostly you will do more changes/updates/fixes to sequence files, so you will need to redeploy just them.
This is a big undertaking, but may be worth it for you depending on the size of your company. TestStand has an API that you can use to develop a custom GUI. That GUI can then open any sequence file you like after being compiled as a C program that runs as an executable file.
I'm trying to find all of the (javascript) resources located on a specific site.
What would be a efficient way of finding them?
Everything I could think of is bruteforcing every possible name and check whether there's a file with this name at the server, although this isn't exactly that efficient.
Yes you can do this. The thing which you actually want to do is web directory traversal..
It is a kind of web vulnerability which is usually taken in to consideration by the web master so you get 403-Forbidden or 404-Not Found Error. Manual exploitation on this is surely possible with trial and error basis in case u get to know directory that contains .js files. For automation You can take use of Python/Perl for ease of use. I am personally working on a same project targeting the same objective using PHP and cURL. At very present I can not help about any source code but for sure I'll be posting same.
When I try to generate a javadoc, using the menu command Project\Generate Javadoc, the following warnings and error are produced for my custom classes in XPages:
javadoc: warning - No source files for package net.focul.utilties
javadoc: warning - No source files for package net.focul.workflow
javadoc: error - No public or protected classes found to document.
The packages are in the WebContent/WEB-INF/src folder which is configured in the build path and are selectable in the Generate Javadoc wizard. The classes are public with public methods.
Javadocs are generated for all of the Xpage and Custom Control classes if I select these.
You're experiencing this behavior because javadoc doesn't understand the Designer VFS (Virtual File System). It assumes that your project consists of a bunch of separate files in some folder structure on your local hard drive, not self-contained inside a single NSF. On the whole, the Designer VFS successfully tricks Eclipse into believing it's interacting with local files by intercepting read/write requests for project resources and importing/exporting DXL or CD records, etc. But apparently they haven't applied this sleight of hand to javadoc as well.
The Java source files corresponding to each XPage and Custom Control are processed successfully because, ironically, they are never stored in the NSF. During every project build, Designer discards any of these it has already generated and re-creates them based on the current contents of the various .xsp files. It then compiles those Java files into .class files, which are stored as design notes inside the NSF. At runtime, it's these files that are extracted from the VFS and executed... the source code no longer matters at this point, so there's no reason to ever bother including the .java files in the NSF, so they're just kept on the hard drive. One indication of this behavior is that the folder is named "Local" when viewed in Package Explorer / Navigator.
If you're using the built in (as of 8.5.3) version control integration (see this article for a great explanation of how to use this feature), you can tweak the Build Path to include the copy of the src folder stored in the on-disk project as a "linked source folder". This causes javadoc to consider the duplicate copies valid source files, and therefore includes them in the generated documentation. On the downside, it also causes Designer to consider them valid source files, which causes compilation errors due to the duplication. So this approach is only viable if you only need to generate the documentation on an infrequent basis, and can therefore break the Build Path temporarily just to run javadoc, then revert to the usual settings.
An alternative is to actually maintain your custom Java code this way on an ongoing basis: instead of creating the folder in WEB-INF inside the NSF, just create a folder on your hard drive that stores the source, then include that location as a linked source folder indefinitely. That way Designer can still find the source, but so can javadoc. NOTE: if you go this route, then you definitely need to use SCM. Because your source code no longer lives inside the NSF, providing the convenient container we're used to for getting the source code to other developers and ensuring inclusion in whatever backup schedule you use, the only place your source code now lives is on your local hard drive. So make sure you're regularly committing those files to Git / Subversion / Mercurial, etc., or, at the very least, storing them on some file server that is backed up regularly and, if applicable, accessible to all other members of the project team.
When you expand the net.focul.utilties in Designer, you will see all the methods and properties. But when you click on on of the methods, you will see neo source code.
So this is where javadoc fails to generate the documentation. I guess that the author of the application has not provided you with the source code. If you have the source somewhere, you can attach this code and then javadoc will be able to generate the documentation.
I run into the same situation and I have found the most straightforward method is to export the source to an external folder and then use regular Eclipse to generate the JavaDoc. Not sure my process is any less of a hassle than Tim's suggestions but for me it just feels less risky than trying to deal with the VFS vagaries.
Hey i'm trying to access a windows share to get a given XML file that I need to do some work on.
I'm trying to do this with a groovy script that will run in soapui, but i can't see how I can access the share without adding something like JCIFS or another external lib.
Is there anyway to access the share without external libs and if not could somebody point me to an example of how you access the share.
Okay I have tried with the jcifs and that works, but would not be the best.
But we can access with just a normal windows share access.
So if i use: " \\\\<ip>\\c\$\\folder" i can get to my files.
I'd like to be able to have either web dashboard logged in administrators or general users depending on which the team prefers be able to see the contents of this file without remoting into the box, is this possible using the webdashboard?
This is not an answer to how it can be seen from the web dashboard...
... but it is possible to store the ccnet.config file in source control and set up a special build on the build server that automatically retrieves the newest config file.
This way you do not even have to remote into the box in order to edit the contents of the file.
See more details in the documentation:
http://confluence.public.thoughtworks.org/display/CCNET/Configure+CruiseControl.Net+to+Automatically+Update+its+Config+File