Skip to content

News and thoughts from the team behind the Eclipse Hudson project

Hudson and iPhone Development

Just spotted this interesting blog about using Hudson to automate iOS app builds

http://blog.spritebandits.com/2012/08/07/ios-dev-with-hudson/

Don’t forget – you can keep up with Hudson blogs via the aggregator here

 

Duck! Here comes M3!

Today we released the M3 Milestone build of Hudson 3.0 at Eclipse. M3 is a biggy as we’ve finally managed to unravel most of the IP spaghetti surrounding the original Hudson code base and come up with something that an organization can be confident in using with the knowledge that we know where every bit of code came from and under what terms it was contributed. This may seem boring and legal but the truth is that you can’t just trust the licence on the box front so to speak, libraries depend on libraries which depend on libraries. The original Hudson code base was such a melange of licenses including LGPL, Apache, specialist, none at all… (the list goes on). Now we’re down to a list of somewhat over 70 libraries used by core, all of which have been approved, or are in the process of approval, via the detailed Eclipse IP processes.

Great, so what does that mean? Well one of the consequences of the “Great IP Cleanup”, as we’re calling it, is that we’ve had to pull certain bits of functionality from Hudson Core, you may have already noticed that in some cases we’ve be able to replace functionality (e.g. replacing the LGPL JFreeCharts with Eclipses own BIRT charting engine) In other cases we’ve had to move the code out of the Eclipse code base into a “required” plugin which remains in the Hudson-plugins code base. Examples of these include features such as Groovy Support (uncertain provenance for the Groovy code base) and SVN Support (The SVNKit license is incompatible with Eclipse). So what to do? Well fire up an M3 build and you’ll find out!

If you just run with the internal Jetty server you’ll notice a little message during startup:

INFO: Initial setup required. Please go to the Hudson Dashboard and complete the setup

That’s the clue! When you fire up your browser you’ll encounter a new screen, the Initial Setup screen:
The new initial setup screen in M3

This screen provides a simple way to ensure that the Hudson instance can get access to all of the required-but-non-Eclipse plugins that it needs (plus some of your favorites besides) in order to be fully functional. If you scroll to the bottom of the page you’ll see there is also a section to configure your proxy if you’re behind one – make sure you fill this in (and use the Test button to check you have the details right!) if you need to.
Define a HTTP Proxy in M3
Hitting the install button will pull the selected .hpi files from the plugin center into your HUDSON_HOME plugins directory. Be a little patient though, this can take a few minutes depending on the speed of your connection. Once everything is downloaded you can hit Finish and Hudson proper will start and you’ll be back on familiar territory. (Note you can just hit “Finish” to both download and start in one click.)

You can download the M3 WAR file from the Eclipse download page here.

Happy M3-ing!

Duncan Mills

Oracle upgrades Hudson’s infrastructure machines

Whilst the core Hudson project is moving to the Eclipse Foundation its plugin infrastructure is being housed on a new dedicated machine infrastructure provided by Oracle Corporation.

Last weekend the wiki along with the JIRA issue server and Hudson on Hudson were moved from the original Sun provided machines to their new powerful home by the Hudson team at Oracle.

Hudson-on-Hudson has a new dedicated host with two slaves each with 16GB of memory. For the wiki and JIRA and Crowd servers a new machine with a whopping 32GB memory is up and running.

The JIRA issue server will continue to be the main entry point for plugin-related issues whilst the history of core issues will be maintained there and synchronised with the Eclipse Bugzilla going forward. In general we encourage the hudson community to start using the new Eclipse Wiki for future documentation efforts, but again the existing re-hosted wiki will be retained for historical purposes.

This fab new machine infrastructure ensures that Hudson and its plugin infrastructure are future-proofed and ready for growth over the coming years as more and more enterprise users come on board.

First Hudson Release from Eclipse Foundation

The Hudson team is pleased to announce its 3.0.0 Milestone 0 release from the Eclipse Foundation. We have worked diligently and expertly over the past year to get to this milestone release.  Since release 1.398  the Hudson community has benefited from the team’s work through the introduction of the 6-week release cycle, based on a new development and release process and the ongoing work on bugs, enhancements and new features

What is included in this release?

