Embed URL

HTTPS clone URL

SSH clone URL

This tutorial steps through creating, testing and deploying an application using the JBoss Java EE tools and runtimes. You can show up with nothing but Java and a passion to learn. By the end, you’ll have a full application running in the cloud provided by OpenShift.

Here’s the development stack we’ll be using:

OpenShift

git

JBoss Forge

JBoss Tools

JBoss AS 7

Arquillian

Hang on, cause it’s going to move fast.

OpenShift Introduction

Why Java EE on OpenShift?

You’ve probably been hearing a lot about cloud (“to the cloud!”). But, if you’re like me, you just haven’t been that motivated to try it, or it just seemed like too much effort. After all, taking a Java EE application to the cloud typically meant:

Breaking out a credit card (I hate being restricted from exploring)

Implementing tons of hacks to get a Java EE application running on a cloud provider

Not knowing how Java EE development is even compatible with cloud

Lack of crystal clear documentation and examples

All that has changed. I assure you, you’re in for a pleasant surprise.

OpenShift provides a free, cloud-based application platform for Java, Perl, PHP, Python, and Ruby applications using a shared-hosting model. Exploring the cloud has never been simpler. You can deploy a Java EE compliant application without requiring any hacks or workarounds. Best of all, take as much time as you like, because it’s all free. (Oh, and you can show off your applications to your friends, or even run applications for your own purposes).

Creating a domain for your applications

Before actually deploying an app to OpenShift, you first need to create a domain. A domain hosts one or more applications. The name of the domain will be used in the URL of your apps according to the following scheme:

http://[application name]-[domain name].rhcloud.com

Create a domain using the following command:

$> rhc-create-domain -n [domain name] -l [openshift email]

Note

Use the same email address you used to register for your OpenShift account and enter your OpenShift password when prompted.

Tip

All OpenShift client tools prompt you for your OpenShift password (unless you supply it using the -p command flag)

The command will then create a pair of private and public keys as libra_id_rsa and libra_id_rsa.pub in your $HOME/.ssh/ directory. It will ask you for a password to access the private key. Don’t forget it!

Tip

If you want to use an existing ssh key file, you can specify it explicitly in the $HOME/.openshift/express.conf file. You’ll also discover that your email is cached in this file, which means you don’t have to specify it in subsequent commands.

You can see a summary of your domain using the following command:

$> rhc-domain-info

You can also go to the dashboard to see your newly minted domain. You now have your own, free cloud. Woot!

Creating your first Java EE application on OpenShift

We now want to create a new application that uses the JBoss AS 7 cartridge. This allows us to deploy Java EE-compliant applications to OpenShift.

We’ll assume you’ll be developing the application in the following folder: ~/demos/apps/sellmore

Next, use the following command to create a slot in your OpenShift domain in which to run the application and the location where the local project should be created:

$> rhc-create-app -a sellmore -t jbossas-7 -r ~/demos/apps/sellmore

You’ll be prompted for your ssh key password that you created in the previous step.

Behind the scenes, OpenShift has created a git repository for you and cloned it locally. That’s how you’re going to "push" your application to the cloud. The cloned repository contains a Maven-based project structure (which you don’t have to use):

If you’re working with another origin git repository (such as on github), we recommend renaming the OpenShift repository from origin to openshift:

$> cd sellmore
$> git remote rename origin openshift
$> cd ..

That separates the concern of managing your source code repository from deploying files to OpenShift.

You can see a summary of your application configuration using the following command:

$> rhc-domain-info

You can also go to the dashboard to see your application slot. If you click on the URL, you’ll see that a sample application is already running in the cloud. We’ll be replacing that soon enough.

If, for whatever reason, you need to delete your application, use this command:

$> rhc-ctl-app -a sellmore -c destroy

You’ll also want to delete your local .git repository (unless you mean to save it).

But now’s not the time to delete, it’s time to create!

JBoss Forge Introduction

Why JBoss Forge?

