2016-01-29

Cheers - fabric8 Camel Maven Plugin to validate Camel endpoints from source code

Today I recorded a 12 minute video to demonstrate the new fabric8 camel-maven-plugin that is able to validate all your Camel endpoints from the source code. This allows to ensure your endpoints are valid before you run your Camel applications or unit tests. And it helps you catch those type errors or if you use invalid values for the options and so on.

video of fabric8 camel-maven-plugin in action
The fabric8 camel-maven-plugin can be run from within your Java editor as I demonstrate in the video, and of course from the command line. The plugin is able to parse both XML and Java code (the latter uses Eclipse JDT). So should be useful for all schools of Camel users.

We hope to improve on the plugin to have tighter integration in the editors such as IDEA and Eclipse, so you can have in-place Camel endpoint validation and code assistance while typing your Camel endpoints. We are working together with the JBoss Forge team to add the necessary hooks and apis that allows this plugin and the Camel forge commands to tie into that. 

Cheers and have a beer its the weekend soon, and yesterday Apache Camel 2.16.2 and hawtio 1.4.60 was released. That is a good excuse for grabbing a beer or a glass of wine.

2016-01-16

Apache Camel and other ESB products (Camel vs Mule) - 5 years later

Yesterday Raul Kripalani (a fellow Camel rider) posted a tweet:
Shoutout to @davsclaus & #Camel riders! Just added a reflection upon the last 5y on this SO question: https://stackoverflow.com/questions/3792519/apache-camel-and-other-esb-products/34818263#34818263 …. Have a look!
The tweet refers to an old question on stackoverflow about the Apache Camel versus other ESB, and this question is in particular about Camel vs Mule.

The question was asked in September 2010, and now fast forward 5+ years Raul took a look at the situation today. I think his detailed answer is worth attention for users of Camel, and others who are doing assessment on integration software.

Rauls answer starts out as shown below. I suggest to go read his post - after you have finished reading this blog ;). And you are welcome to use the upvote ;)


I think Raul has some major points to point out about the difference between Camel and Mule.

The key differentiator I see is, the non technical aspects, Apache Camel is:
  • 100% truly open source
  • Open community
  • Everything is discussed and happening in the open
  • Anyone can participate (and become a committer)
  • No control of a single vendor
  • All branding and marks belongs to ASF
  • ASF is a non-profit foundation where companies cannot control it
  • All code is open source and ASL licensed (no open-core/community vs enterprise model)
  • No vendor lock-in

An maybe overlocked fact is that the branding and marks of Apache Camel belongs to the ASF foundation. So no commercial company can "take the brand" and run with it. Neither Red Hat or Talend etc. can create a product called Red Hat Camel, Talend Camel ESB etc or some variation of the project name. Apache Camel is the authentic project.

Other projects may encounter such a problem. For example docker is very famous brand today, and there is no neutral foundation that owns that brand, the brand is owned by docker.inc (the company). So IMHO there is an interest of conflict with the brand name and docker.com the commercial company.

Another important aspect of Apache Camel (and ASF projects) is that there is no open-core/community vs enterprise model. At Apache Camel we would never deceive the community, for example by learning which Camel components that are the most popular and remove the source code from the community version and put that under a different license in a closed-source enterprise only product.

We from the Apache Camel project do neither spread/post FUD and eschewed marketing stunts on the Apache Camel website, unlike Mulesoft, where they are doing that by posting their controversial Mule vs Camel post on their commercial website. The piece of material smells of corporate bullshit, and no true honest developer would write such a piece of ...  (excuse my english)

And a final note Its also worth referring people to the previous blog, which also spun from a tweet where you can easily compare projects on blackduck, such as Camel vs Mule.



With Apache Camel it is all about the community, for the community, and all work is done in the open. Anyone can participate and we love contributions.

Roll on 2016 its going to be another great year for the Camels.



2015-12-30

My thoughts on buying professional documentation

The Apache Camel project has a lot of documentation online at its website, we have more than 1000+ pages. However due to project was created so many years ago, and the choosing of a wiki based system for documentation, has lead us today with a website and documentation that is a challenge to navigate and keep up to date, and have a modern look and feel.

The Camel team is aware of this, but its a huge undertaking to build a new website and restructure and redo the documentation. But we will get there, part of the help is the work on being able to keep the EIPs and components, data formats etc. partly up to date based on a build system that can sync the source code and documentation, to ensure all the options are present and documented.

However this last last blog of mine for the year 2015, is a concern of mine. Are commercial companies so bad at allowing their engineers to buy books about the various open source projects they are researching or using?

I sadly see too many new users to Apache Camel, that could benefit from buying one of the many Apache Camel books, and read a few chapters to help set the scene, and get the reader on a much better path and journey with using Apache Camel. I also sometimes encounter private emails from big companies asking for help about various Camel issues they have, and from what I can see then 7 or 8 out of 10 questions are already covered in the books, or at least the books could guide them to a solution in much less time. Besides the books there is also Camel training, where some companies offer training either online or onsite.

Apache Camel is a very feature rich integration library, and it has a lot of functionality. And you will be much more successful when you learn this piece by piece. The Camel books will help you archive that by covering the pieces chapter by chapter.

As an author myself I know that there is a lot of effort going into making a book. The level of details and work from both the authors and publisher goes beyond what is possible to do as online website documentation. You should really see this as different kind of documentation, which gives the synergy effect where 2 + 2 = 5. 

So are we there where a $30-60 book (depending on discount codes and print vs ebook). And during x-mas there is even some publishers that has all their books on sale for $$ is a barrier to entry? Are companies that make $$$ in using free open source projects, and never contribute back, not even able to let their developers get hands on the best documentation, to allow them to be even more successful? 

