On 20/03/12 04:24, Paolo Castagna wrote:
Hi Rob,
this is a problem I sometimes have when I check out stuff from trunk,
mvn package it and then I use the scripts in bin/.
Is this what you were doing?
Somehow, the scripts search for Java binaries in the classes/ directory
instead of target/classes. Only if you fire up Eclipse and compile the
project with Eclipse you'll find out you have stuff in the classes/
directory.
Here is a message where I was having probably exactly your problem:
http://markmail.org/message/yxxofyp6h5cpwmdx
In other projects, I use the same directory for Java binaries from
Eclipse and/or Maven and I did not notice major issues.
You can get contamination of the build directory with a mixture of
Eclipse compiled and maven compiled .class files. You have to be
careful to clean to get a proper build.
Also, you can end up running old class code in Eclipse. It's probably
timestamp problems or Eclipse class caching but you can make changes and
still be running the old code in Eclipse. (There is a related problem
with cross-linked Eclipse projects not seeing changed class files but I
think this one is m2e related.)
Using m2e can't support anything other src/main and src/test. Even
then, it messes with the classpath which makes it hard to extract and
debug tests.
m2e isn't completely stable yet. I'm using it in it's purest form in
another project and sometimes I have to hit the manual reset button on
that project.
In other
projects again, I have separate directories, as we do in Jena, but
I ensure the scripts point to the Maven directory by default not
Eclipse one (this is to enable users to checkout, mvn package and
run scripts without the need for Eclipse).
Having said that, all this stuff affects only developers who checkout
stuff, however we should make our and their life as easy as possible.
See:
http://svn.apache.org/repos/asf/incubator/jena/Jena2/ARQ/trunk/bin/make_classpath_mvn
My proposal is to:
- CP="$DIRROOT/classes${CP}"
+ CP="$DIRROOT/target/classes${CP}"
See the discussion at the time.
Can we have a solution that does fix one thing by breaking something
else? By your own admission, that will break Eclipse development unless
you do something else as well.
The suggestion at the time was to test for the existence or otherwise of
$DIRROOT/classes. if it exists, add it, else if the maven target dir
exist, add it.
(A clever person will notice a subtle issue in that algorithm but it'll
work for now.)
Andy
PS The scripts are now mostly "sh" scripts, not "bash". On Ubunut
"/bin/sh" is "dash" which is faster to start than "bash".
andy
Let me know if this is your problem, or we have something else going
on which is Mac OS X specific (which I doubt).
Paolo
Robert Vesse wrote:
Well I was trying to run the ARQ scripts in this case, bin/arq_path prints the
following:
/Users/rvesse/Documents/apache-jena/arq/classes:/Users/rvesse/Documents/apache-jena/arq/classes:/Users/rvesse/.m2//commons-codec/commons-codec/1.5/commons-codec-1.5.jar:/Users/rvesse/.m2//org/hamcrest/hamcrest-core/1.1/hamcrest-core-1.1.jar:/Users/rvesse/.m2//org/apache/httpcomponents/httpclient/4.1.2/httpclient-4.1.2.jar:/Users/rvesse/.m2//org/apache/httpcomponents/httpcore/4.1.3/httpcore-4.1.3.jar:/Users/rvesse/.m2//com/ibm/icu/icu4j/3.4.4/icu4j-3.4.4.jar:/Users/rvesse/.m2//org/slf4j/jcl-over-slf4j/1.6.4/jcl-over-slf4j-1.6.4.jar:/Users/rvesse/.m2//org/apache/jena/jena-core/2.7.1-incubating-SNAPSHOT/jena-core-2.7.1-incubating-SNAPSHOT-tests.jar:/Users/rvesse/.m2//org/apache/jena/jena-core/2.7.1-incubating-SNAPSHOT/jena-core-2.7.1-incubating-SNAPSHOT.jar:/Users/rvesse/.m2//org/apache/jena/jena-iri/0.9.1-incubating-SNAPSHOT/jena-iri-0.9.1-incubating-SNAPSHOT.jar:/Users/rvesse/.m2//junit/junit/4.9/junit-4.9.jar:/Users/rvesse/.m2//log4j/log4j/1.2.16/log4j-1.2.16.jar:/Users/rve
sse/.m2//org/slf4j/slf4j-api/1.6.4/slf4j-api-1.6.4.jar:/Users/rvesse/.m2//org/slf4j/slf4j-log4j12/1.6.4/slf4j-log4j12-1.6.4.jar:/Users/rvesse/.m2//xerces/xercesImpl/2.10.0/xercesImpl-2.10.0.jar:/Users/rvesse/.m2//xml-apis/xml-apis/1.4.01/xml-apis-1.4.01.jar
This looks fairly sane although it appears to be missing the references to the
actual ARQ jar/class files which would explain the problem. Why would the
scripts not pick that up, is there any assumption about the path for ARQROOT -
I have it set to the root folder of the ARQ trunk in my environment?
Rob
On Mar 19, 2012, at 12:58 PM, Andy Seaborne wrote:
On 19/03/12 16:51, Robert Vesse wrote:
Hi All
So I raised this issue a while ago in relation to TDB but I've been
playing around a bit and found that I can't seem to get any of the
bash scripts distributed with any of the modules to work for me on OS
X
I reliably get an error such as the following regardless of which
command I try to run:
Exception in thread "main" java.lang.NoClassDefFoundError: riotcmd/riot
Caused by: java.lang.ClassNotFoundException: riotcmd.riot
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
Which means that the class path is not getting properly configured.
Given that these scripts have been in the distributions for a long
time I'm gonna to assume user error on my part but knowing very
little about bash I have no idea how to go about debugging the
problem.
What are the possible causes of seeing this problem with the scripts?
What should I be checking to make sure my environment is sane and get
the scripts actually running? I've set ARQROOT but maybe I've set it
inappropriately, which directory within ARQ should it point to?
Thanks in advance,
Rob
Rob,
I'm not sure what's a happening - is this the released version or development
version?
You need to set TDBROOT although the scripts tend to complain if you don't.
If in the development version:
1/ Make sure the local repo is up-to-date, e.g. the ARQ jar
2/ See if environment variable M2_REPO points to the right place.
What does bin/tdb_path print?
(This is invoked by tdb-init)
Andy
