Using AntRun to run a Maven plugin on multiple files (if the plugin only allows 1 file at a time)

So, i was dealing with a plugin the other day that did not allow multiple declaration of files. Then i figured that Maven has a Maven run, that allows us to code a script to do it.

<properties>
...
    <joynr.generator.fidl.file>placeholder</joynr.generator.fidl.file>
...
</properties>

<plugins>
 ...
  <plugin>
    <groupId>io.joynr.tools.generator</groupId>
    <artifactId>joynr-generator-maven-plugin</artifactId>
    <version>${joynr.version}</version>

    <configuration>
      <model>${joynr.generator.fidl.file}</model>
      <generationLanguage>java</generationLanguage>
      <outputPath>${basedir}/src/main/generated-java</outputPath>
      <addVersionTo>package</addVersionTo>
    </configuration>
    
    <dependencies>
      <dependency>
        <groupId>io.joynr.tools.generator</groupId>
        <artifactId>java-generator</artifactId>
        <version>${joynr.version}</version>
      </dependency>
    </dependencies>
  </plugin>

  <plugin>
    <artifactId>maven-antrun-plugin</artifactId>
    <version>3.0.0</version>

    <executions>
      <execution>
        <phase>generate-sources</phase>
        <configuration>
          <target name="Generate Joynr Java artifacts from FIDL files">
            <apply executable="mvn" parallel="false">
              <arg value="io.joynr.tools.generator:joynr-generator-maven-plugin:generate" />
              <srcfile prefix="-Djoynr.generator.fidl.file=" />
              <fileset dir="src/main/resources">
                <patternset>
                  <include name="**/*.fidl" />
                </patternset>
              </fileset>
            </apply>
          </target>
        </configuration>
        <goals>
          <goal>run</goal>
        </goals>
      </execution>
    </executions>
  </plugin>
 ...
</plugins>

Let me explain a bit of what is happening in the above code: I'm declaring a variable that can be set from the command line environment using -Dvariable=value. Then i proceed to configure all the fixed parameters to the target plugin (in this case joynr-generator-maven-plugin), and then, i configure the Ant Run Plugin to run Maven for each FIDL file that it finds on a particular folder with more advanced filters (include/exclude).

Happy coding!

How to Mavenize a Visual Studio project

Since i was so used to work with Maven, due to past Java+Maven experiences, when i was asked to work in C# i felt something was amiss.

Here are my reasons:

1. The capability of building the solution in the Windows command line (without the need to open Visual Studio IDE)
2. Being able to build some parts of the project including dependencies
3. Being able to run test suites during the build
4. Provide an automated solution that any member of the team should be able to build/test/run with a single command
5. Integrate the automated solution with Jenkins

I don't know if Microsoft has their own Continuous Integration server/service, but i managed to come up with a pretty elegant solution for what i needed using Open Source/Publicly available software such as Maven/Jenkins, and so, i decided to share.

As usual, i will provide the sources of this project here, so you can download and inspect the sources for yourself, and adapt it to your needs.

Here is a recipe of how to build a new project from the ground up, as well as a showcase of what can be achieved using this set of technologies.

First off, lets create a new Solution/Project. In this case, i've created a WebAPI 2.0 project plus a test project that will be used to test if the WebServices are on-line or not (can also be used to test if the WebServices are working as expected)

This is a pretty standard process, and i will not go into the details on how to create this. I just used the Visual Studio wizards to help me create these 2 projects.

As you can see there is a HealthInfoController and a HealthInfoControllerTest. The first is the WebService we want to test, and the latter is the test. Note that, the test project does not contain any reference to the WebApp project. This means the WebApp.Tests build will not trigger a build of WebApp on the VisualStudio IDE, but it also means that the WebApp.Tests has no access to the WebApp internals, and cannot access the WebApp namespace.

The WebApp.Tests is therefore, an Integration Test project, not a Unit Test project. This means, we have to run WebApp on the IIS Server before starting the test suite.

After you have a buildable solution and tests, we need to add Maven artifacts to the solution, in order to be able to run this as a Maven project.

So, we need a file with instructions on how to start the IIS Server, called iis_express_start.bat. A pre-integration and post-integration scripts that will be used to launch and shutdown the IIS Server running as a child process. And we need a pom.xml and corresponding hierarchy in order to orchestrate this project as an IIS integration test project for Maven.


The Maven artifacts in the root directory include the following:

• pom.xml - Root description of the Mavenized project
• module.xml - Skeleton POM descriptor for each of the projects that we want to build and produce binary libraries (DLL's)
• packageManager.xml - Maven descriptor for NuGet package management resolution
• test_module.xml - skeleton POM descriptor for unit tests
• test_module_iis.xml - skeleton POM descriptor for IIS server integration tests

As you can see, all the build + tests can be done from Maven, without the need to start Visual Studio. I can even edit the files using notepad if i'm in a rush.

Here is what a build of this project looks like:

Happy coding!

Status update for 2018/2019

So, this year i made no posts to this blog, but i did not forgot about it :)

I've been making contributions on Github, check them out here!

In 2019 i'm hoping to post new articles about how to Mavenize your Visual Studio solution and integrate it with Jenkins :)

Have a happy 2019!

Bashttpd - Yes! an HTTP daemon written for bash!

Last week i received a request for a web page prototype for an embedded system that i'm working on. Not wanting to go through the painstaking procedure of compiling all artifacts for a full fledged HTTPd daemon such as Lighttpd server, and because it is a prototype, it will be run in a controlled environment... I decided to say: hey, perhaps i could do it in bash! Why not? I just have to parse the request directory/file, and serve the file to the user...

I've started developing, but then it hit me: Why do it before looking for it? I can't be the only one thinking about this. And i googled this: https://github.com/avleen/bashttpd

Behold 'The holy grail'!

I've started investigating the sources and decided to try it out. Turns out, it is quite impressive what it can do and the speed it does for 'development' environments. Sure i don't recommend this for production environments, but if you ever have to do a prototype and have limited resources, look no further: This is a powerful candidate!

Of course that 'With great power comes great responsibility': You can do a lot of powerful stuff with this, but beware: put it in an unsafe environment and a 'monster' will be unleashed! Hackers can do all kinds of nasty stuff with it :D

Here is my fork: https://github.com/rochajoel/bashttpd

Happy Coding!

RESTful WebServices Tutorial with Maven+Tomcat+Failsafe

Technology credits:

Apache Maven & Failsafe

Apache Tomcat

Jersey

Disclosure

Before you start reading further: Keep in mind that this is a work in progress, and although i'm a "Systems&Informatics Engineer" i consider myself a novice programmer. If you have any question you don't see answered here, please leave your comment on the section below to help me improve this article.
Also, you should be aware that this post was a result of a lot of work. If you like it, please feel free to show your appreciation by offering me a cup of coffee through paypal and/or add value to this article by sharing your knowledge.

Objectives of this tutorial:

• To establish a standard "archetype" for RESTful JAX-WS WebServices development
• To demonstrate how a Maven project can build-deploy-test a RESTful WebService

Pre-requisites:

• You have knowledge on Plain Old Java Objects (POJO's) development.
• You understand the concept of WebService, it's benefits and are able to decide when and how it should be used.
• You understand the diference between a RESTful WebService and a SOAP WebService
• You understand the concept of "server side container" and it's purpose.
• You have downloaded and installed the Maven build software, or you are using Maven through the m2e Eclipse plug-in

The sources for this project are available here. Just unzip it and build it using 'mvn clean verify' (on the cmd line or 'clean verify' targets using the m2e Eclipse plugin)

Conventions over Configuration

First of all, as we will be using the Maven WAR plugin we should be aware of the project's file structure that is required by this plugin (as well as other conventions required by Maven which i won't discuss here)

As you can see from the picture above, all you need to build and deploy a RESTful WebService to Tomcat are this 4 files (the ones above with the SVN icon). Be aware that the Maven WAR plugin requires you to have the web.xml at that specific location so that they can be included in the deployment to Tomcat. We will talk about each file in the following sections.

What should the pom.xml contain?

The pom.xml is the Maven build file and contains all the required configurations to build, deploy and test the project. In this tutorial, it only contains the configurations that are absolutely essential for this project to pass the tests. I will talk here about the essentials of the configuration that prepare the WAR for proper Tomcat deployment and the Failsafe plug-in.

Get ready for WAR

So... What do we need to get started? First of all let's start by calling some friends to the WAR :P We will need some "dependencies" to resolve our classpath needs:
This is the Jersey Servlet that will use our classes to generate URLs and forward the REST requests to the appropriate classes. This will be more clear when we configure the web.xml