Because starting a project is hard. It doesn’t just take time, it takes mental energy. We want to save that energy for creating useful things. Trust me, even if copying and pasting 20 lines of build XML seems easy, somewhere along the line your going to find yourself roasting your brain. Let’s toss the complexity over the wall and let a tool like Forge deal with it.

Forge is your monkey, or 10,000 of them.

Setting up Forge

To create our application, we’re going to use JBoss Forge. Forge is a plugin-based framework for rapid development of standards-based Java applications.

Begin by grabbing Forge from the download area. Then, unpack the distribution:

$> unzip forge-distribution-1.0.0.Beta5.zip

Move the extracted folder to the location of your choice and change into that directory in your console:

$> cd ~/opt/forge

Finally, run Forge:

$> ./bin/forge

To be sure everything is working okay, run the about command in the Forge shell:

Any command in this document prefixed with $forge> is intended to be run in the Forge shell.

Things look good. We’re ready to create an application.

Generating an application with Forge

Forge allows you to create a Java EE application from scratch. We’re going to generate a point of sale application step-by-step in the Forge shell using the commands below (make sure Forge is running):

Create more entities, also add a relationship between Customer and their Orders

Add more relationships between our entities

Generate the UI for all of our entities at once

Setup JAX-RS

Generate CRUD[Create, Read, Update & Delete] endpoints

Build the project

Return to the project root directory and leave it in your hands

You’ve got a complete application, ready to deploy!

But wait! That sure seemed like a lot of typing. What’s really great about Forge is that it’s fine-grained enough to perform simple operations, but it can also compose those operations inside plugins or scripts!

You can take all of those commands and put them into a script ending in .fsh and run the script from the Forge shell.

If you’re going to try this approach, you should first wipe the slate clean.

$> rm -Rf src/ pom.xml

Then, copy all the Forge commands listed above into the file generate.fsh at the root of the project.

You may also want to wrap the following two lines around the contents so that the commands run without pausing:

Use as first line

set ACCEPT_DEFAULTS true; (1)

Disables interactive commands

Use as last line

set ACCEPT_DEFAULTS false; (1)

Reenables interactive commands

You can now build the application using a single command:

$forge> run generate.fsh

Alternatively, you can also run a prepared version of this script directly off the web

Application Deployment

Deploying the application to a local JBoss AS 7 instance

Before we get all cloud happy, it’s a good idea to make sure the application runs on our own machine. We want to make sure that we rule out any problems with the application before adding the cloud into the mix.

If you don’t have JBoss AS 7 yet, head on over to the JBoss AS 7 download page and grab the latest 7.1 version. When the download finishes, unpack the distribution

$> unzip jboss-as-7.1.1.Final.zip

Move the extracted folder to the location of your choice (we’ll assume it’s $HOME/opt/jboss-as) and change into that directory in your console:

$> cd $HOME/opt/jboss-as

Finally, run JBoss AS in standalone (single server) mode:

$> ./bin/standalone.sh

You shouldn’t have to wait long to see:

JBoss AS 7.1.1.Final "Brontes" started in 1933ms - Started 133 of 208 services...

Now that’s a speedy app server!

Let’s head back to Forge so we can give this eager server something to run. We’ll start by adding the Maven plugin for JBoss AS 7 to the project (yes, there is a decent Maven plugin finally):

$forge> setup as7

If you don’t have the as7 command yet, you can install it using this command, then go back and do the setup:

$forge> forge install-plugin as7

Okay, build the application and send it to JBoss AS:

$forge> build
$forge> as7 deploy

The first deployment is always the slowest, so give it a few seconds. Then, have a look around the application you generated:

$$http://localhost:8080/sellmore

If everything looks good, then the application is cleared for take off. Let’s now do the same deployment, but this time on OpenShift.

Deploying your first Java EE application to OpenShift

There are two ways to deploy an application to OpenShift:

Deploy the source

