I have set of JVM configured, WAS components (Queues, SIB, etc) created in one environment (WAS 8.0 ) and is all working fine. I need to replicate the same in another set of new servers (and another one potentially). How do I replicate all the steps without typing the information again?
Ideally, you'd make the original changes via scripting and re-run them. An alternative is "properties based configuration" for export/import.
http://www.ibm.com/developerworks/websphere/techjournal/0904_chang/0904_chang.html
Related
I have a website that creates from Laravel. I want to do some customization to that.
Can I edit directly from my server or need anysoftwair or anything else
I need help editing it. How can I do it?
Thank you
You can edit the files directly on your server using any text editor available to you, however, it's not advisable to make changes directly on a live/production environment. What happens if/when you make a mistake or a change has a negative effect (e.g. on performance), how will you revert those changes efficiently and swiftly, and how will you know which file(s) are causing any issue(s)?
Instead create a local environment to make and test your changes, ideally then deploy those changes to a remote staging/development environment for further testing before deploying to your live/production environment.
I'm writing a unified project for 3 smart TVs. I have also 3 configurations created in Visual Studio. Now I want to execute some CLI scripts depending on selected configuration.
The problem is in new ASP.NET 5 project I don't have an editor for post build events.
I know I have to do this in project.json. What I found is:
"scripts": {
"postbuild": ""
}
But using this one I can't create different CLI scripts for different configurations.
I found also:
"configurations": {
},
And I guess this is probably what I want, but... How to use it? Intellisense has no power here and also I wasn't lucky searching the Web...
[edit]
Maybe I should try with .xproj?
You'll need to build a master script which uses the available context and environment variables to switch and run the other scripts of your choice.
In addition to the list of variables Here for compile, you also get these for publish related scripts and then these are available everywhere, as are environment variables returned by Environment.GetEnvironmentVariable, which can be seen here.
The image below shows the intellisense from the VS2015 Update 3 RTM, but it's misleading, since you get others depending on the script block you're using:
So, your full list of context variables that you can use to control flow in your scripts is:
Every script block:
%project:Directory%
%project:Name%
%project:Version%
Compile specific:
%compile:TargetFramework%
%compile:FullTargetFramework%
%compile:Configuration%
%compile:OutputFile%
%compile:OutputDir%
%compile:ResponseFile%
%compile:RuntimeOutputDir% (only available if there is runtime output)
%compile:RuntimeIdentifier% (only availabe if there is runtime output)
%comiple:CompilerExitCode% (only available in the postcompile script block)
Publish specific:
%publish:ProjectPath%
%publish:Configuration%
%publish:OutputPath%
%publish:TargetFramework%
%publish:FullTargetFramework%
%publish:Runtime%
I investigated on this a bit but did not really get to any good result.
There are some project variables that are exposed in scripts. Unfortunately, those are very limited:
%project:Name% gives you the project name
%project:Directory% gives you the project directory
%project:Version% gives you the project version
So there is no way to access the build configuration or the environment here.
The configurations option in the project.json is also limited to build configurations and only allows declaring compilation options there, so that also doesn’t work.
Unfortunately, there also doesn’t seem to be another way to solve this. At least not right now. I would consider myself sending a pull request to DNX to add some additional project variables which one could use but at the moment, it doesn’t really make any sense to invest time into DNX: After all it’s being replaced by the dotnet CLI. We’ll see if that one will come with functionality to access the environment—and if not, I might end up submitting a pull request to add this functionality. But until we get there, I’m afraid there is no solution for this.
I'm forced to use Processing 2 behind a proxy. My problem is: How can I set host and port of the proxy?
I search the settings used by the IDE, e.g. to add libraries or tools. My question is about the usage of a proxy in applications to be developed.
The solution is given in this document: https:Processing's default settings
The proxy settings for Processing (the application itself) can be set in the file Users -> [username] -> AppData -> Roaming -> Processing -> preferences.txt (Windows 7 and higher)
You have to add the values for the keys proxy.host and proxy.port.
It's probably easier to look for a solution in plain Java and you should be able to apply the same solutions in Processing (if you're using the Java Mode).
Unfortunately I won't be able to test, but these related answers seem to address your proxy issue, for example: How do I set the proxy to be used by the JVM
I'd try this in setup() first:
System.setProperty("java.net.useSystemProxies", "true");
Only because it looks very simple. This is the 4th answer on the page.
If it doesn't work I'd move towards the top. If you want to do this straight from Processing you probably need to this programatically at runtime. If neither of the programmatic runtime options work, you should be able to export your sketch from Processing, then run generated the .jar from command line, passing the proxy settings as well.
Although a long stretch, if drawing some graphics on screen is all you need, you can move from Java to JavaScript with P5.js
This is an ongoing problem with all versions of Processing. For anyone else with this issue in Windows:
Processing is unable to run even a single line of code unless it has an internet connection, no idea why this should be the case. If you are behind a proxy there are (at least) two ways to add proxy settings. You can do it per user in c:\users\\appdata\roaming\Processing\preferences.txt
or for all users under the main processing folder (will vary with version) in the lib folder, default.txt. This file says something about "do not edit". Take a backup first if you're concerned, but you can scroll down and edit the proxy settings there easy enough. when a user runs Processing for the first time, these settings will be put into their preferences.txt. If they already have a preferences.txt, you will need to delete or rename it, and a new one will be created at next use.
For a student lab situation, you can copy out this default.txt file to the \lib on all machines, and it will then work for all users.
Are local pre-commit hooks a function of TortoiseSVN only? It seems that the svn command line client does not support them. If the answer is yes, is there any way to script their installation? My situation is that there are a lot of committers, two or three hundred maybe.
We have several release managers who each have multiple VMs with multiple branches checked out on each VM. I'd like to have a script we can lay down and run on each VM instead of manually adding (through the tortoise GUI) one hook per release manager per VM per working copy. Adding it server-side would result in a lot of unnecessary work and slowdown for the server. We are all on windows. Thank you!
Yes, client-side hooks are a TortoiseSVN-only feature (the settings shown here are global to the user's TortoiseSVN client). You can configure them for for specific projects via the tsvn:*hookscript properties.
For distribution, you may want to keep the hook scripts on a centralized file share and reference them via UNC path in those properties. That way, everyone should be pointed to the same hook scripts all the time. You'll need to ensure that your hooks do not depend upon specific paths either for working copies or other tools that your scripts might be dependent upon.
However, you should not become completely dependent upon client-side hook scripts. You can't control which client(s) a user may use and if they don't use TortoiseSVN, that functionality won't exist.
I have a build environment with multiple agents.
I would like to set up an Agent Requirement in my build that detects if certain software is installed. In some cases I can look in the env.Path for a particular string. But some software doesn't modify the Path.
I realize that after I install the software i could edit the BuildAgent.properties file to set a particular property, but I'd like it to be more automatic.
The specific instance is I have a build that uses MSDeploy to deploy websites, but it won't work if MSDeploy isn't installed. How can I specify in my build that I need an Agent that has MSDeploy installed?
You can build a simple agent plugin. Here are a few suggestions:
Extend AgentLifeCycleAdapter and implement agentInitialized method
Implement logic of detection the necessary application (for example based on some file existence) inside agentInitialized method
Use agent.getConfiguration().addConfigurationParameter() to report agent parameter to the server
If your detection logic can be implemented through file detection, you can use FileWatcher to monitor specific files and report parameters based on them even without restart of the agent
To my knowledge Agent Requirements work simply by validating either the existence of, or the value set in an Agent Parameter. As you say, this requires editing the <agent home>/conf/buildAgent.properties configuration file, either manually or in some automated way.
In terms of automation, you could take the approach of authoring a build configuration that acts as an agent bootstrapper; i.e. a build that runs on all agents (scheduled overnight / manually triggered) and maintains build agent parameters in the <agent home>/conf/buildAgent.properties file depending on certain conditions on the agent. Something like (pseudo):
if [ exists /path/to/MSDeploy ] then echo MSDeployExists to buildAgent.properties
This comes with a big disclaimer; I haven't tried this myself, and I believe that the agent will restart automatically based on changes to this file, so there may be issues with editing that file automatically. But it's a potential solution to maintaining your requirements in a centralised manner, and if it works then great. I use a similar approach to bootstrapping custom build scripts out to all agents to augment the already rich feature set in TeamCity.
I agree with the answer from SteveChapman. It is clear that you can test for environment variables (exits, contains, starts with, etc.). TeamCity is aware of versions of .NET installed on the agent (as well as Visual Studio, and VS SDKs). However, I can't find anything that would be equivalent to a "testpath" sort of capability.
The sure way to know is to add an agent parameter via the <agent home>/conf/buildAgent.properties configuration file.