Few months ago, i have written an article on how to install Maven on Linux here. While i am also trying to write a guide on doing so on Windows, let me first show you a few good features of Maven 3.
The guide below walks through some Maven key commands, it is unlikely that you will configure by hand, but it is essential to know Maven’s workings through some plain command lines. For example, you may like to know that certain project dependency management features may be made through a Java IDE such as Eclipse. Discover how here http://java.sg/revolutionize-the-way-you-create-anymore-new-java-applications-with-maven-3-0/.
$ mvn archetype:generate
This command gives us a Maven maintained list of archetypes available for use. The result list of this command is quite long.
bash-3.2$ mvn archetype:generate [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building Maven Stub Project (No POM) 1 [INFO] ------------------------------------------------------------------------ [INFO] [INFO] >>> maven-archetype-plugin:2.0:generate (default-cli) @ standalone-pom >>> [INFO] [INFO] <<< maven-archetype-plugin:2.0:generate (default-cli) @ standalone-pom <<< [INFO] [INFO] --- maven-archetype-plugin:2.0:generate (default-cli) @ standalone-pom --- [INFO] Generating project in Interactive mode [INFO] No archetype defined. Using maven-archetype-quickstart (org.apache.maven.archetypes:maven-archetype-quickstart:1.0) Choose archetype: 1: remote -> docbkx-quickstart-archetype (-) 3: remote -> simple (-) 6: remote -> gquery-archetype (-) 16: remote -> vaadin-archetype-widget (This archetype generates a Vaadin widget project for Vaadin 6.2+ and a test application.) 17: remote -> android-quickstart (Creates a skeleton for an Android application) 98: remote -> maven-archetype-quickstart (An archetype which contains a sample Maven project.) 168: remote -> struts2-archetype-blank (-) 204: remote -> appfuse-core-archetype (-) 238: remote -> ear-javaee6 (Archetype for EAR package using Java EE 6) 362: remote -> javg-minimal-archetype (-) Choose a number: 98:
For the focus of keeping this guide short and purposeful, i have omitted the full results of the archetype listing to show you only some of the common project archetypes you will come across. The number representing each archetype is not a permanent fixture of the archetype but a ordering that is subjected to change.
We are particularly interested in the maven-archetype-quickstart archetype for generating us a simple Java J2SE application.
Choose a number: 98: 98
So when asked to select a number representing the archetype from the list, we key in 98, and notice that by default Maven displays in the prompt the default archetype, this is especially useful for new comers.
Define value for property 'groupId': : sg.java Define value for property 'artifactId': : helloworldMaven Define value for property 'version': 1.0-SNAPSHOT: : 1.0-SNAPSHOT Define value for property 'package': sg.java: : sg.java
Next, Maven asks us to define values for the group id, artifact id, version, and package strategy that we would be employing.
group id is the unique identifier that will differential this project from another. It is most commonly represented in dot notation (sg.java.maven). For example, if i worked in SCS limited, then my group id would be com.scs, and sg.java for my own personal projects. This requirement is not restrictive, and you certainly may choose to break off the convention, just as JUnit does not follow the dot notation.
However, it is best to follow the dot notation, and represent your project in an entity manner. See this article for such reason why we should so. http://java.sg/use-sun-java-packaging-convention-please/
artifact id is the name of the project you want it to be known by. This name differentiates one project from another you create. For example, if you a constructing an integrated billing management system, it makes sense to abbreviate the long name to “ibms”, and thereafter using it as your artifactId.
As the artifact id forms part of your packaging strategy by default, and recommended, it is best to choose a short artifact id so that you package does not become excessively long.
Chances are that if you not writing an API or a library, then you may not be concerned with the overall naming strategy of the project over time and change. Certainly, jasper reports would not want to be known as jasper reports “the beginning”, jasper reports “the prelude”, and jasper reports “the finale” for each version change. Therefore, version is subjective to the incarnation of the project and allows each “version” to keep its name but well differentiated by a meaningful version number, i.e. JUnit 1.0, JUnit 2.0.
Confirm properties configuration: groupId: sg.java artifactId: helloworldMaven version: 1.0-SNAPSHOT package: sg.java Y: : Y [INFO] ---------------------------------------------------------------------------- [INFO] Using following parameters for creating project from Old (1.x) Archetype: maven-archetype-quickstart:1.1 [INFO] ---------------------------------------------------------------------------- [INFO] Parameter: groupId, Value: sg.java [INFO] Parameter: packageName, Value: sg.java [INFO] Parameter: package, Value: sg.java [INFO] Parameter: artifactId, Value: helloworldMaven [INFO] Parameter: basedir, Value: C:\ [INFO] Parameter: version, Value: 1.0-SNAPSHOT [INFO] ********************* End of debug info from resources from generated POM *********************** [INFO] project created from Old (1.x) Archetype in dir: C:\helloworldMaven [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 1:04.715s [INFO] Finished at: Sat Jan 08 18:10:33 SGT 2011 [INFO] Final Memory: 9M/150M [INFO] ------------------------------------------------------------------------ bash-3.2$
Maven asks us to confirm the properties, and once we do, it outputs more verbose text. It ends by generating the actual project in the file system. You may look for the Maven generated artifact sitting in your local file system in the same directory when issuing the mvn archetype:generate command.
bash-3.2$ pwd /cygdrive/c bash-3.2$ ls $Recycle.Bin Program Files Users csvn hiberfil.sys install.res.1036.dll pagefile.sys Documents and Settings Program Files (x86) VC_RED.cab dell install.exe install.res.1040.dll splash.idx Intel ProgramData Windows drvrtmp install.ini install.res.1041.dll vcredist.bmp MSOCache Recovery bea dvmaccounts.ini install.res.1028.dll install.res.1042.dll Oracle System Volume Information c globdata.ini install.res.1031.dll install.res.2052.dll PerfLogs Temp c3 helloworldMaven install.res.1033.dll install.res.3082.dll bash-3.2$
I am actually working on a Windows system, and using cygwin and mintty to emulate a unix environment (this is really a personal preference, having worked in a data center for a year and a half, i grew very customized to looking at prompts).
As you may see from the above, i did a pwd (present working directory) to see where am i, i am located in the C:\ directory, and notice the “helloworldMaven” directory from the listing? That is the project artifact that Maven had us configured earlier and generated for us.
bash-3.2$ cd helloworldMaven/ bash-3.2$ ls pom.xml src bash-3.2$ cd src bash-3.2$ ls main test bash-3.2$ cd main bash-3.2$ ls java bash-3.2$ cd java bash-3.2$ ls sg bash-3.2$ cd sg bash-3.2$ ls java bash-3.2$ cd java/ bash-3.2$ ls App.java bash-3.2$ pwd /cygdrive/c/helloworldMaven/src/main/java/sg/java bash-3.2$
Traverse through the folders, and you may find the exact behavior of our configuration.
Lets see what the pom.xml file contains.
bash-3.2$ cat pom.xml <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>sg.java</groupId> <artifactId>helloworldMaven</artifactId> <version>1.0-SNAPSHOT</version> <packaging>jar</packaging> <name>helloworldMaven</name> <url>http://maven.apache.org</url> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> </project> bash-3.2$
You may have noticed that the pom.xml included the dependencyfor junit 3.8.1. This is because that the archetype we selected (maven-archetype-quickstart) contains some examples of a normal Java project. And quite often does enterprise projects require us to have unit tests. If you are uncomfortable with it being there, you may remove the dependency. When you do so, also remove the test folder and its contents as there is a Java file (AppTest.java) inside that depends on junit libraries.
You may now use the project artifact for development. :) Cheers.
If you continue to navigate through the project folder “helloworldMaven”, you will notice some more folders and files generated also by Maven.
Because the list of available archetypes change from time to time, just as the list maintained by yellow dog update modifier (yum CentOS / RHEL), it is not recommended to keep a “list of archetypes” cheat sheet as the preferred discovery way would be through archetype:generate.
What is a Maven Archetype?
An archetype in Maven terminology is a project terminology package and structure templating toolkit. It defines a set of standard of how some projects manage their initial structures. For example, Java EE web projects, and EJB projects both have its unique way of structuring certain folders and the placement of certain files. Maven allows us to create commonly used “ready” projects that we may base off for development in the quickest way.
Introduction to Maven Archetype http://maven.apache.org/guides/introduction/introduction-to-archetypes.html
Definition of Archetype http://dictionary.reference.com/browse/archetype
Project Object Model http://maven.apache.org/pom.html
Omeka, although as weird as it sounds for a word that is hardly found in any legit dictionary, is an open source and free CMS that is quite simple to understand and capable of integrating into your development projects – as a CMS, to leave you to concentrate on more important aspects of your other software development. And although it is not as robust as Microsoft Sharepoint document management system in terms of its ease of integration as mentioned above, i personally find it interesting and quite relevant in the context of a project that i was recently involved in that i would recommend to you to take a look.
I begin and end by showing you around how Omeka would be installed under a GNU/Linux Kernel environment (i quite have to pretentiously or not put ‘Linux’ as we mostly know, as ‘GNU/Linux Kernel’ so as to respect all my acquaintance who place the distinction between Linux as a GNU/Linux kernel, and the ‘Linux’ we call any general Linux products. And of course i must agree it should be called GNU/Linux Kernel.)
Our target distribution appears to be CentOS which i have come to know and love, CentOS is a fork of RHEL as most would agree with, it is capable as a stable enterprise computing GNU/Linux kernel based server, and something that i would highly recommend for Omeka CMS to be installed and run on.
Because Omeka CMS runs on a HTTP server such as Apache HTTPD, we will step through installing Apache HTTPD in your operating system.
Prerequisite / Imposed Working Environment
1. You have installed in your server CentOS 5.5 or similar CentOS operating system version number, such as 4, 5.1, 5.2, 5.3 or its RHEL equivalent.
2. You have access to the Internet as we need to download certain packages and installation files related to the setup.
3. You have root access or may execute sudoer commands in the server.
4. You have installed in your server MySql DBMS server.
5. You have the necessary PHP installation in your server.
Required Installations (Which we will walk through in this guide)
1. Apache HTTPD
Installing Apache HTTPD Web Server
1. By using the yellowdog updater modified package manager of CentOS, installing Apache HTTPD is as simple as issuing a ‘yum install httpd’ command.
$yum install httpd
Upon issuing the ‘yum install’ command, the package manager searches for the package to be installed, outputs some verbose information and asks for decision to continue to download the installation files and any dependencies that need to be updated and installed along with the HTTPD.
Verbose information being output, the yellowdog (yummy) updater modified package manager searches for dependencies and suggests to you what it intends to do with you to choose between yes or no. Choose ‘Y’ for yes to proceed.
Yum install completed.
2. (Optional) Configure Apache HTTPD to start automatically following a start up or restart.
You may configure Apache HTTPD to start automatically after a server restart or a cold start up. It is generally a good idea if you have many servers under your charge, it is not just for the particular reason of easing your workload or responsibilities. Circumstances following a warn restart usually are perplexing and there may be many other things you want to skip through to get to the main agenda, investigation or patching for example.
$chkconfig –level 2345 httpd on
The chkconfig command allows you to specify the state of the runtime (1 to 6) of any particular software. The above command will ensure Apache HTTPD is started automatically.
You may double configure this by checking through chkconfig –list httpd.
$chkconfig –list httpd
Apache HTTPD in set to ‘on’.
3. Start Apache HTTPD web server.
$service httpd start
(There are some irrelevant output from the server as seen in the screenshot, this is due to some configurations i did not set on my server, i am using a virtual machine for this example, you shouldn’t be having this)
At this point we have installed in our server Apache HTTPD which the only additional setup we need to perform before installing Omeka.
And at this point, Omeka is not installable via $yum install omeka, which requires us to manually download, unzip and manage the packaging, directory ourselves.
Omeka is available for download from here although it may quite possibly change from time to time. And in this case nevertheless, Google is your best mate.
1. Download omeka from your server.
Doing a quick listing ($ls -l) shows the installation file that is downloaded to the server.
2. Unzip the installation package into /var/www/html/
The unzip command unzips the zip package to the current directory by default, you may have noticed that i have sent in a few parameters and pipes. Let me explain these options.
The unzip command by default verbosely outputs all the directory and files that it is unzipping to, to the screen, and what you get are things you not necessarily need to ‘scan’ through. the pipe -q quietly unzips.
Because the default behavior of the unzip command unpacks all files into the same directory of the zip file and our intention is to place it into the /var/www/html where Apache HTTPD is configured by default to serve from, we pipe in -d /var/www/html.
3. Go to your unzip directory
We will go to our unzip directory, /var/www/html using the “cd” command and “ls -l” to list.
We will also change the verbose name of the default installation directory name from “omeka-1.2.1″ to simply “omeka” using the “mv” move command.
4. Change ownership of the Omeka installation from “root” to “apache”
For Apache HTTPD to effectively manage Omeka, change the ownership of the entire Omeka installation to “apache” from whatever it was.
Notice that i have in my screenshot showed the effects of the chown command on the targeted directory before and after.
The flag -R specifies that the command will traverse every folder under the folder specified and apply the same owner and group (apache:apache), essentially, everything.
5. Configure the DBMS connection settings through db.ini
The db.ini find can be found in the first level directory of omeka which currently resides on /var/www/html/omeka/. Using your favorite text editor, edit the text file.
I would be using the text editor vim for this guide.
By default, db.ini shows default values in which we must change out.
host: This can be localhost, the ip equivalent of localhost (as specified by your /etc/hosts or by default 127.0.0.1), the domain name or ip of where the DBMS resides on.
username: Self explanatory.
name: The name of the database, this is the name you supplied when you created your database for use with omeka (create database abc; for example).
prefix: The use of prefix is commonly found in shared hosting facilities where one has limitations over the number of mysql database server or instances for the package paid for. It is perfectly fine for you to leave this empty otherwise, as it would not serve any use other than the above mentioned multiple databases enabling “loophole”.
6. Finish off installation through web browser.
Once we are past this stage, we may finish off the rest of the installation and customization of Omeka through the web browser.
Special thanks to Eugene for the comprehensive explanation and practices on chkconfig!
One of the cornerstones of MySQL installation is enabling automatic startup with server boot up. This is important if are have many services running under a server and have many servers for that matter.
CentOS Linux 5
Shell Access / PuTTY / Console Access
Step 1 SSH To Linux Server And Switch User To Root
SSH to your Linux Server and switch user to root
Step 2 Check Config For mysqld Run Level
#chkconfig –list mysqld
As you may see from chkconfig, mysqld is off for run levels 1 to 6. We need to turn it on for 2, 3, 4, and 5.
Step 3 Turn On Run Level For 2, 3, 4, 5
#chkconfig –level 2345 mysqld on
Done, next, ensure that mysqld is turned on by issuing the chkconfig –list mysqld command again.
#chkconfig –list mysqld
Those familiar with Linux environment may remember the sftp command, secure file transfer protocol, we use this protocol to primarily transfer files between Linux boxes. Although it is also possible to use the same protocol from Windows to Linux, we seldom get to do so from the windows command line, and always through file transfer protocol GUI clients such as Filezilla.
If you are not familiar with ftp, ftp basically is a mechanism you use to upload and download files from machines such as a server.
To use sftp from a windows command prompt, you need an additional piece of software called psftp (putty sftp), the guide shows you the installation.
This guide shows you how you can use sftp from a MS windows box to place / get files from/to a Linux box. You will not need GUI clients such as Filezilla going forward.
1) psftp (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html)
You need this piece of software from PuTTY which is a win32 executable binary for use in Windows XP/7/Vista/*. You are unable to proceed if you do not download this piece of software.
Download psftp from the downloads page.
After downloading psftp, unzip and place the executable onto a permanent installation directory such as C:/program files/psftp. You may create a folder to keep psftp in the program files directory.
Add psftp Into Environment Path
You need to add psftp into the environment path so that you may use it from the command line.
> For Windows 7 Users
Start > My Computer > Right Click on “My Computer” > Click on “Properties” from the context menu
On the pop up window, select “Advanced System Settings” from the left side bar.
On the System Properties menu, select “Environment Variables”
Locate the “Path” system variable, select “edit …”.
Now, carefully append the directory path to psftp onto the back of the last variable value as shown.
Once done, click on “Ok”, and close the environment variable and system properties window.
Test psftp From Command Line
Open up command prompt (Start > Run > “Cmd” > Enter)
Type in “psftp” and press <enter>
If you see the output above, you installed the environment for psftp correctly. Congratulations!
You may use sftp from the command line anytime by bringing up the command prompt.
For VM users, if you have the chance to do a snapshot before you begin this guide to configure static IP for your Linux box, do so, because chances are if you make a mistake, you would want to conveniently “revert” to the last working snapshot. For remote users, please be warned that if you run the risk of having to make a beeline for your data center to reboot or console in should you make a mistake.If you are following this guide on a spare desktop machine that within your reach, or non critical systems, then you have little to worry about. Please do not try this on a production/live/through remote means if it is your first time. You may be disconnected straight away from your Linux machine.
#ssh root@localhostor#ssh firstname.lastname@example.org#ssh yourdomain.com
Step 2 Change directory to /etc/sysconfig/networking/devices/
Change directory to /etc/sysconfig/networking/devices/, this is where your network interfaces are.
Step 3 List all the network interfaces in the directory (use command ls -la or ll or ls or ls -l)
#ls -laYou should see the following:
vi ifcfg-eth0You should see this:
#ifdown eth0 && ifup eth0