Well folks, after plenty of API refinements and battle-testing within our own projects at the JBoss Community, we’re proud to offer ShrinkWrap Resolver at a locked 2.0.0 release.  I’m posting the full user guide here, but the TL;DR of it is this: it’s an API for you to pull down Maven artifacts (and optionally their dependencies) in a simple fashion.  The project requires zero dependencies, will work on any JRE5+ runtime, and is open source with an Apache License 2.0 hosted here: https://github.com/shrinkwrap/resolver.  Have at it.

Special thanks go out to our contributors:

Ales Justin
Andrew Lee Rubinger
Aslak Knutsen
Bernard Labno
Carlo de Wolf
Davide D’Alto
George Gastaldi
Ivan Pazmino
Jörg Prante
joserodolfofreitas
Karel Piwko
Michal Matloka
Sachin Patil
Samuel Santos
Tair Sabirgaliev
Thomas Segismont
Tommy Tynja

…with special note to Karel Piwko from our JBoss QE department for both championing the concept of this project and its utility AND providing the proof-of-concept and implementations which lead to our solving the issue of nontrivial deployments in Arquillian in a sane way that didn’t involve too much software guesswork or cyclic build problems.  Enjoy!

S,

ALR

Introduction to ShrinkWrap Resolvers

<dependencies>
    ...
    <dependency>
      <groupId>org.jboss.shrinkwrap.resolver</groupId>
      <artifactId>shrinkwrap-resolver-depchain</artifactId>
      <version>2.0.0</version> <!-- Or whatever version you need -->
      <scope>test</scope>
      <type>pom</type>
    </dependency>
    ...
</dependencies>

 <dependencies>
    ...
    <dependency>
      <groupId>org.jboss.shrinkwrap.resolver</groupId>
      <artifactId>shrinkwrap-resolver-api</artifactId>
      <version>${version.shrinkwrap.resolvers}</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.shrinkwrap.resolver</groupId>
      <artifactId>shrinkwrap-resolver-spi</artifactId>
      <version>${version.shrinkwrap.resolvers}</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.shrinkwrap.resolver</groupId>
      <artifactId>shrinkwrap-resolver-api-maven</artifactId>
      <version>${version.shrinkwrap.resolvers}</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.shrinkwrap.resolver</groupId>
      <artifactId>shrinkwrap-resolver-spi-maven</artifactId>
      <version>${version.shrinkwrap.resolvers}</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.shrinkwrap.resolver</groupId>
      <artifactId>shrinkwrap-resolver-impl-maven</artifactId>
      <version>${version.shrinkwrap.resolvers}</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.shrinkwrap.resolver</groupId>
      <artifactId>shrinkwrap-resolver-impl-maven-archive</artifactId>
      <version>${version.shrinkwrap.resolvers}</version>
      <scope>test</scope>
    </dependency>
    ...
  </dependencies>

<dependencyManagement>
  <dependencies>
    ...
    <!-- Override dependency resolver with latest version.
         This must go *BEFORE* the Arquillian BOM. -->
    <dependency>
      <groupId>org.jboss.shrinkwrap.resolver</groupId>
      <artifactId>shrinkwrap-resolver-bom</artifactId>
      <version>${version.shrinkwrap.resolvers}</version>
      <scope>import</scope>
      <type>pom</type>
    </dependency>
    ...
  </dependencies>
</dependencyManagement>

<plugin>
  <groupId>org.jboss.shrinkwrap.resolver</groupId>
  <artifactId>shrinkwrap-resolver-maven-plugin</artifactId>
  <version>${version.shrinkwrap.resolvers}</version>
  <executions>
    <execution>
      <goals>
        <goal>propagate-execution-context</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Maven.configureResolverViaPlugin().resolve("G:A").withTransitivity().asFile();

ShrinkWrap.create(MavenImporter.class)
  .loadPomFromFile("/path/to/pom.xml").importBuildOutput().as(WebArchive.class);

ShrinkWrap.create(MavenImporter.class)
  .loadPomFromFile("/path/to/pom.xml", "activate-profile-1", "!disable-profile-2")
  .importBuildOutput().as(WebArchive.class);

ShrinkWrap.create(MavenImporter.class).configureFromFile("/path/to/settings.xml")
  .loadPomFromFile("/path/to/pom.xml").importBuildOutput().as(JavaArchive.class);

In my case at JavaOne 2012, it’s my last session with Aslak: “Continuous Enterprise Development: Case Studies in Java EE Integration Testing”.  We hit the stage at the Parc55 again in Cyril Magnin II/III Wednesday, 3 October, at 11:30 Pacific, and the session info can be found here.  From the abstract:

