Upgrade Fedora 12 to Fedora 13 howto

A few simple steps to upgrade:

# As root you would like to have a clean start to the
# upgrade, so get an update out of the way.
#
$ yum update rpm

$ yum -y update

$ yum clean all

# Should a new kernel install/update require it,
# reboot before continuing with the rest.
#
# Then install the preupgrade package.
#
$ yum install preupgrade

# For console upgrade, use:
#
$ preupgrade-cli "Fedora 13 (Goddard)"

# If you like gui's to upgrade, use this.
#
$ preupgrade

This is exactly the same process as I previously described with Fedora 11 to Fedora 12 upgrade.

=============== Update ===================
There was a hitch on my laptop, some friends have asked about how to install when your boot partition is smaller than the Fedora 13 required 250 MB. I have been upgrading since Fedora 10 so have like 200 MB boot partition. Just try this:

# run preupgrade as normal, when it complains about not enough space just 
# continue, it will install the stage2 installer after the first reboot.
# When it asks to reboot, do that. It should continue to finish the installation
# when it restarts.

This solution is also to be found on the Fedora Project Wiki.

Open Source Expert Panel - Geen open source kennis? Nee, bedankt!

I just submitted the following Dutch language article for the opinion section Open Source for the on-line Computable.nl.

Geen open source kennis? Nee, bedankt!

Ik gooi het maar direct op tafel. Als ik een ontwikkelaar zoek, dan is aantoonbare affiniteit met en kennis van open source een absolute must. Ik ben er heilig van overtuigd dat de kwaliteiten van dit type ontwikkelaars veel beter zijn dan van hun closed source tegenhangers. Dat is niet enkel een gevoel maar een simpele kwestie van het opsommen van de feiten.

Een opensourceontwikkelaar is iemand die meewerkt aan opensourceoplossingen en de ontwikkelingen volgt. Ik ervaar dat zij - in vergelijking tot hun closed source concullega’s - een grotere passie hebben voor wat zij doen. Dit zie je bijvoorbeeld terug in de hoeveelheid vrije tijd die ze spenderen aan opensourceprojecten. Ze werken in een gemeenschap van ontwikkelaars waarbij hun communicatie, contributies, codes en sociaal gedrag online worden gedocumenteerd. Al deze gegevens zijn over het algemeen te achterhalen via een simpele online zoekopdracht. Bovendien zijn opensourceontwikkelaars zeer flexibel in de omgang met problemen. Als er iets mis is met een opensourceproduct bestaat er altijd de mogelijkheid het verder uit te zoeken, tot aan de broncode aan toe. Het zal je niet verbazen dat het uitzoeken alleen al vaak leidt tot een oplossing. Die oplossing kan vervolgens weer worden teruggegeven aan het desbetreffende project. Die flexibiliteit is overigens ook terug te vinden in hun omgang met veranderingen. Opensourceontwikkelaars beschikken vaak over diverse mogelijkheden die hen kunnen helpen bij het oplossen van problemen, zoals een stuk tooling, product of framework. Deze nieuwe technologieën worden dan eigenhandig gemaakt en toegepast in hun werk.

Hieruit blijkt maar eens te meer hoe zij zelfsturend te werk gaan met betrekking tot educatie en het bijhouden van kennis. Een opensourceontwikkelaar leest graag, offert graag tijd op om dingen uit te zoeken en bezoekt conferenties en congressen om zijn kennis op te vijzelen en up-to-date te houden. Over het algemeen is het dan ook veel kosteneffectiever om dit type ontwikkelaars aan het werk te houden, hun kennis bij te spijkeren en ze tevreden te houden zodat zij voor je blijven werken dan het bij closedsourceontwikkelaars het geval is.

Closedsourceontwikkelaars leunen namelijk op hun certificaten. Dat is op zich niet zo verwonderlijk. Immers, hoe kan ik weten wat iemand zijn capaciteiten zijn en wat hij kan zonder zijn lijst met certificeringen in te zien? Het is namelijk niet mogelijk op een andere manier terug te vinden hoe zij coderen, hoe zij communiceren in een ontwikkelgemeenschap of hoe zij omgaan met veranderingen. Een persoonlijk interview is in dergelijke gevallen dan ook van groot belang. Een closedsourceontwikkelaar richt zich namelijk vaak op een enkele omgeving, met een beperkte verzameling tools waarmee zij kunnen werken. Veranderingen in deze verzameling worden niet als normaal ervaren waardoor zij van nature geen flexibele manier van werken en handelen hebben. Problemen in de tooling of producten worden regelmatig bij de leverancier neergelegd in plaats van dat ze het zelf uitzoeken. Kortom, er bestaat een compleet andere houding qua educatie en het bijhouden van kennis. Deze is namelijk vooral gericht op het bijhouden van certificering op de door hun gekozen tooling en producten. Dat betekent dat het vaak een duurdere aangelegenheid is om deze ontwikkelaars aan het werk te houden, op te leiden en ze de gewenste certificeringen te laten behalen.

