I have created a dynamic web project. A user library with a jar file is also created.
Then the user library has been added to the build path via
project properties--->java build path--->In libraries tab required user library has added and jar file is specified under it.
But exporting the project into the JBoss deployment directory is raising class not found exception over the class in added jar file.
How can I properly add a user library to my project's build path?
I'm not clearly understand your problem but there is nothing to discuss ;)
Because the Java EE Specifications and the application server are dictating how to place something in your app's classpath and that's it.
Here is the documentation:
https://docs.jboss.org/author/display/AS71/Class+Loading+in+AS7
If your problem is not regarding the result on the appserver, only something about comfor or project strcture you want in your IDE. Then use your build system (Maven) to do the job. Like bilding a jar and coping it to desired location etc.
I'm trying to upload a file via FTP client using Java, but when trying the:
import org.apache.commons.net.PrintCommandListener;
the PrintCommandListener is show in red. I verified my library and it does include commons.net. What should I do?
PrintCommandListener is in fact in Apache Commons Net. For example, if you download the current version, the jar you need to include in your build path is commons-net-3.3.jar. If this single jar is seen by your compiler, then the class should be recognized. Make sure there are no other classes called PrintCommandListener (for example custom ones that you might have written) in your build path.
If using an IDE (such as eclipse) make sure the jar is on your build path. For example, with Eclipse right click project, go to Java Build Path and click Add JARs. Navigate to the location of your jar file and add it.
I had a question that was answered with adding jfxrt.jar to standard Eclipse build path.
I followed the suggestion, adding the jfxft.jar as an External Jar on the jdk1.7.0_10.jdk JRE i have installed (under Eclipse > Preferences > Java > Installed JREs).
But when I import "javafx.application.Application"
It errors with:
Access Restriction: The type Application is not accessible due to restriction on required library /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/lib/jfxrt.jar
There are posts on this such as Access restriction: Is not accessible due to restriction on required library ..\jre\lib\rt.jar
I can fix this possibly by the suggestions in that thread (though I'm not convinced they are good solutions).
Or I found a better solution of adding the External Jar directly to the project:
- go to the JRE and remove the External Jar as setup above
- Open project properties and go to Java Build Path
- Go to Libraries tab
- Add External JARS... and choose exactly the same jfxrt.jar
No access restrictions now!
Why does it work one way but not the other? The advantage of adding directly to the JRE configuration is that it only needs to be done once.
Thanks,
Hank
I would not recommend adding JARs to the JRE configuration like that, it's just too easy to forget they are there and that can lead to confusing behavior if you don't expect that particular JAR to be on the build path for a particular project. Also, what happens if one project wants to use a different version of the library?
There are at least 2 other options that I would consider:
Define a User Library for JavaFX and then include the User Library on the projects that need it. You still would have to add the User Library to each project that needs it, but that's not such a big deal IMO, as it only has to be done once for each project.
Create a separate project to contain the JAR(s), call it something like "JavaFX Libs." Add the JARs to its build path and make sure to export them on the Order and Export tab; then add "JavaFx Libs" project as a dependency for whatever projects need it.
Alright, so I have a web service that was created using an eclipse dynamic web project. It is currently shared on a CVS repository, but the versioning system used is irrelevant. At the moment, I have literally NEVER been able to pull this project out as is and get it working. It leads to countless errors that cannot be fixed. Every time I need to work on this webservice in a new machine I have to create an entirely new dynamic project, copy over the source files, add all the necessary libraries and make the deployment assembly work correctly again. After finally making it run I share the project as the same one, stop after a second, and then synchronize again (in a way tricking eclipse into thinking this was the shared project all along).
I feel like others must have run into this problem and found a way around it. So if you have a web service or any dynamic web project, what files do you share, and how do you successfully pull it from the repository and get it to run on another machine besides what I currently do now?
Your help is much appreciated,
-Asaf
Edit: After reading some of the responses I feel that this question is actually more specific to those who use WTP to create/test their web services. Just wanted to add the clarification.
Edit2: Let me also clarify that the other 20 or so projects not using WTP are shared just fine. I am able to pull and run them with no problem. Only web service projects are an issue.
In general, you want to check in everything that's not "derived" (generated or compiled - that's usually the contents of the bin directory or other place where your code is compiled/built into). For Eclipse Java projects, you want to include the .project, .classpath, .settings, and any other similar files that Web Tools might create for Dynamic Web projects. The Eclipse CVS client will ignore files marked as Derived so you shouldn't have to worry to much about it.
Without more detail about what kind of problems you've run into, it's not possible to guess what was causing them. My only guess is that perhaps you had different versions of Eclipse and/or the WTP (Web Tools Platform) plugins installed on the different machine. That's just a wild guess, but could explain some incompatibility when you check out the project from CVS.
Bottom line, checking in those .* files is the long recommended approach from Eclipse gurus. Maven can kind of change things, but you didn't mention it so I'm assuming you aren't using it.
I am primarily sharing my experience, may be you can find some help.
Conceptually speaking, the files which the IDE can generate itself while creating new project should not be pushed. I.e the IDE specific files should not be pushed. And everything which the IDE cannot generate on its own must be pushed.
Forexample in case of eclipse, following files should not be pushed:
.settings
build
.classpath
.project
For setting the project on new machine, first pull the files from server, and then create a project from IDE using pulled files.
EDIT: If your project has external jars/libraries, then you will have to add to the classpath manually. You could also push .classpath but that might give errors while creating a new project.
I think it's easiest to use a build system and let the IDE generate the project from your build system.
Eclipse, Netbeans, and Intellij are all pretty good at building projects from maven or ant build files. With this solution you have a simple build that is easy to setup in CI (Hudson, Bamboo, whatever) and you don't have any IDE specific files checked in. If my workspace is totally different than yours, with different versions, plugins, whatever, I'm not stuck with your project file and you're not stuck with mine. My IDE creates the project appropriate for my environment and your IDE does the same for yours.
Since you mentioned having to manually add libraries, I assume you are not using any build manager (like, maven or ant) besides ecplise.
For ecplise to handle the project properly you need the source files (*.java) in their respective directories, any resources bundled with the web service (e.g. services.xml), the ".project", ".classpath", ".settings", etc. files for eclipse. This should be enough for eclipse to generate anything else necessary to build the project.
Any files/directories that are generated by eclipse during the build process (e.g. target & bin directory, *.class, *.war) should not be checked in -- they will be generated when needed during the build.
I am thinking that, since you are adding the necessary 3rd-party jars manually, these libraries might reside in a different path between computers (e.g. if the path contains the username, it will not be transferable to another computer for a different user). To fix that you can set up the classpath using an eclipse classpath variable. In Preferences->Java->Build Path->Classpath Variables set up a varable linked to the "root" folder where the 3rd party jars a stored. Then add the libraries to the project using this new variable, not their full path. To make it work on someone else's computer, you would only need to set this classpath variable to have the build path point to the correct libraries.
It might be beneficial if you migrated your project from eclipse only to a build manager (e.g. maven) that takes care of many of these issues for you. Eclipse can build a project from the configuration of the build manager, making it easier to manage the project.
I'm building an Android application (as an Eclipse project) that needs to access a web service. We will be sending the data from the service as JSON serialized classes, so we want to share some of the classes between the Android application and the server application. We are currently thinking that the way we need to do this is to structure our Git repository with 3 folders. One for the client, one for the server, and one for the shared library.
But at that point we couldn't figure out how to create the shared code. It looks like we can put all the .java files into a folder and then create a relative link to that folder from the other projects, but is that a good way to go about this?
The other possibility we found was to create another project in Eclipse and then include the library project in the client project. However we ran into a problem here. How can we make the library usable by both the server and Android? If I create a new Java project in Eclipse, I must select a JRE to build for, but Dalvik isn't an option, and even if it was how could I use the library with a desktop VM if the library was compiled for Dalvik?
I would use 3 projects:
server
shared
client (android)
and include shared as a project dependency in both server and client. If you use ant you'd drop the shared.jar in both server/lib and client/lib every time it's changed, and if you use maven it's a dependency (possibly with Ant + Ivy it's also a dependency). Consider Nexus as a repository location in that case.
You don't actually need to create a separate Eclipse project for the shared classes. You can just create a 'common source folder' outside of the other two projects' disk hierarchy. For both the server and client projects :in the Properties/Java Build Path/Source add a 'Link source' to the new folder. (Perhaps this is what you meant by 'relative link'). It's easy to add this common source folder to an Ant build file.
You could add the path to the classes/JARs to the server's runtime classpath.
Since it's unclear which one you're using, here's just a generic answer based on Apache Tomcat.
Open /conf/catalina.properties file.
Edit shared.loader entry to include the path to the package root of those classes or JAR file(s).
E.g.
shared.loader = /path/to/classes
or
shared.loader = /path/to/specific.jar
or
shared.loader = /path/to/*.jar
You can even specify multiple paths separated by a comma.