intellectualcramps » eclipse

Jacoco, Tycho, and Coverage Reports

kingargyle — Thu, 22 Mar 2012 15:07:01 +0000

It’s been a while since I posted here. Most of my postings are now on Google+ or via twitter. However, neither place does well for code snippets so here I am. If you are using Tycho and want Java code coverage, the Jacoco maven plugin makes enabling the agent during your build relatively simple for you unit tests.


   org.jacoco
   jacoco-maven-plugin
   0.5.6.201201232323
   
      
         
            prepare-agent

Add the above as part of the build entry or as part of a build entry in a coverage profile if you don’t want it to always run.

Getting reliable coverage reports in XML or HTML is a bit more work. While there is a report goal for the jacoco-maven-plugin it currently doesn’t display all of the coverage for all bundles instrumented as it needs to see the source code for those bundles as well. However, the Jacoco report Ant Task doesn’t have this problem. So with a bit of help from the maven-antrun-plugin and antcontrib, we can generate the reports. All reports will be populated in target/jacoco/report. Both HTML and XML reports will be generated.


   org.apache.maven.plugins
   maven-antrun-plugin
   1.7
   
      
         org.jacoco
         org.jacoco.ant
         0.5.6.201201232323
      
      
         ant-contrib
         ant-contrib
         20020829
      
   
   
      
         jacoco-report
         install
         
            run
         
         
            
                
                
                
                
                
                
                  
                  
                     
                     
                     
                         
                            
                               
                                   
                               

                               
                                   
                                      
                                   
                                   
                                      
                                   
                               
                               
                               
                            
                         
                         
                             skipping

The code above basically checks for a jacoco.exec file. If one exists, it runs the jacoco-report ant task. The ant task specifies where the classfiles can be found as well as where the source code can be found. It will also generate both HTML and XML reports.

I hope this helps others enable code coverage in their Tycho builds. I’ve contributed the above as examples in the Minerva project on github.

Does Popularity = Success?

kingargyle — Fri, 27 Jan 2012 01:24:30 +0000

Does the current popularity of an open source project, automatically mean that it is successful? It can but how do we define successful for an open source project?

Just because a project is popular does not necessarily mean that it is successful. It just means at that point in time and duration it is also getting a lot of attention. I’ve been involved with a wide variety of open source projects over the last 15 years. Several I’ve started. Several I’ve participated in from both as a community member and as a committer. Some I would say have been popular at one point or another, other’s I would say never hit the “High School” popularity meter thresh hold.

Popularity is defined by Merriam-Webster’s Learner’s dictionary as, “state of being liked, enjoyed, accepted, or done by a large number of people : the quality or state of being popular”.

Successful is defined as “having the correct or desired result.” So being successful does not necessarily equal popularity. A successful open source project is one that has met its desired goals and objectives. One of them could be, to become popular, and blogged about, and tweeted about constantly, but the winds of popularity change at a moments notice. Success lasts for as long as the project is meeting its stated goals.

Success is defined by the commiters and the community that forms around the project. Is it meeting its user’s needs? Is it growing its user community and committer base? Is it adapting and changing to meet knew requirements? These are just some of the criteria that a project can be measured on to be successful. Yes, popularity can be one criteria, but it should not be the sole deciding factor.

We need to be careful on tying success to popularity alone. There are many projects out there that I would consider successful that have never hit the popularity threshold. Those projects may not be used by Millions of people, but they have built a community around their project, and provide value to that community. How many people are using it, or number of companies that have adopted it, should not take away from the success of the project if it has met its objectives.

So success is going to mean different things to different people. There is no one way to measure if project is successful. To me, if your project even gets a handful of people forming a community around it, you are already successful.

New Year, New Challenges

kingargyle — Fri, 06 Jan 2012 18:25:43 +0000

For the last year and half I have been working with eBay through Intalio, on the Turmeric SOA project. With the new year, I’ll be transitioning off the Turmeric SOA project to an internal Intalio project. I’ll still be involved with Turmeric, just not as much as I have been in the past. Turmeric SOA will still be developed and lead by eBay and hosted on their eBay Open Source portal, and for those that need to support developing and deploying a SOA with in their Enterprise I still think it can be a good fit and something to at least consider.