Natuurlijk is het beeld dat hierboven wordt sterk gechargeerd. Maar ga het voor u zelf eens na: Met welk type ontwikkelaar wilt u samenwerken aan uw volgende project? Dan zult u zien dat ik er toch niet zover naast zit.

EMEA Partner Summit in Valencia, Spain - JBoss event to remeber for 2010

It all started on Sunday, 02 May 2010 with a group from the Netherlands flying out to Valencia, Spain for the EMEA Partner Summit. Weather was great, very warm and sunny but was soon to change into rain.

We checked in, attended our meeting to get things sorted out for the Kickoff at 1900 hours. The Summit was opened by Jim Whitehurst himself welcoming the 450+ partners and Red Hat personnel.

After the opening keynotes we migrated into the venue hall and mingled with our partners while enjoying the Spanish food and drinks.

The second day was my active day to present two presentations on JBoss SOA-P and BRMS. I was also able to attend a few sessions on JBoss ON CLI usage (tech session) and JBoss SOE (tech session). The rest of the day involved talking with various partners and developers about all things JBoss (BPM, BRMS and SOA-P mostly). My sessions went pretty well, even had a partner in the front recording everything on a hand held video recorder. He mentioned it would be on YouTube sometime soon.

In the evening the partners were put into a bus sorted by their region, so I was off with the Benelux partners to the beach for some traditional Spanish food, Paella!

The evening ended in a beach club with about 100 of the partners enjoying the company of all the Red Hatters!

The third day is a full agenda of sessions, round tables and speeches from partners and Red Hatters. There are both infrastructure and middleware in a abundance! The evening will be concluded with a party at an old convent here in Valencia.

Follow all the active news on my twitter account @ericschabell and sort on the tag #emeapartnersummit, there are more pictures and running commentary until the Summit concludes Wednesday afternoon.

The atmosphere has been really great and I am really enjoying the chance to interact with partners. This is a different engagement than with customers as we are both trying to accomplish the same things. Very open and easy hum of activity in the sessions and exhibition hall, I would be very happy to come back next year!

jBPM 5 RFC - nobody gets left behind

I have posted my thoughts and evaluation of the jBPM 5 RFC posted last week, see the jbpm-dev list (may take a bit to appear).

I think the theme should be 'Nobody gets left behind' when working towards the jBPM future.

======================================
UPDATE: (seems to be something wrong with mailinglists, not posted yet so adding here)

Posted 23 April 2010:
============
I have been watching the replies and seeing what the jBPM core
community developers would be saying before responding with my own
thoughts on this topic.

My background with jBPM is not well documented here in the forums or
mailing lists. I have been using jBPM in an enterprise environment
over the last three years or so as both a developer and lead
developer. It started on the jBPM v3.1.x community versions and later
migrated to the current supported jBPM v3.2.x. I also have had
personal meetings with Tom, Joram and Koen discussing jBPM 3 and jBPM
4, be that development questions, use cases from customers or just my
experiences deploying enterprise solutions into production
environments. One award winning case was published
(http://www.schabell.org/2009/11/2009-silver-winner-for-europe-financial.html)
on the implementations we did with jBPM v3.

Looking at the various sections presented by Kris in the design
overview https://community.jboss.org/wiki/jBPM5RequestforComments, I
will run through each section and give my thoughts:

Architecture:
=========
This picture is clear and concise, providing a pretty good idea of
what the overview is. I miss JBoss Rules / BRMS as a block in the
Connections side. I feel that Rules is just as important as JBoss ESB
and you need to provide this to push your own products. On a side
note, the roadmap needs to come ASAP to provide clarity where the
focus is. You will see below in my evaluation, there is a focus needed
on the core functionality to make something that can make it into a
product.

Core process engine:
===============
When I look at this component I see many of the existing jBPM 4 branch
as being a strong candidate to be leveraged along with whatever the
Drools project has completed. Would be great if they could/would
compliment each other. I am very happy to see the PVM being the
leading theoretical foundations for the BPM suite. Three items are of
some note:

1) process instance migration is mentioned as if it is about stateless
processes. I do not see how you can manage this at all. If you show me
a process you think you can migrate, I bet I can break it.

2) process instance migration could and should be a target for moving
from one version of jBPM to the next.

