How to use -Dinstallation.host= in intelliJ tomcat configuration without command line - intellij-idea

I am using mvn for build and deploy my code in tomcat. I am using command for build clean install -DskipTests -DskipJangarooApp -pl :studio-webapp -am -T 4C where studio-webapp is my module name.
And after build i use tomcat:run command like this :
tomcat7:run -Dinstallation.host=192.168.252.100
where 192.168.252.100 is my host machine IP. This process is running well.
But the problem is when I change any java class in my IntelliJ I again run buil command then run. And its taking so much time. So that I want to apply tomcat configuration in IntelliJ but i am not able to find any option of "-Dinstallation.host" in this screen

Related

Unable to install nextflow correctly

I've attempted to install Nextflow with command "curl get.nextflow.io | bash" in my Windows system command prompt-bash, but I consistently see this error: Unable to initialize nextflow environment
In parallel, on a remote server, the Nextflow is installed with the same command and I can verify that with ls command. However, when I prepare a sample script (hello.nf), executing it by "nextflow run hello.nf" shows that Nextflow is not characterised.
In any of cases, typing "nextflow info" doesn't recognise nextflow. Is there anyway that I can install Nextflow or have I missed any step? I have also tried with wget, but no success yet.
Thanks in advance!
If you have Windows 10 Version 1903 with Build 18362 or higher, you can use the Windows Subsystem for Linux 2 (WSL 2) rather than having to configure a Linux VM. There's a few hoops to jump through, but this guide (Oct 2021) should be sufficient: Setting up a Nextflow environment on Windows 10
On your remote machine, all you should need to do is to move your nextflow to somewhere in your $PATH. Alternatively, you can just call it with ./nextflow (assuming it is in your current directory).

Flatpak Intellij Idea - problem with subversion executable

After installing Intellij Idea using flatpak on Clear Linux I'm not able to make it run svn executable.
I added ---filesystem=host to flatpak permissions and tried to set executable path to /run/host/usr/bin/svn but with no luck (path is available/exists, though Intellij keeps complain)
svn command is normally available from system terminal.
When I try to run /run/host/usr/bin/svn command via Intellij Idea built-in terminal, I've got error that library is not available:
sh-5.0$ /run/host/usr/bin/svn
/run/host/usr/bin/svn: error while loading shared libraries: libsvn_client-1.so.0: cannot open shared object file: No such file or directory
I also tried set flatpak-spawn. Following command works perfectly fine in Intellij Idea built-in terminal:
/usr/bin/flatpak-spawn --host /usr/bin/svn, though when set as path to svn executable still gives me Intellij Idea error:
"The path to Subversion executable is probably wrong"
Could anybody please help with making it work?
TLDR: You probably need to add the path to svn into your IntelliJ terminal Path.
Details:
It looks like you are having a path issue. I had a similar problem running kubectl running PyCharm installed from a flatpak on Pop_Os.
If I try to run kubectl I see the following:
I have kubectl installed in /usr/local/bin. This is a screenshot from my 'normal' terminal.
In the PyCharm terminal this location is mounting under /run/host/usr/local/bin/.
If I look at my path in the PyCharm terminal, it is not there.
So I'll add the /run/host/usr/local/bin/ to my path and I can then run kubectl:
To make sure this comes up all the time, I need to add the PATH to the Terminal settings:
I can now execute any of the commands in my /usr/local/bin dir.
I found a really ugly solution for dealing with SVN with the JetBrains family, which does actually answer the question. But in a very roundabout way. Unfortunately Alex Nelson's solution didn't work for me.
You would think the Flatpak would come with a valid SVN, since it's actually part of the expected requirements for the program...
When in the terminal, you can run
cd ..
/usr/bin/flatpak-spawn --host vim ./svn
Then press i to go into input mode, then paste the following in the opened text file (Basically what it does is create an executable which passes it to the flatpak-spawn invocation):
#!/bin/bash
/usr/bin/flatpak-spawn --host /usr/bin/svn $#
Save and quit from vim (ESC, then :wq!). Make it executable:
chmod +x svn
Then in IntelliJ's menu, set the "path to svn" to
/home/<yourusername>/IdeaProjects/svn
It's worked for everything I've tried... Hope this helps out anyone else who was struggling with this.
I am using a similar solution to caluga.
#!/bin/sh
cd
exec /usr/bin/env -- flatpak-spawn --host /usr/bin/env -- svn "$#"
exec makes it replace the wrapper script process so the wrapper script process can end.
I'm using /bin/sh instead of /bin/bash as bash features are not needed.
using /usr/bin/env, but maybe not necessary if PATH is set up right.
remember to quote "$#" in case there are spaces in arguments.
I am putting it in ~/.local/bin and referencing it with its absolute path in the IntelliJ settings (Settings -> Version Control -> Subversion -> Path to Subversion executable).
I also was running into problems with IntelliJ saying that /app/idea-IC path does not exist. Figured that something outside the flatpak (i.e. svn or env) was trying to change directory to the working directory from where the wrapper script was invoked (inside the flatpak). Using cd allows the wrapper script to change to a directory that exists both inside the flatpak and on the host.
Fedora Silverblue or toolbox users might want to use dev tools inside their toolbox, in which case you can do:
#!/bin/sh
cd
exec /usr/bin/env -- flatpak-spawn --host toolbox run svn "$#"

