I was working on a project with a seriously large amount of classes that I want to compile to a jar. I know about entry-points and the manifest.txt and all the needed items inside my jar, my classes are all compiled and have the .class file and everything, but the problem is I will have to add all the class files to the final jar in compilation through a single line in Command Prompt. I was wondering and stumbled upon literally nothing in the internet if it could be done in an easier way because I will be updating my work constantly and have to recompile and re-jarify my work. I have heard of third party programs that will do the trick, but somebody on some website said that they could potentially be causing problems and stuff, so I dropped the idea quite quickly. Now that I am in a seriously tight spot though, I wish to hear opinions and suggestions on this. So to sum up:
I want a way to compile a big bunch of .class files in a single jar without typing all of them over and over again between compilations allowing me to save time and frustration.
I would prefer native stuff if this is even possible to do - e.g. the jar compiler of the JDK instead of anything third-party. If there is a way to do this using manifest or any other file in compile-time arguments, let me hear it.
Anyone who cares to suggest, discuss or give me a good reason why to or not to use third party applications for this will be most welcome.
Keep in mind that I work on Windows but my aplication will be cross-platfrom, so don't suggest as a main option some compile solution that will make a final file with a .exe extension (although if anyone knows how to do this, I would like to hear it in a comment as I wonder about this as well).
Thanks in advance and if you feel the need to ask me anything to help you reply, shoot away!
Have a look at this ant tutorial which shows how to write a simple build.xml which can compile and jar.
http://ant.apache.org/manual/tutorial-HelloWorldWithAnt.html
You can then adapt it for your own needs.
Note: ant is only suited for smaller projects like yours.
The solution to this, and related, issues, is to stop typing at the command line and use a build tool. The common tools here for Java builds are:
Apache Ant http://ant.apache.org
Apache Maven http://maven.apache.org
There are other less common ones. Both of these tools will provide you with what you need.
Just want to add some information about Ant and Maven.
In your case, you need to automate the build of your application. The basic solution would be some kind of script but it's not used at all. Nicer solution exist :
If you come from the idea of a script to automate your build, you can use a tool like Ant, it's a bit like make and such tool in the C world where you define the needed tasks for your build in a configuration file. The problem with such solution is that it allow you to define your own structure for your build and a new comer to your project may have some difficulties to understand the logic of the build.
The other approach is to describe what kind of build you want to do, organize your sources and resources as it is done in most cases (by following a convention in fact). For example, java sources are in src/main/java, tests are in src/test/java, config files are in src/main/resources, and so on. In the description of your build you will just say : this is a java project and I want to build a War web application and execute my tests using jUnit 4. The dependencies of my project are apache xerces and hibernate 4. Then, the tool will know what to do without the need to say how to do. This is the way maven do.
In short, in the Ant approch, you will say how to do what you want and in the Maven approach you will define what you want to do and the tool will know how by default.
You may also be interested in some kind of hybrid approache like the one provided by tools like Gradle.
For more information :
http://ant.apache.org/
http://maven.apache.org/
http://www.gradle.org/
Hope it helps
Related
I love being organized, and I hate having all my java projects in eclipse right in the workspace. It makes it very cluttered, and I wanted a more organized approach, where I have folders in my workspace for different kinds of projects. However, folders can only be added into other folders, and not the workspace itself. Also, I wanted a way to be able to put classes into just any folder, and not just the src folder in a project. I love eclipse, but I really want the way to organize my programs to be a little more flexible. Does anyone know how I can do this?
I think what is organized to 1 person is not the same for another. I have found some of these techniques helpful maybe they will help you
Group projects to working sets so you do not see the full workspace
You can keep sources in different folders add those source folders in the build path
Use tools like Collabnet that integrates with your version control repository and issue management systems like JIRA and at given point in time you can view only the files that are relevant to the issue you are working with.
Know your keyboard shortcuts very well
For what I understand, you are formulating two expectations:
Have a clear directory structure for your projects, independent from the IDE;
Have a clear workspace organization, which reflects the underlying structure of your projects.
There is something you did not mention, which is the build facility for your project. I guess you are compiling and running your projects from within Eclipse? If not, or if you are willing to compile, test, deploy and run your project besides your Eclipse IDE, you can have a look to full-featured tool like Maven.
The point is that even if you do not want to build your project outside of the IDE, this tool will save you so much time that it is even worth to use it only to have a clear, proper, conventional and understandable directory structure as you seem to expect. On the other hand, the problem is that such a tool addresses issues that are far beyond your own requirements, which may render it overkill to use for the sole purpose exposed above.
Maven is a perfect tool for those who like to be organized. One of its core concept is convention over configuration.
This means, for instance, that if you follow Maven conventions for your projects, the simple command
mvn eclipse:eclipse
will generate for each of your them a corresponding Eclipse project, which you will be able to configure, generate and clean from outside Eclipse.
I have a project that's currently built with ant that pulls the latest trunk version of Solr in through git and then builds through ant. I'm pretty used to Maven and its system for dependencies at this point and find our old ant way of doing things pretty messy and hard to maintain. With that said, basically everywhere I seem to look online, people are building solr with Ant, and the few tutorials I found for doing things with Maven are all along the lines of this one, which doesn't seem to work.
So, to be clear, all I'm looking for here is a clean way to develop the project in Eclipse and to be able to deploy it. I'm sure someone must have done this before and must have a good answer. I'd be really interested in hearing it.
I just got it working by throwing all dependencies into Maven, making my own repo for a pegged version of Solr 4.0-SNAPSHOT, copying the web.xml from it into src/main/webapp/WEB-INF/, and running things through mvn jetty:run with salient variables passed in as arguments as:
mvn jetty:run -Dsolr.dataDir="./solr-data" -Dsolr.master-host="localhost" -Dsolr.solr.home="./solr-home"
This method is officially unsupported, but it means I no longer have to bother with ugly ant configs or holding all of Lucene and Solr in git repos attached to my project, so I could build from them. It also means changing/updating versions just requires a one line change in my pom.xml instead of digging through and switching a whole ton of extraneous configs. I'm pretty happy, and once I got a better feel for how Solr is supposed to work, reconfiguring the project really wasn't that bad.
This answer is probably more a comment, but a comment is too small to expose it all.
I know nothing about Solr, but from a neutral point of view, I would say you have two options:
Mavenize Solr (looks like what is suggested by your article). Maybe you could post another question on what problems you encounter using their solution.
Invoke the original ant tasks using the maven-antrun-plugin. This would also probably require to attach the built jars (or if it only contains classes/resources, jar them first). You could decide to install them locally using maven-install-plugin or attach them with maven-build-helper-plugin.
In eclipse, there are plenty of tricks to access the built files. You could simply add the project as a dependency.
This second option should work, but I don't find it very clean
You should be able to use Maven if you want, I know some of the Solr developers do. Have a look here: http://wiki.apache.org/solr/HowToContribute#Maven. This isn't the most supported way though, and I can't help you with this since I never tried it.
I actually work with Solr + Ant and there's basically a task for everything: ant test, ant dist and so on. I agree that's a bit old fashioned, but it works. Lately the build has been improved a lot introducing Ivy as dependency management tool, in order to remove all jars from the source tree.
Let me know if you have some specific problems with ant, maybe I can help you more.
I'm working on a build system that has bad practices piled on other bad practices for a long time and I'm in the process of re-writing the build. The languages involved are C/C++, Fortran, Ada, and Java and for the time being I'm sticking with GNU style makefiles -- though we're considering other alternatives such as SCons.
With that said, I'm looking for some specific recommendations -- not recommendations of the form "use a different build system", etc.
Whoever wrote the particular makefile I'm looking at right now had planned on a sequential build of java code that looks something like this:
LIST_OF_JAVA_FILES = file1.java
LIST_OF_JAVA_FILES += file2.java
LIST_OF_JAVA_FILES += file3.java
...
LIST_OF_JAVA_FILES += fileN.java
all: ${LIST_OF_JAVA_FILES}
${LIST_OF_JAVA_FILES} : %.class : %.java
${JAVAC} ${CLASSPATH} ${<}
Provided you perform a build in serial, this works fine. However, as soon as dependencies come into the mix it becomes more problematic.
C/C++ compilers have options built-in for dependency generation ... does a similar facility exist for Java?
Is it necessary to use third party tools (like Jikes) to generate dependencies?
Typically speaking, if a team were using makefiles for building anything java related, is it more typical to call the java compiler one time listing out all .java files in one command-line -vs- one target for each .class file?
If this is more common, is this strictly for simplicity sake or is there a deeper reason?
note: I understand that for a sequential build this would be the faster option, but I want an answer to do empirical tests for parallel builds
We had similar issue in our project.
We decided to build all java code via ant and invoke ant from a makefile.
Unless you have a lot of JNI (c++ <----> java) dependencies this might work for you too.
Good luck.
Doing something like
javac -cp MY_CLASSPATH Main.java
suffices most of the time, as it resolves dependences automatically. Sometimes you may need to use more files on the command line, since some of them may get used without an explicit reference.
There are also ant and maven and ivy and whatever, but it's an overkill for something that simple.
It ended up being most expedient (and the norm for java development as a whole) to just specify all source files in a single build step and allow javac to resolve all the dependencies that way.
I am looking for an lightweight Java build tool. As light as possible. Even at the expense of features. Any recommendations?
As light as possible? That must be javac running from within a batch file or shell script.
But why?
There are only really two choices: Ant or Maven.
Ant is essentially a scripting tool that you can do anything with but you have to write everything yourself.
Maven comes with a lot of predefined project types. It will dictate a directory structure to you (which some people don't like) but will also handle dependencies (which Ant can sorta do with Ivy).
Personally I prefer Maven. A few lines of XML will get you the tasks to run unit tests, stop and start a Web container (eg Jetty or Tomcat), etc.
As said elsewhere, your real choice is between maven or ant. To echo other sentiments, I find there is more configuration to do with ant, so I prefer maven. That said, a lot of people tend to criticise maven in that although you need less configuration, it downloads a lot of dependencies (and dependencies/ dependencies), so it all depends on what you mean by "light" - do you mean light in configuration or light in dependency jar downloads/installation size?
If you want something light in terms of config and downloads, you are better off with a shell script, but that will only be as feature-rich as you have time to make it!
I'd again recommend Maven2 - it is very feature rich through the use of plugins, but it can also be very "light" (depending on what that means):
it doesn't need hard installation (just unzip directory + add the path to it to the environment variables (depending on OS))
it doesn't require configuration - just copy-paste a simple POM file and your build is ready. You will just have to follow the directory structure conventions of maven
it has a plugin for every IDE, so using it with GUI makes it even easier.
Of course, an alternative is ant, but I find it less "light". And I find it less light, because ant scripts grow ugly and unpredictable, and become hard to manage, while maven scripts stay simple, because of the rich functionality provided with the tool.
It really depends on your definition of 'light'. Do you want a tool that requires very little work to use (light on code)? If so, Maven or Gradle might be a good option. Maven has been around for a while. If you are doing something that follows their conventions, then you will need to write very little in your pom.xml files. If you start deviating from the norm it can get difficult to make it do what you need (making things less light). Gradle is also an option. It hasn't be around as long as Maven, but allows you to deviate from the convention easier.
If you are looking for something that is light in terms of the tools itself being lightweight, Apache ant may be a better option. It doesn't have the conventions built in like Maven. If you have a non-standard build that is pretty simple it might be possible to create a very light ant script to do your build.
Maven is simplest if you follow its directory structure. If you are on linux or unix system, I would use shell script. Or you could consider IDEs eclipse or netbeans, they will do the job for you, and dependencies are very easy to configure.
Have you tried BlueJ (http://www.bluej.org/) ?. I used it a few years ago to teach students. It is simple in the sense you can just copy/paste code and run it. It was created to teach students, hence is very simple and good for java starters. Note that it is is a full IDE, not a command line tool like maven or ant.
If you are going to stick with standards, Maven is the best bet.
If you want flexibility consider Groovy AntBuilder. terse syntax, and full power of ant and groovy scripting.
I am currently refactoring a large Java application. I have split up one of the central (Eclipse) projects into about 30 individual "components", however they are still heavily inter-dependent. In order to get a better idea of what depends on what I am looking for some way to graph the compile time dependencies.
All tools I have found so far are capable of graphing package or class dependencies or the dependencies between Eclipse plugins, however what I have in mind should just take a look at the classpath settings for each Eclipse project and build a coarser grained graph from that.
Later I will then go deeper, however right now this would just mean I would not be able to see the forest for all of the trees.
Check out JBoss Tattletale. It might not do all you ask but it's worth checking out. It's still relatively new though.
The tool will provide you with reports that can help you
Identify dependencies between JAR files
Find missing classes from the classpath
Spot if a class is located in multiple JAR files
Spot if the same JAR file is located in multiple locations
With a list of what each JAR file requires and provides
Verify the SerialVersionUID of a class
Find similar JAR files that have different version numbers
Find JAR files without a version number
Locate a class in a JAR file
Get the OSGi status of your project
Remove black listed API usage
Structure101 is capable of visualizing class and method JAR level dependencies in Jboss 5.
See the screenshot below or view it larger.
One tool that I believe would do what you want is Understand. It's not free, but you can download a free trial edition before investing any money into it.
Take a look at Dependency Finder
I am not sure if there is a(n Eclipse) classpath analysis tool.
May be Understand mentioned by MattK can help.
The closest I would pick amongst all the static code analysis tool referenced here would be JarAnalyzer (no graph though), able to detect "Physical dependencies" amongst jars.
Sounds like a use case for Degraph. It analyzes a bunch of class files and jar's, and visualizes the dependencies.
What makes it suitable for your usecase (I think) is the possibility to define arbitrary groups of classes to be bundled together. So you can reproduce your jar structure, seeing dependencies, especially cyclic dependencies.
You can unfold the groups to see their contained classes or collapse them to simplify the view.
For a quick impression what is possible, take a look at the Degraph Examples.
Example for Log4j:
JDeps is already included in the JDK, and shows JAR dependencies. For example:
jdeps -R -cp "my\jar\dir\*;my\other\jar\dir\*" my\classes\dir
Check out Class Dependency Analyzer (CDA): http://www.dependency-analyzer.org/
I have found it very useful for tidying up jars.
for the record (and for improving this knowledge base), I found Shrimp very helpful:
http://www.thechiselgroup.org/shrimp
Also, for easy dependency-checking, Byecycle is worth a try, but seems not to be updated anymore:
Byecycle
Both tools also offer Eclipse integration.