3) jPDLv3 -> BPMN2 process definition conversion tooling is a must and
I was pushing this before the split, with project space already setup:
http://anonsvn.jboss.org/repos/jbpm/projects/migration_tool (current
leads are more than happy to have someone to help on this conversion
tool, great place to get your feet wet in open source!)

Finally, this part of the project should have about all the attention
available to ensure a speedy delivery. This is what is needed to offer
customers a path into the future of BPM.

Human Tasks:
===========
Following a standard makes lots of sense. I do see this as a bit of an
external project when related to the console and form editor. First
order of business is having them available.

Process repository:
==============
I would assume that this component could also leverage the efforts of
ModeShape project maybe? Keep work to a minimum by conforming to what
they recognize as an artefact. Seems also to fall into the category of
nice to have but not yet essential to initial releases.

BPM Console:
==========
Looks like this can and should leverage the jBPM 4.x work, the GWT
console project, along with whatever Drools project can / has to
offer. This is nice to have stuff.

Eclipse-based process tooling:
======================
To leverage jBPM 4.x existing tooling and Drools project tooling. The
extra bits mentioned are again fine for later releases.

Web-based process tooling:
====================
Is Oryx / Signavio one team? I was under the impression that Drools
went one way and jBPM project another... who will win now and what are
the criteria to be judged?

