Step two of "The Joel Test: 12 Steps to Better Code" states "Can you make a build in one step?". My answer to this is currently no. My application is structured as follows:
+
+-MyApp // this is just a vanilla Java Application
+-MyWebApp // this Dynamic Java Web Application (deployed Tomcat and launches
// a thread contained in MyApp)
+-MyCommonStuff // these are common classes shared between MyApp and MyWebApp
// Ex. Database access code & business classes
In order to build and deploy my software I perform the following steps:
1. Checkout MyApp, MyWebApp, MyCommonStuff from svn
2. build MyCommonStuff.jar and copy to a "libs" directory
3. build MyApp and copy to a "libs" directory
4. build MyWebApp.war (Ant build.xml file specifies where MyApp.jar and MyCommonStuff.jar are located)
5. The deploy portion of build.xml used Tomcat deployment tasks to deploy to a tomcat server.
My question is does the Joel rule above apply to this scenario. i.e. should there be a "master" build script which executes steps 1. to 5.?
Should the script just be a normal #/bin/sh script or are there tools I can leverage. My preference would be stick to using Ant and linux console commands.
Thanks
You can (and should) use maven2. It supports everything required (via plugins). You just need to conform to its directory conventions.
In addition I'd suggest a Continous Integration Engine, which will take your maven configuration and execute and deploy everything. Hudson and TeamCity are good options.
An alternative to Maven, if you just want to use Ant, is Ivy. This is just a dependency manager, a bit like Maven but without all the other stuff Maven does.
I would suggest using one of the two. If you have a project with dependencies like this, you're going to make it so much easier for yourself if you store them in a central repository and use a dependency manager to include them!
You should do a global Ant script, calling all little ant parts through the Ant ant task.
Edit after reading other answers : you should also use maven. But if Maven is really overkill, and you just want to launch the whole build in one step, use a global build.xml
Related
I want to use Maven for building my next Java Project.
So I have some questions about Maven before starting right off.
Does Maven need to be installed? Or can Maven binaries just be copied to a system (Windows) and be used in the same way.
Setup a Maven project required?
From a Maven tutorial i've seen that the first step in Maven is to setup a Maven project like this:
mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
Why is that? Is writing a POM file not enough when I only want to compile some Java files and include some jars?
Question 1 (Installation):
Well it mostly is simply copy, add to path, and run.
However in real world there is a bit more than that. For example,
- in a company, you may want to have a company central repository proxy. You will need to do extra set up in either HOME/.m2/settings.xml or MVN_DIR/conf/settings.xml (Wish I remember the path right :P )
You may want to put local repository in a different directory in some case, you will also need to change settings.xml.
In order to have building of big project works, you may need to adjust M2_OPTS environment variable.
etc...
All these things are extra manual installation work you may need (Not difficult though)
Question 2 (Archetype):
You are actually right. You can simply write your own pom.xml and forget about archetype (That's what I was doing in the past too :) ). You can think Archetype as some template-project-generation feature, so that you may generate some pre-defined project types, and the essential project directory structure, required dependencies and settings in POM are all done for you. Of course you may even provide your own archetype, so new projects in your company can make use of them to conform with guideline or standard you want.
Does Maven need to be installed? Or can Maven binaries just be copied to a system (windows) and be used in the same way.
Maven comes bundled as a zip archive that you just need to unzip. You then need to add the bin directory to the PATH environment variable and you are good to go.
Setup a Maven project required? From a Maven tutorial i've seen that the first step in Maven is to setup a Maven project like this:
mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
There are multiple ways to create a Maven project. However, it is important to remember that a Maven project only comes down to having a single pom.xml file. This file will be located at the root of your project. So you are right when you say that "writing a POM file is enough".
Now, since Maven is a tool that is built under the convention-over-configuration principle, several utilities have been created to help adhere with the basic conventions of Maven. One of those utilities is the maven-archetype-plugin, which is invoked by the call to mvn archetype:generate. This utility will create a basic pom.xml file along with the standard directory layout.
If you are using an IDE, you could also create a Maven project by using the corresponding Maven plugin of this IDE (for example for Eclipse, this is the M2Eclipse plugin).
Answer to 1st question:
Maven is available in distributed binary format.You just have to download it and extract it in your local machine. And then, you have to create one user variable named M2_HOME(sometime M2_OPTS is also required) and add it to PATH variable. That's all you need to set up basic needs.
If your system is inside some proxy network then you have to perform one additional settings. That is to copy secuirity xml, which is available inside the downloaded files, and modify the elements values inside it according to your network.
Answer to 1st question:
For the 1st time you need to use the command you specified. Once you get the file-structure, you may reuse it based on your need. But remember to follow predefined file-structure else you would be surely in a trouble.
However,it's always advisable to create the projects using maven command as it would do many things for you which you might have to do manually if you opt for manual maven project creation.
What is the 'best practice' way of separating Maven deployment configuration from the build config?
I have a war project, that is built by Jenkins. I'd like Jenkins to deploy this to Elastic Beanstalk, but alas the best solution available at the moment is to use the beanstalk-maven-plugin.
I'm not sure it makes sense for the POM.xml to include information about deployment; after all, at build time that .war could end up anywhere.
In this situation, is there some way of using Maven modules to store the beanstalk-maven-plugin config in a separate POM to that of the actual software project?
I think you have to solutions.
Just add the beanstalk-maven-plugin definition to your regular pom.xml. The configuration can be stored in separate properties file or provided via system properties in command line (-D option). Add beanstalk goal to command line of maven in Jenkins. So, each build will be deployed on beanstalk. Alternatively you can define yet another project in Jenkins that just runs the deployment without compilation. You can run this deployment project on scheduled basis or via projects dependencies in Jankins.
Create yet another maven project. It will just run beanstalk plugin. I personally do not see serious advantages to do this.
I think about three things:
a. I'm not sure (I'm admit I was a bit busy trying to come up with 0.2.7-RC7), but I think the Elastic Beanstalk Configuration Files are supported in Java.
So it perhaps could be a good idea to separate (I admit managing config in Beanstalker is Boring)
b. Another option is using war overlays in maven-war-plugin's overlay feature, and create a war which depends on your other war.
In my personal case, if you ask, I do have a separate deployment profile in Maven, and that feature often come in handy
I'm currently building a desktop java application in a very clumsy manner. The application is deployed on Windows, Mac and Linux. Here's my build process now:
On Windows:
Update local repository
Fire up Eclipse
Refresh the project
Double click the .jardesc file to generate an executable jar file
Commit the executable jar to source control
Open up the .nsi script and click the build button (I have NSSI plugin installed) to produce the .exe installer
Upload installer to ftp server to publish
On Mac:
Update local repository
Run shell script to generate .dmg file using .jar in source control
Upload to ftp server to publish
On Linux:
Update local repository
Run shell script to generate .deb file using .jar in source control
Upload to ftp server to publish
I'd also like to include some extra steps in my build in the future, such as:
Setting build date
Setting the HEAD git commit-id
Performing some code obfuscation
Any suggestions on how I can streamline and speed up this process?
If you are serious about having a good build system, then I'd recommend learning and using Maven, which provides:
Comprehensive project build lifecycle management based on a declarative project definition (pom.xml)
A huge range of plugins, which I expect will be able to handle all the specific build steps you require
Very good integration with Eclipse
Full dependency management (including automatic resolution and download of dependencies)
This is not for the faint hearted (Maven is a complex beast) but in the long run it is a great solution.
First step would be to just get everything building without Eclipse.
You might also want to consider using something like Jenkins to automate some of this. You'll still require build scripts.
A solution could look like
Update repository.
Jenkins detects update and builds the jar.
Jenkins saves the jar to some location.
Then you can have separate builds for each OS, also running in Jenkins. These could be triggered automatically on successful completion of the first build. These would each:
Pick up the jar from the previous build.
Publish the OS specific binary to an FTP site.
Ant is a good start, but you may also want to look at Apache Ivy or Maven, as these will help a bit with managing your build outputs and dependencies.
You should have a look at Ant: https://ant.apache.org/
Apache Ant is a Java library and command-line tool whose mission is to drive processes described in build files as targets and extension points dependent upon each other. The main known usage of Ant is the build of Java applications.
Also, a long list of build systems: https://en.wikipedia.org/wiki/List_of_build_automation_software
I have a muti-module maven project, and I created a new module that depends on 3 other modules. (I already have a web app maven module that produces a .war file, now I need this)
This module's output is a .jar, and it has a few resources also which are:
spring context xml file
properties file
Now I want to produce a production ready folder so I can upload it to my server. I am hoping maven can do this for me.
I need the following layout:
myjar.jar
/libs/ (the 3 other maven modules that are dependancies)
/resources
Also, there are some generic dependancies that my parent pom.xml have like slf4j/log4j/ that I also need to package.
It would be cool if I could add a switch to mvn that will produce this like:
mvn clean install production
I plan on running this on my server via the command line.
I think what you are looking for is a Maven Assembly:
https://maven.apache.org/plugins/maven-assembly-plugin/
You can use profiles to disable the generation of the assembly by default (can speed up the development process).
#puce is right in that you may be best to use the Assembly Plugin. What you can't do easily is add another lifecycle 'production' to maven. If you have time you could write a plugin to do this, but you might be better off using a profile called 'production' or 'prod-deploy' to enable the coping into place on the server.
mvn clean install -Pprod-deploy
One thing to remember with maven is that it is very good at building projects in using it's conventions, but it is pretty bad at actually script things to happen out side of the build lifecycle.
I have on several occasions used external scripting tools such as ant/python/bash and groovy to first run the build using mvn then to script the deployment in a more natural language.
The intention of Maven is building not deployment in the sense to production. For this purpose i would recommend things like Chef or Puppet. From a technial point of view it's of course possible to handle such things via Maven. What also possible to build on CI solution like Jenkins. Furthermore it's possible to run a script from Jenkins to do the deployment on production.
I have a series of Eclipse projects containing a number of plugins and features that are checked into CVS. I now need to run an automated build of these plugins. Ideally I'd like to do it without having to hardcode large numbers of Eclipse library locations by hand, which has been the problem with the automatically generated Ant files that Eclipse provides. The build also needs to run headlessly.
Does anyone have experience of this sort of set-up with Eclipse, and recommendations for how to achieve it?
There are a few options for you to look at, depending on which build scripting language you're using:
For Maven2, the way forward seems to be Spring Dynamic Modules. Other options are Pax Construct, m2eclipse, Maven BND
For Ant/Gant, Eclipse PDE Build, Ant4Eclipse
For command line or both the above, Buckminster.
At my current clients we use Buckminster, which wraps PDE-Build, and call it from Ant/CruiseControl. We've got code coming in from multiple repositories all being built into a single RCP product.
Also, these questions may be of help.
The standard way to make an Eclipse Build is to use the PDE Build Plugin.
http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.pde.doc.user/guide/tasks/pde_feature_build.htm
http://wiki.eclipse.org/index.php/PDEBuild
The PDU plugin is normally included with the Eclipse IDE and contains a series of templates. The templates help you set up a system that will:
fetch: Checkout all plugins and features using a map file, that contains the locations of the plugins
generate: Creates a build process for every plugin checked out
process: Compiles the plugins
assamble: Jars and packs the plugins
postBuild: Allows to set up automatic tests and deployment
Theoretically all you need to do is to modify a customTargets.xml file , write a map file that contains a reference to every plugin that you need to check out and modify a build.properties file to indicate such properties as the cvs server location.
I had a similar problem to the one you have. The build mechanism is divided into several steps. You can customize the preFetch target of the customTargets.xml file so some "bulk" libraries are imported from specific trees in the repository and add them to the build directory, so you don't have to specify every single plugin in the map.
You can use Tycho to build your eclipse plugins with Maven. This is how the M2eclipse plugin is built. Find out more at http://m2eclipse.sonatype.org
You could write some sort of a script that finds those libraries for you and puts them into a format understandable by Ant.
For example, it could build a eclipse.lirbaries.properties file, then you could read in that file using:
<property file="eclipse.libraries.properties" />
You could also use the FileSet attribute:
http://ant.apache.org/manual/Types/fileset.html
Or even a combination of both.
1) Call Ant Script
2) Ant Script calls bash (or whatever scripting language) script which builds eclipse.libraries.properties
3) Ant loads eclipse.libraries.properties
4) Ant goes on with the build