This highly technical session examines solutions for easing the testing of some of the more complex use cases within Java EE. Each example is backed by a runnable test (publicly available to participants), and the presentation covers automated continuous development of:

• The Web user interface (via Selenium)
• Persistent data and JPA
• Transactional boundaries
• Cloud-based deployments
• RESTful endpoints
• More

It showcases various techniques outlined in the book Continuous Enterprise Development in Java, forthcoming from O’Reilly Media, and is delivered by the authors. Expect a lot of proof through open source demos. You’ll see the presenters exercise the features of any compliant Java EE 6 runtime, using the Arquillian platform.

My team’s been lucky enough to enjoy some very positive feedback from our sessions over the years, but one comment we sometimes receive is that the message can be a little “soft” as we’ve catered to attendees of all skill levels.  So it’ll be interesting to see how this hour plays out, as the slide content will be limited to some supporting theory and the real meat of the course will be spent examining some solutions to the rougher edges of Java EE development.

I always want to kick myself for putting “Testing” in the title of these things, because that implies something separate from “real” development.  In truth the opposite is more accurate.  I’m fond of saying that “Testing is Development”, but the sentiment is better expressed by Jeremy Norris:

The purpose of automated testing is to enable change. Verifying correctness is just a nice side effect.

…or Tim Ottinger:

Move testing from the caboose to the engine.

Dan Allen voices the soundbyte “Coding with Confidence”.  Whichever way you spin it, the point is to consider testing a first-class citizen within your code.  In fact, I place it in order of importance somewhere below API design but definitely above implementation bits.  It’s a decent testsuite that enables me to brazenly work on a month-long refactoring that results in a 4000-line patch to be committed and released together.  The API is your contract with calling client code;  the testsuite is the contract your implementation has with your API.

So today’s session is going to cover the testable development of roughly 5 use cases.  I say “roughly” because we’ll favor quality over quantity; we want the talk to be fairly interactive with observations and suggestions from the attendees, so if we have to punt on some of the examples in order to give more complete coverage to a a fewer number, so be it.

Working with Data

One of the questions we most often receive revolves around interacting with a database.  The point of an application is to do stuff to state, and most programs require persistent state in some form or another.  Today we’ll focus a bit on relational mechanisms via JPA.

The example we’ll pull from here is a work-in-progress for the Book, a standard N-tier application with a JSF frontend.  While we spend a lot of time talking about the importance of integration testing alongside a backing container, we shouldn’t forget the obvious utility obtained by exercising unit tests as well.  Bean Validation definitions on the entity model are a wonderful candidate for standalone bootstrapping thanks to Hibernate Validator, so we’ll ease into the talk with a quick analysis of this in action.  Also, Emmanuel is in town and we like to make him smile.

With the easy stuff out of the way, we move along to an integration test which uses the Arquillian Persistence Extension to prepopulate data before testing from an external model, returning the database to a configurable (row-level or table-level) state when done.  Additionally, we can configure the feature to use transactions under the hood to roll back all changes made by the test upon test completion.  Sidenote: one of my favorite things about this extension is that it’s lead by a community contributor, Bartosz.  A simple annotation on the test methods does the dirty work for us:

@UsingDataSet("test_objects.yml")

This simple YAML file defines our source data for use in testing.

The View Layer

On the other end of the spectrum, seeing our data returned in the expected format is more than a nice bonus.  Of course, parsing out the possibly huge output from an HTML page can be a bit of a drag, so we’ve got a few tools to help in this department.

We use the same example here as we did with data, this time centering on the ConferenceTestCase.  There’s a lot going on here.

Remember that white-box testing allows us to inspect the inside of a system, while black-box testing focuses on the outside view.  With the following annotations above the test class, we’d like to introduce “gray-box” testing:

@WarpTest
@RunAsClient

Arquillian Warp is an extension which allows a test to both initiate a client-side request and perform assertions on server-side logic from inside the container.

Arquillian Drone lets us simply control the lifecycle of Selenium, through which we’ll examine UI output via a real web browser.  With the addition of Arquillian Graphene, we’re given an object model view of the DOM like this:

@FindBy(id = "conference")
private ConferenceView conferenceView;

Using this mechanism we may actually “mock” the data model used to render the response without going to the database.

Likely this example on its own should go into its own blog post, and it’ll definitely be used in the book.  So we’ll let it mature a bit then document it fully.

Testing Close to the Production Environment

With the advent of Cloud it’s become quite easy and cheap for us to spin up instances that are nearly equal in their makeup.  Because we should aim to exercise our application in an environment as close as possible to Production, it’s nice to take advantage of this setup as either a remote personal server extension to our development environment, or as a shared staging server for the development team.  We’ll see three approaches to interacting with OpenShift.

