So there's a folder /usr/share/stuff in the root directory
in stuff there are a bunch of java files with package org.name definitions at the top
I am running javac test.java where test.java is in a subdomain
I added /usr/share/stuff to my class path.
and at the top of test.java I add import org.name
But I get a package does not exist error...why?
There is not a performance or overhead cost to doing import .* vs importing specific types. However, I consider it to be a best practice to never use import .* My primary reason for this is I just like to keep things straightward, clean and with as little ambiguity as possible, and I think with a .* import you lose that.
This works:
package com.example.model;
public class BearExtra {
public static void go() {
System.out.println("Yay, it works!");
}
}
package com.example.web;
import com.example.model.*;
public class Bear {
public static void main(String[] args) {
BearExtra.go();
}
}
Now, to compile and run these classes, go to the directory where you can "see" the com folder and do:
javac -cp . com/example/model/*.java com/example/web/*.java
java -cp . com.example.web.Bear
javac -cp . comexamplemodel*.java comexampleweb*.java
java -cp . com.example.web.Bear
and the following is being printed to the console:
Yay, it works!
Ideally, you shouldn't use a Spring Boot application (something that's been repackaged) as a dependency. From the documentation:
Like a war file, a Spring Boot application is not intended to be used as a dependency. If your application contains classes that you want to share with other projects, the recommended approach is to move that code into a separate module. The separate module can then be depended upon by your application and other projects.
If the proposed solution isn't possible in your situation, the documentation goes on to describe an alternative:
If you cannot rearrange your code as recommended above, Spring Boot’s Maven and Gradle plugins must be configured to produce a separate artifact that is suitable for use as a dependency. The executable archive cannot be used as a dependency as the executable jar format packages application classes in BOOT-INF/classes. This means that they cannot be found when the executable jar is used as a dependency.
To produce the two artifacts, one that can be used as a dependency and one that is executable, a classifier must be specified. This classifier is applied to the name of the executable archive, leaving the default archive for use as dependency.
To configure a classifier of exec in Maven, the following configuration can be used:
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <classifier>exec</classifier> </configuration> </plugin> </plugins> </build>
David, The location of the directories doesn't matter. It's the packages that matter. You can add multiple directories to your classpath when you compile/run the program to refer to these extra directories.
Are they in the right subdirectories?
If you put
/usr/share/stuffon the class path, files defined withpackage org.nameshould be in/usr/share/stuff/org/name.EDIT: If you don't already know this, you should probably read this: http://download.oracle.com/javase/1.5.0/docs/tooldocs/windows/classpath.html#Understanding
EDIT 2: Sorry, I hadn't realised you were talking of Java source files in
/usr/share/stuff. Not only they need to be in the appropriate sub-directory, but you need to compile them. The.javafiles don't need to be on the classpath, but on the source path. (The generated.classfiles need to be on the classpath.)You might get away with compiling them if they're not under the right directory structure, but they should be, or it will generate warnings at least. The generated class files will be in the right subdirectories (wherever you've specified
-dif you have).You should use something like
javac -sourcepath .:/usr/share/stuff test.java, assuming you've put the.javafiles that were under/usr/share/stuffunder/usr/share/stuff/org/name(or whatever is appropriate according to their package names).