The new project I’ll be working on gets me back to some of the things I like to do, plus will finally get me to learn some of the newer languages and play with other technologies. It should also free me up a bit to address some of the open source projects I’ve had to neglect over the last year at eclipse. So hopefully, I’ll be able to get to some of the eclipse XSL Tools bugs reports, and maybe..just maybe, I’ll look at Orion and see what it would take to get an XML/XSLT editor going there.

I’ve got a lot of little projects going on at github as well, and I’ve got some ideas around improving the state of web service documentation that I feel are necessary to explore. The early part of this year I have some presentations lined up at STAR and HR-XML around REST and Web 2.0. So I hope to explore how to get organisations like OAGI and related data standard bodies looking at not just XML but how to play well with JSON in the new Web 2.0 world.

So I wish the Turmeric SOA project well, but I’m really looking forward to getting my hands back into some new stuff this year. Embrace change, good things tend to happen.

Testing Turmeric SOA Web Services

kingargyle — Wed, 21 Dec 2011 23:26:25 +0000

With the recent release of Turmeric SOA 1.1.0, I thought it was a good time to revist some of the tutorials around Turmeric. While working on updating some these, I realised we can make testing of the web services a lot more painless. Enter the jetty-maven-plugin.

We will use the jetty:run-war plugin. To get started create a maven war project. You can use the maven webapp archetype to create the project. Once that is completed, you will need to add a dependency to your Turmeric SOA service implementation project and add a plugin entry to specify the version of jetty to use. You will end up with something like this:




  4.0.0
  com.example.test
  test-hello-world
  1.0.0-SNAPSHOT
  Test Hello World Web App
  war

  
     
         org.ebayopensource.turmeric.impl
         DemoHelloWorldV1
         1.0.0
     
  
  
    
      
        org.mortbay.jetty
        jetty-maven-plugin
        7.5.4.v20111024

To test and deploy your web service, you just need to type run: mvn jetty:run-war

You can test that the service is deployed by point your favorite web browser to http://localhost:8080/DemoHelloWorldV1?wsdl

Remember to replace the above with the name of your service.

I typically use this for some quick testing of changes done to a service, or items that need some sort of integration testing. You could also use this to help with some automated testing, but in those cases I recommend writing your test to extend from the Turmeric SOA jetty-common-tests framework. This framework provides an embedded instance of jetty that can be used in integration tests.

Turmeric SOA 1.1.0 Released

kingargyle — Thu, 15 Dec 2011 17:59:04 +0000

Turmeric SOA 1.1.0 is now available for download.

https://www.ebayopensource.org/index.php/Turmeric/Downloads

Included in this release are several new features and improvements.

Cassandra storage support for both Rater Limiter, Runtime, and Monitoring Console. Metrics are captured and stored in a cassandra data store. The JPA option for relational databases is still available for Monitoring and Runtime.
Jetty Turmeric application server. A pre-configured version of jetty 7.4 with turmeric runtime components and common service handlers has been provided for download. This should make testing and development of turmeric services simplier. All runtime items are deployed to a common location. Support for JPA (using Derby) and Cassandra data sources are available, as well as access to the various Security handlers.
Protobuf support has been added as an option for serialization and deserialization for services to use.
Expanded support for RESTful web services, using GET, PUT, POST, and DELETE operations.
OSGI improvements with the way classloaders are implemented. This will allow the turmeric runtime components to be used within an OSGI container.
Additional work on the Repository Service has been done. This version requires WSO2 Governance Registry 4.x, and the service is still beta. Work continues to implement the full functionality against the WSO2 Governance Registry.
Policy Admin UI is now released as 1.0.0. Minor bug fixes have been included. See the release notes for more information.

Many bug fixes, and tweaks have been done as well. For further information please seen the release notes.

Repost: EclipseCon 2012 – What I WANT!

kingargyle — Fri, 11 Nov 2011 17:29:43 +0000

I’m reposting this, after having reviewed the first batch of submissions. I’ve gone through and higlighted some key sections, at least for me. You have through Monday for early bird selection. Final submission deadline is Nov 18th.