The M0 release is the first release of Hudson as a top level technology project from the Eclipse Foundation. It has been a very busy 12 months for us and that is shown in the large numbers of new features, enhancements and bug fixes the team has developed.

Over 50+ new features and enhancements cover:

  • Maven 3
  • Cascading Projects
  • JAXB-based REST API and plugin,
  • enhancements to
    • Parameterized Builds
    • Downstream Projects
    • User Management
    • Security and Authorization
    • UI
    • GIT support

Over 350 bugs across the full range of Hudson have been fixed especially focused on stability, performance and the core SCM plugins such as GIT and SVN.

In parallel to this, in August 2011 the team began the process of submitting the Hudson core code to the Eclipse Foundation  The foundation has stringent entry requirements on all project source code and third party licences to ensure they are IP and license clean. Hudson’s source code, split over 10 core modules, has now been approved and is available in the Eclipse GIT repository.

There are over 200 third party libraries distributed with Hudson (including many that relate only to plugins).  Some of these are LGPL licensed libraries that the Eclipse Foundation does not accept under any circumstances. The team developed and implemented a strategy to replace these with more suitable libraries ensuring little impact on the core code or Hudson plugins using them.

For example:

  • The Java Native Access, JCaptcha and JFreechart  libraries have been repackaged as external plugins for this release. Additionally HawtJNI will be bundled as part of Hudson core for future releases, to replace the JNA support.
  • The BIRT Charting engine will be the charting method of choice going forward, but backward compatibility with JFreechart is maintained by existing plugins through the simple addition of a dependency on the external JFreechart libary package.
  • Winstone, originally used as the the standalone container for Hudson has been replaced by Jetty.

The balance of the libraries were considered for submission to the IP checking process.  In itself this is no small task. Each library has to be submitted with its source code.  Some of the libraries were so old that the code was not readily available or had been forked with local changes.

The Hudson team modernized the code through such means as replacing forked libraries with current versions and working with library owners to feed forked changes back into the latest library versions.  The Eclipse Foundation contacts owners and contributors to libraries to establish IP cleanliness.

As you can imagine, this is a labour intensive process but the work of both the Hudson team and library owners has ensured that over half of the 100+ third party libraries have been approved already. This core set of 100+ libraries represents those that are physically packaged in the core war.

The rationalization and approval process for the balance of the libraries is ongoing. But the result of this mammoth effort is that Hudson is ready to move forward and develop features related to the high level themes that the community agreed upon.

The final part of the effort in the leadup to this M0 release is the work that has been done on both the Hudson Eclipse website and wiki. Much of the content from the older hudson-ci.org has been rewritten or updated and moved to the new infrastructure. Over 70 pages are now available from the new sites, including the recently published Hudson Book (151 pages of material in it’s own right) that contains the most up to date information on installing, administering and using Hudson.

What can you contribute to this release?

As an alpha release we are not expecting miracles! But the release has gone through development and testing cycles and we are very pleased with the results.  You should be able to run this release of Hudson on your container of choice and expect it to behave well. You can install plugins  and expect them to run.

With the changes to libraries detailed above there may be some issues that we need to address quickly. Known issues will be with any plugin that uses JFreechart. We are in the process of either forking or contacting plugin owners to create the dependency on the external plugin. But the plugin may not yet be available from the update center. Keep an eye on the blog and Twitter feed for the latest news.

If you have any issues or further enhancements relating to this Eclipse release Please raise issues in the Eclipse Bugzilla system which you can find at https://bugs.eclipse.org/bugs/ – Hudson lives under the top level Eclipse Technology project. You will need to register for an Eclipse BugZilla account to log issues if you don’t already have one. For more information on the Hudson community, mailing lists, forums etc. please head over to the communities page.

Feel free to join us at the next community phone call to voice your opinions and experiences with this new release.

What is coming next?

It’s our intention to release monthly milestones until we get to our first approved Eclipse production release. By which time we feel that the Hudson project at Eclipse will be fully functional and ready for migration of your production servers. In the meantime, updates will continue in parallel on hudson-ci.org for all your production Hudson needs.

Susan Duncan

The Hudson Book – Now Available in EPUB Format

