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.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am about to start a Java project just for practice. I've read about Maven, but I don't actually understand when it is meant to be used.
Can you give me some practical tips? Does Maven help a lot? What does Maven actually do for my project?
What it does
Maven is a "build management tool", it is for defining how your .java files get compiled to .class, packaged into .jar (or .war or .ear) files, (pre/post)processed with tools, managing your CLASSPATH, and all others sorts of tasks that are required to build your project. It is similar to Apache Ant or Gradle or Makefiles in C/C++, but it attempts to be completely self-contained in it that you shouldn't need any additional tools or scripts by incorporating other common tasks like downloading & installing necessary libraries etc.
It is also designed around the "build portability" theme, so that you don't get issues as having the same code with the same buildscript working on one computer but not on another one (this is a known issue, we have VMs of Windows 98 machines since we couldn't get some of our Delphi applications compiling anywhere else). Because of this, it is also the best way to work on a project between people who use different IDEs since IDE-generated Ant scripts are hard to import into other IDEs, but all IDEs nowadays understand and support Maven (IntelliJ, Eclipse, and NetBeans). Even if you don't end up liking Maven, it ends up being the point of reference for all other modern builds tools.
Why you should use it
There are three things about Maven that are very nice.
Maven will (after you declare which ones you are using) download all the libraries that you use and the libraries that they use for you automatically. This is very nice, and makes dealing with lots of libraries ridiculously easy. This lets you avoid "dependency hell". It is similar to Apache Ant's Ivy.
It uses "Convention over Configuration" so that by default you don't need to define the tasks you want to do. You don't need to write a "compile", "test", "package", or "clean" step like you would have to do in Ant or a Makefile. Just put the files in the places in which Maven expects them and it should work off of the bat.
Maven also has lots of nice plug-ins that you can install that will handle many routine tasks from generating Java classes from an XSD schema using JAXB to measuring test coverage with Cobertura. Just add them to your pom.xml and they will integrate with everything else you want to do.
The initial learning curve is steep, but (nearly) every professional Java developer uses Maven or wishes they did. You should use Maven on every project although don't be surprised if it takes you a while to get used to it and that sometimes you wish you could just do things manually, since learning something new sometimes hurts. However, once you truly get used to Maven you will find that build management takes almost no time at all.
How to Start
The best place to start is "Maven in 5 Minutes". It will get you start with a project ready for you to code in with all the necessary files and folders set-up (yes, I recommend using the quickstart archetype, at least at first).
After you get started you'll want a better understanding over how the tool is intended to be used. For that "Better Builds with Maven" is the most thorough place to understand the guts of how it works, however, "Maven: The Complete Reference" is more up-to-date. Read the first one for understanding, but then use the second one for reference.
From the Sonatype doc:
The answer to this question depends on your own perspective. The great
majority of Maven users are going to call Maven a “build tool”: a tool
used to build deployable artifacts from source code. Build engineers
and project managers might refer to Maven as something more
comprehensive: a project management tool. What is the difference? A
build tool such as Ant is focused solely on preprocessing,
compilation, packaging, testing, and distribution. A project
management tool such as Maven provides a superset of features found in
a build tool. In addition to providing build capabilities, Maven can
also run reports, generate a web site, and facilitate communication
among members of a working team.
I'd strongly recommend looking at the Sonatype doc and spending some time looking at the available plugins to understand the power of Maven.
Very briefly, it operates at a higher conceptual level than (say) Ant. With Ant, you'd specify the set of files and resources that you want to build, then specify how you want them jarred together, and specify the order that should occur in (clean/compile/jar). With Maven this is all implicit. Maven expects to find your files in particular places, and will work automatically with that. Consequently setting up a project with Maven can be a lot simpler, but you have to play by Maven's rules!
Maven is a build tool. Along with Ant or Gradle are Javas tools for building.
If you are a newbie in Java though just build using your IDE since Maven has a steep learning curve.
My friend and I are working on a Java project collaboratively. We are both very inexperienced with regards to Eclipse and Git alike.
The primary goal is:
For my friend and I to seamlessly contribute to the code via git, with minimal limitation.
To be able to develop the SWT interface without running into dependency errors that might arise due to absolute class paths and/or due to differences in OS (it would be beneficial if I could work on the project not only on my Windows machine at home, but my Macbook as well)
When I looked up the question, it seemed this question had the answer.
However, doesn't changing the build path affect the .classpath, and will thus be affected when you commit changes to git (see goal #2)? How do I ensure that virtually anyone can clone my repository, regardless of OS (see goal #1)? The other answers I have found involve setting the class path variables—however, as I have said, I am woefully inexperienced with Eclipse. I have also heard that Maven might be the answer, but I have no clue how to use the pom file and how to set it up for the 10 or so different jars in the "Referenced Libraries" part of my project.
Thank you in advance for the assistance
We are both very inexperienced with regards to Eclipse and Git alike.
And presumably SWT and Maven as well? Brace yourself for an exercise in patience and frustration - this sounds like a very ambitious (but not impossible) goal without much experience in these things.
develop the SWT interface [...] not only on my Windows machine at home, but my Macbook as well
SWT has different .jars for different OSes and architectures. If you truly want a single .jar that can be run on different platforms, it's not going to be trivial to handle which one is used at runtime. I would recommend building different assemblies depending on the target OS. If that is simply something you cannot do, then unfortunately I can't help much in regards to how to load different SWT .jars at runtime.
Maven might be the answer
Maven will definitely help, and you can use this repository in your pom.xml to get the corresponding SWT dependency: http://maven-eclipse.github.io/maven.
I have no clue how to use the pom file
A bit of Google-searching should bring up some very basic Maven examples. Take some time to understand the different parts of the pom.xml file (Maven in 5 Minutes).
how to set it up for the 10 or so different jars in the "Referenced Libraries"
You will need to find the corresponding Maven dependency for these. Eclipse will be very helpful with this, and you will not need to manually manage the .classpath file (How do I get my Eclipse-Maven project to automatically update its classpath when I change a dependency in my pom.xml file?).
Without throwing too much info at you, while still trying to provide a helpful answer, I would recommend (after getting a grasp on Maven basics) taking a look at using profiles in your pom to determine which SWT dependency will be used (Related: SWT on different systems). This will address your primary concern, as you will no longer be hard-coding a platform-specific dependency, so anyone on a different OS can now build your project.
For my friend and I to seamlessly contribute to the code via git, with minimal limitation.
IMO Git will be the least confusing part about what you're trying to achieve :) That said, just take some time to learn the basics of Git and you should be fine. It's not overly complicated once you understand the basics and stick to the basics.
In general, be aware that with SWT there are some nuances with how it will look/behave on different OSes. Just because something works for you Windows doesn't mean that it will look/behave exactly the same way on a Mac.
Side note: A "gotcha" that you will eventually run into on macOS is the need for the -XstartOnFirstThread JVM argument (Running SWT based, cross-platform jar properly on a Mac).
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
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 see reference of ant a lot but I don't get exactly what its meant to do? from what i've heard its supposed to compile your projects but can't i just do that by clicking Run->Run in eclipse?
Edit : I guess I should rephrase my question. I already know that ant is a 'build automation software', my question is, what exactly is build automation? I thought that you're supposed to test your app, and when it is running you click the 'build' button in eclipse or through command-line java, and it makes a .jar file out of it? So why do you need to 'automate' this process?
I already know that ant is a 'build automation software', my question is, what exactly is build automation? I thought that you're supposed to test your app, and when it is running you click the 'build' button in eclipse or through command-line java, and it makes a .jar file out of it? So why do you need to 'automate' this process?
Not all the Java development is done through eclipse and not all the jars may be built from the command line ( or should be built from the command line ) .
You may need additionally run test cases, unit tests, and many, many other process.
What ant does, is provide a mechanism to automate all this work ( so you don't have to do it every time ) and perhaps you may invoke this ant script each day at 6 p.m.
For instance, in some projects, a daily build is needed, the following are the task that may be automated with ant, so they can run without human intervention.
Connect to subversion server.
Download/update with the latest version
Compile the application
Run the test cases
Pack the application ( in jar, war, ear, or whatever )
Commit this build binaries to subversion.
Install the application in a remote server
Restart the server
Send an email with the summary of the job.
Of course for other projects this is overkill, but for some others is very helpful.
rogeriopvl is absolutely correct, but to answer your "can't I just do that by clicking Run->Run in Eclipse?" question: that's fine for a project that you're working on on your own, and don't need a repeatable, scriptable build in multiple environments.
If you're working on an open source project, however, or professional software which needs to be able to build on a build server etc, requiring a particular IDE to be running isn't a good idea.
Ant is used to automate a build process, but a build process is often much more than compiling. Ant has "tasks" that can be used to perform miscellaneous useful functions. You can create your own task to do just about anything by writing a java class and telling ant where to find it. You can then mix and match these tasks to create targets that will execute a set of tasks.
You can also set up a dynamic environment in which to build your application. You can set up property files to hold variables that can be used in the build process, i.e. to hold file paths, class paths, etc. This is useful for instance to differentiate between test and production builds where deployment paths, database instances, etc. might change. Ant also includes flow control (if, etc.)
Some things I've seen ant do:
Compile code
Use version control to checkout the latest version or to tag the version being built
Run sql scripts to build or rebuild a test database
Copy files from an external resource for inclusion in a project
Bundle code into a jar, war or ear file
Deploy a web application to an application server
Restart an application server
Execute a test suite
Static analysis, i.e. CheckStyle or PMD
Send email to a team to alert them to a build.
Generate files based on information from the build.
Example: I have a jsp in my app that does nothing but display version/build information. It is generated by ant when I run a build, and the production operations team checks this page when they deploy the application to make sure they've deployed the correct build.
In many larger companies (and likely some smaller ones), you'll find that production code is not built by the people who developed it. Instead, the developers may check their code into a source code repository and tag it. Then they give this tag to a build team.
The build team, in a separate (clean) area - possibly on some headless server (i.e. with no GUI) - will then check out the code and run a build script. The build script will be completely independent of the desktop environment/IDE.
This ensures that nothing which happens to be on any one developer's computer is "polluting" the build. (Or, more likely, nothing outside source control is required for the system to work!)
So most software you use will never, ever be built from a developer's desktop.
PS. You might also want to look at the idea of Continuous Integration
The short answer is that Ant is a great way to create a complete project build that is independent of any particular tool any developer may be using. Without an independent build, things can go haywire quickly - especially for large project teams.
And now for the long answer... I have been brought into several projects without any sense of an independent build. On one project, there was one guy who was not a developer that was tasked with building and deploying the software. He had created 147 separate windows batch files to compile each EJB, each servlet, and each client component. There was no error checking for this build. All log messages, including error messages went to standard out. It was up to him to manually recognize by reading this log which exception or message printed was a normal and which message was an error. He also had to deploy this software he just built. Deploying was equally as complex since there were several load-balanced tiers. Each module had to be placed in the right place manually with options setup to match downstream and upstream tiers. Building and deploying this software took him at least 3 days using this method. Of course, only then could anyone determine if the build "worked". Usually, after this period all the programmers would scramble to debug the build. Programmers would say my module works fine in my IDE. I just click run like this, see?
Indeed, the individual software modules usually worked, but the build and deployment was horribly ineffective. And just as bad, it was equally as difficult for anyone to deploy a build to more than one environment. Management would say, ok you now have this build working in our regression testing environment. Now deploy that same build in this other environment so the sales guys can demo up and coming software. That should be simple to do, but it also took at least 2 days, followed by a "debugging the build" period. Builds and deploys were never simple and never accurate. It really slowed the project down.
Anyway, we replaced this entire procedure with a complete Ant based build and deploy mechanism. The end result was that a complete build could be created and deployed in less than 30 minutes, completely automated. The QA guy managing the builds and deploys could keep a whiteboard of which environment had which build deployed to it and which group was using that environment. This was something that was just not possible with the old system.
Ant is for automating software build processes:
http://en.wikipedia.org/wiki/Apache_Ant
Ant allows CRISP (complete, repeatable, informative, schedulable, portable) builds. You can find great info on it in this presentation by Mike Clark and in his book, Pragmatic Project Automation.
Ant is a build tool, akin to makefiles (albeit with a very different syntax in XML). If you're only using Eclipse it's fine to stick to that and you can always convert an Ant build file into an Eclipse project (Eclipse's launch configurations are then, if I remember correctly, the equivalent of Ant's build targets).
If you want to deploy the source code of the application and allow others to easily build or set it up, automating that using Ant is probably not a bad idea. But it's usually not a consistent experience for users or at least I haven't seen much consensus on what targets should be there and doing what so far.
Ant may also be used for regular automated builds (you wouldn't want to hit Run in Eclipse every night, right? :-))
If there's one close to you I think you'd get a lot out of CITCON, the Continuous Integration and Testing Conference. You get to talk with lots of people about the benefits of automation applied to building and testing software.
Basically people use Ant (with other tools) to automate everything they want to have happen after a commit. The basic advantages of such automation are faster, better and cheaper.
Faster because things happen right away without waiting for a human to get around to it.
Better because computers are really really good at doing the same thing the same way every time. (Humans tend to suck at that.)
Cheaper because you have fewer mistake and the mistakes that occur are caught sooner and therefore cheaper to fix.
You are also referring to the ""Export ant buildfile".
If you write your own Ant script for building your application outside eclipse, you can write your own targets that use the Ant task to delegate to the generated build.xml.
Also, you can configure a project's 'builders' (project properties » Builders) to run any script (ant or otherwise) you want when you build the project, manually or automatically.
Joel (Spolsky) has a great article on "The Joel Test." Many of them revolve around being able to do important things often, quickly and reliably. One of those things is your build.
Eclipse is using ant for building, running, deploying, ...
"Ant is a Java-based build tool. In theory, it is kind of like Make, without Make's wrinkles and with the full portability of pure Java code." (from link text