You can commit your source files and push them to the remote server using git, at which point the application will be built and deployed on the remote host. Alternatively, you can use a Jenkins slave to handle the build and deploy steps on the server. More on that later.

Deploy a package

You can copy a pre-built war into deployments/ (with the corresponding .dodeploy file for an exploded war) and use git to commit and push the file(s) to the remote server for deployment

In the first scenarios, you edit the files locally and let OpenShift build the app using Maven and deploy it to JBoss AS 7 once you push the changes using git. In the second scenario, you build the application locally and just push the final package to OpenShift, which it will deploy to JBoss AS 7.

We’re going to take the source route.

First, add the following profile to the end of the pom.xml file (inside the root element):

pom.xml (fragment)

<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>sellmore</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>

Important

If you forget this profile, then the application will build on the OpenShift PaaS, but it will not be deployed to JBoss AS 7.

Caution

You may want to add the Eclipse project files to .gitignore so that they aren’t committed.

Next, we’ll add all the new files to git, commit them and push them to the server. You can perform these operations directly inside the Forge shell:

You’ll see the OpenShift begin the build lifecycle on the server, which includes executing Maven and downloading the (nearby) internet. The console output you’re seeing is from the remote server being echoed into your local console.

OpenShift Build Lifecycle

The OpenShift build lifecycle comprises four steps:

Pre-Receive

Occurs when you run a git push command, but before the push is fully committed.

Performs any required tasks necessary to prepare the application for starting, including running the .openshift/action_hooks/deploy script. This step occurs immediately before the application is issued a start command.

Post-Deploy

Allows for interaction with the running application, including running the .openshift/action_hooks/post_deploy script. This step occurs immediately after the application is started.

When the build is done, you’ll notice that the application is deployed to JBoss AS 7. You can now visit the application URL again to see the application running.

http://sellmore-[domain name].rhcloud.com

You should see the Forge welcome page and a list of items in the sidebar you can create, read, update and delete (CRUD).

If you want to push out a new change, simply update a file, then use git to commit and push again:

The OpenShift build lifecycle will kick off again. Shortly after it completes, the change will be visible in the application.

Application Management

Managing OpenShift applications from a shell environment

OpenShift isn’t just a black box (black cloud?), it’s Linux and it’s open! That means you can shell into your cloud just as you would any (decent) hosting environment.

So what’s the login? It’s embedded there in the git repository URL. Let’s find it.

$> git remote show -n openshift

You can also get the same information using:

$> rhc-domain-info -a

You are looking for the ssh username and host in the form username@hostname. Once you’ve got that, just pass it to ssh and the authentication will be handled by the ssh key you setup earlier. Here’s the syntax:

$> ssh [UUID]@[application name]-[domain name].rhcloud.com

There’s a lot of power in that shell environment. You can type help to get a list of speciality commands (such as starting, stopping or restarting your app), or use just about any Linux shell command you know. Be sure to pay attention to what you’re typing, though rest assured that the box is running on RHEL[Red Hat Enterprise Linux] secured with SELinux.

Viewing the log files

There are two ways to view (tail) the log files of your application. You can use the client tool:

$> rhc-tail-files -a sellmore

Or you can shell into the server and use the built-in tail command:

$> tail_all

You can also use the regular tail command in the remote shell environment.

Restarting or stopping your application

You can control your application directly without pushing files through git. One way is to use the client tool from your location machine:

$> rhc-ctl-app -c restart

You can also shell into your domain and execute a command using one of the special commands provided:

$> ctl_app restart

In addition to restart, you can use the commands start, stop, etc.

Persistence Storage

Preserving the database between restarts

You may have noticed that each time we restart the application, the data gets lost. There are two ways to resolve this:

Update tables rather that dropping and recreating them on deployment

Save the data to a safe location on disk

The first setting is a feature of Hibernate (or alternate JPA provider) and is changed using the following property in src/main/resources/META-INF/persistence.xml:

src/main/resources/META-INF/persistence.xml (fragment)

<property name="hibernate.hbm2ddl.auto" value="update"/>