• Attach a debugger from your development machine to the remote instance, allowing inspection of running code and hotswap.
• Trigger Jenkins builds from a repository push, and on successful build, push changes to the staging and/or production instances
• Use the Arquillian OpenShift Container to execute locally-initiated client tests upon a remote instance in the cloud.

The demo we’ll use for this is located here.  Go ahead and put your personal mark into what will become our test data!

Transactions in Action

I’ve always liked showing how to leverage in-container testing to perform assertions on the configuration.  One of my favorite demos from the EJB 3.1 book shows how a simple omission of a transactional annotation can result in a serious change to your application and potential loss of revenue.  Transactional boundaries are important to respect, and they must be set appropriately.

Aslak has recently written another example which allows the test case to gain control over the UserTransaction in play:

@Inject
private UserTransaction transaction;

From there we get to play around with generic Callable instances, really to wrap any action in a Tx:

private  T transactional(Callable transactionalCallable) throws Exception {
  transaction.begin();
  T result = transactionalCallable.call();
  transaction.commit();
  return result;
}

Motto: Don’t be afraid to dig into the inner workings of the container while you’re in there.

Get some REST

To be honest, RESTful testing is one of the less-complex cases we get requests for.  It’s typically a black-box request from the client to a service, one illustrated by this example from the Arquillian Showcase.

The magic bit is knowing exactly what URL to hit, as the host or context path shouldn’t really be hardcoded.  Arquillian helps us out here:

@ArquillianResource
URL deploymentUrl;

…and from there it’s business as usual, though the RESTEasy Client APIs make this even simpler for us than a standard HTTP client:

ClientRequest request = new ClientRequest(deploymentUrl.toString() + RESOURCE_PREFIX + "/customer/1");
request.header("Accept", MediaType.APPLICATION_XML);

// we're expecting a String back
ClientResponse responseObj = request.get(String.class);

Assert.assertEquals(200, responseObj.getStatus());
System.out.println("GET /customer/1 HTTP/1.1\n\n" + responseObj.getEntity());

String response = responseObj.getEntity().replaceAll("<\\?xml.*\\?>", "").trim();
Assert.assertEquals("1Acme Corporation", response);

Wrap-up

Again, this presentation is more fun when it’s interactive.  There’s definitely more than one way to skin a cat, and we’re open to hearing your suggestions, solutions, and pain points.  It’s likely that some ideas you’ve got could make it into the book, so we’re excited to see and hear from you, either in person at the session or here in the comments.

S,

ALR

Because not everyone can be joining us in person, and because this is a technical talk we’d like to better enable our attendees to follow, this entry should serve as a guide for the live coding and demos we’ll be covering.  Session details may be found via the JavaOne site and on Lanyrd.

The abstract reads:

The myth of Java EE as a cumbersome platform is easily dispelled in this session, which aims to create a working application, from a blank repository to a live cloud deployment, in real time. It:

• Covers tools that bootstrap project creation, freeing you from mucking around with Maven POM boilerplate
* Generates a domain model and reverse-engineers JPA entities from it
* Automatically creates the scaffolding for tests that run in a real Java EE container, launched from the IDE
* Pushes it all to production on a public site

Using a variety of projects from the JBoss Community adhering to and building upon open standards, this presentation can create real enterprise apps in the time it takes other sessions to click through some slides. Let’s get building!

Presentation (intentionally-minimal) slides are available here, and I’ve posted some scripts and other human-readable instructions on GitHub.  The content we cover today is more or less adapted from an early chapter of the upcoming Continuous Enterprise Development in Java, now in Early Access Release and available for pre-sale.

The name of the game here is to take a blank repository (or filesystem), make a minimal, but fully-functioning data-based project, and get it online for the world to use before the JavaOne guys at the back of the room cut off our microphones.  Given the typical unreliability of conference network connections, we’ll pray extra hard to the Demo Gods that all goes smoothly.

Here we go.

I’ll be the first to admit that I’ve never much been a “tools” guy.  Sure, I use an IDE, but until recently I never saw much need to even dig too deeply into its featureset or gather many extra Plugins.  I used to catch Ruby on Rails demonstrations build an app from scratch and was typically left as one of the dissenters in the audience who believed that an application which directly mirrored the CRUD operations of a domain model was essentially worthless.  I’m well-versed in Maven configuration and can copy XML with the best of them, so that’s primarily how I’ve been coding my projects.

And I continue to believe in Java EE as a component model, especially as we’ve seen the Platform get less verbose and implementations break new ground in speed and efficiency.  Over the past few years we continually get feedback that figuring out exactly how to piece all the EE techs together into a cohesive application is difficult; documentation is scattered and may vary heavily from vendor to vendor.  At JBoss we’ve been working hard the past year or so on initiatives to address this very problem.