Good news! We’ve just altered the Hudson Book build process to generate a copy of the Hudson Book in EPUB format. So you can now download the book and read it offline in your favourite e-book reader, tablet or phone device. Head over to the book page on the wiki for the latest copy of the book in all of the available formats. http://wiki.eclipse.org/The_Hudson_Book

Using Hudson on SOA Projects

I attended two sessions on using Hudson in SOA development projects at the DOAG conference this week. Both were given in German, not my strong suite, but it’s amazing how being present and hearing the enthusiasm in a conference session transcends language barriers – Kontinuierliche Integration – is important in every development language!

The first was a joint presentation from OPITZ Consulting and Continental Automotive. They worked together on  developing a custom testing framework for integration testing of SCA composites as part of Continental’s central IT.  Jurgen Broda, from Continental, spoke in glowing terms of the ease of use and the benefits that his team has encountered from the automation of its testing and integration with MKS through Hudson. In fact, this presentation inspired Lonneke Dikmans, a Managing Partner with Vennster, to blog that she is returning to her current project to install Hudson and implement CI as soon as possible.

The second session was given by Trivadis. Interestingly, the slides for this session were in English but the presenters spoke in German to the predominantly german-speaking audience. They delved deeper into how they use Hudson, Maven, Nexus, SVN, Sonar, MySQL and JIRA together as their CI infrastructure for OSB/SOA client projects.  From this they have a reference project which they quoted as the ‘project team couldn’t live without it anymore‘.

I hope that the DOAG slides will be available soon if you are interested in looking further into these or other sessions.

Susan Duncan

 

 

How Hudson is helping the development of JSF

This week I am at the German Oracle User Conference. It’s great to be out and talking and listening to Hudson users about their experiences with Hudson and how it is being used. I’m going to get some of these customer experiences both from here and the recent EclipseCon (Europe) conference onto this blog in coming weeks.

As I sit working in one of the conference lounges I am joined by Ed Burns, the JavaServer™ Faces Technology lead for the Java Community Process.

After just a few minutes he smiles and says, “We could not be supporting the complex stack that we do without the agility that Hudson gives us” as he clicks the Build Now button, picks up his stuff and moves on to his next appointment after quickly fixing a just found bug in the JSF implementation used by the Oracle JDeveloper team.

JSF are using Hudson with a complex mix of tests to build, test and deploy to a public Maven repository. Now he can update the bug with the build details and the JDeveloper team can grab that patch as soon as they hit the decks later today in the USA.

You can see the JSF2.1  Hudson view here and some more detail about how the JSF team are using Hudson from Ed’s blog 

Susan Duncan

The Hudson Book

We are very excited to announce the publication of this fantastic new book on Hudson. Over the last few months Manfred Moser and Tim O’Brien have worked long and hard to produce a comprehensive guide to using Hudson from initial download to production deployment.

It is packed with 10 chapters of information covering the very latest features in Hudson at the Eclipse Foundation including the Maven 3 integration and even the new Cascading Projects that is so new it’s only a Beta release!

For anyone looking to start with Hudson or those looking to improve their knowledge this book is the place to go.

Manfred says, “Going forward we hope to expand the book’s depth and make it the authoritative and up to date documentation for Hudson users covering the core of Hudson features and moving to documenting more and more use cases, further plugins and advanced usage like plugin creation or scripting console usage.”

The link provided here takes you to the rough format of the book on the Hudson project at Eclipse. Right now, it’s a bit ‘rough and ready’ but we will get a wrapper as soon as possible that provides the single and multi-page html and the pdf. But we wanted to get this information out to you – so enjoy!

http://www.eclipse.org/hudson/hudsonbook

Susan

Cascading Projects released as BETA

Have you ever despaired at having to update multiple Hudson jobs when you need to change properties? Perhaps you use templates or copy jobs to try and alleviate this at job creation, but what about further down the road? What you’ve dreamed of is the ability to have some kind of inheritance of properties throughout the life of jobs.

Dream no longer! Hudson has released a beta of its new Cascading Projects feature. Now you can define a project with a cascading parent and have a child project derive its configurable properties from its parent.

Cascading Projects is not a template, you can configure a job to inherit properties from its parent, whilst overriding those that need to be changed or later reverted back to the parent. Any changes you make to the properties in a parent will cascade down through the child jobs that inherit that property.