The second feature depends on the database you are using. If you are using the provided H2 database, you’ll likely want to change the configuration in .openshift/config/standalone.xml to use the OpenShift data directory:

Open a browser and go to the URL shown, then login as admin with the password reported by the previous command.

Caution

It’s a good idea to create another user with limited privileges (select, insert, update, delete, create, index and drop) on the same database.

You can also shell into the domain and control MySQL using the MySQL client. You’ll need to connect using the hostname provided when you added the cartridge since it’s running on a different interface (not through a local socket).

Now we’ll configure our application to use OpenShift’s MySQL database when running in the cloud.

Switching the application datastore to MySQL

The JBoss AS 7 cartridge comes configured out of the box with datasources for H2 (embedded), MySQL and PostgreSQL. The datasources for MySQL and PostgreSQL are enabled automatically when the respective cartridges are added. You can find this configuration in .openshift/config/standalone.xml.

Here’s the datasource name that cooresponds to the MySQL connection pool:

Advanced Deployment

Building with Jenkins

Jenkins is a continous integration (CI) server. When installed in an OpenShift environment, Jenkins takes over as the build manager for your application. You now have two options for how to build and deploy on OpenShift:

Building without Jenkins

Uses your application space as part of the build and test process. Because of this, the application is stopped to free memory while the build is running.

Building with Jenkins

Uses dedicated application space that can be larger then the application runtime space. Because the build happens in its own dedicated jail, the running application is not shutdown or changed in any way until after the build is a success.

Here are the benefits to using Jenkins:

Archived build information

No application downtime during the build process

Failed builds do not get deployed (leaving the previous working version in place).

Jenkins builders have additional resources like memory and storage

A large community of Jenkins plugins (300+)

To enable Jenkins to use with an existing application, you first create a dedicated jenkins application:

$> rhc-create-app -a builds -t jenkins-1.4

Then you add the Jenkins client to your own application:

$> rhc-ctl-app -a sellmore -e add-jenkins-client-1.4

Make a note of the admin account password for Jenkins and point your browser at the following URL:

http://builds-[domain name].rhcloud.com

Once you are there, you can click "log in" in the top right of the Jenkins window to sign in and start tweaking the Jenkins configuration.

Now you simply have to do a git push to remote branch and Jenkins will take over building and deploying your application.

The pre-Jenkins way of doing this was to fire off a command line build and dump the output to the screen. You’ll notice that this output is replaced with a URL where you can view the output and status of the build.

Integration Testing

Writing real cloud tests with Arquillian

Bring your tests to the runtime instead of managing the runtime from your test. Isn’t the cloud one of those runtimes? It sure is!

Let’s use Arquillian to write some tests that run on a local JBoss AS instance. Later, we’ll get them running on OpenShift.

Setting up Arquillian requires thought. Let’s put those 10,000 monkeys to work again. Open up Forge and see if it can find a plugin to help us get started with Arquillian.

This test is going to read and write to a database. You probably don’t want to mix test data with application data, so first copy the JPA descriptor (persistence.xml) to the test classpath and prefix the file with test- so it doesn’t get mixed up:

Make sure the test-persistence.xml uses the ExampleDS datasource (or whatever you want to use for tests).

Next, open up the test in your editor so we can work it into a useful test. Begin by updating the ShrinkWrap archive builder to snag the JPA descriptor from the test classpath (instead of the production one):

src/test/java/com/acme/sellmore/rest/ItemEndpointTest.java (fragment)

.addAsManifestResource("test-persistence.xml", "persistence.xml")

Assign the @Test method a meaninful name and replace the contents with logic to validate that an item can be created in one transaction and retrieved in another:

Run the Arquillian test on this instance by activating the cooresponding profile when running the Maven test command:

$forge> test --profile JBOSS_AS_REMOTE_7.X

If things go we’ll, the tests will pass and you’ll see some Hibernate queries in the JBoss AS console. “Green bar!”

