Permalink
Browse files

Creating template

  • Loading branch information...
0 parents commit c1446b88f05ca5ded04562b56f6de3be677ef84a root committed Sep 26, 2012
@@ -0,0 +1 @@
+target
@@ -0,0 +1,5 @@
+#!/bin/bash
+# This is a simple build script and will be executed on your CI system if
+# available. Otherwise it will execute while your application is stopped
+# before the deploy step. This script gets executed directly, so it
+# could be python, php, ruby, etc.
@@ -0,0 +1,5 @@
+#!/bin/bash
+# This deploy hook gets executed after dependencies are resolved and the
+# build hook has been run but before the application has been started back
+# up again. This script gets executed directly, so it could be python, php,
+# ruby, etc.
@@ -0,0 +1,4 @@
+#!/bin/bash
+# This is a simple post deploy hook executed after your application
+# is deployed and started. This script gets executed directly, so
+# it could be python, php, ruby, etc.
@@ -0,0 +1,14 @@
+#!/bin/bash
+
+# The pre_start_cartridge and pre_stop_cartridge hooks are *SOURCED*
+# immediately before (re)starting or stopping the specified cartridge.
+# They are able to make any desired environment variable changes as
+# well as other adjustments to the application environment.
+
+# The post_start_cartridge and post_stop_cartridge hooks are executed
+# immediately after (re)starting or stopping the specified cartridge.
+
+# Exercise caution when adding commands to these hooks. They can
+# prevent your application from stopping cleanly or starting at all.
+# Application start and stop is subject to different timeouts
+# throughout the system.
@@ -0,0 +1,14 @@
+#!/bin/bash
+
+# The pre_start_cartridge and pre_stop_cartridge hooks are *SOURCED*
+# immediately before (re)starting or stopping the specified cartridge.
+# They are able to make any desired environment variable changes as
+# well as other adjustments to the application environment.
+
+# The post_start_cartridge and post_stop_cartridge hooks are executed
+# immediately after (re)starting or stopping the specified cartridge.
+
+# Exercise caution when adding commands to these hooks. They can
+# prevent your application from stopping cleanly or starting at all.
+# Application start and stop is subject to different timeouts
+# throughout the system.
@@ -0,0 +1,5 @@
+#!/bin/bash
+# This is a simple script and will be executed on your CI system if
+# available. Otherwise it will execute while your application is stopped
+# before the build step. This script gets executed directly, so it
+# could be python, php, ruby, etc.
@@ -0,0 +1,14 @@
+#!/bin/bash
+
+# The pre_start_cartridge and pre_stop_cartridge hooks are *SOURCED*
+# immediately before (re)starting or stopping the specified cartridge.
+# They are able to make any desired environment variable changes as
+# well as other adjustments to the application environment.
+
+# The post_start_cartridge and post_stop_cartridge hooks are executed
+# immediately after (re)starting or stopping the specified cartridge.
+
+# Exercise caution when adding commands to these hooks. They can
+# prevent your application from stopping cleanly or starting at all.
+# Application start and stop is subject to different timeouts
+# throughout the system.
@@ -0,0 +1,14 @@
+#!/bin/bash
+
+# The pre_start_cartridge and pre_stop_cartridge hooks are *SOURCED*
+# immediately before (re)starting or stopping the specified cartridge.
+# They are able to make any desired environment variable changes as
+# well as other adjustments to the application environment.
+
+# The post_start_cartridge and post_stop_cartridge hooks are executed
+# immediately after (re)starting or stopping the specified cartridge.
+
+# Exercise caution when adding commands to these hooks. They can
+# prevent your application from stopping cleanly or starting at all.
+# Application start and stop is subject to different timeouts
+# throughout the system.
@@ -0,0 +1,3 @@
+Place your jboss-as7 modules in this directory. This directory is added to the
+module path of the jboss-as7 server associated with your application. It has the
+same structure as the jboss-as7/modules directory.

Large diffs are not rendered by default.

