Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Forge Core Framework APIs and Implementation
Ruby Java C Python Groovy JavaScript Other

Fetching latest commit…

Cannot retrieve the latest commit at this time

Failed to load latest commit information.
addon-manager
addons
bootstrap
configuration
convert
dependencies
dist
environment
facets
javaee
maven
parser-java
projects
resources
scaffold
shell
ui
.gitignore
.travis.yml
CONTRIBUTING.md
LICENSE
README.asciidoc
addon-dependencies.graphml
eclipse-code-formatter-profile.xml
forge-install.bsh
pom.xml

README.asciidoc

JBoss Forge 2.0

The fastest way to build applications, share your software, and enjoy doing it.

What’s new and noteworthy?

  • Addons: What were previously called "Plugins" in Forge 1, are now "Addons" in Forge 2. This decision was made to clear up confusing verbiage like, "Plugin X has N Plugins" (due to the org.jboss.forge.plugins.Plugin interface.)

  • Modular Container fully rewritten:: The Forge runtime is now a fully functional Java module system based on JBoss Modules (The same engine behind JBoss AS 7+ and JBoss EAP). This means you may now pick-and-choose which addons are important for you.

  • Smaller, leaner, and faster:: Forge 2 now sports a slimmer four megabyte download size, and starts up in under three seconds. (Compared to upwards of 10+ seconds for Forge 1)

  • Better IDE Integration:: Forge 2 addons have been de-coupled from the command line, meaning you can create addons that run as wizards in the IDE, as well as commands in the shell - the same code works in both environments.

We are currently in the process of migrating Forge 1 to Forge 2, so expect to find some Forge 1 functionality missing in the early versions of Forge 2.

Download Forge 2:

Forge 2 is packaged inside an Eclipse plugin and also as a standalone ZIP file. They are independent of each other. It is worth mentioning that the Eclipse plugin does not support access to shell yet.

Get Started with the Command line tools:

Note
The shell is not fully working at the moment, so we recommend you to use the Forge 2 Eclipse Plugin

Forge is now ready to go.

Install the required addons by running the following commands:

    forge --install groupId:artifactId,version
  • Forge will install the required dependencies for each addon.

If you wish to install the prototype Forge 2 Shell called Aesh, be sure to run the following:

    forge --install shell

If you wish to remove any addon, you can use the following command:

    forge --remove groupId:artifactId,version

Get Started with the Forge 2 Eclipse Plugin:

This plugin starts the Forge 2 Container and your installed addons, so you can use them directly in your workspace

  • Press Ctrl + 5 to show the installed addons that you may interact with (these addons use the UI addon, hence providing a user interface - see Developing an UI Addon for more details).

The eclipse plugin already bundles the following addons

  • addon-manager

  • convert

  • dependencies

  • environment

  • facets

  • javaee

  • maven,projects

  • resources

  • ui

  • ui-spi

Developing an Addon

Forge addons are simple Maven projects with a special classifier "forge-addon". This classifier is used while installing an addon so the Furnace container can calculate its dependencies, freeing you from Classloader hell.

One of the most important things to know about developing a Forge addon, is that the Furnace runtime container (the core of Forge), is actually an embeddable, modular Java container. This means that each addon has its own ClassLoader and that addons share classes from each other, in addition to supplying their own local classes. Furnace builds a graph of addon dependencies at runtime, and automatically calculates which addons should see classes from other addons.

For now, however, just treat your first addon as if it were any other Java project. The differences between a "modular" and "traditional" environment are not as great as you might think, and the Furnace development model has been created in a way that should make these differences seem natural, almost transparent.

Create a Maven project

Forge Addons must be JARs published with a forge-addon classifier. Add this plugin configuration to your pom.xml:

<build>
   <plugins>
      <plugin>
         <groupId>org.apache.maven.plugins</groupId>
         <artifactId>maven-jar-plugin</artifactId>
         <executions>
            <execution>
               <id>create-forge-addon</id>
               <phase>package</phase>
               <goals>
                  <goal>jar</goal>
               </goals>
               <inherited>false</inherited>
               <configuration>
                  <classifier>forge-addon</classifier>
               </configuration>
            </execution>
         </executions>
      </plugin>
   </plugins>
</build>

In order to use CDI and services from other addons in your addon, you’ll need to reference the Furnace CDI container addon as a dependency your pom.xml file:

<dependency>
   <groupId>org.jboss.forge.furnace.container</groupId>
   <artifactId>cdi</artifactId>
   <classifier>forge-addon</classifier>
   <scope>provided</scope>
</dependency>

Your complete POM should now look something like this:

<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>com.example</groupId>
   <artifactId>example</artifactId>
   <version>0.0.1-SNAPSHOT</version>

   <name>My First Addon</name>

   <dependencies>
      <dependency>
         <groupId>org.jboss.forge.furnace.container</groupId>
         <artifactId>cdi</artifactId>
         <classifier>forge-addon</classifier>
         <scope>provided</scope>
      </dependency>
   </dependencies>

   <build>
      <plugins>
         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-jar-plugin</artifactId>
            <executions>
               <execution>
                  <id>create-forge-addon</id>
                  <phase>package</phase>
                  <goals>
                     <goal>jar</goal>
                  </goals>
                  <inherited>false</inherited>
                  <configuration>
                     <classifier>forge-addon</classifier>
                  </configuration>
               </execution>
            </executions>
         </plugin>
      </plugins>
   </build>
</project>

Add behavior to your addon

Once this is done, to expose services in your Addon for injection and service lookups in other addons, your types must be annotated with @Exported:

@Exported
public class ExampleServiceImpl
{
   public ServiceResult doSomething() {
        // Do stuff...
   }
}

However, best practices favor placing the @Exported annotation on a service interface, otherwise consumers will be required to request your specific service implementation. For example:

@Exported
public interface ExampleService
{
   public ServiceResult doSomething();
}

Then simply implement the service interface, and the @Exported annotation will be inherited automatically:

public class ExampleServiceImpl implements ExampleService
{
   public ServiceResult doSomething() {
        // Do stuff...
   }
}

Re-use functionality from other addons:

Forge has a modular architecture that enables you to re-use functionality from other addons, directly in your own addon code. In order to achieve this, you must add addon-dependencies in your pom.xml file.

<project>
   ...

   <dependencies>
      <!-- Addon Dependencies -->
      <dependency>
         <groupId>org.jboss.forge.addon</groupId>
         <artifactId>resources</artifactId>
         <classifier>forge-addon</classifier>
         <scope>provided</scope>
      </dependency>
      <dependency>
         <groupId>org.jboss.forge.addon</groupId>
         <artifactId>ui</artifactId>
         <classifier>forge-addon</classifier>
         <scope>provided</scope>
      </dependency>

      <!-- Furnace Container -->
      <dependency>
         <groupId>org.jboss.forge.furnace.container</groupId>
         <artifactId>cdi</artifactId>
         <classifier>forge-addon</classifier>
         <scope>provided</scope>
      </dependency>
   </dependencies>

   ...
</project>

What scope should my addon dependencies be?

There is a simple rule that will make this an easy decision:

"compile if it shows, provided if nobody knows."

To explain, if you never publicly expose types (classes, interfaces, etc…) from another addon in the outward-facing APIs of your addon, then you should include that addon as provided scope. If you do, however, expose classes from that addon in the public APIs of your code, then that addon should be labeled as compile scope (default,) which means that this dependency will be exported to consumers that depend on your addon.

Addon dependencies may also be made optional if consumers of your addon should be able to choose whether or not certain functionality is enabled, or if your addon behaves differently when other addons are already deployed to the container.

The following chart explains this in detail. Assume that our addon depends on the resources addon, which provides the ResourceFactory and FileResource classes:

Example Scope should be Explanation
public class InternalExample {
   @Inject private ResourceFactory factory;

   public void doSomething(File file) {
      Resource<?> r = factory.create(file);
      System.out.println("New resource: " + r)
   }
}

provided

Consumers of your addon never see classes or interfaces from the resources addon; it is only used internally as an implementation detail.

public class ExposedExample {
   public Resource<?> doSomething(File file) {
      Resource<?> r = factory.create(file);
      return r;
   }
}

compile

Consumers of your addon require classes from the resources addon to interact with your code, since it has been used in the public APIs of your classes.

public class TransitiveExample {
   public void doSomething(Facet<?> f) {
      System.out.println("I got a facet! " + f);
   }
}

compile

Consumers of your addon require classes from the facets addon to interact with your code, which is an exported dependency of the resources addon.

The Facet class comes from the facets addon and is used in the public APIs of your addon.

Test your addon