Take the example here.  Job3.2 will inherit its properties from Job3.1, which in turn inherits from Job3 and so on.

But what if Job3 overrides a property it inherits from Job1? That change will cascade down to Job3.1 and Job3.2

If the the same property is subsequently changed in Job1 then the change will cascade down to Job2 but the override in Job3 will stay in place for that job and its children

You use the project config page to select an existing saved project to inherit from. Any project can be used as the parent, but you cannot create a cyclic inheritance. Most of the properties are cascadable and if the parent contains Builders, Publishers or Triggers they will be merged with the child.

So what kinds of projects might benefit from Cascading Projects? A few of the most common examples include updating email notification lists, project-based security, reports published locations and polling the source repository.

This new feature comes from a request from the community in HUDSON-3157 and is an example of the work that the Hudson team is engaging in along with bug fixing and all the work associated with the entry to the Eclipse Foundation as detailed in a previous post.

The details of the implementation and the full list of cascadable properties are detailed on the wiki. As with any beta release, your feedback is greatly appreciated. The final release is scheduled for mid-November and we will endeavour to address any feedback and make updates to the feature before then.

You can download the Hudson 2.2.0-Beta war file here. Please be sure to test this with a copy of your production Hudson home. The implementation adds some additional elements to the project configuration XML which will not be recognized by Hudson 2.1.x and previous.

Susan Duncan

IP and License Clean for Eclipse Foundation

Over the past couple of months the Hudson community has been working hard to ensure that its source code and libraries are IP and license clean in order to pass the stringent entry requirements of the Eclipse Foundation. I spoke briefly about this at my Hudson session at JavaOne and the response was so enthusiastic that I feel I need to bring the facts to a wider audience through this blog.

The Hudson code that is moving to Eclipse is made up of its core components and plugins for SSH-Slaves, Git and Subversion. The initial upload was made up of around 1700 Java files, 125 XML files, 600 Jelly files and some 3700 property files. The core elements (core, UITest and UpdateCenter) have now been approved and are around 8 of the external libraries but there is still some way to go. Each license is checked by both Eclipse’s automated system and by hand.

There are a number of different areas that are slowing down the progress and causing us to do major rework:

1. GPL/LGPL libraries
Eclipse does not allow any of these libraries in. We have had to make major code changes to remove 5 libraries. One major example is Java Native Access , like many libraries, when we came to a thorough example of the jars we discovered additional libraries that also had to be removed and worked around. You can see the complete list of libraries here. Notice that this list includes Winstone. This was the bundled web container for standalone Hudson, but the version was obsolete and GPL LGPL licensed so had to be changed to the Eclipse Jetty Container.

Another major code change involved JFreeChart. We have had to abstract this library to a plugin so that it can be provided from outside Eclipse.

2. Obtaining Source Code
Some of the libraries being used in Hudson are so old that obtaining the source code, as required by Eclipse, has proved difficult. One example is the acegi security library. We spent some time trying to procure the source code for the version of this library that Hudson uses. But eventually had to remove it.

3. Forked external libraries
There are a number of external libraries that have been patched within Hudson. These we are having to upgrade to a more recent version and if necessary discuss the patch with the library owner to get it consumed back into the main library . These include jtidy.sourceforge.net, xstream.codehaus.org and others.

4. Duplicate Functionality libraries
Whilst going through the external libraries we have also come across a number that provide duplicate functionality. although not in themselves a problem we do want to analyze and where possible reduce the number of external libraries necessary.

Why is all this necessary? Well, primarily because the Eclipse Foundation require it, and many of our customers are asking for it. But why? And this is really the crux of the matter. Hudson and the Eclipse Foundation are committed to providing a product in which the code and IP are clean, and the process is predictable, stable and open. For some organizations and users this is more important than to others, but for us it is part of our raison d’etre. We believe that if Hudson is to continue along the path of being the de facto standard for CI and to increase its importance to development shops both small and enterprise wide, then it must be absolutely clean. The users, the legal departments, the procurement bods, everyone who has an interest in software and in IP in an organization must be able to categorically say that Hudson is clean, reliable, stable and safe.

Susan Duncan

Design a site like this with WordPress.com
Get started