Open Source Advocacy | mojavelinux.com

Seam in Action Translations

January 02, 2012

A long overdue post, I'm still excited to share that Seam in Action was translated (in 2010) into Korean and Simplified Chinese--two languages I can't even pretend to understand. It's pretty strange to see words that you spend countless hours revising look complete foreign to you. But exciting at the same time!

These books arrived in a box that clearly looked like it came out of a shipping container that was aboard an ocean carrier. My goal is that sometime soon (2012 perhaps?) I'll get to travel to where these texts originated :) (but hopefully on an airplane).

I have a whole stack of these books, so if you are in the DC area (or the US for that matter) and you want one of these books, just let me know. I'll mail it to you, free of charge.

Posted at 03:00 PM in Seam in Action | Permalink | Comments (1)

Open letter to the JCP Executive Committee calling for JCP reform

November 01, 2010

Seizing the opportunity of a new Executive Committee (EC) under a new regime, I'd like to issue a call for reform of the Java Community Process (JCP) to allow it to produce more iterative and timely technology and live up to it's name as a "community process", rather than acting as the "corporate process" many believe it is today [1].

Goals and current problems

The goal and of this call to action parallels a statement made by Mark Little, CTO of JBoss and member of the EC, in response to questions for the 2010 EC candidates [2].

We believe that the EC still has an important role to play in the future of Java, and working within the EC is the best place to push for change and improvements. Java is certainly more "open" now than it was a decade ago, but it's not as open as [...] other standards bodies [OMG, OASIS, W3C and IETF]. We would like to see that change.

Indeed, the central problem with the current JCP is lack of transparency and openness. Although the JCP defines itself as "the open, participative process to develop and revise the Java technology specifications, reference implementations and test suites", it's not very open nor participative in practice. The community is almost entirely excluded when developing so called "open standards".

The root cause of this problem is that the Expert Group (EG) mailinglists are not open to the public (save a few exceptions, notably JSR-303 and JSR-311). The mailinglists are where the bulk of the technology design takes place. The private mailinglists don't merely close the doors to the general public. EG members from one JSR can't even read the correspondence of another JSR.

Feedback is one directional, from community to EG. All the general public can see are the drafts of the JSRs. They don't know how the EG arrived at that draft, meaning they aren't able to study the discussions that went into it. The EG may reciprocate by publishing another specification draft, with or without the feedback incorporated.

While companies and major Java leaders are involved in the JCP, individuals from the Java community have to really fight to be included or provide feedback. Let us not forget the significance of their participation, as Mark Little points out.

A strong JCP and a strong EC should be to the benefit of the entire Java community and not just to a select few.

The JCP also fails to respect the nature of software development. Instead of following an iterative process, JSRs target big-bang releases that have no clear continuum to the next generation. These major shifts in the platform make it increasingly harder for consumers to carry out migrations. Smaller releases would be easier to adopt. There are also huge lapses between releases, which is time for the technology to fall out of date.

How can we expect to define a unified and consistent platform that integrates well if the technologies bundled are created in different campuses at different times? The decisions that occur behind close doors effectively turn off would be participants and consumers. The community becomes frustrated because they don't know what's going on.

It's true that progress can emerge even from even a crippled process. There's no doubt that Java EE has been experiencing a revival since the release of Java EE 6, but with no clear target for EE 7, how long can the honeymoon last? Bill Burke cites how a small company like Red Hat has been able to make a big impact on the JCP standards [3]. He provides this evidence to make the point that the JCP is salvageable. Great, so let's salvage it and get it moving again.

The call for reform

I propose that the JCP redefine itself as:

"An open, community-oriented standards organization that produces standard technical specifications for Java technology in order to keep it competitive and to bring value and choice to businesses worldwide. These goals are achieved by honoring the nature of software development, which means fostering a collaborative, evolutionary process where change of all types (addition, revision and deprecation) is inevitable and standards are snapshots in a timeline along that evolution.

Standards produced by this process are published under and open, non-clickthrough license, which applies to the specification documents, the APIs, the reference implementations (RIs) and the compatibility test suites (TCKs). A fair voting system is used to maintain a balance of power and there is complete openness of process and membership.

The goal of this organization, above all else, is to produce timely, iterative, high-quality standards, which means never standing in the way of progress nor precluding proposals or ideas that may lead to a better way forward."

To make it very clear what changes I'm calling for, I've itemized them below, ranging from "must have" to "nice to have".

Must haves:

Specifications must be published under and open, non-clickthrough license, which covers the specification documents, the APIs, the reference implementations and the compatibility test suites
Specifications should be free to use and implement (no TCK fees)
Specifications must provide a non-clickthrough specification document, stored in an open VCS system and easily viewable online by anyone (a nightly build of the spec would be sufficient of the document is created by for-pay software)
Specifications should be required to publish API binaries, sources, and JavaDocs to Maven Central
Specifications must have public issue trackers, open source TCKs and public mailinglists for all JSRs, and require information about these resources to be public and easy to find
Expert Groups (EGs) should not be automatically disbanded after a final release of a spec (maintenance releases are an extremely important part of a JSR's evolution)
Maintenance releases should be easier to initiate (and get approved); the software process should be iterative
Names of individual representatives, and the company they represent, should be listed on the specification page; it should be clear who the representatives are
There should be an official process for deprecating or removing a technology; old technologies currently die a slow unused death, dragging the platform down, and leaving complexity in its wake as vendors are required to pass the TCKs; let's not hide behind the term "pruning"
All specification communication must be considered public, and should be archived, unless initiated privately by a member of the community

For accessibility:

Specification documents should be made available in HTML format for easy web access; PDFs should merely be one viewing option, not the only one
Specifications should provide end-user, user-case driven documentation for a technology (for instance like the first half of the Weld reference guide and the Java EE tutorial)
Decent and familiar social business software should be used for jcp.org to make it truly a community (jcp.org is extremely difficult to use and poorly organized)
jcp.org should host all the specification artifacts (specification document, API, reference implementation and TCK) (there is currently too much burden on developer to find them)
Specification artifacts should require no more than two clicks to begin said download, with no login required

Nice to have:

Periodic EC meetings should be open to the public
Platform releases (i.e., Java EE) should occur at regular, scheduled intervals, every 6 months or so, with clear paths for ratification and deprecation of JSRs.
The JCP should be an independent organization, similar in structure to the Eclipse foundation; it should be run and funded by donations/investments rather than petty membership fees
JSRs must be allowed to compete with each other, or standards evolution merely excludes and fragments participation within the Java community (for instance, one view technology is not sufficient)

Support and endorsement

The evidence of a general call for JCP reform is widespread.

Earlier this year, Mark Little, Red Hat's representative on the EC, called for a more open process, with everyone acting as peers. [4] He reinforced those statements in his follow-up to questions posed to the EC candidates. [2] IBM states on their standards page that they will "begin or end participation in standards bodies based on the quality and openness of their processes, membership rules, and intellectual property policies." [5] Bob Sutor has said that IBM expects to see "long needed reforms in the JCP [...] to make it more democratic, transparent, and open." [6] In an open letter from the CTO of SAP, Vishal Sikka, he calls for more openness in the JCP, saying "To ensure the continued role of Java in driving economic growth, we believe it is essential to transition the stewardship of the language and platform into an authentically open body that is not dominated by an individual corporation." [7] Darryl K. Taft published an editorial in eWeek outlining 15 guidelines for making Java better, one of which included setting the JCP free. [8] Doug Lea made a firm statement a few weeks ago that the JCP is no longer a credible standards organization [9]. And we cannot forget the long-standing open letter from the Apache Software Foundation to Sun asking to have the IP rights restrictions on the Java SE TCK removed. "[F]ailure to comply with your contractual obligations poses serious risk to the credibility of the JCP as an open standards organization, and the reputation of Java itself as an open technology." [10]

There are numerous other public statements on the web of calls for JCP reform.

Summary

I'm calling for reform of the JCP. I want the JCP to be accountable to its namesake, a "community process." The fact that the JCP claims to be open but does not uphold this promise tarnishes it and causes people to lose trust. It's a tragedy that the technology is way ahead of the process.

But hope is not lost. A few fundamental changes would drastically improve the effectiveness and credibility of the JCP. As Mark Little has said, "we would like to see the JCP continue to evolve and address those issues which we all know tarnish it."

I hope that the new EC is brave enough to rise to this challenge.

Signed,

Dan Allen
Lincoln Baxter, III

This call to action represents my personal viewpoints. I am not speaking on behalf of my current employer, Red Hat.

Refer to the corresponding entry on PetitionOnline to find a count of the signatures.

References

Posted at 02:32 PM in Java | Permalink | Comments Off

Curious how JSF loads without requiring a listener in web.xml?

October 07, 2010

I always wondered how Mojarra (the JSF Reference Implementation) managed to initialize without requiring a Servlet lifecycle listener entry (using the <listener> element) in web.xml. I figured it was either initializing on the first request or otherwise relying on some container integration. People would have likely complained already if the first approach was used, and the second doesn't make sense because Mojarra boots even in a Servlet container.

I finally discovered the secret while trying to get JSFUnit to work in Jetty from an Arquillian test. Mojarra wasn't loading. I switched to MyFaces and it also failed to start. But this time, I got an interesting error message along with it:

java.lang.IllegalStateException: No Factories configured for this Application. This happens if the faces-initialization does not work at all - make sure that you properly include all configuration settings necessary for a basic faces application and that all the necessary libs are included. Also check the logging output of your web application and your container for any exceptions!

If you did that and find nothing, the mistake might be due to the fact that you use some special web-containers which do not support registering context-listeners via TLD files and a context listener is not setup in your web.xml.

Aha! That's the ticket. The JSF implementations are using a TLD file in the JSF implementation to register the listener so that it doesn't need to be setup in web.xml!

That prompted me to take a look at the JavaDoc for MyFaces' StartupServletContextListener. There, the full strategy is laid out.

This context listener is registered by the JSP TLD file for the standard JSF "f" components. Normally, servlet containers will automatically load and process .tld files at startup time, and therefore register and run this class automatically.

Some very old servlet containers do not do this correctly, so in those cases this listener may be registered manually in web.xml. Registering it twice (ie in both .tld and web.xml) will result in a harmless warning message being generated. Very old versions of MyFaces Core do not register the listener in the .tld file, so those also need a manual entry in web.xml. However all versions since at least 1.1.2 have this entry in the tld.

That prompted me dig into the documentation for the listener element in TLD files. I learned that this capability was first introduced in JSP 2.0, part of Java EE 5. The Java EE 5 tutorial explains the function of the listener element as follows:

A tag library can specify some classes that are event listeners. The listeners are listed in the TLD as listener elements, and the web container will instantiate the listener classes and register them in a way analogous to that of listeners defined at the WAR level. Unlike WAR-level listeners, the order in which the tag library listeners are registered is undefined. The only subelement of the listener element is the listener-class element, which must contain the fully qualified name of the listener class.

The reason JSF wasn't loading in my Arquillian JSFUnit test was because I inadvertently left out the TLD processor (TaglibConfiguration) from the Jetty context in the Arquillian container adapter. I guess I now have motivation to add it back in ;)

So now you know.

Posted at 11:56 AM in JavaServer Faces | Permalink | Comments (2)

Don't overlook this framework

June 10, 2010

During my long flight to Frankfurt last month, I responded to an interview by Jan Groth about Seam for the German Java Magazin. In the interview, I reflect on the value of Open Source, how I got involved in Seam and where we are headed with Weld and Seam 3. I ended up writing so much (surprise, surprise) it had to be split into two parts. I justify my thoroughness in my first response:

I'm going to be a little long-winded [...], but I think it's important to communicate what led me to Seam because it says a lot about the software itself.

The full, 2-part interview is available online at the JAXenter Magazine website:

In part 1, I share the thoughts I had after reading the Seam reference documentation the first time:

It's like the Seam developers were reading my mind. [...] I felt like a kid in a candy store. I started banging out applications in no time and I was happy with how they looked.

I go on to explain that it wasn't just enough for me to know about it. I wanted other to benefit too.

I didn't want others to overlook this framework given how much it helped me. While the manual made sense, I knew it wasn't enough. [...] I decided to yell from the mountaintops by writing a series about it for IBM developerWorks.
The overwhelming feedback from that series made it pretty clear, someone needed to write a book about it (a higher mountaintop) that was going to explain every last detail. I took on that challenge (and believe me, it was quite a challenge.) [...]
I quite literally immersed myself in Hibernate, JPA, EJB 3, JTA, JSF and Java EE 5 in general. I came to appreciate the value of the platform, the remaining limitations and what Seam had to do to fill in the gaps.

I squeeze in a short review of the Art of Community at the end of the first part because it really sums up my vision of this project:

The Art of Community is a truly inspiring book and it reminded me why I love doing what I do...it's really about the people and the ideas. We are not just writing software for the community and publishing it as Open Source. It's the community's software, solutions to problems that come from the real world. We want to support and foster that engine and the Seam Community Liaison is the spark plug of the engine and ensures it's properly greased.

Part 2 dives more into the technical details and where we are headed.

CDI and Seam 3 are the Future of Both the Seam Community and Red Hat.

I explain our standards strategy as a defender of choice:

Red Hat is strong when the Java EE platform is strong. Our strategy does not depend on the platform remaining weak to justify the existence of our projects. It's quite the opposite. If we make one of our own projects obsolete, or some part of it, that's progress.

To quote Jay Balunas, it's cyclic:

Find a void. Fill the void. Standardize the fill.

I liken Seam modules to JSF UI component libraries and explain how we will ensure portability:

Seam 3 is primarily built on the CDI portable extension SPI, insulated from handling low-level concerns that run a high risk of breaking portability.
One of the principal requirements of Seam 3 modules is portability.
The Arquillian in-container test framework allows modules to be continuously tested against an array of application servers.

But with the improvements to Java EE, the question comes up whether Seam is still needed:

Is Java EE 6 a solid platform? Yes. Will you still need extensions? Yes. And CDI was designed specifically to be able to root and foster such an ecosystem. You can even write your own extensions, which really wasn't possible with Seam 2. Now we just need a plug-in site ;)

I'm very excited about all the innovation that is taking place in the JBoss Community right now and I encourage you to become a part of it. You never know where it will lead, but I can guarantee you it will open doors for you.

This post is syndicated from my JBoss Community blog.

Posted at 12:19 PM in Java, Seam, Seam News, Seam in Action | Permalink | Comments (3)

A concise and eloquent look at Seam

March 30, 2010

Despite all that I have written, explained and presented about Seam, I often find myself struggling to sum it up in a few short breaths. Fortunately, Matt Campbell does an superb job of defining the essence of what Seam provides eloquently and concisely in his blog series An Honest Look at Seam. (And I'm not just saying that because he credits Seam in Action as being his guide in his exploration of Seam).

In part 1, Matt explains how the attention to scoping of components is what sets Seam apart from Spring and makes it more suited for the web environment. In my talks on Java EE 6, I often say that JSR-299 (CDI) considers the scope of a bean (where it's stored) to be just as important as the component instance itself. Speaking of Java EE 6, Matt does some comparisons of his own between Seam and CDI.

Having established the importance of context, Matt opens part 2 introducing the conversation scope. He quickly delves into the symbiotic relationship between this scope, the persistence context and the multi-request use case (which is just about any use case on the web). He raises the ever important issue of manual flush mode in Hibernate and how it enables use of an optimistic transaction.

Matt takes a break from the theory in part 3 to address the developer's first experience with Seam. He calms the anxiety a typical newcomer might have the first time the developer observes seam-gen churn out application. While some may appreciate the huge boast that a fully-functional application provides, the shear number of artifacts is daunting for those expecting "Hello World". But as Matt clarifies,

There is a lot to Seam, but not becuase Seam itself is vastly huge and complex, but because Seam integrates so many things together.

So take your time and explore it all. Use what parts you need and skip the parts you don't.

In the future, rather than struggling to find the words to describe Seam on a trip in an elevator, I'm just going to hand the interested listener a card with the URL to these blogs on it ;)

It's important to zero in on what Seam 2 provides, especially as we look ahead to Java EE 6 and the development of the Seam 3 portable extension library. So regardless of where you are in your adoption of Seam 2 or Java EE 6, take a moment to read through these entries.

Posted at 01:05 AM in Seam, Seam News, Seam in Action | Permalink | No Opinions?

Why you didn't know the Unified EL is being updated

August 02, 2009

Information about the proposed Unified EL update slated for Java EE 6 is hard to come by, so I decided to put together a blog entry with some useful links.

If you haven't heard yet, which is understandable given the lack of publicized information, the Unified EL is getting an update for Java EE 6. The update consists of functionality we have all wanted for a long time. Most notably, literal method names in value expressions for more flexible data retrieval and method arguments for both value and method expressions. To see examples of these feature enhancements, take a look at this blog entry by Kim-Man Chung. (If you are using Seam or Spring Web Flow, you are already enjoying these enhancements courtesy of the JBoss EL).

But you probably don't just want to take my word for it. You want to know where these enhancements are officially documented. That's the point of this entry :)

Let's start by looking at the big picture. The Unified EL is defined in Part II of the JSR 245: JavaServer Pages 2.1 specification, lead by Kim-Man Chung. The maintainence release 2 of JSR 245 is the one on the ballot for Java EE 6.

I'll pause in anticipation of your pressing question. No, there is no dedicated specification for the Unified EL. (I'm lobbying for one, though). The Unified EL evolved out of JSP (where it was just the EL) and was later adopted by JSF. It's just as much a part of JSF as it is a part of JSP, which is why the situation is so awkward right now.

To find the proposed changes for the Unified EL, you have to look at the JSR 245 MR2 Change Log. Specifically, focus your attention on the Expression Language page. Believe it not, that's as official as it gets. Trust me, the absence of process disturbs me too.

Great, so what about the implementation? Can you try this stuff out? I had some difficulty finding that information too, but alas, I have more links for you.

The reference implementation of the Unified EL is hosted at java.net. The project is named uel, short for Unified EL. There are several tags corresponding to beta releases in the Subversion repository and the artifacts (JARs) for most of the beta releases have been published to the java.net Maven repository (EL api, EL impl). However, I can't find any announcements about these releases.

The version of the Unified EL you are looking for is 2.1.2. "How did the version jump from 1.1 to 2.1.2?" you may ask. I happen to know the answer to this question because I was in the EG meeting at JavaOne in which Kim-Man Chung gave a status update of the JSR 245 MR2 spec. He said that the version was bumped to align it with the JSP version, which will also be 2.1.2. Given that the Unified EL should be it's own spec, this makes absolutely no sense, but at least you know the reasoning behind it (and don't think you missed a haf-dozen versions in between). I'm also not happy at all about the closed-door decision, but I digress.