The first steps in setting up a new project are to lay out the structure, define the required dependencies, and get a working build in place.  As has become widely-accepted, I’ve been filling these via Maven for the past several years, and the process typically involves heavy use of copying an existing project, searching Google for relevant XML snippits, and wading through the Maven Central Repository index to find the coordinates of  whatever libraries you’ll depend upon.  Let’s see if we can take a different tack now.

JBoss Forge

Forge is an incremental project construction tool, and it’s implemented as a handy shell.  Through it, we can set up a Maven POM, quickly stub out our domain layer, reverse-engineer view components, get a head start on our test cases, manage servers and deployments, and much more through its extensible API.  This becomes especially handy for scripting.  Additionally, it’s well-integrated into:

…JBoss Developer Studio, an integrated set of plugins atop the Eclipse Platform geared towards Java EE, and specifically, JBoss project development.

Once we fire up JBDS, we’re set with an empty slate.  By invoking the Forge shell within the IDE (Control-4), we’re met with a prompt ready to take our input.  From here we can start to put our project together.  Each action we take will be automatically reflected in the Project Explorer.  For this application, we’ll execute the following Forge commands:

new-project --named feedback --topLevelPackage org.cedj.javaone2012.feedback --projectFolder feedback;

That’ll make us a new project. Now we’ll enable JPA and Bean Validation:

persistence setup --provider HIBERNATE --container JBOSS_AS7
validation setup --provider HIBERNATE_VALIDATOR

With that behind us, we can create some Entities and set their properties and constraints:

entity --named FeedbackEntry
field string --named twitterHandle
constraint NotNull --onProperty twitterHandle
field string --named feedback
constraint NotNull --onProperty feedback

We’ll also let Forge generate some JSF View pages for us to play with later.

scaffold setup
scaffold from-entity org.cedj.javaone2012.feedback.model.*

Those who have been following this space should be aware of my involvement with the Arquillian Test Platform, so it’ll probably come as no surprise that I’d be interested in setting up the POM with Arquillian dependencies (to be executed against JBossAS7) and generating a test case upon which to build:

forge install-plugin arquillian
arquillian setup --container JBOSS_AS_REMOTE_7.X
arquillian create-test --class org.cedj.javaone2012.feedback.model.FeedbackEntry.java

Before we continue, let’s change the default in persistence.xml to allow us to preserve data between deployments:

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

We’re now ready to build our application; Forge can execute the Maven lifecycle for us:

build --notest --profile JBOSS_AS_REMOTE_7.X;

We may also equip Forge and our project with the ability to interact with the application server:

forge install-plugin jboss-as-7
as7 setup
as7 start
as7 deploy

Assuming all went to plan, our application should be available in the browser at http://localhost:8080/feedback. Let’s put some data into our application for us to test. Pick whatever values tickle you and save them through the web interface.

When done, we can undeploy the application from the app server:

as7 undeploy

Now let’s change our generated FeedbackEntryTest to something more reasonable. Something like this:

@RunWith(Arquillian.class)
public class FeedbackEntryTest {
	@PersistenceContext
	private EntityManager em;

	@Deployment
	public static WebArchive createDeployment() {
		return ShrinkWrap.createFromZipFile(WebArchive.class, new File(
				"target/feedback.war"));
	}

	@Test
	public void canFindFeedbackByUser() {
		final FeedbackEntry feedback = em.createQuery(
				"from " + FeedbackEntry.class.getSimpleName()
						+ " where twitterHandle='@ALRubinger'",
				FeedbackEntry.class).getSingleResult();
		Assert.assertNotNull(feedback);
	}

	@Test
	public void testIsDeployed() {
		Assert.assertNotNull(em);
	}
}

This will deploy our application into the running server and ensure that we may find a user by the specified Twitter handle. If you’ve populated the database via the web interface above and are looking for the right handle in “canFindFeedbackByUser”, this should pass when executed from the IDE in “Run As > JUnit”.

So we’re managed to set up a minimal application, run it, and test it locally.  In the spirit of “release early, release often”, might as well make this public.

OpenShift is the Cloud-based PaaS offering from Red Hat.  It’s free to sign up, and provides hosting for a series of applications, Java EE apps on JBossAS7 included.

Once signed up, it’s easy to create a Domain in the JBoss Developer Studio “OpenShift Explorer”.  From there, “Create New Application…”

After logging in, you may set up the new JBossAS7 application on OpenShift via the IDE:

Once the new OpenShift Application is made, link it to the existing project in your workspace:

You’ll be asked if you’d like to connect your project to the OpenShift application’s Git settings (this is the version control system which backs the OpenShift deployment mechanism).  Agree.

Once your server is set up, you can find it in the “Servers” tab.  Right-clicking your application under the server will afford you the opportunity to “Publish”.

Do it.

After some pause while OpenShift uploads your application, builds it remotely, and deploys it, you’ll be able to open via the browser and share the link with the world.

With any luck, things will go just this smoothly at JavaOne.

S,

ALR

So we built an API which made it easy to group resources together in a single deployable unit:

JavaArchive archive = ShrinkWrap.create(JavaArchive.class, "deployment.jar")
   .addClass(MyEjb.class, MyCdiBean.class);

Combined with the Arquillian Test Platform which deploys objects like the above into Application Servers, Servlet Containers, and IoC Containers, the result is a full integration test which writes and executes like a unit test.  This is the heart of the Arquillian component model.

ShrinkWrap excels at filing byte-based content into a tree structure; that’s all a virtual filesystem does (or should do!).  But for a long while now there’s been a divide which has made testing more complex deployments difficult: you might not always have the content you want to insert on-hand.  Consider the following use cases:

1. A CDI bean which has library dependencies on a 3rd-party project
2. An EAR module which is composed of a few JARs, WARs, etc. which are built by other projects.
3. Module A depends on Module B, and you want to easily test the development versions (ie. unreleased) without changing your test code to match

The problem we have here is that once you start calling out to code that’s not in your project, you need to incorporate  dependencies into your deployments.  And finding these dependencies is a nontrivial problem to solve:

• Not every developer will be keeping a dependency repository in the same place on her machine
• Versions change as development progresses
• If you’re testing as part of your build, and your test relies upon a build output (like a JAR), you’ve got a cyclic dependency

This gap is the number one complaint we get in the Arquillian Community, and I’ve been happy to take the blame from the ShrinkWrap side because I’ve refused to offer up stopgap solutions.  I don’t like software that guesses, and I especially don’t like it when software guesses incorrectly.  Behaviour should be clear, concise, and deterministic.

So what we have really is two different problems: First, getting dependency content into a ShrinkWrap archive.  That’s easy.  The harder part is in resolving the dependencies from some coordinates which make sense to put into a test.

Perhaps the biggest asset made available by the Maven community is its expansive Central repository.  Regardless of the build tool you’re using, this repo makes  libraries available under a coordinate system which acts as a unique address (per repository).

Additionally, the Aether project, used by the Maven backend, is a standalone dependency resolver.  Unfortunately, the Aether API isn’t really built to handle the kinds of slimmer-code aims we espouse in the Arquillian community.

Perhaps no one is aware of the warts in testing enterprise software better than the JBoss Quality Engineering team in Brno, and our own Karel Piwko last year started prototyping an adaptor between ShrinkWrap and the Aether backend.  What he built worked, and over the next several months we got a handle on exactly how users were hoping to pull dependencies into their deployments.  We’re now happy with the API and seeking more input to refine it before it locks as backwards-compatible, so:

Tonight we’d like to officially announce ShrinkWrap Resolvers (SWR), 2.0.0-alpha-2.

org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-depchain:2.0.0-alpha-2:pom

The base has no compile-time dependencies (though you’ll need a bunch at runtime), and is capable of resolving to Files, InputStreams, or a custom type if you’d like to provide your own FormatProcessor.

The syntax follows generally the form:

Resolve [this coordinate set] using [some resolution strategy] formatted as [a type]

Its use looks like:

File junit = Maven.resolver().resolve("junit:junit:4.10")
   .withoutTransitivity().asSingle(File.class);

It’s also easy to pull in transitive dependencies associated with a coordinate:

File[] dependencyAndTransitives = Maven.resolver().resolve("groupId:artifactId:version")
   .withTransitivity().as(File.class);

Often we need to run resolution using alternate repositories or project-specific configuration.  In that case:

Maven.configureResolver().fromClassloaderResource("settings.xml")
   .resolve("groupId:artifactId:version").withoutTransitivity().as(File.class);

When we need to test the current version of the software we’re building, we might want to take advantage of all the dependencyManagement settings in our POM such that we don’t have to manually specify the version.  In that case:

Maven.resolver().loadPomFromFile("pom.xml").resolve("groupId:artifactId")
   .withoutTransitivity().as(File.class);

And perhaps we just want to get everything the current POM has defined as a dependency, with correct versions:

Maven.resolver().loadPomFromFile("pom.xml").importRuntimeDependencies()
   .as(File.class)

We’re offering a separate “ShrinkWrap Archive” extension to SWR, enabling direct resolution to an archive:

JavaArchive jar = ShrinkWrapMaven.resolver().resolve("groupId:artifactId:version")
   .withoutTransitivity().asSingle(JavaArchive.class);

SWR also supports offline mode, and integration with a Plugin enables the developer to skip explicitly setting the settings.xml or pom.xml file.

Over the next few alpha-level releases we’ll work on validating that the API makes sense, building up documentation, and porting in more essential features.  As always, we’d love you to get involved in development or offer us your experience through feature requests and bug reports.

S,

ALR

1. The API is clean, concise, and intuitive
2. The backend adaptors allow us to translate the ShrinkWrap grammars into something Java EE containers can understand

Though the project has never had any EE dependencies, its most famous application has always been as the deployment mechanism for the Arquillian Test Platform.  Today I can announce that ShrinkWrap is officially equipped with its first SE-targeted feature as backend provider of an in-memory Java7 FileSystem.

Creation of the FileSystem through the NIO.2 API looks like this:

final JavaArchive archive = ShrinkWrap.create(JavaArchive.class,"myArchive.jar");
final Map<String, JavaArchive> environment = new HashMap<>();
environment.put(ShrinkWrapFileSystems.FS_ENV_KEY_ARCHIVE, archive);
final URI uri = ShrinkWrapFileSystems.getRootUri(archive);
final FileSystem fileSystem = FileSystems.newFileSystem(uri, environment);

And of course we offer a shortcut API:

final JavaArchive archive = ShrinkWrap.create(JavaArchive.class);
final FileSystem fileSystem = ShrinkWrapFileSystems.newFileSystem(archive);

From there, simply interact with ShrinkWrap through the NIO.2 classes just as you would with the default filesystem; lots of operations are made easy by the new Files API.

The magic piece backing all I/O is our new implementation of SeekableByteChannel.  This interface defines operations for random access to an in-memory byte store in  both read and write modes, and our implementation is available for use standalone.

In addition, we compose this support together with the ability to be directly added to an archive via MemoryAsset and MemoryNamedAsset.

ShrinkWrap Core remains free of dependencies.  While the base implementation runs on Java5, this new support does require Java7.  To this end, we’ve provided a new Dependency Chain POM to bring in this support without imposing Java7 on all users.

ShrinkWrap NIO.2 is available in versions starting at 1.1.0-alpha-4, now available from Maven Central.

S,

ALR

It’s become very clear to us on the Arquillian team that users aren’t really seeking a component-by-component approach to building applications.  While docs on EJB and Seam are all well and good, they’re instructive of a particular technology.  And users don’t primarily aim to learn APIs, they want to solve problems.

• How do I bootstrap my application tests with data?
• What’s a good approach to handling server-push events?
• Where is the best place to keep my logged-in user’s state?
• When is it appropriate to leverage a distributed data grid?
• Why would I opt for a NoSQL solution in place of a relational model?

For a long time now we’ve debated undertaking an “Arquillian Book” to showcase our beloved test platform.  But as the idea to author a text evolved, our own advice increased in relevance:

Testing is development.

Arquillian isn’t really the focus; it’s just a tool.  And under the JBoss umbrella, we have a veritable armada of projects suited to ease, extend, and enhance Enterprise Java.

What’s been lacking is a illustrative source to address how these disparate bits work in tandem, and more importantly, when they should be applied.

So I’m proud to announce that Dan Allen, Aslak Knutsen and I will be delivering a guide to some of the most common and interesting use-cases in building multiuser applications.  It’s aptly entitled: “Continuous Enterprise Development in Java“.

The book is currently on-target for an Early-Access Program, presales, and some initial material to be available around the JavaOne 2012 timeframe, with formal release following in the Spring of 2013.

We’ve enlisted the editorial expertise of O’Reilly Media, and in particular Meghan Blanchette to assist with quality assurance, translations, electronic media, and worldwide distribution.

The decision to go with O’Reilly was two-fold.

1. Trust.  Meghan made it clear that she’d mediate on our behalf to address some rather non-traditional requests for the authoring and publication process.
2. O’Reilly catered to our needs and enabled us with the open process we’d been hoping for.

At a time when half the world has gone mad over intellectual property and copyrights in a vain effort to “protect” their work, Tim O’Reilly has advocated for the “free flow of information“.  As developers of free software, we agree and will be authoring the book’s source content under the Creative Commons Sharealike License.

This enables us to hook into a complementary effort already underway at JBoss: The JBoss Way.

Put simply, the JBoss Way is an approach to building Java EE applications using the JBoss stack.  It’s backed by a series of quickstart examples and tutorials branded as the JBoss Developer Framework.

The JDF team has been doing some great work that’s available NOW to use/view/fork.  The TicketMonster example is already running on the OpenShift cloud.

