we are testing a setup to automate building of NSF's using headless designer.
when a developer pushes a change to a repository on github ultimately this will result in an update of an NSF that resides on a Domino server.
local odp -> github -> local nsf with headless designer -> replace design nsf on domino server
however we noticed that the process stops sometimes. as far as we can see headless designer cannot "copy" (or translate) the design elements from the ODP into a new local NSF. so only an empty skeleton NSF is created.
we noticed that the stop does NOT occurs when the name property in the .project file of the ODP has changed.
so somehow it looks as designer still has the ODP in memory and does not notice any changes, unless it "finds" a "new" project via the project description "name".
anyone experienced something similar ? or recommendations how to start designer without any cache?
An (in-?)elegant solution which I use, since I want to keep things tidy and separate for each build, is to compute a unique filename for the NSF. This will create a separate NSF for each build and while it will retain things like the Application name and template name, it is unique in enough other ways to not cause issues for the DDE headless build.
Defining in CI Config
]1
Using Env Vars in PowerShell Script
For example, I use an app specific prefix, defined in my GitLab CI config, which then is used with the unique build number (both set as environment variables), which my modified version of Egor Margineanu's PowerShell script picks up for the build.
Bottom Line
The unique namespacing means no conflict from DDE's perspective.
Related
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 am trying to migrate my working sets to a new installation. While searching the web I found this link which says that by copying the file <DATA FOLDER>\workspace\.metadata\.plugins\org.eclipse.ui.workbench\workingsets.xml we can get our original working sets back. I tried it, but it only restores my working sets and they are empty with no database inside them.
What am I missing here? Does any one know how to get all the working sets from old installation and put it into new installation of Domino Designer?
Databases in designer are held as eclipse projects, so you would need to copy project directories inside workspace directory. You can see their directory names in designer just after database title.
Although, I wouldn't recommend that, because different designer versions may have different structure of its content.
I had the same issue. I migrated from the same Notes 8.5.3 release on the old computer to the new computer, so after reading the tips above, I decided to just replace the whole workspace folder under the C:\Lotus\Notes\Data\ folder on my new PC with the workspace folder on my old PC.
It worked! When I opened the Designer client, I had all my working sets complete with database icons. I don't know anything about the workspace folder, so I probably would be cautious applying such an approach if I were migrating to a new release, but since I had not yet started to work on the new PC, I was prepare to reinstall the software if necessary.
FYI, if you don't want to lose your custom commands in the Domino Administrator client when migrating to a new PC or when installing another release of Notes on the same PC, you simply copy the domadmin.nsf database file from the old environment and replace the one in the new environment (if it exists, it won't yet exist if you haven't launched the app after a new install). If you have upgraded to a new Notes release, then open this domadmin.nsf DB in Designer in the new environment and refresh its design from the StdAdminDatabase template (domadmin.ntf).
http://www.lotusguru.com/lotusguru/LGBlog.nsf/d6plinks/20100310-83ESQC
The Notes client being totally closed, backup or restore the following directories :
..data/workspace/.metadata/.plugins/..
com.ibm.designer.domino.ide.resources
org.eclipse.core.resources/.projects
org.eclipse.core.resources/.root
org.eclipse.core.resources/.safetable
org.eclipse.ui.workbench
I'd like to update existing production moss2007 website and to do that I want to create this website on my dev environmen (vhd win 2003EE, MOSS 2007 trial version).
I was given:
some stp files which include(aspx pages, javascript files, etc...)
some aspx pages, masterpage, css file
some wsp files
source code for almost all wsp files.
There is no documentation how to install all this stuff and I'm not a sharepoint developer but Asp.net dev in fact.
I set up local dev enviroment (i had no problems when following http://www.pptspaces.com/sharepointreporterblog/Lists/Posts/Post.aspx?ID=28
) and try to create a website based on given files.
My questions:
Do I need a copy of the database?
I noticed that one of wsp files is not a webpart but a project that contains some web controls and even a master page) - what should I do with it?
I tried to import all stp files. I had to use stsadm, but I can't see them. I can list them using "stsadm -o enumtemplates" - all of them have the same id!
I changed stp->cab->modified the "WebUrl" in the manifest.xml -> created new cab and rename it to stp-> imported to sharepoint but still the same, I can't see them (custom tab is still not visible).
I created a custom site template locally (custom tab appeared with it) and opened its manifest.xml. I noticed that the section contains 17 parameters (manifest.xml files from other stp files 9 parameters only).
I think that my SharePoint (Trial version) works in a different way and that's the problem.
Can it be?
What is the best way to create this site locally?
thx ahead for all answers
if you want to set up development environment containing the same functionality as your production server, you can duplicate your production site collection by:
Copying and attaching production SharePoint content database to your development environment farm
Backuping and restoring it by stsadm tool
By firstly you need to prepare your development environment. If you have any wsp solutions deployed on production farm, deploy it on your development environment.
Then if you prefer first option check this link
If you prefer second option check this link
But if you prefer backup way, you can catch some problems with version difference between production and development revilement, different updates installed, so different assemblies in GAC.
So I advice to use attach database way, it should upgrade attached database if it has different version automatically.
Just google little bit, may be you'll find more complete guide for attaching or restoring site collections. I just give you start point.
Had started my typical EE build (using a bootstrapped config) for a client when they announced they wanted another additional site using the MSM module (le sigh).
So added the MSM module, I commented out the $config['site_url'] and $config['cp_url'] and set those in index.php instead using $assign_to_config.
That's when I discovered this bug where MSM config file settings are not recognized, which is a pain but I can work around it. However, I noticed that when I created the secondary site, it wouldn't recognise my custom location for add-ons and so I had to add that to index.php as well to $assign_to_config['third_party_path'] = "../assets/third_party/";.
Then I discovered that when I create or modify a template file, it won't automatically sync and so I need to manually do that each time which is a real PITA.
Why would my templates not be syncing to the database? Is this related to the MSM config bug?
While I haven't tried bootstrapping the third party path yet, I've definitely been able to bootstrap the template path for MSM sites... What bootstrap method are you using?
Are your sites on subdomains or subfolders? I've only had experience with subfolders so perhaps that makes a difference (although it shouldn't).
Could you maybe walk through in a bit more detail what's happening? Your first site (site_id = 1) templates sync automatically from filesystem edits, but your second site does not? Yet if you go to CP > Design > Synchronize Templates, that works?
The $assign_to_config portion of MSM setup is definitely a weakspot when it comes to bootstrapping... I wonder if we need to work up an additional bootstrap for MSM+CP environment, where it looks at the cp cookie ($_COOKIE['exp_cp_last_site_id']), and sets values based on that.
It may be helpful if you let us know which bootstrap you are using. For example, if you look at this bootstrap the site_url and cp_url are set using the HTTP_HOST server variable, so this shouldn't clash with your MSM install (and multiple domains) at all.
Perhaps you could try using that boostrap file instead, and see if it fixes your issue with template syncing?
Finally, if you're going to use the EE template manager, you don't really need to store templates as files. Conversely, if you want to save templates as files, it's probably much easier editing them using Sublime Text or another editor, rather than the clunky built-in editor (which is really only useful for small/simple changes).
I want to create a development environment running Movable Type 5.
To create a separate development environment, it is necessary to copy and paste to reflect production.
How would I go about building a good environment?
There are many ways to build a development environment, and an experienced Movable Type developer would need to know more about your goals in order to make a good recommendation.
All of the following guidance assumes that Movable Type has been installed and is ready to run
on the development server.
Here are a few basic tips:
Although some of the key configuration details for a Movable Type instance are kept in mt-config.cgi, there are website-level and blog-level settings that are of equal importance that are kept in the underlying database.
Since most Movable Type 5 instances use MySQL as the database backend, it's possible to dump the entire contents of the Movable Type database using the mysqldump utility or a more visual tool like the Export function of phpMyAdmin. This produces a large text file with MySQL CREATE TABLE and INSERT statements.
Once the database is dumped to a file, the file can be moved to another server, modified, and reconstituted. One of the tasks we commonly perform at that point is to go through the database using an editor, the UNIX sed command, or some similar process, and perform global searches and replacements for the URLs and file system paths that are embedded in the database dump.
This is necessary in many cases because your production website may be http://www.mysite.com/, but your development environment may be http://dev.mysite.com/ or even http://localhost/. Similarly, the file system paths in production may be /var/www/mysite/htdocs/... while development may be /opt/local/apache2/htdocs/mysite/....
Once changes of this nature are made and the modified file is saved, the database is reconstituted on the development server by using a UNIX shell command like:
cat mysite.sql | mysql -u mt_user -p mt_password
Or by importing the database into another copy of phpMyAdmin.
Once all of this is done, the mt-config.cgi file from production needs to be copied into the Movable Type working directory and rewritten so that several important elements are changed:
CGIPath
StaticWebPath
Database
DBUser
DBPassword
DBHost
These Movable Type Configuration Directives are discussed in the online documentation.
All of the non-database assets have to be copied from production to development. Things like files containing jpeg, png, and gif images, files that have been placed in the production file system either manually, or using the Asset Manager. There may be other files that need to be copied from production, depending on how you use Movable Type.
Once all of this is done, and you are able to login to the Movable Type development server successfully, you will probably want to the websites and blogs to ensure that all of the content has been copied into development.
I hope these instructions are somewhat helpful to people needing to setup a development environment. I would be happy to get comments or edits if anyone thinks I left out anything significant.
By saying that you need a development environment for Movable Type, what exactly do you need to develop?
If you are developing a plugin? or theme? a website? content?
It is possible to assign a different mt-config.cgi file to each virtual server, and working on different database, for the same installation.
If you are developing a plugin, you will want to use the PluginSwitch directive so the developed plugin won't be loaded on the real website.
http://www.movabletype.org/documentation/installation/managing-multiple-instances-of.html
Eslar, you may like to consider also this documentation resource:
http://www.movabletype.org/documentation/mt41/rsync.html
Alternatively, you may like to consider:
http://www.cis.upenn.edu/~bcpierce/unison/
If you go with the 'rsync' solution described in the movable type documentation, you may like to check also these configuration directives mentioned there:
http://www.movabletype.org/documentation/appendices/config-directives/rsyncoptions.html
http://www.movabletype.org/documentation/appendices/config-directives/synctarget.html