I'm beginning to play with Clojure a bit and my Java experience is pretty limited. I'm coming from the dynamic world of Ruby and OO, so the functional side of things is very interesting!
Anyway, as I discover libraries and various tools for use (and the tutorial files for the Pragmatic Clojure Book), everything typically calls for placing files in the CLASSPATH in order for Clojure to see the library for use.
Is there such thing as good CLASSPATH practice? Would I ever want to only have a CLASSPATH with just the external libraries of files I need or can I go ahead toss any library or file I would ever need in a directory and simply define it as my CLASSPATH and only require what's needed?
If it helps, I'm an OSX and Emacs user (Using slime and swank-clojure).
I recommend using leiningen and lein-swank to manage this. You can start a REPL in the directory and connect to it from Emacs.
Personally, I'm using a variant of a clojure-project elisp function by Phil Hagelberg, see source in this post to the Clojure group. It sets up the classpath appropriately for the project you'll be working on, then launches SLIME. (EDIT: You'll need to change the value which gets assigned to swank-clojure-jar-path to point to clojure.jar. I'm using (expand-file-name "~/.clojure/clojure.jar") as the default.)
To answer the question about having everything on the classpath all the time vs only throwing in what's needed: to the best of my knowledge, nothing will actually break if you take the first approach (I know I do that for experimental purposes), but apparently things might break with the first approach (see cjstehno's comment below) and in a proper project I find the second to be cleaner. At some point it'll be necessary to determine what libs are being used (and which versions of them), if only to tell leiningen (or maven) about it -- why not keep tabs on it as you go.
We are using Clojure and use a number of infrastructure tools, especially Eclipse (IDE) (http://en.wikipedia.org/wiki/Eclipse_%28software%29) and maven (http://en.wikipedia.org/wiki/Apache_Maven). maven manages libraries and jar dependencies so if you have a number of these and they are likely to grow start using maven.
In answer to your original question you can just put your jars in one directory and you can access them by name every time you run. But you will benefit from the tools...
If you are just exploring then Eclipse will probably manage your jar files fairly painlessly. You can add these to the project as required through the Build Path -> Configure Build Path option.
As your work progresses you will possibly wish to split it into Projects which Eclipse supports so you can add your (or other projects) to your Build Path.
If you use external Clojure libraries look to see if they have been packaged as maven projects (they will have a pom.xml file). The POM will give a list of dependencies.
#
The usual CLASSPATH practice for Java is to put only the jar files needed for a project into this projects class path, which means to have potentially different class paths for diffent projects. This is usually managed by the IDE as part of it's project properties.
Since you are using Emacs and thus probably don't have or use something like projects it might be more convinient for you to set up and use a single global class path for all your clojure related stuff or maybe even simply put all the needed jar files into the java2se/jre/lib/ext directory of your java installation.
The two main problems that could arise from having unneded jar files in your class path are: 1. it has a minor negative impact on the start up time of the JVM and 2. it becomes more difficult to make sure that you are not having classes with different versions in the same class path (i.e. different classes with the same package and name in different jar files).
Since Java SE 1.6 (or JDK 1.6) you can include class path entries by wildcard. If your class files live in .\bin, and your library jar files live in .\lib, then on Windows you could define your class path like this:
set CLASSPATH=bin;lib\*;
This will let you add jar files into the .\lib directory and they will automatically be added to the class path for new instances of the JRE.
See this link for details: Setting the class path
Prior to JDK 1.6 you had to add each jar file onto the ClassPath individually.
I just discovered this bit which I need to give a shot:
(setq swank-clojure-extra-classpaths (list "/class/path/1" "/class/path/2" "/class/path/3" "etc"))
clojure-contrib/launchers/bash/clj-env-dir has an interesting property that you can point it at a directory and it will basically include anything in there. In the past I've had a ~/classpath directory which I would dump any jars into and link any commonly used directories and it worked great. Very simple way to dump and use. Now I tend to use Maven clojure-maven-plugin and that works well also though can be a bit tedious when you just want to muck around with some ideas.
Related
I have recently started using Sightly in AEM 6.1, which allows the Java files to be located in the same folder as the component and use the WCMUse class. However, I am noticing that whenever I do a Maven build that involves a change to one of those Java files that the page functionality operates as if the Java class had not been changed, though the Java file in the crx does include the changes. As a workaround I have been been able to modify the Java file in the crx, save it, then modify it back and save again in order to update the functionality, but I do not have that capability on all of my instances.
Anybody have an idea how to force the recompile of the Sightly Java within the components either during or following the build?
A few things to validate:
1- Do you change the version of the software when doing a maven build/deploy? Sometime if your zip or jar does not have -SNAPSHOT in it AEM won't update the code when maven deploys.
2- there a /var/classes/sightly in CRX/DE that you can delete compiled classes, I think even in the system console there is an entry
Hope this help.
Bambara actually helped me get to the answer that I needed. It turns out the /var/classes folder holds the compiled sightly files, but it doesn't naturally recompile on build. Deleting that folder on build, then running a page that uses the sightly code forces a recompile and shows the new functionality.
Hopefully others can answer why this happens and how to avoid it. Having faced this a number of times, I'm beginning to think placing Java code into the component folders is not a very good idea. Using a maven multi-module project with a Services/Core bundle, then all Java code could go there. Calling it from the view just requires using the fully qualified classname (including the package). Placing the Java into the services bundle has the following benefits
Allows the classes to be extended. For some reason compilation was unpredictable when extending classes from component folders.
Easier IDE setup. Java classes in component folders in the view module have a Sling specific folder structure, so getting IDE's to provide code assist requires extra effort.
Sling folder conventions follow URI practices and might have dashes, Java packages cannot have dashes... import apps.my-cool-project.components.pages.base.Header; // won't compile
I check out a java project from svn repository include .classpath and .project files. And I import these codes into eclipse. But the eclipse will modify the content of .classpath file. How can I stop eclipse to do this? just write off build automatically option?
You can't. But instead of putting a JAR on the Java build path you could
choose an execution environment which should stay stable when you change
the JRE and hence the .classpath file will not change either.
.Project and .classpath files should not be checked in under svn repos.Blindly copying such files from one machine to another may be risky. These are the files that eclipse automatically constructs for you as per your project structure. If you want to edit, you can do that.
Here is the nice explanation What's in an Eclipse .classpath/.project file?
Adding information to a 2-year old question just in case of any one else is stumbling across this.
Due to insufficient detail in the original question, I am guessing that the problem experienced is due to the project's classpath pointing to a different location on the questioner's machine as on the original project author's machine. When a project uses 3rd party libraries (JARs) and is shared between different team members (as hinted at by the use of a version control tool), this is a common occurrence.
A solution to this would be to have all team members set up the location of the directory containing all 3rd party JARs to have an identical structure on all individual machines. So instead of changing the classpath, change the directory structure to that required by the classpath.
Unfortunately this is not always the best solution:
Team members may have different operating systems (Windows vs Linux) and you will not be able to have a (absolute) class path that works on all platforms (e.g. C:\libraries\3rdparty.jar vs /opt/libs/3rdparty.jar)
Team members may differ in how they prefer to organize their directory structure. Especially, if a team member places libraries into his home directory (e.g. C:\User\abcd\libraries\3rdparty.jar or /usr/abcd/libs/3rdparty.jar), another team member will struggle to replicate that directory structure.
Eclipse provides various methods to set up a project so that it can easily be shared between team members. These however require team members to all agree on the convention, and will be slightly easier if set up by the original project author right from the start. Two methods most commonly used:
Add all third-party libraries to the project itself (the usual convention is to have a /lib directory inside the project for this - on the same level as /src and /bin etc.). The classpath can now be set up to be relative to the project's root and thus usable across different setups. A variation for large multi-project-file projects would be to have a separate eclipse project containing the libraries, then add it to other projects as a dependency ("Required projects on the build path" in the "Java Build Path" dialog).
This has the benefit of being able to version control your JARs too. However, it may use up a lot of extra storage/bandwith, so may not always be desirable. For instance, I would not do this with Java Enterprise Edition JARs contained in my preferred Application Server distribution, as I may want to migrate my project in future to a new version or another product, without such dependencies - I also do not want to have my project saddled with duplicate JARs that are in any case already available in the AS distribution. So you need to think through your requirements.
Eclipse also provides the concept of a classpath variable. This may be set up to point to the root of a team member's JAR-containing directory, and be extended with subdirectories and filenames inside the classpath. This needs to be done only once, and is also accessed via the "Java Build Path" dialog.
Whenever a new team member uses the project for the first time, he needs to configure eclipse (once) to point that variable to the relevant path on his own machine.
The above mechanisms are explained in more detail on various web pages, here is one reference: http://www.informit.com/articles/article.aspx?p=367962
I have a project that uses a lot of external libraries (mostly .jar files). I am using Eclipse Helios Service Release 2.
When something doesn't work, the problem is usually caused by missing jars or some problem with classpath. What I have to do, is to check that all necessary jars are correctly included in my classpath.
The problem is that I have several libraries imported + external jars (in case of libraries, the classpath only points to the directory with the jars) and Eclipse provides no easy way to search for included jars. If there was any kind of function that would work like this: "search for xyz.jar" and find if the jar with given name is already included somewhere, instead of manually controlling this, it would be a great help.
It would also help if Eclipse provided a function to sort all the jars and libraries by name instead of displaying them in the same order they are specified in path (I mean only in the project manager, of course).
So my question: is there an easy way to check these things or do I have to do that manually? I have cca 30 jars to include and cca 300 already there and this is a real pain...
You could use a build environment, such as Maven, to manage your dependencies for you. Then Eclipse does zero thinking on its own and your life becomes far more pleasant (particularly when the time comes to package your code for release).
I couldn't imagine managing 300+ dependencies any other way.
I was recently given some code that was worked on by someone other than myself, and after lots of work involving hunting down external dependencies, and editing the build.xml file to get ANT to build things in a sane way, I'd like to now get the code into a subversion repository.
The team I'm working on is rather small, but the members on the team change often. So I want people to be able to start working on this code as quickly as possible. A simple checkout from the repository, and opening the project in Netbeans to have everything building and executing properly would be ideal.
How do I achieve this when there are external dependencies that are not going to be on other team members machines?
Should I place the libraries my project uses in the VCS?
How do I instruct subversion to not track generated files such as class files and jar files?
Should binary resources that are unlikely to change such as images and sounds be placed in the VCS? If not what would be the best way to distribute them?
Thank you.
1) yes. Anything needed to build and deploy the application and isn't generated by the build process goes into version control (yah, I know the maven fanz don't like that).
2) make sure everything that's generated goes into distinct directories that you exclude from version control.
3) see 1). Same thing. Same with project documentation, release notes, etc. etc.
The biggest problem of course are directory names which will be set in your IDEs configuration files and differ between development machines.
Not just the location of the project directories, but the IDE itself, JDKs and other tools, appservers, can all be different between machines. It's a constant problem.
I usually use maven cause you can have a repository for jars and dependencies this makes life easier, but since you have already refactor your code to use ANT maybe this is not what you want, to use subversion with netbeans then you might want to add another folder for jars like libs or something and then another for the binaries like audio etc. Also check for the svn plugin for netbeans it will add the ignore to the dir and just update java files.
To add files to ignore you can use
svn propset svn:ignore -F .
or you can look for the config file in your subversion home and add something like this
global-ignores=*.classs
Hope this helps
I'm writing a java app using eclipse which references a few external jars and requires some config files to be user accessable.
What is the best way to package it up for deployment?
My understanding is that you cant put Jars inside another jar file, is this correct?
Can I keep my config files out of the jars and still reference them in the code? Or should the path to the config file be a command line argument?
Are there any third party plugins for eclipse to help make this easier? I'm using an ant build file at the moment but I'm not sure I know what I'm doing.
Is there an equivelent of the deployment projects in Visual studio, that will figure out everything you need and just make an installer? I've used install4j before, and it was powerful if no where near as automated as .Net deployment projects.
Cheers.
There is no one 'best way'. It depends on whether you are deploying a swing application, webstart, applet, library or web application. Each is different.
On point 2, you are correct. Jar files cannot contain other jar files. (Well, technically they can, its just that the inner jar file won't be on your classpath, effectively meaning that jar files do not contain jar files).
On point 3, you certainly can reference config files outside the jar file. You can typically reference a config file as a file or a resource. If you use the resource approach, it typically comes from the classpath (can be in a jar). If you use a file, then you specify the filename (not in a jar).
In general, most Java developers would use Apache Ant to achieve deployment. Its well documented, so take a look.
(1) An alternative to ant that you may wish to consider is maven.
A brief intro to maven can be found here.
For building a JAR, maven has the jar plugin, which can automate the process of ensuring all dependent jars are listed in your jar's manifest.
If you're using eclipse, then download the maven integration as well.
(2) Another alternative is to use OneJar (disclaimer: haven't tried this myself).
The answers vary depending on what kind of thing you're building.
If you're building a library, it's best to distribute your work as a jar file. It's possible to refer to your jar dependencies via the Class-path attribute in your jar manifest, although I generally think that's uncool. That attribute was designed for applets and it's used infrequently enough in libs that when this technique pulls stuff into the classpath (particularly common stuff the user might already be using), you can get unexpected version conflicts. And it's hard to track down why you're seeing them.
Publishing a jar to a Maven repo with pom info to track dependencies is an excellent choice for libraries as well. If you do that, please publish your Maven coordinates in your docs!
If you're building an app, the two popular choices are to distribute a zip/tar/whatever of a deployment structure OR to use an installer program. If the program is a server-ish kind of thing, the former is far more common. The latter is more common for clients. Generally, the installer program is just going to lay out the deployment structure and maybe do some extra tasks like installing in OS-specific locations.
To build your deployment structure (aka "kit") you'll want to create a repeatable process in whatever build system you're using. Ant has copious examples of this and Maven has the assembly plugins that can help. Generally you'll want to include a jar of your code, any dependencies, scripts to start the program, maybe a JRE, and any other resources you might need.
If you want to create an installer, there are many options both free and commercial. Some folks I know have recently had good experiences with the free IzPack but check out your options.
You should try FatJar. It's an Eclipse plugin that with just a right click at the Project can build a JAR file with all you need to run the application, including the necesary third party JAR.
We use it everyday, in conjuction with JSmooth to create the executables, to deploy our software packages to our customers, and works like a charm.
Well, if you are speaking of deployment of a standalone desktop application:
Before we switched to web start we have been creating three deployment archives, one for windows, one for mac and one for other platforms.
On windows we have successfully used the Nullsoft Scriptable Install System (known for it's usage by the older winamp versions) and its ant task, although some drawbacks are:
It is only usable on windows AFAIR
You have to do some work by hand, i.e. customizing the wizard-created script AFAIR
It can create a windows installation with start menu entries on the other hand. There also exists an eclipse plugin for integrated NSIS shell script editing.
On Mac OS X there is an ant task to create an .app file from your java files so that you can start it like a native os x application. But beware of not writing any setting to your home dir and using the the application dir instead.
For others you have to expect they are in a un*x env and deploy your app with a shell script to start the application.
In any case you may have to deploy your custom policy file to get access rights for your application.
If you want to get rid of all the packaging and stuff you should seriously consider using web start. We have saved much time since switching to it, i.e. simplified our deployment process, takes care of updates etc.
Update 2014
Use maven assembly plugin, see section "Creating an executable jar"
Ant. It's not the best thing in the world, but it's standard, it's apache, and it works.
There's some good examples on the web how to make a simple build.xml for any, and it's got some features like the 'war' task that knows how to put all the basic stuff (classes, web.xml etc) in the jar file for you.
You can also tell it to pick up other config files and jars and it will happily do it.
It's also really smart about what to compile. You give it a directory, and it finds all the java files and builds them only if their classfile is out of date, so you get some of the traditional make functionality for free without much effort.
You could look at other java projects (e.g. JMeter, SquirrelSQL, JEdit, Cernunnos, etc.). Each package their applications slightly differently, so consider your goals when you review these.