Professional documentation such as books are a key to become more successful

You may also consider that as a developer in the IT industry, you have constantly to improve and learn new skills to keep up, or stay relevant. During my many years in this industry and with the rise of the internet, its become much easier to self study, than in the old days, where you had to wait 1-2 years before your company would send you to some outside training. So what cheaper way is there not to spend a bit $$$ on a book (and if your company reimburse its even better) and start reading. 

If you look for free material, then I was recently interviewed by DZone and there I gave some links to what I think are good resources to get started learning Apache Camel. There is links for both blogs / articles / videos etc.

Its been many years since I last did a job interview, but in my previous engagements a question of mine was always asking for the company to allow me to buy IT books of my choosing.

I buy books today as well. Because I like to read the old fashioned print books, I am looking forward to the Netty in Action book, to learn this excellent library much better, which also helps me to better support the Camel netty components. Another book I enjoy reading is the Functional Programming in Java book which is excellent at covering all the new stuff that Java 8 brings to the table.

To end my blog, then Manning has a 39% discount on the Camel in Action 2nd edition book (you will get 1st edition for free - the ebook version) if you order the book using the discount code camel39 from their website.

2015-12-24

A few recent Apache Camel presentations on youtube

Markus Eisle has been giving a number of Apache Camel talks this year, and recently his talks from Oredev 2015 and JavaOne 2015 was made available on youtube. Markus has a strong JEE background and so he touches how to use Camel on JEE servers such as JBoss Wildfly.


Myself has been giving talks at the Red Hat MicrosServices days we hosted this year at London and New York. My talk from the big apple was made available as well.



Developing Microservices with Apache Camel
(notice the first 10-15 minutes is a Camel introduction part).

Have a happy Christmas and see you in 2016.

2015-12-17

DZone Q&A with Claus Ibsen on Apache Camel

I was recently interviewed by DZone about Apache Camel.

If you have ever been faced with the task of integrating multiple enterprise services, Apache Camel is definitely a tool you should have in your toolbox. In this Q&A, Claus Ibsen shares some insights into the origins of Camel, how to get started, some of the challenges working on a such an ambitious project, and where Camel is going.

The article has just been posted online: https://dzone.com/articles/qa-with-claus-ibsen-on-apache-camel

I also talk a bit about what else I am working on currently besides Apache Camel, such as fabric8, hawtio and the Camel tooling.

2015-12-16

Video of Apache Camel tooling to edit your routes in type safe manner

Today its a special day. I am doing two blog post on the same day. I do not think this has happened before.

This blog post is a quick video which I though was about 5 minutes, but its more 10 minutes. Sorry so you may need to grab a big cup of coffee or tea.

The video demonstrates the current progress we have done on the Camel tooling from the fabric8 project. We have developed a set of small Camel commands that let you able to edit/work on Apache Camel projects in any IDE of choice such as IDEA, Eclipse or NetBeans. And as well from command line and web browser. The latter is being demonstrated later.

This video shows how to edit Camel routes with endpoints in a type safe manner that are Java code. To do that I use the vanilla Apache Camel 2.16.1 release with the camel-example-spring-boot.

fabric8 camel commands to edit Camel endpoints in a type safe manner

The video demonstrates how to install the camel tool and use it in IDEA, Eclipse and from the command line. Yay finally you are not forced to use Eclipse heavy weight tooling. Just imagine when we get code awareness added to the tooling so you just press ctrl + space in your Camel endpoints uris and the tooling shows a popup with code suggestion for every option, just as the tooling does today for Java code ;)

To active and use forge from IDEA press cmd + alt + 4. From Eclipse its just cmd + 4.

Beers++ to the JBoss Forge team to make this tooling library so awesome, allowing us to develop the code once, and reuse it in IDEA, Eclipse, NetBeans, CLI and web with REST.

The Camel tooling is documented (a bit limited) at the fabric8 documentation. But there you can find the latest release, as we do frequent releases at fabric8 so it can be a good idea, to take a look there to ensure you install the latest if you try this on your computer.


JBoss Fuse 6.2.1 Released - How to quickly try it

JBoss Fuse 6.2.1 was recently released which is a much hardened release of the summary 6.2.0 release. The Fuse team has spent a lot of time to QA and harden the bits, as we all know OSGi is tricky, and the runtime provisioning of Karaf containers either manually managed or managed with fabric8 v1.

When 6.2.0 was released I wrote a blog post with some easy steps how to try this release. I did this because I do not agree with the getting started guide at the JBoss Fuse website. IMHO those steps are too complicated, lead you in wrong directions, and let you spend your first experience with JBoss Fuse, to download and install an Eclipse Editor, which sadly is a myriad of confusing steps to install, and worst of all it alters your local maven settings. I have cried wolf about this many times within the company but to no avail. Likewise in the bottom of the getting started guide, the table with reference to more material refers to a mix of old examples, none working examples, and videos that are outdated. Instead you should look at the examples that are actually shipped which is in the quoickstarts directory of the installation.

As I am not primary working on JBoss Fuse anymore, its much less I can do, and surely as a developer when it comes to presenting the product on the Red Hat websites. So why I am doing this - I am tired of the history repeating itself, and that a product I have been passionated and worked hard on, first as part of the FuseSource company and for 3 years within Red Hat. 

So lets repeat the history. If you want to try JBoss Fuse 6.2.1 then I suggest you follow the steps I blogged about last time. They are the same, what is changed is the version number from 6.2.0 to 6.2.1, and the build number is 621084.

The link to the 6.2.1 download which you can also find on the JBoss Fuse website, which is that green button.