It’s that time of year again…EclipseCon North America submission time.

Like every year, the program committee is asking you to submit your talk early. Ian and Doug have been cracking the whip pretty hard telling us to blog, so here I am. One of the topics that came up recently is how do we choose the talks, what are we looking for, who are the rock stars that people want to see. One sure way is to ask what you want to see or attend at the conference, so provide your feed back here, to Doug, Ian, or any of the other committee members.

Last year, I referenced a paper, “How to Get a Paper Accepted at OOPSLA“, in which it outlined some of the items that, that committee was looking for in a submission. So I’ll jot down some things that I’m looking for below.

I don’t have a particular technology or niche that I focus on any more, it used to be XML and the related technologies around it, but in most cases the XML tools at eclipse are good enough for most people’s uses. So I’m not necessarily looking in that area, unless something REALLY REALLY cool comes along. Also if you submitted the same talk in the past or presented it in the past….not interested.

I’m more focused over the last year or two on quality of the code that is produced by a project and developers in general. How to make sure we keep the code maintainable and the practices around that. So static analysis tools like PMD, and FindBugs are interesting, but I want to know how your projects are using these tools to improve your code. What are the new and interesting things coming out of these tools? Projects like Code Recommenders peak my interest, and the additions they provide. Mylyn…well they do interesting things, so I’m looking not so much the Core Mylyn task oriented project, but their sub projects, and how they are improving developers lives.

Experience reports from projects migrating to or from a centralized version control system to a distributed version control system. The pains, the gotchas. How can EGit be improved, how are you using JGit to get your work done. Has moving to a distributed version control system made your life easier, harder? Are they over hyped?

Builds…Builds…Builds. The battle of the builds continues to happen, but more importantly what can we do about p2? p2 started as provisioning system for an application, but is being used more and more for to provision a build and a repository for those build artifacts. Are you doing any work in the enterprise or open source projects around addressing the issue of stale or non-existant p2 repositories. How does this affect the reproducability of your build? Are there ways to address this? How does the p2 model of a repository compare the Maven Central concept? Should the Eclipse foundation replicate the model for p2 and if so how?

What are the problems that a project and committers coming from a corporate environment experience when working on a previously closed project that is now open? How did you adapt, what leasons can be taken away from this?

The web and mobile space is still hot, but how do we evolve our development environment and particularly the eclipse interface to the new touch screen mentality? Is there something within Eclipse 4.x platform that allows for adapting to the new platform? Is SWT even the right technology going forward? Should we be looking at new ways to develop our user interfaces so they are cleaner and easier to use? How do we get more UI specialists involved with open source projects in general?

In general, I’m interested in things that challenge the status quo, that make me think, and challenge my beliefs. That help make me more productive, improve the quality of the code I produce, and make it easier for people that use that code. Give me more demos, and less talk. For tutorials, I really want lots of hands on, and short introductions to the topics that will be worked on in an exercise. Get me up and running quickly.

So those are the types of things that will peak my interest on a submission. It’s not so much the underlying technology (i.e. xtext, xml, emf, css, javascript, json, java, scala, osgi, etc), but what does it enable and improve upon. Tell me how it improves or challanges the status quo.

I look forward to your many submissions.

Refactoring: Maintainable Web Services

kingargyle — Mon, 07 Nov 2011 21:26:24 +0000

One of the problems I have with WSDL based web services is the fact that operations are typically generated into one big interface file that must be implemented. I’ve seen WSDLs with 50 to 70 operations, and this leads to a Service/Client Implementation that has 50 to 70 methods that need to be implemented. The problem here is that the code becomes a magnet for change. The correct thing to do is to refactor the WSDL into multiple services, but if you can’t do this and you don’t have control over the WSDL, how can you deal with this situation?