The previous test runs inside the container. Let’s write another test that acts as a client to the REST endpoint. To keep effort to a minimum, we’ll use the Apache HttpComponents HttpClient library to invoke the HTTP endpoints. We can get Forge to add it to our build:

Sigh. There’s no better way to do this at the moment, so copy the previous test and rename it to ItemEndpointClientTest (rename both the file and the class name). Then, replace the class definition with the following source:

If you get a test failure, it may be because the type the endpoints are configured to consume is incorrect. Open the ItemEndpoint class and replace all instances of @Consumes with:

src/main/java/com/acme/sellmore/rest/ItemEndpoint.java

@Consumes(MediaType.APPLICATION_XML)

Run the tests again. With any luck, this time you’ll be chanting “Green bar!”

Running the Arquillian tests on OpenShift

Okay, now you can say it. "Let’s take it to the cloud!" If they work there, they’ll work anywhere :)

It’s up to you whether you want to run the tests on the same OpenShift application as the production application or whether you want to create a dedicated application. We’ll assume you’re going to create a dedicated application. Let’s call it ike.

$> rhc-create-app -t jbossas-7 -a ike

You’ll also need an Arquillian profile. The Forge plugin doesn’t honor the OpenShift adapter yet, so you’ll have splice this profile into the pom.xml by hand:

You can either put the passphrase for your SSH key in the descriptor or you can export the SSH_PASSPHRASE environment variable:

$> export SSH_PASSPHRASE=[libra_id_rsa passphrase]

To activate this container configuration, write the name of the qualifier to the arquillian.launch file (alternatively, you can select the configuration using the -Darquillian.launch flag when you run Maven):

$> echo "OPENSHIFT_1.X" > src/test/resources/arquillian.launch

Are you ready to see some tests run in the cloud?

$forge> test --profile OPENSHIFT_1.X

You may want to tail the log files in another terminal to moniter the progress:

$> rhc-tail-files -a ike

If you can’t see the green bar, look above you :)

Hosting Configuration

Making your application a top-level domain

Do we expect that you’ll use *.rhcloud.com for all of your public websites? Of course not! That’s where the alias feature comes in.

You can create a domain alias for any OpenShift application using this command:

$> rhc-ctl-app -a sellmore -c add-alias --alias sellmore.com

Next, you point the DNS for your domain name to the IP address of your OpenShift server (or you can cheat by putting it in /etc/hosts).

I just get the following error when trying to install the Arquillian plugin:

Running test.integration.PluginTest
log4j:ERROR Could not create an Appender. Reported error follows.
java.lang.ClassNotFoundException: org.apache.log4j.rolling.RollingFileAppender
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at org.apache.log4j.helpers.Loader.loadClass(Loader.java:198)
at org.apache.log4j.xml.DOMConfigurator.parseAppender(DOMConfigurator.java:247)
at org.apache.log4j.xml.DOMConfigurator.findAppenderByName(DOMConfigurator.java:176)
at org.apache.log4j.xml.DOMConfigurator.findAppenderByReference(DOMConfigurator.java:191)
at org.apache.log4j.xml.DOMConfigurator.parseChildrenOfLoggerElement(DOMConfigurator.java:523)
at org.apache.log4j.xml.DOMConfigurator.parseRoot(DOMConfigurator.java:492)
at org.apache.log4j.xml.DOMConfigurator.parse(DOMConfigurator.java:1001)
at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:867)
at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:773)
at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:483)
at org.apache.log4j.LogManager.(LogManager.java:127)
at org.slf4j.impl.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:73)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:249)
at org.slf4j.cal10n.LocLoggerFactory.getLocLogger(LocLoggerFactory.java:59)
at org.jboss.weld.logging.LoggerFactory.getLogger(LoggerFactory.java:47)
at org.jboss.weld.bootstrap.WeldBootstrap.(WeldBootstrap.java:124)
at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.TestContainer.(TestContainer.java:212)
at org.jboss.arquillian.container.weld.ee.embedded_1_1.WeldEEMockContainer.deploy(WeldEEMockContainer.java:66)
at org.jboss.arquillian.impl.handler.ContainerDeployer.callback(ContainerDeployer.java:62)
at org.jboss.arquillian.impl.handler.ContainerDeployer.callback(ContainerDeployer.java:50)
at org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:63)
at org.jboss.arquillian.impl.context.AbstractEventContext.fire(AbstractEventContext.java:115)
at org.jboss.arquillian.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:96)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:162)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.jboss.arquillian.junit.Arquillian$3$1.evaluate(Arquillian.java:186)
at org.jboss.arquillian.junit.Arquillian$MultiStatementExecutor.execute(Arquillian.java:297)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:182)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:127)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
at $Proxy0.invoke(Unknown Source)
at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
log4j:WARN No appenders could be found for logger (org.jboss.weld.Version).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
Tests run: 46, Failures: 0, Errors: 43, Skipped: 3, Time elapsed: 11.451 sec <<< FAILURE!