So Dan, Aslak and I are very, very excited to pursue this open approach to publishing along with our friends in the Java EE Community, for the Java EE Community.

S,

ALR

This year we’ll be having an informal, unofficial meetup at the oldest continually operating tavern in the United States, the Bell in Hand.

45 Union Street
Boston MA 02108
(617) 227-2098

We’ll be there 6PM – 9PM on Sunday night, the 24th of June, the night before JUDCon.

Take note of the driving or public transit directions (relative to the Hynes Convention Center), and be sure to join up!

Lost?  Ping me on Twitter @ALRubinger and I’ll do my best to guide you.

S,

ALR

And just as Open Source isn’t restricted to programming, Arquillian isn’t bound to Java EE.  Sure, its roots have been in the testability of app servers, but the Platform has grown to reach the UI.  Persistence.  Stress-testing.

Because the mission of Arquillian is to get you testing inside of your real environment.  No mocks.  And to us, testing is development.

This year, we want to take the Platform deeper into the Java ecosystem.  We want to see exactly how easy we can make the testable development cycle for more technologies: JavaFX.  Android.  Eclipse development.  Other VM languages.  Whatever you bring to the table.

So in true Open fashion, we’d like to extend an invitation to all developers and speakers within the Java landscape to join us in a submission for the JavaOne 2012 Community Keynote this October in San Francisco.

The focus of the proposed talk will be testable development of as many Java corners as we can represent, and the Arquillian team will assist with integration as we can.  We’ll have a few months to arrange examples and show the in-IDE testing of components that were previously unwieldy or cumbersome.

Of course, we can make no guarantees that our proposed talk will pass the selection committee, but we feel that the Open nature of this submission speaks to the true Community spirit of the Keynote.

So join us in our run for the Big Stage; leave comments in the Thread below and we’ll kick off a group to together outline the proposal and submit it for consideration by the due date, 9 April.

S,

ALR

Around the same time, Agile Development was really collecting religious momentum, and a guiding precept there was roughly: “Do only what needs to be done now.”

This makes sense; it helps to ensure that we avoid scope creep, we don’t invent requirements that may end up being unnecessary, and we don’t overengineer.  Let’s just focus on delivering the minimal set necessary, then worry about expanding it later.

As such, I adopted the “no” philosophy.  I figured that if a feature was really that important, it would persist and nag in some way until it was included.  Otherwise, it must not be that worthy.  So as a default, my answer to everything was “no.”  Like a knee-jerk reaction: no.  Want me to do something new?  No.  New technologies?  No.  Component upgrades?  No.

It’s not a hard methodology to enforce.  Just pretend you’re every girl I’ve ever met.  ”No.”

So then I came aboard into Professional Open Source in building the EJB3 Container for the JBoss Application Server with Carlo de Wolf.  Oh boy, does that guy know how to separate concerns.  Over the course of a few years my new and reluctant mentor would drill into my head the importance of defining a contract for interaction between components and keeping everything in their rightful place.  Does this belong here?  No.  Build a new thing.  Then integrate it.  It carried along my tradition of “no” quite nicely, but at least it offered, “not here, go play over there”.

Then I got really sick of running the EJB3 TestSuite upon JBossAS, and started building out some tools – some great, some hacky – to improve the situation.  One of these, a then-unnamed API for manipulating Java Archives, caught the attention of some dude from Oslo named Aslak Knutsen.  Who really started fucking up my universe.

This guy wanted to implement every single integration and feature under the sun.  He wanted to deploy these archives not only into AS, but other vendors.  He wanted to use custom JUnit runners.  He wanted to code stuff just to see if it could be done.  And he’d prototype a way to do it.  For awhile, it was all I could do to keep up with this runaway nutjob that I was sure we’d never be able to support or put into any maintainable form.

The Java Archive API became, of course, ShrinkWrap, and Aslak went on to employment with us as lead of the Arquillian Testing Platform.

And still I advised, “Slow down.”  We needed to keep focus on our primary goals here.  We needed to learn to say “no”.

Well, “no” isn’t in the Norwegian dictionary, I suppose.  And it certainly didn’t help matters to have Seam lunatic Dan Allen be coming along to goad on what was becoming an endless litany of “cool stuff we could do”.  My little team was comprised of children prone to chasing shiny balls; fantastic.

In the years that followed, we’ve watched the Arquillian Suite of projects blossom into a wide array of tools intent on easing the testing of Enterprise Java.  And it turns out, just by trying new ideas in a sometimes half-baked fashion, having something concretely usable is enough to determine if the concept has merit.  Other people in open source will pick it up, be drawn to it.  We’ve got contributors coming in from all sorts of angles: “What about the UI?”  ”What about Behavior-Driven Development?”  ”What about Persistence?”  ”What about…”