On twitter I mentioned we had a situation like this on the Turmeric SOA project, and I’ve talked about similar situations regarding various eclipse project code as well. For Turmeric there is a Repository Service, which provides a specification for Governance of Assets for a service as well as the lifecycle management of these assets. The initial implementation of which for the WSO2 Governance Registry provider can be see here. The code is done the way I see a majority of WSDL web service implementations done. The methods contain all code related operations in the one class file. This leads to several problems. First the class is over 1500 lines long, making more difficult to understand what the class is doing and maintain. Second it has more than one reason to change. The class is handling Update, Delete, Subscription, Submittal, Add, etc of various repository assets. So it is a magnet for any change that has to happen in the implementation. It is difficult to test in isolation, and also tends to lead to some over use of static utility methods. (The static utility method is another plague, but that is for another post).

There is a general rule of thumb that your classes should ideally be no more 500 lines long, and that they should have very few reasons to change. The implementation above was refactored into the following:

Each of the operations now only has a single reason to change. Each class is less than 500 lines, and is a bit easier to understand. Just because an Interface defines all the methods does not mean that you have to put all the functionality within the class and method. Break it up, make your code easier to test, and easier to maintain. Ideally, I’d refactor this service into at least two or more separate services. Are there other ways to handle this? Is there another set of patterns besides Proxy/Delegate that could be used to handle this situation?

Re-Writing Eclipse Commit History

kingargyle — Tue, 27 Sep 2011 13:45:31 +0000

So you took the plunge and migrated your project from CVS/SVN to GIT? However at the time you did so, you didn’t think about possibly splitting out the projects into multiple git repositories. You and your project were still getting familiar with GIT, and didn’t know the advantages/benefits of splitting the repo up could bring. This is the situation that occurred when the WTP Incubator project and its components made the move to git.

When we originally decided to make the switch we just took the easy way out and migrated the incubator directory in CVS to git. All the components were arranged in the following directories:

sourceediting
    development
    features
    plugins
    examples
    documentation
    tests

webservices
    development
    features
    plugins
    examples
    documentation
    tests

The incubator project is made up of several incubating components, including Vex, XML Security, XQuery, RelaxNG, and others. You can view the current git repository here.

With Vex getting ready to graduate, and move to the Mylyn Docs project, we needed to split out the commit history just so that it represented the relevant items for the Vex project. To help with this the command line git filter-branch command was used to re-write the commit history to remove the other projects all together. The newly cleaned git repository was then pushed to a clean git repository on GitHub.

To clean the tree and remove all empty commits during the process the following bash script was used.

git filter-branch -f --prune-empty --tree-filter 'rm -rf webservices' HEAD git filter-branch -f --prune-empty --tree-filter 'rm -rf sourceediting/examples' HEAD git filter-branch -f --prune-empty --tree-filter 'rm -rf sourceediting/development/org.eclipse.wst.xml.relaxng.releng' HEAD git filter-branch -f --prune-empty --tree-filter 'rm -rf sourceediting/development/org.eclipse.wst.xml.security.*' HEAD git filter-branch -f --prune-empty --tree-filter 'rm -rf sourceediting/development/org.eclipse.wst.xquery.*' HEAD git filter-branch -f --prune-empty --tree-filter 'rm -rf sourceediting/development/org.eclipse.wst.xquery.repository' HEAD git filter-branch -f --prune-empty --tree-filter 'rm -rf sourceediting/features/org.eclipse.wst.xml.relaxng.*' HEAD git filter-branch -f --prune-empty --tree-filter 'rm -rf sourceediting/features/org.eclipse.wst.xml.security.*' HEAD git filter-branch -f --prune-empty --tree-filter 'rm -rf sourceediting/features/org.eclipse.wst.xquery*' HEAD git filter-branch -f --prune-empty --tree-filter 'rm -rf sourceediting/features/org.eclipse.wst.xquery.build.feature' HEAD git filter-branch -f --prune-empty --tree-filter 'rm -rf sourceediting/features/org.eclipse.wst.marklogic*' HEAD git filter-branch -f --prune-empty --tree-filter 'rm -rf sourceediting/plugins/com.google.gson' HEAD git filter-branch -f --prune-empty --tree-filter 'rm -rf sourceediting/plugins/com.matinprobst.xqpretty' HEAD git filter-branch -f --prune-empty --tree-filter 'rm -rf sourceediting/plugins/com.thaiopensource.jing' HEAD git filter-branch -f --prune-empty --tree-filter 'rm -rf sourceediting/plugins/org.antlr.runtime_v31' HEAD git filter-branch -f --prune-empty --tree-filter 'rm -rf sourceediting/plugins/org.apache.xml.security' HEAD git filter-branch -f --prune-empty --tree-filter 'rm -rf sourceediting/plugins/org.eclipse.wst.rng*' HEAD git filter-branch -f --prune-empty --tree-filter 'rm -rf sourceediting/plugins/org.eclipse.wst.xml.relaxng*' HEAD git filter-branch -f --prune-empty --tree-filter 'rm -rf sourceediting/plugins/org.eclipse.wst.xml.security*' HEAD git filter-branch -f --prune-empty --tree-filter 'rm -rf sourceediting/plugins/org.eclipse.wst.xquery*' HEAD git filter-branch -f --prune-empty --tree-filter 'rm -rf sourceediting/plugins/org.kohsuke.rngom' HEAD git filter-branch -f --prune-empty --tree-filter 'rm -rf sourceediting/tests/org.eclipse.wst.xml.security*' HEAD git filter-branch -f --prune-empty --tree-filter 'rm -rf sourceediting/tests/org.eclipse.wst.xquery*' HEAD