One of the most important concepts of writing a Forge addon is writing tests using the Furnace test harness. This allows you to test your code in an actual Furnace environment, and verify that things are behaving as expected. Typically we suggest using a separate project to test your addon in order to keep concerns separate, which tends to lead to cleaner code and fewer surprises.

For simplicity’s sake, we’ll assume that your addon uses the default Furnace container (org.jboss.forge.furnace.container:cdi).

Set up the test-harness in your build descriptor (pom.xml)

Add the following dependencies to your pom.xml file if they are not already there. Make sure that the Furnace versions are the same as the rest of your project.

<dependency>
   <groupId>org.jboss.forge.furnace.test</groupId>
   <artifactId>furnace-test-harness</artifactId>
   <version>FURNACE_VERSION</version>
   <scope>test</scope>
</dependency>
<dependency>
   <groupId>org.jboss.forge.furnace.test</groupId>
   <artifactId>arquillian-furnace-classpath</artifactId>
   <version>FURNACE_VERSION</version>
   <scope>test</scope>
</dependency>

If you are writing tests in a separate project or sub-project, you should also add a dependency to your addon, or to the addon you wish to test (you can test anything you like.)

<dependency>
   <groupId>com.example</groupId>
   <artifactId>example</artifactId>
   <classifier>forge-addon</classifier>
   <version>YOUR_VERSION</version>
   <scope>test</scope>
</dependency>

Write your first test

Now, you’ll need to create a test class with the following layout, using the standard JUnit test APIs:

package org.example;

import org.jboss.arquillian.container.test.api.Deployment;
import org.jboss.arquillian.junit.Arquillian;
import org.jboss.forge.arquillian.archive.ForgeArchive;
import org.jboss.shrinkwrap.api.ShrinkWrap;
import org.junit.Assert;
import org.junit.Test;
import org.junit.runner.RunWith;

@RunWith(Arquillian.class)
public class ExampleFurnaceTest {

   @Deployment
   public static ForgeArchive getDeployment() {
      ForgeArchive archive = ShrinkWrap.create(ForgeArchive.class);
      return archive;
   }

   @Test
   public void testSomething() throws Exception {
      Assert.fail("Not implemented");
   }
}

Then you’ll need to add some configuration so that your addon will be deployed to the test environmenet. This is done using the @AddonDependency annotation. You’ll also need to add an addon dependency link from your test case to your addon (otherwise the test case will not be able to use any of your addon’s classes or services.)

@RunWith(Arquillian.class)
public class ExampleFurnaceTest {

   @Deployment
   @Dependencies({
       @AddonDependency(name = "org.example:example", version = "YOUR_VERSION")
   })
   public static ForgeArchive getDeployment() {
      ForgeArchive archive = ShrinkWrap.create(ForgeArchive.class)
         .addBeansXML()
         .addAsAddonDependencies(
            AddonDependencyEntry.create("org.example:example", "YOUR_VERSION"),
         );
      return archive;
   }

   @Test
   public void testSomething() throws Exception {
      Assert.fail("Not implemented");
   }
}

Now that the test case deploys and depends on your addon, you may access services from it via injection:

@RunWith(Arquillian.class)
public class ExampleFurnaceTest {

   @Deployment
   @Dependencies({
       @AddonDependency(name = "org.example:example", version = "YOUR_VERSION")
   })
   public static ForgeArchive getDeployment() {
      ForgeArchive archive = ShrinkWrap.create(ForgeArchive.class)
         .addBeansXML()
         .addAsAddonDependencies(
            AddonDependencyEntry.create("org.example:example", "YOUR_VERSION"),
         );
      return archive;
   }

   @Inject
   private ExampleService service;

   @Test
   public void testSomething() throws Exception {
      Assert.assertNotNull(service);
      Assert.assertNotNull(service.doSomething());
   }
}

This is the basic premise of using the test-harness. For detailed examples, take a look at some of the existing Forge test cases in our github repository.

Install your addon in the local maven repository:

    mvn clean install

Run

    ./forge --install yourgroupId:artifactId,version
Warning
This coordinate is NOT the same as maven’s. You MUST use a comma (,) between the artifactId and the version**

Install your Addon

Depending on the Forge environment in which you are running, installation steps will differ.

For Eclipse

Open the Forge quick-assist menu, select either "Build and install an Addon" or "Install an addon" to build and install your project, or install a pre-built maven artifact.

For the Shell

Make sure that you have run a mvn install prior to executing forge --install artifactId:groupId:version on the native system terminal command line.

Something went wrong with that request. Please try again.