Other than this, we just need to create the POJO files and annotate them with the appropriate declarations to be processed by Jersey

The WebService

In here i use a JSONObject return instead of a plain String so that this can be more than just the simple 'Hello World!' example. JSONObjects allow us to transfer complex datatypes over a standard data type language similar to XML but with a smaller footprint. This is great when you want to improve communications throughput or when working with constrained devices such as mobile phones or others. This also allows you to see that if you develop your own datatypes by extending from JSONObject you can return them like this and Jersey will take care of the serialization for you :)
Also: We can also receive JSONObjects as a parameter they work the same as a String, it's just a matter of URL encoding them on the request

That (aside from the web.xml configuration) will be all we need to run our first RESTful WebService
But don't trust me, let's test it using the Maven Failsafe&Tomcat plugins! :)

Integration test programmatically

To ensure the code above, and the integration of all technologies work as expected, lets develop a simple set of tests to ensure basic communication is as expected.

We will create tests started with IT*.java or ended in *IT.java or *ITCase.java. This classes are just like standard JUnit tests, only the filename pattern is different. The configuration is in the Maven POM but this time i wont go into details. You can see other tutorials that talk about this here

The WebService configuration files

I acknowledge that it takes quite a configuration effort to put the WebService "up and running" but this is the last step. Take it easy :)

The web.xml: What are we saying here?
First of all, a WebService is not a Servlet. A servlet is the basic "entrance point" for any J2EE application. It's like a Main class for J2SE. Because of that, we must tell Tomcat which Servlet do we want him to invoke at what address. As we didn't develop any, we must use one from another provider :) This is were the com.sun.jersey.spi.container.servlet.ServletContainer comes along to save our back. Next, we configure it to inspect all classes in ext.domain.pkg and gather information from the annotations we provided earlier.
That's it! Just run your 'mvn clean verify' and you should be able to "succed your build" with 0 failures.

Happy Coding!

Mozilla Build: My first accepted contribution to an open source project

It began in 2011, i started to review some Mozilla Build code and noticed that some scripts could be improved.

A couple of years later, they asked me if i could re-do the changes, and so i did. Although this change does not have a clearly visible impact on the Mozilla products, it improves the start up of the build environment for developers.

Here is a link to the Mozilla repository with the changes:
http://hg.mozilla.org/mozilla-build/rev/587f5ce581e5

This change as already been superseeded due to some recent developments, but some changes remained. Hurray!

Simple Maven archetype for Axis2 web services with Tomcat embedded

Technology credits:

Apache Maven & Failsafe

Apache Tomcat

Apache Axis2

Disclosure

Before you start reading further: Keep in mind that this is a work in progress, and although i'm a "Systems&Informatics Engineer" i consider myself a novice programmer. If you have any question you don't see answered here, please leave your comment on the section below to help me improve this article.
Also, you should be aware that this post was a result of a lot of work. If you like it, please feel free to show your appreciation by offering me a cup of coffee through paypal and/or add value to this article by sharing your knowledge.

Apache Axis2 architecture

If you check out some of my older posts, such as this you should by now be wondering whats the deal with Axis2. You can already deploy to Tomcat your own WebServices, so why bother have Axis2 on your WebServices?

Well... Axis2 deploys itself to your 'Application Server' (Tomcat or others) and only then will you be able to deploy your WebService in a special *.AAR format. This allows your 'Application Server Administrator' to deploy your WebApplication only once, give you the required privileges, and let you be responsible for upgrading/updating your own webservices.

This means (as you probably are guessing) that on the Maven building environment, there must be directives to:

• Build an AAR instead of a WAR
• Deploy the Axis2.WAR on Tomcat
• Deploy your AAR on the Axis2.WAR WebApplication

The Maven Project

I've finally sum up the time to compile a simple but fully functional Maven Project for this post and is available here for your convenience.

Project Structure

The main differences from previous tutorials are on the Java implementation class (notice i've used my_method instead of myMethod for the method name, this was not an arbitrary choice, but a consequence of a drawback of Axis2).
Second, the web.xml reflects the fact that we'll be using the Axis2 container instead of a standalone container.
And third: the deep nesting of folders to define the services.xml configuration file under WEB-INF folder.
Everything else is pretty much the same as in this tutorial.

Since you have access to the project's source code, I'll leave it up to you to discover its internals.
For any questions, just drop me an email.

Happy coding! :)