I have been trying to get Gradle working on our Continuous Integration server, which has no access to internet (external) URLs.
Currently, we get our maven-style dependencies from an internal proxy server. So I uploaded the gradle wrapper onto that server too, such that when the CI server starts up it can download the wrapper from the internal maven proxy server.
Problem solved, I thought; the build will carry on and pull down the project dependencies from the internal proxy server as well (it's set up in the build script) and should be OK now.
But in between getting the wrapper Zip file and starting the build, it's doing the following:
Downloading http://maven.internal.mycompany.com:8081/nexus/content/repositories/thirdparty/org/gradle/gradle/1.0-milestone-3/gradle-1.0-milestone-3-bin.zip ................
Unzipping /home/user/.gradle/wrapper/dists/gradle-1.0-milestone-3-bin.zip to /home/user/.gradle/wrapper/dists
Set executable permissions for: /home/user/.gradle/wrapper/dists/gradle-1.0-milestone-3/bin/gradle
Download http://repo1.maven.org/maven2/org/codehaus/groovy/groovy/1.7.3/groovy-1.7.3.pom
Download http://repo1.maven.org/maven2/antlr/antlr/2.7.7/antlr-2.7.7.pom
etc...
*** then the actual build starts ***
Download http://maven.internal.mycompany.com:8081/nexus/content/groups/public/commons-lang/commons-lang/2.6/commons-lang-2.6.jar
E.g. it's trying to pull down extra dependencies for the gradle executable from repo1.maven.org which fails on the continous integration server, as it has no access to this server.
In my build.gradle file I have:
repositories {
mavenRepo urls: "http://maven.internal.mycompany.com:8081/nexus/content/groups/public"
}
and in my ./gradle/wrapper/gradle-wrapper.properties file I have :
distributionUrl=http\://maven.internal.mycompany.com:8081/nexus/content/repositories/thirdparty/org/gradle/gradle/1.0-milestone-3/gradle-1.0-milestone-3-bin.zip
So is there another place I can specify which server the wrapper should use to get it's additional dependencies ? Or is this hard-coded into the wrapper itself ? Or I might be missing a trick here, as Google doesn't seem to show up anyone else having this issue at all !
Ben
Picked up a hint from another forum that led me to the answer - a plugin for cobertura that I was pulling down had it's own gradle build file that included the default maven repositories.
I've removed that now, and the calls to external maven have ceased.
Related
I am using Grails 2.2 and the plugins are really old. For some reason the dependencies are not resolving. I think it used to work because the plugins and files were in my local cache. From the documentation grails stores the dependencies locally in home/.grails/ivy-cache
With all these declarative dependencies, you may wonder where all the
JARs end up. They have to go somewhere after all. By default Grails
puts them into a directory, called the dependency cache, that resides
on your local file system at user.home/.grails/ivy-cache. You can
change this either via the settings.groovy file:
So the only option i can think of is to go to my remote server and find this directory to copy the dependencies to my local system. So where is this ivy-cache directory in production server? I dont seem to find it. Thanks for any help.
The same issue also I was working in the last week, from 15th January maven had decommissioned the http protocol where the URL "http://repo1.maven.org/maven2/" has changed to"https://repo1.maven.org/maven2/". Also need to check the grails maven to secured.
In BuilConfig.groovy, you can add the dependencies and the changed maven repo else in the _Events.groovy need to change the repo address to secure protocol.
If still you have protocol issue because of JDK8 try this -Dhttps.protocols=TLSv1.2 -Djdk.tls.client.protocols=TLSv1.2 in the path or bat file.
I have upgraded nexus repository from 2.x to 3.x through following path:
2.4.14 -> 3.4.0 -> 3.5.1
All nexus services were packed in docker with data directory mapped from host's. For all services I use default either sonatype/nexus or sonatype/nexus3 containers. Nexus web interface is hidden behind nginx with simple reverse proxying.
I use the nexus service with boot-cj (with no credentials) tools which manages dependencies the same way as maven. Anyway the tool first downloads nexus-maven.xml with relevant sha1 files and tries to download jars. It works fine with all 2.x I had.
I created a proxy repository against remote sonatype-snapshots repo. When I start compilation I have Could not find artifact error. I found that the meatdata files are cached but all poms and jars.
I have tried to fix it by cleaning cache with the clean_cache file trick and more rough rm -rfv /srv/nexus3/nexus-data/cache/* with no success. There are no any logs about error. Also I have checked manually that required artefact exists in the remote repository. More obvious Rebuild index button gave no solution. I do not thing it is a problem with nginx, but who knows? Also leaving overnight to run the scheduled tasks did not help.
The expected artifact is org.eclipse.rdf4j:rdf4j:pom:2.3-20170901.145510-11.
I am working with WSO2 ESB and I would like to build my .car project like RPM to deploy on Redhat servers.
I have several .car project and I have to manage dependencies between them. I have thought that it is a good idea to do it.
Has anybody tired this before? Where can I find more information about this? Should I use hot-deploys putting .car file into /repository/deployment/server/carbonapps directory?
Thanks in advance.
You can use hot deploy putting .car files into carbonapps, but take care of downloading them on the ESB local filesystem before moving them to carbonapps so that the ESB don't start deploying them before the end of the download.
You can develop your own script and rely on a config file defining dependencies so that your numerous .car are deployed in the right order
You can use maven and plugin org.wso2.maven:maven-car-plugin that offers you a way to package and deploy your .car from a remote host with something like mvn clean deploy -Dhost=esbhostname -Dport=9443
Hope it gives you some ideas to achieve your need...
I've modified a .jsp file in the org.wso2.carbon.identity.entitlement.ui package, in order to customize the server for my purposes.
The problem is that when I build the project with Eclipse, the build is successful, but I don't understand how I can actually run the compiled code. How can I do it?
Once you build the project with maven, in the target directory you will find the jar (OSGi bundle). In your IS Server under /repository/component/patches, create a new directory something similar to "patch0100". Copy the jar inside this "patch0100" directory and restart the IS server.
The number in the patch directory (0100 in this case) is important. If you put the same jar to a patch directory with a higher number, say pactch0200, that particular jar with override the earlier one. That's how patching works in WSO2 Carobon Server, which is the platform on which the products are built.
I need to deploy a production version of a web application. So far, I've been testing it with mvn jetty:run. I've used actual jetty installations before, but they seem only necessary when you want to serve multiple wars on the same web server. In some ways this is the most staightforward however (mvn package and copy it over).
My other options are to create a runnable jar (mvn assembly:single) that starts a server, but I need to tweak the configuration so that the static content src/main/webapp is served and the web.xml can be found.
I've also read about a "runnable war". This might avoid the src/main/webapp problem since these files are already laid out in the warfile. I don't know how to go about doing this, however.
I could also stick with mvn jetty:run, but this doesn't seem like the best option because then the production deployment is tied to code instead of being a standalone jar.
Any opinions on the best way or pros and cons of these different approaches? Am I missing some options?
The jetty-console-maven-plugin from simplericity is simple to use and works great. When you run mvn package you get two wars--one that is executable. java -jar mywar.war --help gives usage, which allows a bit of configuration (port, etc.).
I'm not that familiar with maven, but this is how we approach deployment using embedded Jetty:
We create a single-file JAR with the embedding jetty app and the necessary lib jars packed.
We deploy the static content in a WAR file (which you can package into the JAR as well). Everything is generated by an ANT file that:
1) Build the static files WAR (this also creates the web.xml)
2) Copies the WAR into the application resources
3) Compiles an executable JAR
To get the embedded Jetty to "find and serve" your static files, add the war with a WebAppContext to the Jetty handlers:
Server jetty = new Server(port);
HandlerList handlers = new HandlerList();
WebAppContext staticContentAsWar = new WebAppContext();
staticContentAsWar.setContextPath("/static/");
staticContentAsWar.setWar(resource_Path_to_WAR);
handlers.addHandler(set);
jetty.setHandlers(handlers);
jetty.start();
HTH