I just recently used Github, and when I was trying to upload my java project I realized that I was using some external libraries like apahce poi in this project, and these files have to be stored in libs for my application to function, do I need to upload these files because I realize that might violate some issues(maybe ?).
If yes, then what is the correct way to upload or maybe just post a link to those dependency
Use a tool that provides a dependency management system such as Maven or Gradle (these are both common choices in the Java ecosystem). Your project will then include a configuration file that Maven or Gradle will use to download dependencies so you don't need to distribute them with your project.
Related
I'm creating a Java project which includes a few libraries written by myself. However these libraries are not finished and sometimes require some edits. Because I'm working by myself, I find this more efficient than finishing all libraries perfectly before using them in my project.
My question is: is it possible to automatically rebuild a modified library when building the project which uses it?
Subquestion: what is the optimal configuration for my purposes? Should I export libraries as jar and copy them into the final project or should I configure buildpaths of my project to retrieve them in their respective folders?
Subsubquestion: is it correct to use .jar libraries in the same way that one uses dynamic libraries in c++?
If you have Eclipse set to "build automatically", it'll take care of rebuilding the library projects whenever you make changes, as you go along. You should set your client program to depend on either the Eclipse projects (if doing everything inside Eclipse) or the Maven artifacts (if using m2e). I strongly prefer using Maven for all my Java builds, but it might be overkill for something small. Whatever you do, don't manually export and reimport the libraries.
All libraries in Java are dynamic, and a C++ .so or .dll is the basic equivalent.
I want to create a simple RDF graph and then try simple querying using SPARQL. Since I'm familiar with java and net beans, I want to use Apache Jena on NetBeans. I downloaded the related files from http://www.apache.org/dist/jena/ .
What should I do next to write RDF codes on net beans? i.e Should I install something or add lib files/jar files somewhere?
(Too long for a comment on Ian's reply)
Maven is easy on netbeans, and a good way to get started with everything you need (as Ian says). Here's a quick guide to start a jena project:
File -> New Project. Choose Maven then Java Application.
Pick project name, location, etc., then Finish.
Netbeans will create a new maven project and open it.
Right click on Dependencies, choose Add Dependency....
Use org.apache.jena as the Group ID, jena-core (or jena-arq if you want SPARQL) as the Artifact ID, and 2.10.1 as the Version.
Open the Dependencies folder. It ought to have a number jars present -- these are jena and its required jars. You might need to right-click on Dependencies again and choose Download Declared Dependencies to ensure jena is ready for use.
Under Source Packages you'll find App.java. Try some of the simple jena api tutorials and try running them.
You need to put the .jar files from the Jena distribution where Netbeans will find them. I don't know Netbeans, but in Eclipse I might have a lib directory in my project top-level directory, and then set the Eclipse's project classpath to include each of those .jar files. Netbeans I'm sure has something similar.
Actually what I do in Eclipse is not use downloaded jars at all, but I would use Maven to manage the dependencies for me. So I would create a pom.xml file in my project folder that stated that, among other things, my project depends on Jena, and then Maven takes care of downloading the dependencies for me. Eclipse and Maven work well together; I'd hope the same would be true of Netbeans. Setting up Maven to use Jena is described on the Jena site. However, learning Maven can be a bit of a steep curve, so if you're not ready to take that on just yet then downloading the .jar files to a project lib directory is the way to go.
I am about to use maven to automate my builds. Unfortunately, I am not able to get all the features I want, even after reading several tutorials :(
I would be glad if somebody could explain a way I can achieve all my goals!
I want to automate 3 specific build tasks with several actions for a project from within eclipse, using m2e:
Build snapshot
compile
define current project version + date as version
build jar file
copy jar file into the local repository in the project path itself (ยง{project}/builds/)
Debug snapshot
build snapshot as mentioned above
copy jar file to plugins folder of a local test server
build another project the current project depends on, copy its jar file to the plugins folder aswell
launch server / connect to eclipse debugger (I know how to do that, the previous steps are the important ones)
Create release
compile
define current project version as version
build jar file
copy jar file into the local repository in the project path itself
create javadoc
copy source files and javadoc to an archive folder
increase the project version (for example v6 -> v7)
As mentioned I don't need a perfect solution, just a way to realize this ;)
(Annotation: Chaining multiple launch configurations is not a problem.)
Edit:
Which sections of the pom.xml do I have to modify to realize these steps and how can I invoke them using an eclipse launch configuration?
Hi based on your requirements i can say the following:
Build Snapshots
Building a SNAPSHOT is usually the convention during development cycle.
1.1 just using the conventions.
1.2 Date as version
This is a bad idea, cause Maven has some conventions how a version looks like (1.0-SNAPSHOT or 1.2.3-SNAPSHOT etc.)
1.3 Build jar file
Usually done by the jar life cycle (mvn package)
1.4 The local repository is on your home drive in ${HOME}/.m2/repository for all your projects. Technically you can do what you like but it's against the Maven conventions. The question is why do you need such thing?
2.1 Usual procedure
2.2 Usually a deployment is not a job for Maven but you can do such things by using cargo-maven-plugin (integration testing).
2.3 If you have dependencies between project you need CI solution like Jenkins to do such things otherwise you need to do this manually. But that is different from a multi-module build.
2.4 Integration testing different story. Depends on what exactly you like to do.
3.
1-7
The maven-release-plugin will handle such things except copying to the project path itself which is against the conventions. For such purposes you need a repository manager.
I can recommand reading these books: http://www.sonatype.com/Support/Books
When sharing a project with team members through version control, it is customary to include the .project in the source under version control. This makes sure that others on the team get all the dependencies and resources for the project. But the .project uses full/rooted paths to the resource, and not all members of a team will be working in the same environment. Even if all the members are on the same platform, the paths can often be in the user's home directory.
For the .classpath file, we can get around this problem by using build path variables. Each member defines the path to location of dependent libraries on their system, and the .classpath only refers to the variable.
This is a particular concern for Grails project - when we add a plugin, it updates the .project accordingly.
IMO resources themselves should not be part of the project at all. There is excellent plugin called m2eclipse which simplifies such tasks using Maven. It will immensely simplify your dependency management. All you'd have to keep in your version control system, besides your source code, is project configuration (pom.xml) - all the dependencies will be downloaded and cached automatically no matter what environment developer works in. There a lot more advantages in this approach - just read up on it :)
UPDATE: Just noticed "grails" tag on your question. if you're using Groovy - Maven can be replaced with Gradle. STS is probably the best Eclipse build to use if you're coding in Groovy. Next version of STS will have Gradle support.
General Approach
As others have mentioned, you should not keep the IDE files in VCS, you should keep an IDE-agnostic description of the project in VCS and generate the IDE-specific project files from them.
Java-Maven Example
Keep the pom.xml file(s) in VCS and generate the Eclipse files by running mvn eclipse:eclipse
Grails Example
A Grails project is described by application.properties and grails-app/conf/BuildConfig.groovy. These files are present in every Grails application. You can generate the Eclipse project descriptions from them by running:
grails integrate-with --eclipse
This command also supports other tools such as IntelliJ and Textmate
I don't think its standard practice to include the project file. I personally tell my VCS to ignore all IDE files, and just use VCS for the source. I include at the root level a README telling others how to configure the project (e.g. jars are in lib)
The resource links feature that you are referring to also has ability to use path variables. These are defined under Preferences -> General -> Workspace -> Linked Resources.
You could try keeping the project files in a shared Dropbox with an agreed upon path for each developer.
I'm doing the build automation for a java app with ant. This is a client-server app which has many projects in eclipse. I would like to create a jar file for the client and one for the server, but since the class dependencies are all over the projects (in eclipse)... I had the idea to use a tool to automate the search for dependencies. I've been looking at GenJar witch is almost all I need but it's not been updated in a while. So I would like to know if there are any other tools like this one, maybe Maven?
You may also try FatJar
It kind of sounds like what you really want is a WAR file.
Personally I would go with Ant + Apache Ivy. Each project has its own build.xml file and publishes to a central Ivy repository. Other projects will simply download these dependencies as needed.
The advantage of having an Ant based build process is that you can very easily automate it and use a continuous server to build the entire product after each check-in.