How to configure glassfish or Tomcat server with netbeans Ide in ubuntu 14.04 in 32-bit System

In ubuntu 14.04,i tried to configure glassfidh sever in netbeans. I am also following below steps.
But it could not configured.
Step 1: wget http://download.java.net/glassfish/4.1/release/glassfish-4.1.zip
Step 2: unzip glassfish-4.1.zip -d /opt/
Step 3: nano ~/.profile
Step 4: source ~/.profile
Step 5: asadmin start-domain
step 1 to step 4, there is no problem but at step 5 there is problem like:
No command 'asadmin' found, did you mean: Command 'acsadmin'
from package 'ion' (universe) Command 'amadmin' from package
'amanda-server' (universe) asadmin: command not found
i am following above steps, if i am wrong please correct me.
Thank you.
The asadmin tool is located in the glassfish4 directory that you unzipped. The error message is Ubuntu telling you that it doesn't know of any command named asadmin.
You will need to specify where the asadmin tool is for Ubuntu to interact with it. If you are in the same directory, this means using:
./asadmin start-domain
If you want to be able to start GlassFish like this regardless of the directory, it would be best to install GlassFish as a service as follows:
./asadmin create-service
You should then be able to run something like the following from any terminal window:
service GlassFish_domain1 start
service GlassFish_domain1 stop
service GlassFish_domain1 restart
Find out more details about the options for the command by using the following:
./asadmin help create-service

Running headless firefox Xvfb with Jenkins to run selenium tests

