CAS source and configuration files are stored in the Yale Subversion repository at https://svn.its.yale.edu/repos/cas. If you are updating the current release, everything you need will be there.
...
At any time you can right click a POM file and choose "Run as ..." . However, to duplicate the behavior of the real install process, which runs two Jenkins jobs, it is better to create two items in the Eclipse menus that you can run to do the same thing that Jenkins does in production.
First, lets review what the Jenkins jobs do. The "Trunk Build" job checks the source project out of subversion, runs a "mvn install" on the top level project, and that stores the artifacts (JAR and WAR) in the Yale Artifactory server. The Jenkins CAS Install job checks the Installer project out of SVN, runs Maven on the POM, but then Maven runs an Ant plugin which in turn runs the build.xml script. That script loads the WAR artifact from Artifactory and copies it to the JBoss deploy directory.
If you have the CAS source and CAS installer projects checked out into your Eclipse workspace then there is no need to access subversion. You have two POM files, one for each project, and you need to run them.
Eclipse has Run Configurationsand select a goal (clean, compile, install). Rather than taking all the default configuration parameters, or entering them each time you run Maven, you can build a Run Configuration. Basically, this is a simple job with one step that runs Maven. The Run Configuration panel allows you to select every possible option, including the Java Runtime you want to use to run Maven, and a specific Maven installation so you can run some things under Maven 2 and some under Maven 3, plus the standard Maven options to not run tests or to print verbose messages. Since the Jenkins jobs each run one Maven POM, in the Sandbox you can build two Maven Run Configurations that duplicate the function of each Jenkins job.
First, lets review what the Jenkins jobs do.
- The "Trunk Build" job checks the source project out of subversion. In this case, it is a "parent" project with subdirectories that all get checked out. It then runs a "mvn install" on the parent. The parent POM contains "module" XML elements indicating which subdirectory projects are to be run. Each subdirectory project generates a JAR or WAR artifact. The Jenkins Trunk Build installs these artifacts on the Artifactory server replacing any prior artifact with the same name and version number.
- The Jenkins Install job checks the source of the Install project out of SVN. By Yale convention, each Install project is an Ant build.xml script and a package of parameters in an install.properties file created from the Parameters entered or defaulted by the person running the Jenkins job. Minimally the Install job downloads the artifact from Artifactory and copies it to the JBoss deploy directory, although typically the artifact will be unzipped, variables will be located and replaced by the values in the properties file, and then the file will be rezipped and deployed.
In the Sandbox you already have a copy of the CAS source files checked out in your Eclipse project in your workspace, and you can also check out a copy of the Installer project. So there is no need to access SVN. Similarly, in the Sandbox we do not want to mess up Artifactory, so the local Maven repository (which defaults to a subdirectory tree under the .m2 directory in your HOME folder) holds the generated artifacts.
With these changes, a Build project compiles the source (in the Eclipse workspace) and generates artifacts in the .m2 Maven local repostory. The Install project runs the Ant script with a special Sandbox version of the install.properties to copy the artifact from the .m2 local repository to the Sandbox JBoss Deploy directory (with property edits).
There is one last step. The Jenkins install job stops and starts JBoss. In the Sandbox you will manually start and stop the JBoss server using the JBoss AS Eclipse plugin. This plugin generates icons in the Eclipse toolbar to Start, Stop, and Debug JBoss under Eclipse. You Stop JBoss before running the Install job and then start it (typically using the Debug version of start) after the Install completes.
Now to the mechanics of defining a Run Configuration. You can view them by selecting the Run - Run Configurations menu option. Normally you think of using Run configurations to run an application, but once you install M2E there is also a Maven Build section. Here you can choose a particular Maven runtime directory, a set of goals ("clean install" for example), and some options to run Maven in a project directory. The recommendation is that on your sandbox machine you create two Maven Run Configurations, one equivalent to the Jenkins "trunk build" that creates the WAR artifact in the local Maven repository on the sandbox machine, and a second Install job that runs Maven to copy the artifact to your local JBoss deploy directory. Then you do the sandbox equivalent of the production Jenkins jobs by using Eclipse to Run the two configured jobs.CAS development uses the Eclipse IDE (J2EE development configuration) with the Subversion and Maven plugins. On your desktop "sandbox" machine, CAS is deployed to a local copy of the JBoss server. In production, CAS is built and deployed using Jenkins.. The configuration labelled "CAS Build" runs a Maven "install" or "clean install" goal on the parent POM of the CAS source project. The configuration labelled "CAS Install" runs Maven on the POM of the Installer project (and it has to run Maven 2 because this is still the standard for Installer jobs).
CAS Source Project Structure
In Maven, a POM with a packaging type of "pom" contains only documentation, parameters, and dependency configuration info. It is used to configure other projects, but generates no artifact. The parent "cas-server" directory is a "pom" project. A "jar" project compiles Java source and combines the resulting *.class files and any resource data files into a zip file with an extension of ".jar". This is an artifact that is stored in the repository and is used by other projects. A simple "war" project has some optional Java source that will be compiled into the WEB-INF/classes directory, and a special src/main/webapp resource directory that contains the HTML, JSP, XML, CSS, and other Web data files. Any JAR files that are listed as a dependency in a war-type POM are included in the WEB-INF/lib directory. The classes, resources, and libraries are then zipped up and stored as a WAR artifact.
...