At some point, the Unified EL update will show up in GlassFish V3. As far as I can tell, it is not bundled today (but could be by the time you read this). How can you tell if it's there or not? The EL API can be found in the glassfish/modules/javax.servlet.jsp.jar file and the implementation is glassfish/modules/web/jsf-impl.jar. Extract the JARs and look at the META-INF/MANIFEST.MF or the pom.xml file to determine which version it is. You could also look for the presence of the javax.el.ValueReference, which is a new class in the API.

In case you were wondering, JBoss EL 2.0 is not (yet) and implementation of the Unified EL 2.1.2 API. Stay tuned.

So there you have it, information about the Unified EL update. I'm sorry this information is so hard to piece together. I think this would all be a lot simpler if EL was its own spec and/or there was decent information published about JSP. Oh, if the spec were actually open. The thing is, I don't give a care about JSP and frankly I want to divorce that spec in every way.

UPDATE: I put together a formal list of proposed enhancements requested by the Seam community on seamframework.org .

UPDATE: Ryan Lubke also blogged about the Unified EL update for Java EE 6. He included tips on how to update GlassFish with the latest EL build.

UPDATE: The EL spec document has been updated, making the changelog I cited above official. Grab the EL spec document from the "for evaluation" link on the JSR-245 maintenance release download page.

