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.
Related
I'm looking at an application and it has the following statements
executeProcess("java.exe -cp { 500-characters worth of stuff } someProg");
This is done several times through the program, since this application launches other programs to perform certain tasks. The previous developers decided to just copy and paste again and again as long as it works.
The problems I have with this are
it's redundant. That classpath is copied a dozen times. I can refactor it and move it to a single location, so that's easy to deal with for now and makes life easier for the next guy that might have to maintain this thing.
everytime a program adds a new dependency, I need to update the class path. All of our libraries are stored in a single folder (with subfolders for different libraries), so I can't just use wildcards because they do not check recursively: -cp "path/to/lib/*
Currently I'm the only one maintaining our entire tool set, so if I add a library, I know what to do to make it work, but in general this seems like bad practice.
What are some ways to make these process calls easier to manage?
You can add it as an environment variable and then refer to that, if
that is feasible.
As you already suggested, you can refactor it to a
single location.
I have had good experience with using ant and maven-ant-tasks for launching java applications without managing the classpath manually. Of course, in order to do that you would have to use maven for build/dependency management or at least install your jars to a local nexus instance.
The end user needs to checkout a maven project that declares a list of top level runtime dependencies (transitive dependencies will be resolved automatically, for libraries that are maven projects) that also contains some ant scripts with targets that execute the application.
You will have to figure out how the java application will know the actual location of the ant scripts (an env variable maybe?), but it's an extremely superior solution to manual jar and classpath management.
This might look like a gargantuan task - and it kind of is - but the benefits of transparent jar version and classpath management are so huge, that I cannot even dare to remember how we did it in my current company before setting up the infrastructure for this.
Also, note that apart from installing ant (with maven-ant-tasks) and maven (with nexus configured) everything else you need to launch is on the SCM.
I'm thinking about start using (not playing with) Clojure. Are there any useful guides? I'm not asking about lein, javac or any other 'small' manual tools. I need to know how to have Java and Clojure sources in eclipse in the same project. How to make them calling each other without compilation errors? How to configure maven? How to set up fully productive development environment? Is it even possible at the moment? What plugins may be useful? Where to start?
I have a fully working production setup with Eclipse, Maven and Clojure that is working very nicely at the moment. Hopefully it is helpful as an example of a good polyglot setup within a Java IDE.
I don't use leiningen - Nothing against lein at all - it's very nice and ideal in a pure Clojure/CLI world. But I've found that pure Maven is nicer to work with in a polyglot Java+Clojure environment with an IDE since the tool integration is so much better. Also from an ecosystem / audience / community perspective if you want people from the Java world to be able to build your source you are going to cause a lot less confusion if you just use Maven directly.
Here is my setup:
Eclipse 4.2 as main IDE
Counterclockwise Eclipse plugin - very good, takes care of REPL, Clojure editing etc.
Maven used to manage all projects (I use the built in Eclipse Maven integration mostly, but occasionally use the CLI version as well)
cljunit used to enable JUnit tests to run on Clojure parts of the project
Github / Travis CI used for SCM and Continuous integration, accessed using the built-in EGit team provider in Eclipse
In terms of actually how I manage / set up the project itself:
I configure everything with Maven, using standard Maven directory layout. Polyglot Java+Clojure Projects typically have both src/main/java and src/main/clojure
Clojure is just a Maven dependency, like any other Java library.
I make the Clojure source directories into resource directories in the Maven setup. This means that the .clj files get bundled in any jars and can be loaded / run dynamically at runtime.
I usually make the entry point on the Java side with a public static void main(...) as usual, but call quite quickly into the Clojure code. See this blog post on calling Clojure from Java.
Finally some coding tips for polyglot Java+Clojure
I find that Java is better for low level data structures, libraries and algorithms, while Clojure is better for integrating things together and "glue" code.
Clojure calling Java is usually easier / more elegant than the other way round. Also it makes sense since you generally want the dependencies to flow that way (higher level code calling lower level code)
If you make all your Java classes immutable, they play very nicely in a Clojure world with minimal effort.
Sometimes it is worth making one or more of your Java classes implement some of the Clojure interfaces, particularly clojure.lang.IFn for example. This way your Java objects can act as first class functions in Clojure code.
Here's an example project that mixes Java and Clojure source:
https://github.com/mikera/enlight
I also wrote a small library (clojure-utils) that includes some example code for calling Clojure from Java, which you may find useful.
Despite your tone about leiningen, I recommend looking at it. Leiningen supports Java compilation, so combining java and clojure sources in one project isn't a problem.
The Counterclockwise plugin, the clojure plugin for Eclipse, can work with leiningen project files (project.clj). So within Eclipse you have dependency management and java compilation all handled for you by defining the right things in project.clj, without the need to install leiningen separately or execute commands from the command line.
In the project.clj set :java-source-paths, like for example:
:java-source-paths ["src/main/java"]
In package src/main/java put a class Foo:
package main.java;
public class Foo {
public static final String value = "Michiel";
}
Somewhere in a clojure source file define this function and "Michiel" will be printed when it is called:
(defn foo
"I don't do a whole lot."
[]
(println (main.Foo/value)))
Further reading:
http://leiningen.org/
http://code.google.com/p/counterclockwise/
You could also try the framework "Funky". It will completly seperate you Clojure and Java code . Just have a look at https://github.com/windler/Funky
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'm trying to learn project automation and I'm using the book Pragmatic Project Automation as a guide. It's examples are in Java so I find it easier to follow it along in Java. I don't have any experience using Java or any of its IDEs. However, I've learned some C# using Visual Studio (although I'm still a beginner).
I'm having trouble understanding some parts of setting up a Java project. I'm using Netbeans IDE 7.0 on Windows 7. With Visual Studio, I have a solution with projects underneath. With Netbeans, I appear to just have a project with directories determining the rest of the structure (and the IDE to some degree)? The equivalent to Add Reference appears to be adding a source to the Classpath. There also seems to be a degree of separation between the compiler and the IDE. I'm currently in a situation where I can compile my project just fine while the IDE tells me I still have errors (and I assume this is because I have the project set up incorrectly).
I'm basically looking for analogies that will help me better understand Java project structure.
Lots of similarities between the two languages and IDEs. I spent many years in both. For starters the equivalent to 'add reference' in VS is adding a library or jar in netbeans. In respect to a reference - a jar is pretty much the same thing as a module or .dll in VS. A jar is a compiled reference. To add a reference just go to the project menu and then properties then to the libraries menu from there you can add either pre-assembled netbeans libraries, which are collections of .jar's, or a single .jar, or even a project. Once you add a reference you can import them into your class just like you would in C#.
Netbeans doesn't really have a 'solution' as VS does. You deal with individual projects. It does however have the capability to add a project as a reference so you don't have to continually re-build the references when you change something between multiple projects. It also has project groups to group similar projects.
Lastly Apache ANT is responsible for tying everything together in the background. Netbeans creates a build.xml and build-impl.xml file in the background to tell ANT how to assemble the project into a .jar.
There are my other things to cover but I thing this answers most of your questions. Does this help?
I can't speak for NetBeans, as I use Eclipse, but you are on the right track with classpath being roughly equivalent to references in the Visual Studio world. Libraries (usually .jar files) are placed on the classpath and must be there both at compile time and runtime (you specify the classpath to the compiler at compile time, and to the JVM at runtime). The classpath can contain many different entries, and they can be anywhere in the project structure (or outside of it entirely).
Java itself doesn't impose many restrictions on your project structure, although various IDEs and build tools do. The one thing that is a universal restriction in all Java environments is that source files (and class files) are placed in a directory named after the package name. So if your package name is com.test.something, then your source files will be in SRC_DIR/com/test/something, and your class files in OUT_DIR/com/test/something (note: SRC_DIR and OUT_DIR are not special variables; each IDE will have a different way to specify those directories).
Java libraires tend to heavily build-on one-another, so at some point, you'll find that the classpath entries are too many to manage manually. Before you get there, you'll want to take a look at Apache Maven or Apache Ivy which are dependency management tools. You'll need to understand how they work (either one, not both) and how to integrate them with your IDE. If you use Eclipse and Maven, m2eclipse offers fairly complete integration between the IDE and the dependency management tool.
With Netbeans, I appear to just have a
project with directories determining
the rest of the structure (and the IDE
to some degree)?
Visual Studio dictates a particular project layout and since the compiler is so tightly integrated into the IDE there's no real concept of a build script. In contrast, Java has no such structure (although certain 'best practices' have emerged such as having a 'src' directory for source files, 'lib' for libraries, 'test' for test source, etc.) and a build script is usually required to tell the compiler were to find source files and libraries, what artefacts to produce and a miscellany of other chores (running tests, deployment, creating code metrics and so forth).
In simple cases, the IDE will take care of this for you (if you follow the convention for that particular IDE) but ultimately you will probably want to take a look at a build tool to understand what's going on behind the scenes. Apache Ant and Apache Maven are both prominent offerings. Ant is very flexible whereas Maven attempts to dictate a common layout. I suggest you investigate both and see which suits.
There also seems to be a degree of
separation between the compiler and
the IDE. I'm currently in a situation
where I can compile my project just
fine while the IDE tells me I still
have errors
If your code compiles, it is correct. The IDE is simply acting in an advisory capacity (and will highlight issues beyond compiler errors, such as warning you of potential code mistakes or bad practice).
and I assume this is because I have
the project set up incorrectly
This is a possibility although, as stated above, there are many other explanations.
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.