Oops, something went wrong.
@@ -0,0 +1,22 @@
+Run scripts or jobs on a periodic basis
+=======================================
+Any scripts or jobs added to the minutely, hourly, daily, weekly or monthly
+directories will be run on a scheduled basis (frequency is as indicated by the
+name of the directory) using run-parts.
+
+run-parts ignores any files that are hidden or dotfiles (.*) or backup
+files (*~ or *,) or named *.{rpmsave,rpmorig,rpmnew,swp,cfsaved}
+
+The presence of two specially named files jobs.deny and jobs.allow controls
+how run-parts executes your scripts/jobs.
+ jobs.deny ===> Prevents specific scripts or jobs from being executed.
+ jobs.allow ===> Only execute the named scripts or jobs (all other/non-named
+ scripts that exist in this directory are ignored).
+
+The principles of jobs.deny and jobs.allow are the same as those of cron.deny
+and cron.allow and are described in detail at:
+ http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-Automating_System_Tasks.html#s2-autotasks-cron-access
+
+See: man crontab or above link for more details and see the the weekly/
+ directory for an example.
+
No changes.
No changes.
No changes.
No changes.
@@ -0,0 +1,16 @@
+Run scripts or jobs on a weekly basis
+=====================================
+Any scripts or jobs added to this directory will be run on a scheduled basis
+(weekly) using run-parts.
+
+run-parts ignores any files that are hidden or dotfiles (.*) or backup
+files (*~ or *,) or named *.{rpmsave,rpmorig,rpmnew,swp,cfsaved} and handles
+the files named jobs.deny and jobs.allow specially.
+
+In this specific example, the chronograph script is the only script or job file
+executed on a weekly basis (due to white-listing it in jobs.allow). And the
+README and chrono.dat file are ignored either as a result of being black-listed
+in jobs.deny or because they are NOT white-listed in the jobs.allow file.
+
+For more details, please see ../README.cron file.
+
@@ -0,0 +1 @@
+Time And Relative D...n In Execution (Open)Shift!
@@ -0,0 +1,3 @@
+#!/bin/bash
+
+echo "`date`: `cat $(dirname \"$0\")/chrono.dat`"
@@ -0,0 +1,12 @@
+#
+# Script or job files listed in here (one entry per line) will be
+# executed on a weekly-basis.
+#
+# Example: The chronograph script will be executed weekly but the README
+# and chrono.dat files in this directory will be ignored.
+#
+# The README file is actually ignored due to the entry in the
+# jobs.deny which is checked before jobs.allow (this file).
+#
+chronograph
+
@@ -0,0 +1,7 @@
+#
+# Any script or job files listed in here (one entry per line) will NOT be
+# executed (read as ignored by run-parts).
+#
+
+README
+
@@ -0,0 +1,22 @@
+Markers
+===========
+
+Adding marker files to this directory will have the following effects:
+
+enable_jpda - Will enable the JPDA socket based transport on the java virtual
+ machine running the JBoss AS 7 application server. This enables
+ you to remotely debug code running inside the JBoss AS 7
+ application server.
+
+skip_maven_build - Maven build step will be skipped
+
+force_clean_build - Will start the build process by removing all non
+essential Maven dependencies. Any current dependencies specified in
+your pom.xml file will then be re-downloaded.
+
+hot_deploy - Will prevent a JBoss container restart during build/deployment.
+ Newly build archives will be re-deployed automatically by the
+ JBoss HDScanner component.
+
+java7 - Will run JBoss AS7 with Java7 if present. If no marker is present then the
+ baseline Java version will be used (currently Java6)
No changes.
153 README
@@ -0,0 +1,153 @@
+Repo layout
+===========
+deployments/ - location for built wars (Details below)
+src/ - Maven src structure
+pom.xml - Maven build file
+.openshift/ - location for openshift specific files
+.openshift/config/ - location for configuration files such as standalone.xml (used to modify jboss config such as datasources)
+.openshift/action_hooks/pre_build - Script that gets run every git push before the build (on the CI system if available)
+.openshift/action_hooks/build - Script that gets run every git push as part of the build process (on the CI system if available)
+.openshift/action_hooks/deploy - Script that gets run every git push after build but before the app is restarted
+.openshift/action_hooks/post_deploy - Script that gets run every git push after the app is restarted
+
+Notes about layout
+==================
+Note: Every time you push, everything in your remote repo dir gets recreated
+ please store long term items (like an sqlite database) in the OpenShift
+ data directory, which will persist between pushes of your repo.
+ The OpenShift data directory is accessible relative to the remote repo
+ directory (../data) or via an environment variable OPENSHIFT_DATA_DIR.
+
+
+Details about layout and deployment options
+==================
+There are two options for deploying content to the JBoss Application Server within OpenShift:
+
+1) (Preferred) You can upload your content in a Maven src structure as is this sample project and on
+git push have the application built and deployed. For this to work you'll need your pom.xml at the
+root of your repository and a maven-war-plugin like in this sample to move the output from the build
+to the deployments directory. By default the warName is ROOT within pom.xml. This will cause the
+webapp contents to be rendered at http://app_name-namespace.rhcloud.com/. If you change the warName in
+pom.xml to app_name, your base url would then become http://app_name-namespace.rhcloud.com/app_name.
+
+Note: If you are building locally you'll also want to add any output wars/ears under deployments
+from the build to your .gitignore file.
+
+or
+
+2) You can git push prebuilt wars (with the corresponding .dodeploy file for exploded wars) into deployments/. To do this
+with the default repo you'll want to first run 'git rm -r src/ pom.xml' from the root of your repo.
+
+Basic workflows for deploying prebuilt content (each operation will require associated git add/commit/push operations to take effect):
+
+A) Add new zipped content and deploy it:
+
+1. cp target/example.war deployments/
+
+B) Add new unzipped content and deploy it:
+
+1. cp -r target/example.war/ deployments/
+2. touch deployments/example.war.dodeploy
+
+C) Undeploy currently deployed content:
+
+1. git rm deployments/example.war.dodeploy deployments/example.war
+
+D) Replace currently deployed zipped content with a new version and deploy it:
+
+1. cp target/example.war deployments/
+
+E) Replace currently deployed unzipped content with a new version and deploy it:
+
+1. git rm -rf deployments/example.war/
+2. cp -r target/example.war/ deployments/
+3. touch deployments/example.war.dodeploy
+
+WARNING: If you go with option 2) there are a couple issues to keep in mind with both prebuilt and exploded
+wars. With exploded wars the main issue is with committing binaries (class and jar files) can make merge
+conflicts tedious. With prebuilt wars the main issue is each time you modify the war and git push, it
+takes up the size of the war file away from your OpenShift file system quota. One alternative to this
+(other then using Maven from option 1) is to use rsync to push your war into the deployments folder. You
+would have to do this after each git push followed by 'rhc app restart -a appname'. Example:
+
+rsync -avz localdir/deployments/ app_uuid@appname-namespace.rhcloud.com:~/appname/repo/deployments/
+
+Note: You can get the information in the uri above from running 'rhc domain show'
+
+If you have already committed large files to your git repo, you rewrite or reset the history of those files in git
+to an earlier point in time and then 'git push --force' to apply those changes on the remote OpenShift server. A
+git gc on the remote OpenShift repo can be forced with (Note: tidy also does other cleanup including clearing log
+files and tmp dirs):
+
+rhc app tidy -a appname
+
+
+Whether you choose option 1) or 2) the end result will be the application
+deployed into the deployments directory. The deployments directory in the
+JBoss Application Server distribution is the location end users can place
+their deployment content (e.g. war, ear, jar, sar files) to have it
+automatically deployed into the server runtime.
+
+The filesystem deployment scanner in AS 7 and later works differently from
+previous JBoss AS releases. The scanner will no longer attempt to directly
+monitor the deployment content and decide if or when the end user wishes
+the content to be deployed. Instead, the scanner relies on a system of marker
+files, with the user's addition or removal of a marker file serving as a sort
+of command telling the scanner to deploy, undeploy or redeploy content.
+
+The marker files always have the same name as the deployment content to which
+they relate, but with an additional file suffix appended. For example, the
+marker file to indicate the example.war should be deployed is named
+example.war.dodeploy. Different marker file suffixes have different meanings.
+
+The relevant marker file types are:
+
+.dodeploy -- Placed by the user to indicate that the given content should
+ be deployed into the runtime (or redeployed if already
+ deployed in the runtime.)
+
+.deploying -- Placed by the deployment scanner service to indicate that it
+ has noticed a .dodeploy file and is in the process of
+ deploying the content. This marker file will be deleted when
+ the deployment process completes.
+
+.deployed -- Placed by the deployment scanner service to indicate that the
+ given content has been deployed into the runtime. If an end
+ user deletes this file, the content will be undeployed.
+
+.faileddeploy -- Placed by the deployment scanner service to indicate that the
+ given content failed to deploy into the runtime. The content
+ of the file will include some information about the cause of
+ the failure.
+
+.undeploying -- Placed by the deployment scanner service to indicate that it
+ has noticed a .deployed file has been deleted and the
+ content is being undeployed. This marker file will be deleted
+ when the undeployment process completes.
+
+.undeployed -- Placed by the deployment scanner service to indicate that the
+ given content has been undeployed from the runtime. If an end
+ user deletes this file, it has no impact.
+
+
+Environment Variables
+=====================
+
+OpenShift provides several environment variables to reference for ease
+of use. The following list are some common variables but far from exhaustive:
+
+ System.getenv("OPENSHIFT_GEAR_NAME") - Application name
+ System.getenv("OPENSHIFT_GEAR_DIR") - Application dir
+ System.getenv("OPENSHIFT_DATA_DIR") - For persistent storage (between pushes)
+ System.getenv("OPENSHIFT_TMP_DIR") - Temp storage (unmodified files deleted after 10 days)
+
+When embedding a database using 'rhc app cartridge add', you can reference environment
+variables for username, host and password:
+
+ System.getenv("OPENSHIFT_DB_HOST") - DB host
+ System.getenv("OPENSHIFT_DB_PORT") - DB Port
+ System.getenv("OPENSHIFT_DB_USERNAME") - DB Username
+ System.getenv("OPENSHIFT_DB_PASSWORD") - DB Password
+
+To get a full list of environment variables, simply add a line in your
+.openshift/action_hooks/build script that says "export" and push.
No changes.
45 pom.xml
@@ -0,0 +1,45 @@
+<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/maven-v4_0_0.xsd">
+ <modelVersion>4.0.0</modelVersion>
+ <groupId>booksite</groupId>
+ <artifactId>booksite</artifactId>
+ <packaging>war</packaging>
+ <version>1.0</version>
+ <name>booksite</name>
+ <properties>
+ <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
+ <maven.compiler.source>1.6</maven.compiler.source>
+ <maven.compiler.target>1.6</maven.compiler.target>
+ </properties>
+ <dependencies>
+ <dependency>
+ <groupId>org.jboss.spec</groupId>
+ <artifactId>jboss-javaee-6.0</artifactId>
+ <version>1.0.0.Final</version>
+ <type>pom</type>
+ <scope>provided</scope>
+ </dependency>
+ </dependencies>
+ <profiles>
+ <profile>
+ <!-- When built in OpenShift the 'openshift' profile will be used when invoking mvn. -->
+ <!-- Use this profile for any OpenShift specific customization your app will need. -->
+ <!-- By default that is to put the resulting archive into the 'deployments' folder. -->
+ <!-- http://maven.apache.org/guides/mini/guide-building-for-different-environments.html -->
+ <id>openshift</id>
+ <build>
+ <finalName>booksite</finalName>
+ <plugins>
+ <plugin>
+ <artifactId>maven-war-plugin</artifactId>
+ <version>2.1.1</version>
+ <configuration>
+ <outputDirectory>deployments</outputDirectory>
+ <warName>ROOT</warName>
+ </configuration>
+ </plugin>
+ </plugins>
+ </build>
+ </profile>
+ </profiles>
+</project>
No changes.
No changes.
Oops, something went wrong.

0 comments on commit c1446b8

Please sign in to comment.