Posted at 01:46 AM in Java | Permalink | Comments (5)

A game-changing Maven 2 plugin you absolutely must use

May 04, 2009

Ever since I first started using Maven 2, I envisioned having a console in which I could execute life-cycle goals without having to incur Maven's startup cost between every run. It just seemed to me such a waste for Maven to build up the project object model (POM) from the pom.xml only to run a single sequence of goals and immediately shutdown. It also gives the impression that Maven is slow. In fact, it's extremely slow when it's used in this way, especially multi-module projects. But it doesn't have to be if you take advantage of...

The maven-cli-plugin

Today my vision has come true thanks to Mr. Don (and the ease of collaboration made possible by git). Having a similar vision to mine, he wrote the maven-cli-plugin, hosted at github.com. This plugin uses the jline library to create an execution console for Maven 2 (i.e., command shell), shown here:

maven2>

At the prompt you can issue Maven 2 life-cycle phases or plugin goals. The console even supports tab completion of commands! In this entry, I'll explain how you setup and use this console to put Maven into hyperdrive.

Technically, the plugin has two consoles. One is for executing Maven 2 life-cycle phases, including all prerequisite phases, and the other is used to only run plugin goals (the life cycle is not executed). Those are the same two ways you use Maven 2 from your normal shell. In this entry, I'll be focusing on the execute-phase console.