I've been getting this error ERROR [scaffold from-entity] Error generating default scaffolding when i run the command scaffold from-entity ~.domain.* --scaffoldType faces --overwrite. However, when I remove the Customer.java class the error goes away. Being even more specific, I have run all the field entries for the Customer.java entity class, but when i get to issuing the first relationship on the Customer.java class involving the Address it throws the above errors. Also, FYI I am using the Eclipse plugin with the Beta5 forge release.

I am running it without openshift, so I am just starting on the forge part. The script works all the way till you get up to the scaffold command. I have run this manually and NOT using the script way because I wanted to learn the forge keywords. Is there a forge log anywhere? The error i am getting is very vague.

The error being reported when installing the Arquillian plugin should not actually cause any failures, but it's been resolved in the latest SNAPSHOT of Forge. (You can get it at http://jboss.org/forge - then look for Snapshot Downloads)

Regarding the scaffolding error. I'll look into it, but I have noticed some strange issues regarding executing this command from within scripts.

Thats the thing, I am not executing this from a script its when I run each command manually. Weird right? Anyways deleted old project, and now I am starting fresh. Ill let you know if everything goes as planned.

Thats the thing, I am not executing this from a script its when I run each
command manually. Weird right? Anyways deleted old project, and now I am
starting fresh. Ill let you know if everything goes as planned.

? Choose an option by typing the number of the selection [-default] [0] 60
Wrote /home/cbritz/arquillian/tests/arquilTest/src/main/resources/META-INF/persistence.xml
Wrote /home/cbritz/arquillian/tests/arquilTest/pom.xml
[arquilTest] arquilTest $ validation setup --provider HIBERNATE_VALIDATOR
Warning: The encoding 'UTF-8' is not supported by the Java runtime.**SUCCESS* Installed [forge.spec.validation] successfully.
Which version of hibernate-validator would you like to use?

Ok, so I went ahead and ran this in the actual Forge window in the terminal and it ran fine. So this must be an eclipse issue. Also, which i thought was wierd, was that i had to run the scaffold setup command again because Forge said it was missing faces. However, when i ran "scaffold setup --scaffoldType faces" I got this error "ERROR [scaffold setup] Failed to create required [home/myhome/arquillian/tests/arquilTest/src/main/webapp/WEB-INF/faces-config.xml]" To resolve this error I had to remove the faces-config.xml file then run the scaffold setup command again.

I've tried it a bunch of times using the Forge Console in JBoss Tools and it always works for me (if I do all the steps in proper order). I'm using the development version of JBoss Tools for Eclipse Indigo.

Forge Tools - 1.0.0.v20111208-2108-H31-M5

It may just be the result of having an older version of the tooling installed.

You last error seems to be the result of your project just getting into a messed up state and Forge being confused as to what to do.

The most important thing about reporting an error is to be able to reproduce it consistently (I know that's not always possible, but it's very helpful). That way, you can explain the exact steps to get from a blank slate (no project) to the error.