Simulation:
========
Very advanced feature that is nice to have (would make Product sales
easy to visualize and demo's very slick) but nothing to focus on in
the initial releases I would think. This could be an apart
sub-project.

BAM / BI:
======
This is a very interesting one, how to provide without dictating what
a person is to get/use/have in the BAM/BI area. It should be about
facilitating and ease of customization. Also an apart sub-project and
not important for the initial releases.

Usability:
=======
Strange mix of stuff here; Domain-specific processes (what for? why?
let's get normal process engine out there first?), install scripts
(already there?), continuous integration (leverage existing setups?),
documentation (has always been outstanding, should not slip), OSGI
(what for?).

Integration:
========
Every item mentioned here in this section needs to have a block in the
architecture overview picture. Very good to leverage and use our own
projects. Make that the easiest path.

Final thoughts, I see many panic reactions on the lists/forums with
regards to jBPM 4. Looking at this overview Kris provides, I expect
much of the jBPM 4 will function as some sort of base line for further
development. DroolsFlow will play a role and if more projects are
leveraged then this overview of a BPM suite on functionality is
achievable. I think the first steps need to be to ensure that
customers are taken from jBPM3 to jBPM5. plan this from the beginning.
Rule #1: nobody gets left behind.

jBPM v3.2 custom exception framework example now available

In December of last year I posted on a project of mine called a custom exception framework. I have been working on this for the last few months and have now put together a running unit testing example to demonstrate the final results and committed this to the jBPM projects directory.

The idea is that you are now able to use a single exception handling process (see image provided) to provide all your processes with exception processing. There are only two options in this framework, a human task to allow fixing your processes problems by hand or a retry option to allow for automated continuation based on settings you define.

Currently the unit test demonstrates only human task fixing of a single node failure, but I will continue to work on this. I plan to complete a state node failure and demonstrate the Retry option.

The project includes maven dependency handling (see the pom.xml) and you can start in the readme.txt file included at the root level of the project.

Fedora 12 Eclipse Subversion plugins missing javahl

I tend not to use the integrated Fedora 12 Eclipse packages as I want more control over my Eclipse or JBoss Developer Studio (JBDS) and Java versions. I have many Java JDK's installed and can use them easily with the alternatives setup from Fedora 12.

What I keep running into is that the local subversion packages provide Java HL in the /usr/lib64/* location and the Eclipse or JBDS Subclipse plugins are looking for them in /usr/lib/*, so how to correct this?

// adding the pointer to my javahl libs in eclipse.ini file 
// as follows to make use of the Fedora 12 native rpm javahl
// package installed libs:
//
-Djava.library.path=/usr/lib64

Now my subversion tooling in Eclipse / JBDS works without complaining...

jBPM migration strategies - Introduction

For some time now I have been looking to put together my views and experience on how to position your current jBPM v3.2.x implementations for migration to a newer version. This article will outline some of the best practices within the four layers identified in general jBPM projects.

These ideas will be put forth based on the simple diagram provided here which outlines a typical enterprise business process implementation. It is not necessary to have all the various components in an implementation to be able to make use of the guidelines detailed in this article. The extensive list of components is provided to allow for discussion on the typical interactions I have encountered in my jBPM travels. In this introduction these layers will be outlined and future articles will cover them in more detail.

The idea behind each layer will be to identify best practices and ways to keep your implementations as jBPM version agnostic as possible. I believe this can be achieved, to a point, with proper knowledge and design time application of this knowledge. Each section will dive deeper into that specific area and try to provide you with the knowledge to design and implement your jBPM projects in such a way as to future proof them. You will be as ready as you can be to migrate to the next version.

The choice to focus on jBPM v3.2.x is due to the fact that this is currently the supported enterprise version provided in the JBoss SOA-P product. This is what many enterprises are currently using, throughout the world.

Process initialization layer
The first layer covers the details of providing flexible initialization of your processes within enterprises where you might have serious performance wishes, many different processes that can be initiated and allow for prioritising which process will be started when.

Process definition layer
This layer contains the process definition itself, a narrow layer that simply needs to be migrated to some future version of jBPM. Will this layer be jPDL, XPDL or some form of BPMN?

Process implementation layer
Here we dive into the underlying code layer that is best known as Handlers. The actual Java implementation that you may extended with abstraction layers, business logic and helper utilities. There is much to be cautious of here when looking to migrate your processes to a future version of jBPM, but there are some simple practices that will make migration less work than you think!

Process interaction layer
There is much to be won with a good strategy for accessing business logic, back-end systems, back-office systems, user interfaces, other applications or whatever your business processes need to use to get their jobs done. Here you will find a series of components passing review with suggestions for each one on the best way to position your projects for easy migration. A bit of prevention will go a long way in your IT budget!

General best practices
For as far as they have not been covered, I will provide some best practices with regards to any jBPM project. These will zoom in to a lower level than the above layers and can be applied across them all. If you get nothing out of these articles, I hope you will be able to make use of these gems of knowledge learned through harsh lessons in the trenches of jBPM projects.

Please feel free to provide feedback and suggestions for areas that might be missing. I am not trying to cover all possible use cases for jBPM projects, but to provide a reference architecture that is recognisable for the majority of enterprise jBPM users.

The next article in this series examines the process definition layer...

jBPM 3 hints - finding a process instance in your deep dark jBPMContext

While writing some unit testing of the jBPM exception framework I needed to deal with two separately deployed process instances, one for the unit test and one for dealing with the exception I was causing.

My problem was how to obtain the exception process instance when all I know is the process name? I also had it easy from the unit testing point of view, I do not need to worry about multiple running instances of the exception framework as this is under my unit test control (at least I feel like I have some control over it!).

Below you see how you can locate your process instance and context within that instance. I will show you some helper methods that might come in handy for you (all logging done with log4j and assumes you understand what you see below):

/** Used to get the process id of the specific process I want. */
public long getExceptionProcId () {
  JbpmConfiguration jbpmConf = JbpmConfiguration.getInstance();
  long procId;
  
  // Open the transaction.
  JbpmContext jbpmCtx = jbpmConf.createJbpmContext();

  try {
    // Get our process instance back.
    GraphSession graphSession = jbpmCtx.getGraphSession();
    ProcessDefinition processDefinition = 
      GraphSession.findLatestProcessDefinition("Exception Framework");
    assertThat("No process definition found.", 
      processDefinition, is(not(nullValue())));

    // Now, we search for all process instances of this process definition.
    List processInstances = 
      graphSession.findProcessInstances(processDefinition.getId());
    ProcessInstance procInst = (ProcessInstance) processInstances.get(0);
    procId = procInst.getId();
  } finally {
    // Close context.
    jbpmCtx.close();
  }   

  return procId;
}

With the above you can make use of the processId to recall your process instance as follows:

JbpmConfiguration jbpmConf = JbpmConfiguration.getInstance(); 
JbpmContext jbpmCtx = jbpmConf.createJbpmContext();
  try {
    long processInstanceId = getExceptionProcId();
    ProcessInstance procInst = jbpmCtx.getProcessInstance(processInstanceId);
    assertThat("No exception process instance returned.", 
      procInst, is(not(nullValue())));
    assertThat("Exception process in unexpected state.", 
      procInst.hasEnded(), is(true));
  } finally {
    // Close context.
    jbpmCtx.close();
  } 

Another nice one to help you find what processes have been deployed in your current jBPMContext:

// find all our processes that have been deployed and log them.
JbpmConfiguration jbpmConf = JbpmConfiguration.getInstance();
JbpmContext jbpmCtx = jbpmConf.createJbpmContext();

  try {
    List listProcs = 
      jbpmCtx.getGraphSession().findAllProcessDefinitions();
    if (getLogger().isDebugEnabled()) {
      for (ProcessDefinition processDefinition : listProcs) {
 getLogger().debug("Process definition is: " 
          + processDefinition 
          + " with version: " 
          + processDefinition.getVersion() 
          + ".");
      }
    }
  } finally {
    jbpmCtx.close();
  }