A server was upgraded from Windows 2000 to Windows 2003 and now I can't access environment variables from Ant build scripts.
I can still access them fine from a command line, but ${env.JAVA_HOME} for instance fails.
How can I fix this without rewriting ~100 build scripts that work on all other servers to be customized for this server?
Unfortunately I don't think you should have been using that environment variable. To get around such problems there's the builtin ${java.home} you could have been using, which isn't dependent on the operating system and/or user's environment being setup properly. (See the Ant manual discussion of built-in properties in Ant.)
You may be able to get around rewriting all your build scripts by either (1) setting the JAVA_HOME environment variable manually, or (2) modifying the ant.bat file to assign it manually. Both options are brittle because they'll break when Java gets upgraded, but at least they'll likely fail fast.
Related
I was wondering If any one could help me to understand the difference of python virtual environment and docker container.
So I would like to have environment for each tools isolating from each other to avoid dependency conflict for example: use of different version of same dependency causing error in one of the tool because one tool need older version and other one requires newer version.
I’m tested out python venv but not sure if it’s the right one I should use for the issue I just explained or docker is something I should be using for my situation?.
Particularly for day-to-day development, prefer a virtual environment if it's practical.
Virtual environment
Docker
Works with native tools; can just run python myscript.py
Requires Docker-specific setup
Every IDE and editor works fine with it
Requires Docker-specific IDE support
Can just open() data files with no special setup
Can't access data files without Docker-specific mount setup
Immediately re-run code after editing it
Re docker build image or use Docker-specific mount setup
Uses Python installation from host
Use any single specific version of Python
Isolated Python library tree
Isolated Python library tree
Uses host version of C library dependencies
Isolated C library dependencies
A virtual environment acts like a normal Python installation in an alternate path. You don't need to do special things to make your local code or data files available; you can just run your script directly or via your IDE. The one downside is that you're limited to what your host OS's package manager makes available for Python versions and C library dependencies.
A Docker container contains the filesystem of a complete OS, including a completely isolated Python installation. It can be a good match if you need a very specific version of Python or if you need host OS dependencies that are tricky to install. It can also be a good match if you're looking for a production-oriented deployment setup that doesn't specifically depend on installing things on to the target system. But, Docker by design makes it hard to access your host files; it is not a great match for a live development environment or especially for one-off scripts that read and write host files.
The other consideration here is, if you use the standard Python packaging tools, it's straightforward to run your program in a virtual environment, and converting that to a Docker image is almost boilerplate. Starting from Docker can make it tricky to go back the other way, and I see some setups around SO that can only be run via Docker; if they were restructured to use a standard setup.cfg/requirements.txt installation setup they would not require Docker but could still be used with it.
I am trying to debug a huge project using VS Code, the project is supposed to run on dapr using docker. I have installed dapr, docker, both seem to work fine. I also have VS Code, and I managed to get dapr extension for VS Code.
I build the project using dotnet build, no errors, so I am assuming that works fine, but when I try to debug it (run it) I get that error. I have read that it can be caused by having to set up environmental variables, but I don't know which environmental variables, as they seem to be present in the path (c:\users\myself.dapr\bin) is present.
So I have a few questions: what should I do now? and what is the reason behind it? Basically, I want to fix this, but knowing and understanding how, thanks.
As simple as restarting the laptop fix it, I guess that I did all of the installations without restarting and it needed a restart.
It was nothing to do with the environment variables in the end.
In the past I have used environment modules extensively in Unix based systems. The tool proved very usefull since we had many different projects each of them using a potentially different set of tools.
I am now however stuck with a windows machine and need to make the most of it. Does anybody know of a good alternative to environment modules for windows? I am basically looking for a tool that let's me manipulate the PATH (or $env:PATH in windows powershell) environment variable without having to touch it directly.
You can install environment modules on windows as well. The instructions are in the repository https://github.com/cea-hpc/modules/blob/master/INSTALL-win.txt
Basically you have to install active state tcl and copy the source files.
I use this and it works quite well.
I have been trying to install jbpm6.1.0 in my Windows 7 32 bit system. However I am unable to complete so because doing an ant demo.start.noeclipse leads to a
build.xml:508: JBoss application server did not start within 5 minutes
I have increased the time in build.xml and tried other simple tweaks. Then I was suggested to look into log files but I observed they were never created, the log folder within standalone is not present at all. I think that my installation is not getting complete and JBoss application server not starting because of that.
I used this tutorial for installation and also used links given by it
http://docs.jboss.org/jbpm/v6.0.Beta2/userguide/ch.installer.html#d0e281
I am not able to debug and get to a reason. Starting the standalone.bat only gives me info that the Java_Home environment variable is set properly. I can do with a way out or even a direction as where to get more information on the process so that I may be able to debug.
Java_Home is C:\Program Files\Java\jdk1.7.0_51\bin and ANT_HOME is C:\Program Files\apache-ant-1.9.4 with path using the C:\Program Files\apache-ant-1.9.4\bin for its purpose. Hence both the applications must be running correctly
You need to find out what the error is because it seems that the application server is not even starting, that can be because you don't have administrator rights or because there is another server running using the required ports
I have seen this question about deploying to WebSphere using the WAS ant tasks.
Is there a simpler way to do this? In the past I have deployed to Tomcat by dropping a war file into a directory. I was hoping there would be a similar mechanism for WebSphere that doesn't involve calling the IBM libraries or rely on RAD to be installed on your workstation.
Just a hint: if you activate "Log command assistance commands" in System Administration / Console preferences, you will get a logfile in the server log directory that contains the jython scripts for all actions you did on the console. So you can just deploy your stuff per console the first time, and then grab the commands for later and feed them into wsadmin.bat -lang jython "thecommandscomehere" for the next deployment.
There is the concept of WebSphere Rapid Deployment. It's supposed to be the same experience as what you describe for Tomcat.
One way to do it could be using Jython or jacl scripts. See those samples at IBM site.
[EDIT] Especially the wsadminlib.py.zip download near the bottom of the page contains a huge set of examples and helper functions to get you started.
WAS does provide a client jar containing some custom ant tasks. However they seem to be extremely bugy and dont work with remote servers.
IBM ANT TASK Javadoc
Netbeans also has support for was 6 and 6.1 but this again is still quite buggy, however it can be useful for generating some the bindings files etc.