What’s new in Maestro 3.2?

Glassfish Support

You can now deploy your war and ear files to Glassfish from a composition task in Maestro. It’s as simple as adding your Glassfish server as a standalone deployment server in Maestro, adding a deployment composition task that points to your Glassfish server in your composition then executing your composition.. and voila! Your J2EE or web application is now deployed in Glassfish. To get us started, here are some screenshots for each of these steps:

Step 1: Add a standalone Glassfish Server

Step 2: Configure Glassfish Deploy composition task

Step 3: Execute deployment to Glassfish Server

Glassfish support is also available in target environment deployment. Target environments are basically groups of deployment servers where you can deploy to in one go. If, for example, you want to test your application in different application servers.. you can create a target environment for testing purposes that has a Tomcat server and a Glassfish server. You can make use of the composition task specifically for deployment to a specific target environment, as opposed to adding and configuring one composition task each for deploying to Tomcat and deploying to Glassfish.

Target Environment

Deploy to Target Environment composition task configuration

Composition Task/Phase Binding archetype

The composition lifecycle has different phases defined, and for each phase, there are tasks or bindings attached to it. Maestro comes with default tasks/bindings, but you can create your own and plug it in to whichever phase you’d like to attach it to. This is made easier by the composition task archetype. You can use it to create your custom composition task/binding module. A class that implements the Phase Binding API is created by default including a test class for it, as well as the Spring context file where the task/binding bean is defined and configured.

Composition Task/Binding for Sending Mail Notifications

This task/binding can be added to any of the phases in your composition to send a notification to all developers of the Build project regarding the result of the build. It includes the following information in the email:

• Project Name
• Link to the Build project
• Name of the Composition that was executed
• Phase where the mail notification binding was defined in the composition
• Date and time when the notification was sent
• Message

User-Role Assignment Management

Another handy feature present in the Maestro 3.2 series is the User-Role Assignment page. You can now assign specific roles to a user from the UI instead of doing it directly to the database. There are four types of roles that can be assigned to a user:

• Admin
• Developer
• Tester
• Guest

User Management

The Developer and Tester roles are both dynamic roles, meaning for each Build and Test project added in Maestro, a corresponding Developer role and Tester role are created respectively. If the user is assigned a Developer role for Build Project A, the user would only be able to see/access Build Project A. The same behavior goes for a dynamic Tester role. If the user is assigned a Tester role for Test Project B, the user would only be able to see/access Test Project B.

Preliminary GIT Support

Preliminary GIT support has also been implemented in 3.2. Projects in GIT SCM can now be added and built from Maestro. Expect more enhancements for this feature in the succeeding releases!

Upgrade to Sonar 2.5

Maestro 3.2 now bundles and uses Sonar version 2.5. With this upgrade, you can utilize the new features and enhancements available in the release. You may visit www.sonarsource.org/downloads/#2.5 for the complete list of issues included in Sonar 2.5.

Other Enhancements and Bug Fixes

In addition to the new features listed above, there have also been a number of UI improvements put in place in 3.2. Some of these are:

• In the Admin page, there is now an indication whether a restart is required when you edit specific configuration fields.
• Username and password for standalone deployment servers can now be configured from the Add/Edit Standalone Server form.
• Improvement in error handling. All exceptions are either logged in the rolling log file or propagated to the user via the UI, depending on the type of error encountered.

There have also been a number of bug fixes in 3.2, some of the more significant ones are:

• Profiles are not activated during release, even if explicitly specified in the release prepare and perform goals.
• Timing in checking and updating of build result when running Selenium tests sometimes causes Test to have inconsistent results.
• Deleting a Build project does not delete the User-Role assignment entry associated to the project.
• In Test, conversion of Selenium scripts written in the script editor to java tests doesn’t allow assertions. Lines that doesn’t start with "selenium" are not transformed to getSelenium().

You might wonder what staging repositories and artifact promotion are. Let me explain that a bit..

One of the important concepts in developing software is releasing. Releasing means freezing your code, versioning it and then publishing it to an artifact repository which can be consumed publicly or internally. Now, usually when you release software, it undergoes testing first before it gets officially published (e.g. pushed to a repository where users of the software or project can get it). That’s where staging repositories come in. It is the place where a release is first pushed where developers, testers and QA engineers get the release for testing before it is pushed and made available to the project’s official download repository. 

Here’s how this feature currently works in Archiva..

When creating a new managed repository, you will be given an option to create a staging repository by ticking the Create stage repository checkbox as seen below.

The staging repository can be distinguished from the managed repository it is attached to by the -stage appended to it’s ID. So in the above example, since the ID of the managed repository is myproject.releases, the staging repository attached to it is myproject.releases-stage. While the former is accessible in the webdav URL http://mycompany.com/archiva/repository/myproject.releases/, the latter is accessible in http://mycompany.com/archiva/repository/myproject.releases-stage/.

