I am trying to build Tomcat 6 or 7 on my machine from provided source codes.
I have checked out the sources from repository and ran the ant build.
In the very beginning of the build Ant needs to download the libs Tomcat needs. In the 6th version it is done by separate command 'ant download', in the 7th version this command is incorporated into build.xml.
The problem is that Ant cannot download the libs Tomcat needs for build while trying to build both the versions.
It stops here:
trydownload:
[get] Getting: http://www.apache.org/dist/tomcat/tomcat-connectors/native/1.1.24/source/tomcat-native-1.1.24-src.tar.gz
[get] To: /Users/dmitrijskorov/libraries/tomcat-native-1.1.24/tomcat-native.tar.gz
After printing this nothing happens. No errors, no end of execution. The file itself is created inside the folder for downloads, but its size is 111KB instead of 262KB if I download it manually. Ping of that server also evaluates ok.
Looks like I have problems with Ant download task.
Probably the reason is some proxy settings I need to provide to Ant. But I dont know how to find out my proxy settings. All settings in all browsers and OS point to automatic detection of proxies and thus I cannot setup proxy in Ant build. And I dont know whether I need this at all.
MacOs Lion, Tomcat 6 or 7, Java 6.
With Ant 1.7 or later you can use the -autoproxy option to Ant to tell it to use the proxy settings from the operating system
ant -autoproxy download
Ref: Ant manual
Related
Installed clean windows10(1607) and intellij idea(2020.1.2 community edition). When i create new gradle project
Invalid Gradle JDK configuration found. Open Gradle Settings
"gradle-wrapper.properties not found".
How can I fix it?
Install gradle 6.7
sdk install gradle 6.7
brew install gradle
Go to IntelliJ and set gradle version:
On File >> Settings >> Build, Execution , Deployment >> Gradle
or
Preferences >> Gradle
In Use Gradke from specific the correct location
If IDEA is set to use the Gradle wrapper (as it is in your screenshot: "Use Gradle from:" is set to "gradle-wrapper.properties"), IDEA expects the following file structure:
Gradle wrapper JAR: [project root]/gradle/wrapper/gradle-wrapper.jar
Gradle wrapper properties: [project root]/gradle/wrapper/gradle-wrapper.properties
Gradle wrapper script: [project root]/gradlew.bat
If you are missing one of these three elements, IDEA will attempt to generate the wrapper by calling the gradle wrapper task. It will do this using the Gradle JDK, which may or may not be the project SDK (File > Settings > Build, Execution, Deployment > Build Tools > Gradle > Gradle JVM).
I'm not sure how it selects the version of Gradle it uses - I only have 6.8.3 installed on my machine, and I had my wrapper properties set to 7.0-rc-1, yet somehow it used 6.7.0 when generating the wrapper.
I tried various options for clearing the cache, but did not get the result.
Openjdk-14 installed by default and does not work. From site adoptopenjdk.net install OpenJDK 11 (LTS). When creating the project, I chose 11 version. Then the program suggested updating gradle to version 6 and it worked.
I ran into this problem a while ago when I upgraded to intellij 2020.* The first time I created a new project there was no problem: gradle daemon did its work and the project was created with no problems.
In my case, the project would start a new gradle daemon, and attempt to build the project, would get rejected by windows Security, and nothing would happen, so intellij goes ahead and starts another (unsuccessful) daemon. Soon, I had 20+ gradle daemon processes running on my system, all of them doing nothing.
So, it looks like intellij has messed in enabling that it places the appropriate permissions it requires for these folders that it depends on to run properly. So, you need to manually give these permissions, and then things (should) work.
The real issue here is security on your machine: either a virus checker or the security software, Windows Security on Windows 10, for example. The first time you make a project, Intellij goes and produces a number of folders that they need access to.
However, once these folders are available, for whatever, intellij doesn't make sure to give itself access.
On windows 10, in AppData, you'll find several folders required by Intellij to produce, in my case, produce gradle projects.
Try finding the various folders that Intellij has produced on your system, and give them exceptions on your virus checker and on whatever firewall/security software programs that may block access.
I have a Spring Boot 2 project which is a ReST API, and I am using Spring Rest.
I am using 2 plugins to generate an SDK other projects to import to call my API. The first plugin is com.github.kongchen:swagger-maven-plugin:3.17 to generate the swagger-codegen-spec file, and the second is org.openapitools:openapi-generator-maven-plugin:3.2.3 to then generate the actual SDK files as another mvn project.
Finally, I have automated component tests that use that SDK to run tests against the running API.
My goal, is to actually BUILD the SDK as part of the original project build. So when I run "mvn install" on my-api-project, I end up with the web-app jar AND the sdk jar when it is complete, without having to run "mvn install" on the SDK as a secondary step.
I've successfully accomplished this on Linux/Mac in 2 different ways. First was to use the antrun plugin. However, this did not work on my co-worker's Windows 10, 64 bit machine. He was getting many issues regarding invalid directories and shell not being installed, etc.
So I tried using the exec-maven-plugin instead, which seems to be a lot cleaner, and more OS agnostic. Again, this works great in Linux/Max, but in Windows, now we get this error:
Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.5.0:exec
(build swagger-codegen sources) on project my-api: Command execution
failed.: Cannot run program "C:\Program Files\Apache\maven\bin\mvn"
(in directory
"C:\Users\user1\Documents\GitHub\my-project\my-java-sdk"):
CreateProcess error=193, %1 is not a valid Win32 application -> [Help
1]
When he uses the cmd window he can run "mvn install" in that directory just fine.
Any ideas??
This error was fixed by upgrading the exec-maven-plugin version to the latest version. Spring Boot was supplying the version, which was 1.5.0, but the latest is 1.6.0.
Does anyone know of a maven, ant, or gradle plugin that supports invoking cygpath? The cygpath utilities knows how to convert Windows filesystem paths (c:\dev) to cygwin/unix style file paths (/cygdrive/c/dev).
I've searched the internet but didn't find anything. The closest is this jenkins plugin (https://wiki.jenkins-ci.org/display/jenkins/cygpath+plugin).
Context:
I'm trying to automate creating an omniORB maven artifact from the omniORB source tarball. One of the first things I have to do is patch the omniORB source with filesystem paths that match our development environment. On every developer's machine we have an environment variable the specifies the location of their maven repo e.g. c:\mvrepo. The omniORB Windows binaries are built with cygwin. I need to set the omniORB makefile to locate some dependencies from c:\mvnrepo\some-dependency but with a cywin-style path /cygdrive/mvnrepo/some-depenendency.
I cant vouch for it a I haven't used it or looked at it closely but here is a gradle plugin that might be of use: https://github.com/derianto/Gradle-Cygwin-Toolkit-Plugin
In any case, since gradle scripts are written in groovy it should be fairly easy to just code your own solution into your build script if you have to.
utoday I got the task to integrate a floating license server for install4j to our build process. Therefore I read the README.txt and the following two threads:
install4jc-specifying-floating-server and floating-license-setup-on-a-headless-ubuntu-server
Now there are still some questions left. Therefore I will describe our build environment shortly. We are using maven to build our software and installer and startet to test install4j by using the maven-plugin for install4j:
We installed the install4j application as zip file to our maven repository
during maven build we download and extract this file to some target directory
until now we installed the demo-license via maven-plugin to the install4j folder
during the package-maven-phase we using the maven-plugin to build the installer mediums
That works very nice. Now the company decided to buy a license-bundle including a floating license server. But how to include this to our build process? My suggestion would be the following:
install license server to a server reachable over the network
modify the config.xml file at the zipped application of the maven-repository and integrate the floating-license-server address or set maven-plugin-license property something like FLOAT:[server-ip]:11862 at the build configuration?
Is the license-key gotten by ej-technologie only necessary for using the ui? Has anybody some similar build environment and can give me some information how to setup this correctly?
Thanks in advance
set maven-plugin-license property something like FLOAT:[server-ip]:11862 at the build configuration?
That would work for the multi-platform edition. If you have the Windows edition, you have to go with:
modify the config.xml file at the zipped application of the maven-repository and integrate the floating-license-server address
As for:
Is the license-key gotten by ej-technologie only necessary for using the ui?
The license key is entered in the license server. Both IDE and command line compiler contact the license server. Only the IDE actually checks out a license as long as the IDE is open, the command line compiler just verifies the validity of the license.
I am working on a project where i want to copy the compiled file (which compiled through jenkins) from one windows server to another through jenkins. Jenkins is installed on a windows server and after building the code, those compiled file should be copied to another windows server through jenkins. Is there any way to achive it?
Jenkins might be able to do it, via the script steps running the scp command; however, if this is part of a build, I would suggest attaching the file(s) to a project, and distributing them through the maven repository.