I'm trying to run an ant build in linux and I'm getting odd results. I can't seem to get anything to run without specifying each and every library on the classpath, so I systematically added every jar in the "lib" and "ant/dep/lib" locations to the classpath explicitly.
It runs a bit without any issues (it's a setup batch, so in the first phase of the script, it uses a lot of "input" tasks), then I receive the message that org.apache.tools.ant.taskdefs.optional.PropertyFile was not found. Looking around, I discovered it was located in ant-nodeps.jar and I had added it to the class path, but no change.
Complete failure due to missing libraries I can understand, but why would the build partially function if I was sure I was including every library (including ant-nodeps.jar)?
The script file to launch it is as follows:
#!/QOpenSys/usr/bin/bsh
ANT_HOME=dep/ant
PARAMS="-Dant.home=$ANT_HOME -Dsystem.type=as400 -Dis-as400=y"
LIBS="lib/ant-contrib-1.0b3.jar:lib/ant-launcher.jar:lib/ant.jar:lib/catalina-ant.jar:lib/catalina-deployer.jar:lib/commons-net-2.2.jar:lib/el-api.jar:lib/ganymed.jar:lib/jakarta-oro-2.0.8.jar:lib/jasper-el.jar:lib/jasper.jar:lib/jsp-api.jar:lib/log4j-1.2.16.jar:lib/mail.jar"
ANTLIBS="$ANT_HOME/lib/ant-antlr.jar:$ANT_HOME/lib/ant-jai.jar:$ANT_HOME/lib/ant-starteam.jar:$ANT_HOME/lib/ant-apache-bcel.jar:$ANT_HOME/lib/ant-javamail.jar:$ANT_HOME/lib/ant-stylebook.jar:$ANT_HOME/lib/ant-apache-bsf.jar:$ANT_HOME/lib/ant-jdepend.jar:$ANT_HOME/lib/ant-swing.jar:$ANT_HOME/lib/ant-apache-log4j.jar:$ANT_HOME/lib/ant-jmf.jar:$ANT_HOME/lib/ant-testutil.jar:$ANT_HOME/lib/ant-apache-oro.jar:$ANT_HOME/lib/ant-jsch.jar:$ANT_HOME/lib/ant-trax.jar:$ANT_HOME/lib/ant-apache-regexp.jar:$ANT_HOME/lib/ant-junit.jar:$ANT_HOME/lib/ant-weblogic.jar:$ANT_HOME/lib/ant-apache-resolver.jar:$ANT_HOME/lib/ant-launcher.jar:$ANT_HOME/lib/ant.jar:$ANT_HOME/lib/ant-commons-logging.jar:$ANT_HOME/lib/ant-netrexx.jar:$ANT_HOME/lib/xercesImpl.jar:$ANT_HOME/lib/ant-commons-net.jar:$ANT_HOME/lib/ant-nodeps.jar:$ANT_HOME/lib/xml-apis.jar"
java -classpath $LIBS:$ANTLIBS $PARAMS org.apache.tools.ant.launch.Launcher -buildfile install/install.xml
Any help would be appreciated, even if only suggestions for what to try.
EDIT: In light of oers observation, I realized that there are shell scripts for ant afterall (have pity, I'm no expert in linux), so I'm going to attempt to use it to launch ant rather than try to do the same thing myself. I'll let everyone know of my progress and/or if I was able to fix it doing it that way.
I looked into the shellscript on my machine.
There is an additional parameter set:
-Dant.library.dir=\"$ANT_LIB\"
Perhaps this is needed?
ant_exec_command="exec \"$JAVACMD\" $ANT_OPTS
-classpath \"$LOCALCLASSPATH\"
-Dant.home=\"$ANT_HOME\"
-Dant.library.dir=\"$ANT_LIB\" $ant_sys_opts
org.apache.tools.ant.launch.Launcher
$ANT_ARGS
-cp \"$CLASSPATH\"
$ant_exec_args"
Using the ant scripts to launch the setup seemed to do the trick, specifying parameter -lib as lib and -buildfile as install/install.xml.
Related
I administrate a jenkins instance on Linux.
I have been asked to pass a system-wide JAVA_HOME as a global ENV var for jenkins builds (as opposed to just jenkins itself), and I wish to do this through the service/daemon startup script. (Please don't give per-job Jenkinsfile / build pipeline solutions.)
Some plugins like maven-javadoc-plugin apparently require this variable.
(Curiously, this was never before necessary for the existing builds on this jenkins install. Either the used plugins changed, or jenkins did? Since I don't build on this, I can't say which.)
The only way I managed to do make this work for now, is using a fixed string through the GUI at <jenkins-url>/configure under "Global properties > Environment variables".
I understand I can add JDK installations under <jenkins-url>/configureTools/, but this, again, only allows fixed strings, which I can't be bothered to remember correcting on every system update.
What I should be able to do instead, is pass the ENV var to the jenkins service at startup, such as: JAVA_HOME=$(dirname $(dirname $(readlink -f $(which java)))).
jenkins (debian package) in fact brings an /etc/default/jenkins file,
which says you can pass a --javahome=$JAVA_HOME argument; like this:
/usr/bin/java -jar jenkins.war --javahome=/usr/lib/jvm/java-11-openjdk-amd64
However, this seems incorrect and does not work on current jenkins versions. It throws java.lang.IllegalArgumentException: Unrecognized option: --javahome=/usr/lib/jvm/java-11-openjdk-amd64 at winstone.cmdline.CmdLineParser.parse(CmdLineParser.java:52)
Since some other options uses camelCase (like --httpPort), I have also tried --javaHome=$JAVA_HOME instead.
This option is accepted (jenkins doesn't choke on startup), but it also doesn't work, it appears to get ignored?
I didn't manage to figure out if this should be the correct option from the source code either.
Jenkins version: 2.319
Perhaps someone can tell me if this used to work, is a bug, or how to do this if I'm doing it wrong.
[Note: This is ALMOST a duplicate of Linking to a library that hasn't been built yet with CMake, but in this case the unbuilt library is coming from an ADD_CUSTOM_TARGET rather than an ADD_LIBRARY, so CMake can't work its usual magic so effectively.]
One of my CMake 2.8 projects currently has the following code:
# the COMMAND was heavily simplified but you get the idea
ADD_CUSTOM_TARGET(custom_breakpad_target ALL
COMMAND cd ${CMAKE_SOURCE_DIR}/google-breakpad && make
)
# now here we are in the root "CMakeLists.txt"
LINK_DIRECTORIES(${CMAKE_SOURCE_DIR}/google-breakpad/src/client/linux)
ADD_EXECUTABLE(hello)
# ...many lines of code...
ADD_DEPENDENCIES(hello custom_breakpad_target)
TARGET_LINK_LIBRARIES(hello breakpad)
I know that LINK_DIRECTORIES has been deprecated (or at least disdained) because of its weird placement (it has to go before ADD_EXECUTABLE even though we'd really like to put it down next to the TARGET_LINK_LIBRARIES). Also, there's this nifty new command FIND_LIBRARY. So I'd like to write the root "CMakeLists.txt" more like this:
ADD_EXECUTABLE(hello)
# ...many lines of code...
ADD_DEPENDENCIES(hello custom_breakpad_target)
FIND_LIBRARY(breakpad breakpad ${CMAKE_SOURCE_DIR}/google-breakpad/src/client/linux)
TARGET_LINK_LIBRARIES(hello breakpad)
This code works fine... until I "make clean". The next rebuild fails to find breakpad, because it has been rm'ed and not created again yet by the time the FIND_LIBRARY runs.
How can I make this work? or make something work that's more elegant than what I've got?
So far, the best I've got is
ADD_EXECUTABLE(hello)
# ...many lines of code...
ADD_DEPENDENCIES(hello custom_breakpad_target)
TARGET_LINK_LIBRARIES(hello ${CMAKE_SOURCE_DIR}/google-breakpad/src/client/linux/libbreakpad_client.a)
This has the aesthetic disadvantage of having to explicitly write out the "libxxx.a" filename, whereas, as I understand it, FIND_LIBRARY would uncomplainingly continue to work even if we switched to "libxxx.1.so".
Building external targets through custom commands is very difficult to get right. CMake offers the ExternalProject module to assist with that.
With this module external libraries get build at CMake configure time - that is when running cmake for the first time and not when running make to build your actual project. This has the advantage that all of the files are already in place when configuring your project, so it is easy to locate them using a find script or a CMake configure file.
This approach of course only makes sense if the external library does not change frequently, because rebuilding the library requires running CMake again. If you need to recompile the external library upon changes by just running make, the best way to make it work is still to write a full-fledged CMakeLists.txt for it and pull that in with add_subdirectory.
I recently downloaded and installed the Groovy-2.2.0 windows binary, configured my system, i.e., Java is installed and functioning properly, etc. My GROOVY_HOME variable is set to C:\groovy-2.2.0, my path is set to C:\groovy-2.2.0\bin and C:\groovy-2.2.0\lib. However, unlike Groovy 2.1.9, the groovysh command generates a flood of errors (too long to post here) about an inability to run groovystarter. I'm using a WinXP (sp3) machine with Groovy-2.2.0 installed. Oddly, I can compile and run groovy programs. It is only the groovy shell that isn't functioning.
Thanks to a few helpful individuals, i.e., Guillaume, Cédric, and Pascal, the posted issue has been solved. There was a subfolder in my root directory, C:\, named C:\jline. I copied its contents to an unused subdirectory (as a backup) then deleted the C:\jline folder. After doing so, the groovysh command worked perfectly. I felt compelled to post the solution in the event another programmer experienced the same or perhaps highly similar and related problem.
~Caitlin
I am building a Linux system with cross-compiler using ptxdist. It allows me to configure Qt4 for installation and it builds and installs qt-everywhere-opensource-src-4.6.3 Ok. However, the qmake internal settings are screwed up and I don't know how to fix them.
When I run qmake -query I get:
me#ubuntu:~$ qmake -query
QT_INSTALL_PREFIX:/
QT_INSTALL_DATA:/
QT_INSTALL_DOCS://doc
QT_INSTALL_HEADERS://include
QT_INSTALL_LIBS://lib
QT_INSTALL_BINS://bin
QT_INSTALL_PLUGINS://plugins
QT_INSTALL_TRANSLATIONS://translations
QT_INSTALL_CONFIGURATION:/etc/xdg
QT_INSTALL_EXAMPLES://examples
QT_INSTALL_DEMOS://demos
QMAKE_MKSPECS://mkspecs
QMAKE_VERSION:2.01a
QT_VERSION:4.6.3
Through some research, it looks like this can be fixed by simply rebuilding Qt, but it's not fixing this problem. I dug into the build output a bit and it looks like the ./configure command for the Qt build has "-prefix /usr" so I don't know why this isn't being fixed.
I would like to fix these internal values manually if possible because the Qt build takes hours. Does anyone know how to do this?
At configure time these paths are hardcoded in 'src/corelib/global/qconfig.cpp', and end up hardcoded into qmake when it is built. They are also hardcoded into many other files, like all the .la and .pc files, not to mention the Makefile install rules.
The only way to fix this is to figure out why configure keeps screwing up the prefix. configure is a big shell script, so it's easy to see where $QT_INSTALL_PREFIX is assigned from the '-prefix' argument, and then the different checks that are done on it (like running it through 'config.tests/unix/makeabs'). Try putting print statements before/after $QT_INSTALL_PREFIX is changed, and you should be able to find out where the path gets screwed up.
Also, you don't have to wait for the full build to complete to tell if the prefix was set
correctly. After configure runs, take a look in 'src/corelib/global/qconfig.cpp' and see what 'qt_configure_prefix_path_str' is set to.
You can manually set these properties using
qmake -set VARIABLE VALUE
They are stored using QSettings, the Qt built-in persistent applications settings.
see Configuring qmake's Environment
Configure scripts can be fuzzy about slashes. Are you sure that the build prefix is /usr and not /usr/ .
First of all, I'd like to ask to correct my question title if something better comes into your mind.
Let's take a Lift REST web service example from the Simply Lift book by David Pollak here.
If I open a Windows (Windows XP SP3, all the updates, Oracle JDK 7) console inside the directory and run "sbt" (sbt.bat), everything works just fine. But in case I try to do the same (but using "./sbt") in Linux (XUbuntu 11.10, OpenJDK 6, OpenJDK 7, Oracle JDK 7 (tried all of them)), SBT returns (instead of going to SBT console mode) immediately as it has done it's job. This means that may the command be just ./sbt it returns about immediately (after finishing the automatic project maintenance), or be it ./sbt jetty-run - it just starts the web server and shuts it down immediately.
Moreover, a web service I've developed for a project of mine compiles and works ok on Windows, but can't be compiled (using ./sbt compile) on Linux (by the same version of SBT). The error is "source file '/.../src/main/scala/code/lib/FooBar.scala;src/main/scala/bootstrap/liftweb/Boot.scala' could not be found", where "FooBar.scala" is an object where I do all the serves (directly called from Boot.scala).
Any ideas of what can be the reason and how to fix it?
UPDATE: The reason of the first problem (SBT returning to shell instead of offering SBT console) seems to be the file was checked out on Windows and had CR+LF instead of just LF line ending. The solution of source files not being found was in just using clean command to recompile from scratch.
The reason of the first problem (SBT returning to shell instead of offering SBT console) seems to be the file was checked out on Windows and had CR+LF instead of just LF line ending. The solution of source files not being found was in just using clean command to recompile from scratch.
First what happens when you simply type:
java -jar sbt-launch.jar
directly from the command line in the folder where the sbt-launch.jar is placed ?. If the sbt-launch.jar is in the same folder as the sbt script then you can edit the script to look like this:
#!/bin/sh
test -f ~/.sbtconfig && . ~/.sbtconfig
java -Xmx512M ${SBT_OPTS} -jar dirname $0/sbt-launch.jar "$#"
The dirname $0 construct returns the full path of the sbt script folder without the filename of the script. Using the $SBT_OPTS variable allows you to experiment with the various JVM options, like:
SBT_OPTS="-Xss2M -XX:+CMSClassUnloadingEnabled"
Although I would wait with these options as they are likely not the problem here (however be sure to add CMSClassUnloadingEnable later when SBT is working as it ensures that Scala class definitions generated dynamically when running SBT gets unloaded when they are unused, thus preventing memory errors - see more info here):
Also consider using one of
-Djline.terminal=scala.tools.jline.UnixTerminal
or even
-Djline.terminal=jline.UnsupportedTerminal
in your SBT_OPTS.
Finally what happens if you try a never version of SBT ? (you could try running the SBT 0.11 version of the lift example found here https://github.com/lacy/lift-quickstart).
Replace your Linux script by:
#!/bin/bash
java -Xmx512M -jar `dirname $0`/sbt-launch.jar "$#"
On your settings:
Your script sets Xss (the Thread stack size). In Linux you sometimes need to change (via ulimit) the settings for stack per thread (ulimit -s) as you may have conflicts at SO level which may be triggering the "kill" on your threads. Unless you have a very important reason to set this flag just remove it and let the JVM manage this.
It may also be you wanted to put Xms instead of Xss, although then 2M would make this flag irrelevant (heap too small to be practical)
The flag -XX:+CMSClassUnloadingEnabled allows GC to sweep the Perm space. It shouldn't be necessary for sbt. As you can read here the PermGen options will only pospone PermGen issues, so if you have problems with PermGen when running Jetty, just add a bigger PermGen via -XX:MaxPermSize