So when you release your project, you can deploy it to the staging repository first where it can be obtained for testing (and in cases of open source projects, undergo voting in the community). 

Once testing (and voting) is finished, and the release has been approved, it can now be promoted to the official repo, which is the myproject.releases repository in our example above. This can be done in Archiva by clicking the Merge button in the repositories page as seen below. 

Archiva will then check for possible conflicts — artifacts in the staging repository with the same version already existing in the managed repository. If there are conflicting artifacts found, they will be listed where you can choose whether to merge everything (existing artifacts will be overwritten) or to skip the conflicting artifacts in the merge.

Once you selected an option, the contents of the staging repository will be merged to the managed repository.

This is still the initial implementation of the feature and there are still a number of enhancements to watch out for. One of these is the ability to select specific conflicting artifacts to merge as an additional option aside from just skipping everything or merging everything. The UI can also use some improvements. Access control on who can merge/promote artifacts can also needs to be improved. Right now only users with a System Administrator role can do this.

For example, if most of the development work happens during daytime, you can schedule your development builds to run every two or three hours (depending on how long your builds take) during the day when changes are being pushed in your source repository. You can simply configure it with "clean install" as you goals since the purpose of the development builds is to ensure that your build is not broken.

On the other hand, you can schedule your nightly builds to run at night (say every 10 in the evening). All the integration tests must be executed and builds must be deployed to your internal artifact
repository. This ensures that the development team and the QA team get all the changes from the previous day when they build the project and test the nightly builds the following day, respectively.

Make sure that your build notifications are configured so that the development team are immediately notified if the build breaks.

To learn more about these projects, visit:

maven.apache.org/

archiva.apache.org/

continuum.apache.org/

You can grab a copy of the book at www.packtpub.com/apache-maven-2-effective-implementations/book. Grab a copy now while it’s still on sale

(Thanks again to everyone who helped us out and supported us with this book!)

ApacheCon Europe is coming up!** I’m given the privilege of holding an hour long session at the conference to talk about Archiva. Here’s a short summary of what I will be covering in my presentation: www.eu.apachecon.com/c/aceu2009/sessions/169

 Wendy Smoak and Carlos Sanchez will also be speaking at the conference. Wendy will be doing a presentation on Apache Continuum www.eu.apachecon.com/c/aceu2009/sessions/170 while Carlos will be talking about Enterprise Build and Test www.eu.apachecon.com/c/aceu2009/sessions/171, and Eclipse IAM www.eu.apachecon.com/c/aceu2009/sessions/185

See you all in Amsterdam! 

**ApacheCon Europe 2009 is on March 23-27 at Movenpick Hotel, Amsterdam - www.eu.apachecon.com/c/aceu2009/ 

I’ve summarized this into the following steps:

1. You must have a jetty-jmx.xml file with the following configuration:

<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">
<Configure id="Server" class="org.mortbay.jetty.Server">
    <!– =========================================================== –>
    <!– Initialize an mbean server                                  –>
    <!– =========================================================== –>
    <!– Use the jdk 1.5 platformMBeanServer –>
    <Call id="MBeanServer" class="java.lang.management.ManagementFactory" name="getPlatformMBeanServer"/>
  
    <!– =========================================================== –>
    <!– Initialize the Jetty MBean container                        –>
    <!– =========================================================== –>
    <Get id="Container" name="container">
      <Call name="addEventListener">
        <Arg>
          <New class="org.mortbay.management.MBeanContainer">
            <Arg><Ref id="MBeanServer"/></Arg>
            <!– If using < jdk1.5 uncomment to start http adaptor –>
            <!– Set name="managementPort">8082</Set –>
            <Call name="start" />
          </New>
        </Arg>
      </Call>
    </Get>   
</Configure> 

2. In your wrapper.conf file, add the jetty-jmx.xml file in the Application Parameters section like the following:

wrapper.app.parameter.1=org.mortbay.start.Main
wrapper.app.parameter.2=[PATH_TO_JETTY_CONFIG]/jetty-jmx.xml
wrapper.app.parameter.3=[PATH_TO_JETTY_CONFIG]/jetty.xml

3. Add  also the following in the Java Additional Parameters section of the wrapper.conf:

wrapper.java.additional.7=-Dcom.sun.management.jmxremote.ssl=false
wrapper.java.additional.8=-Dcom.sun.management.jmxremote.authenticate=false
wrapper.java.additional.9=-Dcom.sun.management.jmxremote.port=9999

4. Start the Jetty bundle by invoking the startup script for the JSW.

5. To see if JMX was enabled, use jconsole to connect. In jconsole, create a new connection and in the Advanced tab, provide the following JMX url then click Connect:

service:jmx:rmi:///jndi/rmi://127.0.0.1:9999/jmxrmi

After step 4, you should be able to see the Memory, Threads, Classes and MBeans info of your application.

Specifics for the tools used above:

• appassembler-maven-plugin 1.0-beta-2
• java 1.5.0_11
• jetty 6.1.11
  