A fork in the road

I was thrilled when I first discovered the plugin, but after giving it a shot I was disappointed to discover that it wasn't honoring profiles, which are a critical piece of the build (see issue 2). I didn't give up hope though. Since Mr. Don had done most of the legwork in creating the plugin, I figured it wouldn't be that difficult for me to figure out why the profiles weren't working. Sure enough, in under an hour I discovered the source of the problem and was able to apply a fix. That left me with the dilemma of how to distribute my changes. I wanted to be able to use the plugin in the Seam 3 examples, so I couldn't just maintain a hacked version on my computer. Github.com (and git) saved the day.

Following the process for creating a fork on github.com (for which they practically spoon feed you the instructions), I forked the code and committed my changes to a publicly accessible repository. You can access both the master tree and my forked tree. You'll need the version from my tree to use all the features I cover in this entry. Hopefully Mr. Don will merge my changes into the master tree soon, but the fact that you can get my code today is a true testament to the influence git can have on open source collaboration.

Now let's "git" on with the presentation.

Getting started

To get started, add a plugin repository where the maven-cli-plugin is hosted as a top level element in your pom.xml. I recommend using the JBoss maven repository because it hosts my forked version.

<pluginRepositories>
    <pluginRepository>
        <id>repository.jboss.org</id>
        <name>JBoss Repository</name>
        <url>http://repository.jboss.org/maven2</url>
    </pluginRepository>
