I have a project that shares models with my android project. I have a separate eclipse project just for models and other shared code. I add this to my play project as a dependency in eclipse.
In eclipse, play compiles and starts without problem. However, I went to deploy to GAE and found that the compilation stage of play's packaging fails because it can't find the models.
I suspect I could hack the ant build files, but that seems brittle.
Is there a standard way to add extra directories to the play compilation source tree or the classpath?
Make a jar-file with your classes and put it in /lib. That's where I put my libraries.
Files in the application /lib folder is automatically added to the class path by Play Framework. See Classpath settings
From Anatomy: "The app directory contains all executable artifacts: Java and Scala source code, templates and compiled assets’ sources" ... and further: "You can of course add your own packages, for example an app/utils package"
You can copy java source files to make a hierarchy of packages under /app, e.g.:
/app/sharedcode/project2/models/domain1 and import that in WhateverController.scala as:
import sharedcode.project2.models.domain1._
Related
I cloned a GitHub repo onto my disk an successfully built the project by:
ant clean-all resolve create-dot-classpath
within the projects root directory.
I assume this should also be possible from IntelliJ IDE but that fails by doing nothing at all - it simply states "All files are up-to-date" ... what I do is:
"Make module 'pentaho-kettle'"
"Compile module 'pentaho-kettle'"
I could use a hint where to look for a solution or what configuration is most likely missing.
As the project is a multi module project based on Ant and Ivy, you have to
import the project from sources
configure modules (like core, ui, the plugins, …) with the right directories for main and test sources and resources (they seem to overlap with java sources in that project)
setup the class path using an Ivy plugin (I recommend IvyIDEA), use the context menu on the ivy.xml file
and have luck to build. It will be some try and error!
You may also have a try importing from Eclipse as those .project and .classpath files are checked in. But than you also have to check the module directories, the import is more a partial guess and I worry that IntelliJ will not get any information about Ivy from the Eclipse setup.
I'm working on a Java project for which I need a very specific testing code, which I create in Jasmin, the JVM assembly. The project is built with Ant and has a nice directory structure, namely:
root
/src
/classes
/tests
/build
/classes
/tests
The tailor-made Jasmin source file is in the src/tests directory, together with the JUnit Java files. All of these get built with Ant (I use the simple "java" Ant task to run the Jasmin compiler on the source file), they're put into respective directories inside the /build folder, and Ant then runs the JUnit tasks. All of this works fine...
Until I introduced the single Jasmin-generated class, Eclipse worked perfectly with the project. The problem is that Eclipse doesn't see the new .class file. The Build Path contains src/classes and src/tests as source folders, and /build as an output folder. Yet it doesn't seem to be able to find the class generated by Jasmin, so there are hundreds of "ClassX unresolved" problems and it really makes developing quite painful.
Does anyone have an idea how to force Eclipse to see this class?
A simple solution would be to compile Jasmin classes into a separate class folder and then add that folder into Eclipse's build path: Project Properties / Java Build Path / Libraries / Add Class Folder...
It's been tedious. This is the API I am trying to use. Its resources were set up in a pom.xml which I built using Maven. On built up, it gave me the project socrata-publisher that has
src/main/java the source folder with packages com.socrata.api com.socrata.data, com.socrata.util where each contains only .java
files
JRE System Library and Maven Dependency hierarchies where each contains a number of jar files
Problem is com.socrata.api and the 2 other contains classes which I want to deploy in a project outside socrata-publisher. I tried using import com.socrata.api but it didn't work. Moreover, since its a Java project and not android it doesn't have the is Library option in preferences which could rather give me the solution. Both socrata-publisher and tutorial (where i want to use the resources and which is the android application) lie in the same directory eclipseApps in My Documents.
Here's a little visual queue. Help will be greatly appreciated.
You will need to first of all get the output of the socrata project and all its dependencies.
In command line, going to the project folder of the socrata project, where the pom.xml file is, run MVN INSTALL. You shall see a jar file called socrata-api.jar in $HOME/.m2/repository. If you are using windows and installed MAVEN by default, $HOME should be your user profile folder. Once you see the jar file, add it to your tutorial build path.
I think what you actually want to do is just set up the "socrata-publisher" as a project dependency for your "tutorial" project. That will allow you to reference the built Socrata libraries from the code in your project.
Right click on the project and select "Properties". From within that dialog select "Java Build Path" on the left, then the "Projects" section, and click the "Add" button to add the "socrata-publisher" project.
I think that'll work better than creating a separate jar file that you then include, and then you can also keep the socrata-publisher code up to date using Git.
Probably really simple but I just cannot work out how to use any API's with Java (Using Eclipse).
Where do they go?
For example I want to use a Twitter API and I import it using:
import net.unto.twitter.Api;
I then include the API file in the same dictionary as my class file. (This is what I do in python)
Anyone care to tell me the simple answer?
Typically APIs are packaged in so-called JARs, which stands for Java ARchive. What you should do is:
Download the jar.
Put it in some sort of 'lib' directory in your project structure. Do not put it with your source code.
Add the jar to your classpath. Some IDEs you have to add jar by jar, others you tell the IDE which directories are library directories and it will modify the classpath for you to include all the jars in the directory.
Import the relevant package in your files where you use the API.
Once you have the jar added to your classpath and import the relevant classes, Eclipse should automatically pick it up and allow you to use autocomplete features against the API.
It is also a good idea to get the source jar for any libraries you download. Most IDEs let you attach src jars, so you can click into the API and see how the code is written.
You need to include any external JARs in the build path. In eclipse right click on the project and go to 'Build Path' > 'Configure Build Path' then go to the 'Libraries' tab and 'Add JARs'. Also, when using eclipse it is easier not to maintain the import statements yourself, but instead use 'Organize Imports' (ctrl + shft + o) or Import the selected object (ctrl + shft + m). If a matching object is available in the classpath it will be imported.
Java APIs are distributed in JAR files (which are just zip files with a specifiec directory structure).
Download the jar in question, put it in a known location on your disk (known location as in, pay attention to the name of the direcctory where you store the downloaded jar).
There are two times you will need to reference a Jar file:
During project compilation. This includes development of the project using an IDE like eclipse (they all compile the code to find errors).
Option 1, add an external jar:
Open the project properties in Eclipse
Select Java Build Path
Select the Libraries tab
Click the Add External Jar button
Browse to the location of the JAR in question.
Select the JAR.
Click the Open button.
Option 2, add the JAR to your web project's WEB-INF/lib directory.
During project execution. This will be after you deploy your application to a web container (perhaps tomcat). Store the JAR in question in the classpath of the appliction post deploy. For simple web applications, you can put the jar in the project WEB-INF/lib directory.
You should have it included in the classpath (build path) of the project.
In Eclipse Java EE perspective, how does one add a thridparty Jar to a Utility Project?
To elaborate: In a "normal" Java (Not Java EE) project, there's Referenced Libraries where you can put jars. In a Dynamic Web Project, there's Web App Libraries. In a Utility Project, there's only EAR Libraries, which don't appear relevant (well, there are Referenced Libraries that show up in the Package Explorer in Java perspective, but not in the Project Explorer in the Java EE perspective). I went ahead and added a /lib directory under my Utility Project root, and put a jar there (I forgot if I did that in the Java Package perspective, or just in the file system). I added it to Java Build Path, and everything compiles, including the Dynamic Web projects that reference the Utility Project. But when I deploy to Tomcat, I get ClassNotFoundException for the classes in the thirdparty jar.
How do I add the thirdparty jar to the Utility Project in a way that will make it get deployed as part of the web application?
I answered something similar before.
Eclipse and How it Handles JARS -- Odd Case
In essence, there's a difference between build-time and run-time JAR dependencies. For inclusion in EAR / WAR files, you have to use the "Deployment Assembly" panels.
I am not sure to understand exactly your question, but you can simply right-click on your project, in Properties you select Java Build path > Libraries, and then add your JAR in the list of third parties libraries. This will add your jar in the classpath project.
Another way is to use the (ugly) solution of creating a lib directory, put all your third parties libraries in it, and add this directory in the classpath of your project (like for the previous solution, as you can add a whole directory in Eclipse project).
The last solution is to give the responsibility of the dependencies management to a real build system, such as Maven, Ant+Ivy, Gradle...