• jsw 3.2.3 

Release Notes - Continuum - Version 1.3.1

** Sub-task
    * [CONTINUUM-2023] - Document usage of parallel builds

** Bug
    * [CONTINUUM-1513] - Release does not work when maven 2 executable is not on PATH
    * [CONTINUUM-1978] - regression from 1.1 to 1.2.2: Add Maven 2.0+ Project using https POM Url where the source server has self signed certificate
    * [CONTINUUM-1981] - Error while using Windows domain in username when adding a M2 project
    * [CONTINUUM-1984] - Dead link to data-management-cli-1.2-app.jar in upgrade documentation
    * [CONTINUUM-1988] - Cannot build project if triggered from Project Information page
    * [CONTINUUM-1998] - Unable to delete a user
    * [CONTINUUM-1999] - Missing validation error message for duplicate project group
    * [CONTINUUM-2008] - Creating or Editing  "build definition" and "build definition template" generates javascript error
    * [CONTINUUM-2017] - Unable to add build definitions to a template
    * [CONTINUUM-2021] - NullPointerException when sending mail notification
    * [CONTINUUM-2030] - Show Users in Role paging not working
    * [CONTINUUM-2035] - Unable to release when Distributed Build is enabled
    * [CONTINUUM-2040] - NPE encountered when building a project migrated from an old database

** Improvement
    * [CONTINUUM-1829] - separate transient errors from build failures in notification and display
    * [CONTINUUM-1864] - Transient State
    * [CONTINUUM-1884] - Clicking ‘Done’ after a successful release perform sends you all the way out to the list of groups
    * [CONTINUUM-1962] - Migrate to Struts 2
    * [CONTINUUM-1969] - Externalize all strings and make continuum fully localizable.
    * [CONTINUUM-2010] - Add group cancel build
    * [CONTINUUM-2013] - Database migration tool for migration from 1.2.x to 1.3.x

** New Feature
    * [CONTINUUM-265] - Concurrent builds
    * [CONTINUUM-1666] - Distributed Builds

** Task
    * [CONTINUUM-1990] - Unable to publish website from 1.3.0 tag
    * [CONTINUUM-2024] - Upgrade httpclient to 4.0beta2

** Wish
    * [CONTINUUM-1635] - Manage configurable number of parallel build queues

BTW, the release can be obtained here: http://continuum.apache.org/download.html

Enjoy!

I was given a chance to do a fast feather talk about Archiva at the ApacheCon US 2008 on Wednesday Nov. 5, 3pm at the Sheraton Hotel in New Orleans. See you there!

"Rome is an open source library for generating, parsing and manipulating RSS and Atom feeds. It supports different RSS and Atom feed formats such as Atom 0.3, and Atom 1.0, RSS 0.90, RSS 0.91 Netscape, RSS 0.91 Userland, RSS 0.92, RSS 0.93, RSS 0.94, RSS 1.0 and RSS 2.0."

A couple months back, I got to use the Rome library to implement RSS in Archiva. What I liked about Rome is how it’s so easy to understand and use. To generate an RSS feed, you basically just need to be familiar with these three classes: SyndFeed, SyndEntry and SyndContent. These three are Java interfaces with the following concrete implementations: SyndFeedImpl, SyndEntryImpl and SyndContentImpl respectively. Here’s a short example on how you can generate a RSS 2.0 feed:

SyndFeed feed = new SyndFeedImpl(); // create the feed
Date publishDate = new Date( System.currentTimeMillis() );

feed.setTitle( "Techblog.ph RSS Feeds" );
feed.setDescription( "RSS feeds of blog entries from Techblog.ph" );
feed.setLanguage( "en-us" );
feed.setPublishedDate( publishDate );
feed.setFeedType( "rss_2.0" ); // set the type of your feed

List<SyndEntry> entries = new ArrayList<SyndEntry>();

SyndEntry entry = new SyndEntryImpl(); // create a feed entry
entry.setTitle( "Generating RSS Feeds with Rome" );
entry.setPublishedDate( publishDate );

SyndContent content = new SyndContentImpl(); // create the content of your entry
content.setType( "text/plain" );
content.setValue( "Want to have RSS feeds in your Java application? Try Rome….." );

entry.setDescription( content );
entries.add( entry );
feed.setEntries( entries ); // you can add multiple entries in your feed

For the published date, make sure that you update it whenever you have a new entry and publish the feed so that the reader knows there were changes/updates in your feed.

Now, to publish your feed.. you can write it into a file (example, write it to rss.xml) which the feed reader checks for updates or you can generate the feed by request (like how it is done in Archiva). If you are publishing your feeds by writing it on a file, you might need to read the file into a SyndFeed before adding new entries as shown below:

SyndFeedInput input = new SyndFeedInput();
SyndFeed feed = input.build( new XmlReader( outputFile ) );

To learn more about the Rome library, check out the Rome API.