</pluginRepositories>

Alternatively, you can publish the plugin to your local or company repository. Grab the source from github.com or the binaries from the JBoss Maven repository. Remember, you need my forked version until my features get merged in. Follow the project at github.com to find out when that happens.

Next, define the maven-cli-plugin inside the build > plugins element in your POM. This just allows you to use the plugin prefix from the commandline, which is cli. You're also going to use this section to add some configuration options later.

<plugin>
   <groupId>org.twdata.maven</groupId>
   <artifactId>maven-cli-plugin</artifactId>
</plugin>

With the setup out of the way, I'm going to demonstrate three reasons why this plugin is game-changing. By the end, I guarantee you'll be jumping out of your chair.

#1 - Speed

Let's face it, Maven is dog-slow. That's because it has to parse that heap of XML the Maven developers call a POM. Then it has to figure out what it's supposed to execute. Then it pings the internet for updates. Then it enforces constraints. Then it runs through all the precursor phases (likely including tests). And finally it arrives at the phase you really want it to execute.

Of course, some of those steps can be trimmed using various flags, switches, and properties. But that means having to type, and remember, a ridiculously long command that is just something no human should be expected to do. More on that later. Let's deal with this startup cost once and for all.

We'll begin by firing up the maven-cli-plugin phase executor console. You run it just like you would any other Maven plugin:

mvn cli:execute-phase

After Maven goes through it's normal loading process, you are presented with a command prompt:

maven2>

From here you can type any of Maven's life-cycle phases, such as package, or a plugin goal (more on plugins later). Give it a try:

maven2> package

The first time the life cycle executes, you'll see a noticeable improvement in speed. By the second execution, it's blazing fast! You can just feel years being added back to your life. Power up!

Now it's time to extend the build with...

#2 - Profiles

One of the most powerful features of Maven is profiles. In fact, I think Maven is pretty useless without them. That's because in Maven, you really only have one "command" you can execute, the Maven 2 life cycle. There must be a way, then, to instruct that execution pass to perform different steps along the way. That's what profiles are for. With a profile, you can hook additional plugins to a phase as a way to weave that extra behavior into the build.

But we have a dilemma. Profiles are typically activated from the commandline either explicitly using the -Pprofile flag or through an activation, typically by assigning a property such as -Dproperty=value. How can we set the profile once we are in the command console? This is where my contribution to the maven-cli-plugin comes in.

The commands typed in the console are processed by the jline ConsoleReader from the maven-cli-plugin, not by Maven. That means we can allow any command we want, including flags like -P and -D. Fortunately, Maven was designed in such a way that an execution is isolated internally from parsing the POM. So it's possible to execute a life-cycle phase with a different set of profiles and properties, or even put Maven into offline mode for a single execution, without having to start the console again.

I hacked up the maven-cli-plugin to support the following flags:

-P activates the profile specified immediately after the flag (no spaces); this flag can be used multiple times
-D assigns a property specified immediate after the flag (no spaces) in the form name=value; this flag can be used multiple times
-o puts Maven in offline mode for a single execution; if not specified, will inherit the setting used to start the console
-N instructs Maven not to recurse into projects in the reactor
-S skip tests, an alias for -Dmaven.test.skip=true

Here's an example of a command you can issue:

maven2> clean package -Prun-integration-tests -o

That would activate the run-integration-tests profile, run the clean plugin and the life cycle up to the package phase, all while executing Maven in offline mode (to avoid checks for missing pom files, snapshots, and plugin updates).

In addition, the maven-cli-plugin already supported specifying individual projects by artifactId. This allows you to execute a phase on a sub-project without having to descend into that project or use the -f flag.

Let's say you are working with an standard EAR project and you want to build the WAR. To package just the WAR, you would either have to change into the war directory and execute Maven or use the -f flag as follows:

mvn -f war/pom.xml package

With the maven-cli-plugin, you can accomplish the same thing using this command (note that "seam-booking-war" is the artifactId of the module):

maven2> seam-booking-war package

Ah, the simplicity! And now, for the grand finale!

#3 - Aliases

Aliases are the Holy Grail of Maven 2. When I switch people from Ant to Maven, the first thing they get annoyed about is the ridiculous commands they are required to type. To put it simply, if you want to run clean and package, there is no way to specify that with a single command. You have to type:

mvn clean package

Things get worse with plugins. All plugin goals must be namespaced. That's because Maven 2 technically supports any command in the world, as long as there is a plugin to execute it. To run Jetty on a WAR project, for instance, you have to type:

mvn run:jetty

If you want to run clean, package, and then start jetty, you have to type:

mvn clean package run:jetty