Turns out the risk of taking on too much or letting quality suffer naturally corrected itself as these ideas matured.  And the bad ideas just silently died, with minimal effort wasted.

I remember reading something once written by Red Hat People and Brand SVP DeLisa Alexander about the willingness to fail acceptably.  Meaning that if you invest minimally in a bunch of ideas, your eggs aren’t all in one basket and you can afford to lose a few along the way.  From those eggs, you just might get some extra chickens you weren’t expecting, which in turn makes: yep – more eggs.  In short, saying “yes” solves the chicken/egg problem.

But none of this really hit home for me until today.  For one, I’ve been debating with a colleague about accepting more risk in general.  About having the faith to try some new things, even if they may not work out I believe the acceptable risk quota is still in the black.  And I took some time away from this lengthy email exchange to read Tina Fey’s “Bossypants“.

See, Tina spent her formative years as a professional comedienne in a Chicago-based improv troupe where the rule is, “Yes, And…”.  Meaning no matter the premise of the scene thrown at you, agree with your costar.  And then add upon it.  Wrong answers do not exist.  It’s an exhilarating approach.

Of course, I work in software and business.  Obviously wrong answers exist.  Most answers are probably wrong.  But when I’m wearing my hat as a creative problem-solver, probably it’s useful to invest just a little bit into each stupid nugget that comes across, or at least enable the idea-bearer to make some headway on his/her own.  Because I still believe I was right before: good ideas will persist.  Just don’t kill them too quickly.

Yes.  It’s so simple.  Minimally commit yourself to new things and see if they warrant further investment.

And if you have any doubts at all about this approach, check out the movie “Yes Man.”  Because Jim Carrey embraces the affirmative, and he gets to nail Zooey Deschanel.

S,

ALR

Who's the ignorant American now?!

France was the one gap in my schedule devoid of conferences or technical engagements, and I was thouroughly amped to see the city. Of course, when you’re staying with Seam Social Lead Antoine Sabot-Durand’s family, the experience gets amplified as we had the chance to geek out along the way. Throw into the mix old friends like Hibernate/data guru Emmanuel Bernard and new ones like Java EE author Antonio Goncalves, and now we’re cooking with gas. My apologies to the ParisJUG community as we were only in town for the weekend, but I’m hoping to meet your thriving group in the flesh some day sooner than later.

Antonio's Book, Proudly displayed at the Wine Bar in which it was largely penned.

The discussion on this leg that held most interest for me stemmed from a question raised by Antonio on the relationship between JBoss projects. Through the past few weeks I’ve had the chance to think on this further, and I’ve come to this: upstream projects should be given as much freedom and flexibility as can be permitted.

I don’t believe we do the community a disservice by giving as much leverage for individual projects to use whatever tools and mechanisms they deem appropriate. Build systems, documentation delivery, SCM, development methodologies, you name it. I’ve been a part of great projects that run “my” way, and I’ve struggled to work alongside equally great projects that run counter to my every instinct. That’s the beauty of letting a community shape the direction of the project; it becomes a breathing organism which molds to its creators’ tastes. Unification of projects is not an important construct to me. It’s Darwinian. Some undertakings will fail, either because they’re conceptually flawed or poorly run. And we should let them.

That’s why we have the notion of products. For the Enterprise we need to take these ideas and code which have matured, and focus on a streamlined delivery process that makes everything look the same. So if you ask me, let projects run free and arm them with all the tools they need to succeed. Make suggestions for how they should build their communities. But impose judiciously. And allow the supported product to fit the need for customers who rely upon the unification services.

In that light, I’m awfully proud in particular of my teammates Dan, Aslak, and Lincoln. I think about the type of outreach we do, about the type of investment in building the community and the thought that goes into all of the stuff that doesn’t involve code. Dan and his wife Sarah singlehandedly introduced a much more radical and effective presentation platform for us. Not to mention near-daily emails containing some allegory to building software. Aslak is on the IRC channels daily, and his engagement has grown from fielding user questions to coaching ARQ developers. And Lincoln took the task of bootstrapping projects and turned it on its rear-end, making Forge an all-out plugin community with limitless bounds.

For my part, I think the emphasis was always placed on limiting the barriers to entry for new contributors. It’s not a deceptive formula: define small scopes, bite off little bits at a time, and focus first on the API and its use. I’m a simple guy.

But I digress. Paris. Also there was wine. And laughter. The two were likely related.

Slow as a snail? JBoss eats snails.

Speed is to become a theme starting in the next installment, after Linc and I hit the TGV outbound to Stuttgart to meet up with Da Germans.

S,

ALR