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.
Related
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.
The wos2 server.bat sets the carbon class path to pick up jars from the lib folder however the server.sh tries to pick them up from bin.. see code below.. this causes us a big problem because in the dss documentation it says to put the database connector jars in the lib folder:
CARBON_CLASSPATH=""
if [ -e "$JAVA_HOME/lib/tools.jar" ]; then
CARBON_CLASSPATH="$JAVA_HOME/lib/tools.jar"
fi
for f in "$CARBON_HOME"/bin/*.jar
do
if [ "$f" != "$CARBON_HOME/bin/*.jar" ];then
CARBON_CLASSPATH="$CARBON_CLASSPATH":$f
fi
done
for t in "$CARBON_HOME"/lib/commons-lang*.jar
do
CARBON_CLASSPATH="$CARBON_CLASSPATH":$t
done
Can anyone explain this?
WSO2 Carbon is the OSGi based platform for all WSO2 java products. In Carbon, there are four different “lib” folders. If you have ever tried any of the Carbon based products, you may have thought “why are there four different libs?”. If so, this post will provide you the answer for that question.
These are the “lib” folders that you can find in Carbon.
[1] CARBON_HOME/webapps/ROOT/WEB-INF/lib
Carbon is a web app which is deployed in an embedded tomcat instance. This is the lib folder which is specific to Carbon web app just like any other web app has in WEB-INF/lib folder. Bridge servlet is the one who forwards each and every incoming request into the OSGi environment of Carbon. We have used this lib to place our Bridge Servlet. Tomcat pics it up from there and hands over the incoming requests to it.
[2] CARBON_HOME/repository/components/lib
This is the place to put your normal jars if you want them to become pure bundles in the OSGi environment. All packages in these bundles are exported into the OSGi environment. As you may know, Carbon can be extended as you wish. You can add your own bundles into it. So If you have dependent jars for those bundles, you can place those in this lib.
[3] CARBON_HOME/repository/lib
This is the place where all client libraries exist. When you run ‘ant’ from CARBON_HOME/bin, all needed jars are put into this folder. If you want to write a client (or you can generate it using the WSDL2Java tool in WSAS) and test it, the set of all jars you need in the classpath can be found in this lib. For example, WSAS samples are run by adding all these libs into client classpath.
[4] CARBON_HOME/lib
This is the place where we put all jars which are needed by tomcat to start and some others for specific reasons. This is same as the Tomcat root lib. These libraries can be seen from all webapps deployed. And also, if you place the same jar in this lib and also inside Carbon web app, it will be picked up from this root lib as Tomcat uses parent first class loading.
*** there are few libraries that are available in bin folder to get initiate the OSGi service and some special things. You can't put any jars in to the bin to reflect OSGi level or any other class loaders.
You have to put the database connector jar into DSS_HOME/repository/components/lib directory and restart the server[1]. It adds them into server class path.
[1]https://docs.wso2.com/display/DSS301/Changing+the+RDBMS
Is there a full download I can use which downloads leiningen and all related stuff in one go? I am not able to change the proxy settings on my local network, and this is the error I get:
"DownloadFile" with "2" argument(s): "The remote server returned an error: (407) Proxy Authentication Required."
Update
You need to download the Leiningen standalone jar and then point LEIN_JAR to it:
set LEIN_JAR=full path to leiningen standalone jar
For me - setting the proxies didn't work (and downloading the jar was unsatisfactory)
I got:
the wget binary, and
the wget dependencies
and put them on my PATH - ie h:\util contains:
wget.exe
libssl32.dll
libintl3.dll
libiconv2.dll
libeay32.dll
(where H:\util was already on my path. )
and then got a new terminal cmd.exe - and then lein self-install worked.
Assumptions:
Downloading the jar was unsatisfactory because the point of lein is to be a dependency manager (like maven). You need to keep downloading stuff. If you manually download the first jar - then when you add some more jar dependencies to your project you'll have to manually download those as well. Might as well chuck out lein and go back to doing things on the Java classpath.
In my view - in a windows environment proxy settings should be automatically detected. Lein can't do this (yet) - but the wget version I downloaded could. So you solve the problem of needing to explicitly specify the proxy. (In addition - manually setting the proxy just didn't work for me)
This should help:
https://github.com/technomancy/leiningen/wiki/HTTP-Proxies
You should work on your googling skills ;)
I want to post this as a comment to #hawkeye, but I dont have enough reputation. This work for me only when I set environment variable.
set HTTP_CLIENT=wget --no-check-certificate -O
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
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.