If you use the --all option it will rewrite it across all branches, otherwise, it runs against the current branch you have checked out.

Effectively once the filter-branch is done, you will effectively have purged all history of the prior components.

EclipseCon 2012 – What I WANT!

kingargyle — Fri, 23 Sep 2011 13:55:49 +0000

It’s that time of year again…EclipseCon North America submission time.

Experience reports from projects migrating to or from a centralized version control system to a distributed version control system. The pains, the gotchas. How can EGit be improved, how are you using JGit to get your work done. Has moving to a distributed version control system made your life easier, harder? Are they over hyped?

The web and mobile space is still hot, but how do we evolve our development environment and particularly the eclipse interface to the new touch screen mentality? Is there something within Eclipse 4.x platform that allows for adapting to the new platform? Is SWT even the right technology going forward? Should we be looking at new ways to develop our user interfaces so they are cleaner and easier to use? How do we get more UI specialists involved with open source projects in general?

I look forward to your many submissions.

Turmeric SOA Distributions

kingargyle — Fri, 16 Sep 2011 15:22:10 +0000

One of the challenges with any open source project, is making it easy to get up and running. A user should be able to download a binary, and type one command to get started. Until recently with the Turmeric SOA project, it wasn’t this simple. Just take a look at the instructions for getting started with the Turmeric Runtime. If it isn’t easy for somebody to get up and running in about 15 minutes or less, then you have probably already lost a potential adopter.

To help address this, the Turmeric SOA project has started to create some pre-configured open source application servers with the basic turmeric configuration already installed. These servers are ready for testing and development purposes, and provide a guide how particular services can be deployed. They will share a common Turmeric Runtime configuration, and will allow for a much smaller WAR file to be created for the services.

The server that we support out of the box is Jetty. Specifically we are currently providing a pre-configured Jetty 7.4.5 application server configuration for Turmeric SOA, with a sample echoservice deployed. Currently there is no binary to be downloaded, but during the next release cycle of Turmeric SOA we will be providing this binary distribution for download as well.

The source repository is available on GitHub, with simple instructions on how to get started. The initial version uses the released Turmeric SOA 1.0.0 runtime.

To build the distribution and sample war yourself, follow these basic steps.

Clone the repository from github
Make sure you have the settings.xml deployed to your .m2 directory or saved as a file somewhere.
Install Maven 3.0 if not already installed.
Change to the directory you cloned maven, and type: mvn clean install

If you saved the settings.xml file to your hard drive, you can use the alternative form:

mvn clean install -s path/to/settings.xml

That is it. The binary distribution for the jetty-turmeric appserver will be located in the app-server/jetty-turmeric/target directory. Just unzip and follow the rest of the instructions in the README file for the project repository.

Going forward, we are open to community contributions to support deploying and running Turmeric SOA for other application servers. If you want something else supported, please feel free to fork the project and provide patches back.

Update: Development Snapshots of the jetty distribution can be downloaded from here.