I face with Error: no display specified error when running play framework tests in Jenkins at FreeBSD server.
So every time I face with timeout
org.openqa.selenium.firefox.NotConnectedException: Unable to connect to host 127.0.0.1 on port 7055 after 45000 ms. Firefox
Jenkins has:
1) Xvfb plugin installed
2) Play Framework installed
Tests are written using selenide library and selenide module for play framework.
Xvfb configured and enabled in job configuration.
Job console output is:
Checking out Revision 3f485bd2e3dbcfa058fc19f89ab18020e36707d8 (origin/trunk)
...
Xvfb starting$ /usr/local/bin//Xvfb :1 -screen 0 -fbdir /usr/local/jenkins/xvfb-9-786185694297443042.fbdir
...
Command detected: clean
Command detected: deps --sync
Command detected: precompile
Command detected: auto-test
[YalsTests] $ /srv/java/play/play clean
...
~ using java version "1.8.0_72"
[YalsTests] $ /srv/java/play/play auto-test
~ 14 tests to run:
~
~ selenium/front/CorrectInput... org.openqa.selenium.firefox.NotConnectedException: Unable to connect to host 127.0.0.1 on port 7055 after 45000 ms. Firefox console output:
Error: no display specified
at org.openqa.selenium.firefox.internal.NewProfileExtensionConnection.start(NewProfileExtensionConnection.java:113)
at org.openqa.selenium.firefox.FirefoxDriver.startClient(FirefoxDriver.java:271)
Job configuration:
[X] Start Xvfb before the build, and shut it down after.
Xvfb specific display name 1
Xvfb display name offset 0
Invoke Play Framework
Command set Play 1.x
Goals
Clean project [clean]
Custom parameter
Custom command deps --sync
Precompile all Java sources and templates [precompile]
Automatically run all application tests [auto-test]
The selenium tasks needs to know the DISPLAY that it shall connect to.
You can set it e.g. as an environment variable (don't forget to export it, if you do that in .profile)
export DISPLAY=:10
This is for bash, other shells might need a 2 step process:
DISPLAY=:10
export DISPLAY
You can also specify the variable at the command line before the command:
DISPLAY=:10 java -jar mySelenium.jar
You could avoid all these issues by using Selenoid project which starts headless browsers in parallel in Docker containers. Container images are created by considering compatible version of webdriver and browser. They also include fonts, flashplayer and so on. Just choose one of already existing images and run your tests. No need to install Java to run Selenium tests.
I tend to supply this if I'm running my tests via Jenkins:
xvfb-run --server-args="-screen 0, 1920x1080x16" mvn clean install...
One thing that has tripped me up in the past is that while xvfb-run will create a virtual display, it can really screw up your screenshots and web interactions if it isn't sized correctly, so it's usually advisable to supply a resolution size which will suitably display your browser.

Subversion export/checkout in Dockerfile without printing the password on screen

I want to write a Dockerfile which exports a directory from a remote Subversion repository into the build context so I can work with these files in subsequent commands. The repository is secured with user/password authentication.
That Dockerfile could look like this:
# base image
FROM ubuntu
# install subversion client
RUN apt-get -y update && apt-get install -y subversion
# export my repository
RUN svn export --username=myUserName --password=myPassword http://subversion.myserver.com/path/to/directory
# further commands, e.g. on container start run a file just downloaded from the repository
CMD ["/bin/bash", "path/to/file.sh"]
However, this has the drawback of printing my username and password on the screen or any logfile where the stdout is directed, as in Step 2 : RUN svn export --username=myUserName --password=myPassword http://subversion.myserver.com/path/to/directory. In my case, this is a Jenkins build log which is also accessible by other people who are not supposed to see the credentials.
What would be the easiest way to hide the echo of username and password in the output?
Until now, I have not found any way how to execute RUN commands in a Dockerfile silently when building the image. Could the password maybe be imported from somewhere else and attached to the command beforehand so it does not have to be printed anymore? Or are there any methods for password-less authentication in Subversion that would work in the Dockerfile context (in terms of setting them up without interaction)?
The Subversion Server is running remotely in my company and not on my local machine or the Docker host. To my knowledge, I have no access to it except for accessing my repository via username/password authentication, so copying any key files as root to some server folders might be difficult.
The Dockerfile RUN command is always executed and cached when the docker image is build so the variables that svn needs to authenticate must be provided at build time. You can move the svn export call when the docker run is executed in order to avoid this kind of problems. In order to do that you can create a bash script and declare it as a docker entrypoint and pass environment variables for username and password. Example
# base image
FROM ubuntu
ENV REPOSITORY_URL http://subversion.myserver.com/path/to/directory
# install subversion client
RUN apt-get -y update && apt-get install -y subversion
# make it executable before you add it here otherwise docker will coplain
ADD docker-entrypoint.sh /enrypoint.sh
ENTRYPOINT /entrypoint.sh
docker-entrypoint.sh
#!/bin/bash
# maybe here some validation that variables $REPO_USER $REPO_PASSOWRD exists.
svn export --username="$REMOTE_USER" --password="$REMOTE_PASSWORD" "$REPOSITORY_URL"
# continue execution
path/to/file.sh
Run your image:
docker run -e REPO_USER=jane -e REPO_PASSWORD=secret your/image
Or you can put the variables in a file:
.svn-credentials
REPO_USER=jane
REPO_PASSWORD=secret
Then run:
docker run --env-file .svn-credentials your/image
Remove the .svn-credentials file when your done.
Maybe using SVN with SSH is a solution for you? You could generate a public/private key pair. The private key could be added to the image whereas the public key gets added to the server.
For more details you could have a look at this stackoverflow question.
One solution is to ADD the entire SVN directory you previously checked out on your builder file-system (or added as a svn:externals if your Dockerfile is itself in a SVN repository like this: svn propset svn:externals 'external_svn_directory http://subversion.myserver.com/path/to/directory' ., then do a svn up).
Then in your Dockerfile you can simply have this:
ADD external_svn_directory /tmp/external_svn_directory
RUN svn export /tmp/external_svn_directory /path/where/to/export/to
RUN rm -rf /tmp/external_svn_directory
Subversion stores authentication details (if it not disabled in configuration) at client side and use stored username|password on request for the subsequent operations on the same URL.
Thus - you have to run (successful) svn export in Dockerfile with username|password only once and allow SVN to use cached credentials (remove auth. options from command-line) later