Let's say that you also need to expand the WAR in-place and you want to run offline. Then the command becomes:

mvn -o clean package war:inplace run:jetty

I think you can see where this is going. When I first setup the booking examples for Seam 3, the record for the longest commandline in the readme went to this command, which undeploys, packages, and redeploys an EAR to JBoss AS:

mvn -o -f ear/pom.xml jboss:undeploy && \
  mvn -o package && \
  mvn -o -f ear/pom.xml jboss:deploy

Uuuuugly! That's why the aliases feature of the maven-cli-plugin is absolutely game-changing (perhaps even life changing). In fact, combined with the other two features I have covered, they make Maven 2 better and faster than Ant, hands down. I'll go so far as to say that there has never been a faster, more convenient way to execute builds.

So what is an alias? Quite simply, a string of commands you would otherwise have to type in the console, aliased to a single word. You define them in the plugin configuration. Here's an alias I put together to deploy an exploded EAR archive to JBoss AS in the Seam booking example:

<plugin>
   <groupId>org.twdata.maven</groupId>
   <artifactId>maven-cli-plugin</artifactId>
   <configuration>
       <userAliases>
           <explode>package -o -Pexplode</explode>
       </userAliases>
   </configuration>
</plugin>

After starting up the console, the user only has to type one word:

maven2> explode

It's no longer even necessary to prefix commands with mvn (or ant in the old days). Just one command. One word.

The execute-phase console also supports direct execution of plugin goals. That means you can include them in the alias command. The only limitation is that when you include one in an alias, you have to specify the fully qualified name of the plugin (groupId:artifactId) before the goal rather than just it's prefix (e.g., org.codehaus.mojo:jboss-maven-plugin rather than jboss). This next alias invokes the harddeploy goal of the jboss-maven-plugin after packing the project.

<userAliases>
   <deploy>seam-booking-ear package -o org.codehaus.mojo:jboss-maven-plugin:harddeploy</deploy>
</userAliases>

You can even mix aliases with regular commands. Perhaps you want to clean first:

maven2> clean deploy

I find it nice to alias commonly used built-in Maven goals too, such as the one that lists the active profiles:

<userAliases>
   <profiles>org.apache.maven.plugins:maven-help-plugin:active-profiles -o</profiles>
</userAliases>

The maven-cli-plugin also provides a handful of built-in aliases.

If this plugin isn't game changing, I don't know what is. All I can say as hell yeah!

See the Seam 3 booking example to see this plugin in action and read additional commentary.

Update: There is also a cli client for IntelliJ IDEA that can invoke builds remotely. Of course, the plugin supports this from the commandline too.

Update: I should also mention that this is a great way to debug Maven since you get an opportunity to attach a debugger before executing a command. First, set the MAVEN_OPTS environment variable:

MAVEN_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"

Then run cli:execute-phase, attach a debugger (port 8787 in this case) and execute a command.

Posted at 02:18 PM in Java, Programming, Usability | Permalink | Comments (38)

30 certainly was something

April 02, 2009

What a year! There's no question that year 30 was the most eventful and life changing year of my life to this point. I truly feel like I have grabbed life by the horns and got it steered in the direction I really want it to head.

By far, the biggest accomplishment of the year was getting Seam in Action published. But writing my first book was the catalyst for many of the other events that took place. From start to finish of year 30, I presented for the first time at a software conference, which led to a half a dozen speaking engagements, more travel than I've ever done in one year, including my first ever trip to Europe, and the chance to meet a lot of prominent industry leaders. Writing the book also helped me be more prolific. I passed my 100th blog entry and posted 1000 tweets on Twitter, which I began using just before JavaOne. The gutsiest and most permanent decision I made all year was deciding to get LASIK, and in the words of Tiger Woods, "the results were fantastic". What follows is an account of this passage into my 30 somethings, most of which can be found in my tweet archive.

[ Continue Reading » ]

Posted at 10:27 AM in Personal, Seam in Action | Permalink | Comments (2)

Chariot Tech Cast: Seam Interview Part 2

March 17, 2009

I didn't expect Ken Rimple for Chariot Solutions to be so quick in getting up part 2 of my Seam interview, which I introduced in a previous entry, so you get two posts in one day. If you had iTunes or your RSS feed reader working, you'd already be in the know.

In the second part of this two-part interview, we focus on the future of Java EE 6, including JSR-299, formerly known as Web Beans, and how Seam will change as the Java EE specification evolves. We also discuss varying front-end technologies such as Flex and AJAX, and a bit about workflow.

Resources we mentioned in the talk include:

Granite DS - A Flex remoting framework that includes support for Seam as well as other platforms such as Guice, Spring and POJOs
Flamingo - Another Flex (and JavaFX) remoting framework that exposes Seam and Spring services using a variety of protocols including AMF and Hessian.
JSR-299. I emphasize that it is well worth your while to read it and something I think every Java EE developer needs to be aware of at some point in the near future.
Web Beans - The namesake of the reference implementation (RI), which is being developed by Red Hat and its community as an open source project.

Thanks again to Ken for the hard work that I know went into publishing this interview.

Posted at 11:22 AM in Java, Seam, Seam News | Permalink | Comments (1)

Maturing Your Application's Security with Seam Security

March 17, 2009

I'll be speaking at two conferences back-to-back in March, which is about as much madness as I can handle. First I'll be traveling to Vegas to speak at TheServerSide Symposium at Caesar's Palace on my birthday (March 20th). It's interesting to note that just over 6 months ago I was near Caesar's real palace, or what's left of it. Then I'll be coming back home and speaking at Emerging Technologies for the Enterprise in nearby Philadelphia the following Friday. In both cities, I'll be speaking about Seam Security.

Always wanting to put on a good show (I mean, it is Vegas after all) I put together a fresh application that leverages Seam's new identity and permissions management API. It's a design comp manager that allows a designer to share designs with clients. The application showcases how Seam Security blends ACLs and rules in a truly unique and revolutionary way to provide a powerful and expressive security model.

While creating an application like that may sound difficult to achieve, my talk demonstrates that it's shockingly simple setup and start using. Like poker, though, it does take time to perfect. Authoring complex rules are not always easy. I spent nearly two days getting a feel for the API. But then again, I've got a killer app to show for my labor.

The full abstract of the talk is below.

Security is the cornerstone of your application's integrity and, consequently, you need to weave it throughout each layer, often in diverse ways. Seam Security allows you to evolve the security model of your application over time, keeping pace with the development cycle. You can start with a very simple configuration that applies an exclusive security blanket over the application to keep out guests and establish a basic identity for the user. You can then mature the security infrastructure gradually by adopting Seam's declarative approach to authentication or defining fine-grained authorization rules that enforce contextual restrictions at the level of database records, database fields, object fields and UI fragments.

Seam's security module, a central aspect of the Seam framework, offers a significantly simpler alternative to JAAS - the monolithic and cumbersome security model in Java EE. The talk begins with some definitions to sort out what we mean when we say "security". The talk then switches to a tutorial style, showing you first how to get your foot in the door by setting up a JSF form-based authentication routine in Seam using either a custom authentication method or a declarative approach where the authentication is handled by the framework. You are then presented with the numerous authorization styles that Seam supports ranging from binary, role-based, rule-based (Drools), and ACLs. Examples are presented to help you differentiate the four styles of authorization and when it is appropriate to use each one. In the process, you learn to appreciate that Seam's authorization is able to take the context (the target) of the restriction into account, a feature than many security frameworks overlook. Finally, the talk zooms out to show how to bring authentication under one roof using Seam's Open ID module.

See you at the tables...er, I mean conferences!

Posted at 05:26 AM in Java, Seam | Permalink | Comments (4)

Featured Article

Speed up your JSF-based Seam Application by Two Orders of Magnitude | Mar 2009: In this two-part article, you'll be presented with a series of four lessons for eliminating performance problems in a JSF-based Seam application one-by-one until you have observed a remarkable, two orders of magnitude improvement in performance.

Recent Blog Entries

Latest Comments

eMexo Technologies said:
June 08, 2019
Good Post! Thank you so much for sharing this pretty post, it was […]
Sunil said:
September 16, 2013
Do you know whether Maven could be installed in the server with n […]
Dan Allen said:
August 23, 2013
Thomas, I strongly encourage you to post these ideas either the […]
Thomas Zimmermann said:
August 23, 2013
So the problem is that the JSESSIONID cookie is shared between br […]
Mike Miller said:
March 04, 2013
Hi, We are testing a migration of our application from H2 to H3 […]

News Feeds

(blog entries)
(blog entries)

mojavelinux.com: Open Source Advocacy

January 02, 2012

November 01, 2010

Goals and current problems

The call for reform

Must haves:

For accessibility:

Nice to have:

Support and endorsement

Summary

References

October 07, 2010

June 10, 2010

March 30, 2010

August 02, 2009

May 04, 2009

The maven-cli-plugin

A fork in the road

Getting started

#1 - Speed

#2 - Profiles

#3 - Aliases

April 02, 2009

March 17, 2009

March 17, 2009

Featured Article

Recent Blog Entries

Latest Comments

Blog Categories

News Feeds

You Might Also Enjoy

Blogroll

Site Credits