RSS

Tag Archives: Maven

Maven and XPages Plugin – From Scratch / Part IV The feature

While Switzerland was covered with snow, the OpenNTF Base project has made some progress. There are two new plugins, one is org.openntf.base and the other is org.openntf.base.lib.internal.

org.openntf.base contains all the stuff to register the plugin collection as an extension library and also all “Top Level” classes. org.openntf.base is designed to have all the dependencies to the XPages engine. I try to make org.openntf.base.jaxb.dxl with less dependencies to other plugins, as possible. specially not any dependency to the XPages Engine (as I sad, I TRY). My intention is to reuse the org.openntf.base.jaxb.dxl part also for Notes Client plugins.

org.openntf.base.lib.internal contains all the JAR files which will be used in the org.openntf.base package, but not exposed to the Desinger Client. Maybe there will be a org.openntf.base.lib.external plugin, which contains jars of useful java libraries, that could also be used at the Designer Client level. GSON and GUAVA are candidates for this.

Btw. the org.openntf.base.jaxb.dxl.testsuite is also moved to org.openntf.base.testsuite and is now a fragment of org.openntf.base

Ready for the next move? ….. we need a feature to bring all the plugins under one umbrella. (Btw. the testsuite Fragment will not be part of this feature!)

It all begins with a new ………. module!

And the packaging type of this plugin is “eclipse-feature”

Once we have the new project, we need to files:

feature.xml
build.properties

Lets open feature.xml and fill the following stuff into the editor:

On the plugins tab, please add all the plugins you need

And on the information tab, please fill at least the Copyright Notice. Without it, you wouldn’t belive, but the feature is not loaded in the Designer Client.

And on the build tab, please select feature.xml

Check if everything is fine with your run configuration “clean install”

Maven and XPages Plugin – From Scratch / Part III – The Testsuite

23 Dec

Part I has covered the building of the parent pom.xml, Part II was about the plugin and now in Part III we talk about the test suite. It’s fair to say that this part seems not to be very interesting, but in this Part we talk also about the why.

Why do I make the org.openntf.base.jaxb.dxl plugin?

The core purpose of the jaxb.dxl plugin is to convert a DXL export of a document, or of some design elements into an object based representation. Imagine this: You have a document with 2 rich text fields, one is a traditional rich text field and the other is mime based. For some reason (like transforming the content of the rich text field to a POI document or PDF document) there is an interest in the structure of this rich text field. A simple export as DXL and conversion to this java objects which are cascaded helps a lot.

Or you have this database, and you want to scan the content of all design element for a specific @Formula….. Export the database to DXL and convert it with jaxb to java object tree. And the scan the tree and analyse.

But why not start with the implementation, that sound better than testing!

Agree. Implementing is always better than writing test for the sake of writing tests. But after reading the book “Test Driven Developement” by Kent Beck, my understanding of test has changed. Tests explains what I want to do. Read the following test:

This test covers my user story “Reading a dxl-document.xml and convert it to a java object structure”. To make this test work, I’ve to writte a lot of implementation stuff, so stay tuned.

The next Maven module -> org.openntf.base.jaxb.dxl.testsuite

Again with the eclipse client:

select as packaging type “eclipse-test-plugin”:

And we have a new project.

And now repeat the following steps, like you have done for the plugin in Part II

New file called MANIFEST.MF into the folder META-INF
New file called build.properties

Open the MANIFEST.MF File and go to the MANIFEST.MF Tab and enter the following stuff:

The directive “Fragment-Host” makes this plugin to a fragment of org.openntf.base.jaxb.dxl. This is the best behavior to separate test and implementation in a plugin.

Open the build.properties File and go to the build.properties tab. Enter the following stuff:

Now is a good moment to do a right-click on the project go to Plugin-Tools and execute “Update Classpath”

Open the MANIFEST.MF again and add the following dependency. This is needed that we can start writing our test class.

Let’s write the first Test:

We have also imported the dxl-db-test.xml and the dxl-document-test.xml. This documents were produced by a nice simple DXL Export.

To make the test compile (STEP 2 in TDD), we have to import the XSD File for domino_9_0_1 and convert it to classes. We use for this the JAXB import

JAXB Import of the domino xsd

Start with menu “New” and select the JAXB Classes from Schema Wizard

Select the target project for the import (yes our plugin)

If you do not have the domino_9_0_1.xsd in a project in your workspace, you can import it from your Notes/Data directory

Please specify carefully the package, where the classes should be produced. Existing classes will be overwritten (note to myself, move the DXLActivator Class to an other package or a level up)

Select finish. The import will now generate a lot of classes.

You can now resolve the import of the Document object (yes its a …jaxb.dxl.Document object)

Time to finish the compilation problems in the test class.

Create the ConvertorFactor in the plugin (see the package that I select? It’s outside of the dxl package, because the content of this package was generated before).

We build also a dummy implementation of “convert2DocumentFromStream”.

Only one step, and we can test (with executing our runtime configuration)

We have to include the *.xml Files in our binary build. We open for this step the MANIFEST.MF and add the 2 files

Lets build the project by executing org.openntf.base clean install

Oh yes the build fails! This is total ok at this point, because our test fails, and a failing test should stop our build!

Now its time to have some fun and finalize the plugin… The next Part will cover how to build the feature and the update site

If you wanna follow the project, please watch this repository on github.com https://github.com/guedeWebGate/org.openntf.base

A word about Maven

23 Dec

When I try to explain what Maven is, then I’m using often the following picture:

Maven is a factory building with a brilliant factory manager

Imagine this: There is this empty factory building and you walk with your construction plan to the office of the factory manager. You enter the room and the factory manager takes your construction plan. He read it and then he runs to tool storage. In a short time he has all the tools to build your construction taken from the storage and build a production line.

According to your plan, he has also hired the Q & A people, which let first run some unit tests directly in the production line and also some integration tests. At the end of the whole production line is also an assembly line to build the kit that is ready to ship.

… at this point you say. “mvn clean install” and the factory manager builds the software.

The other day, you come back to the factory building with a new construction plan. And the factory manager “cleans” the building and setup a new production line for you. If he finds some tools not in the storage, he orders the tools directly from *Maven Central*. But with the same passion and quality as the day before the manager tries to build the software.

What Maven can do for you depends on your construction plan and the tools that are available

Back from the analogy:

factory building -> maven
factory manager -> mvn
construction plan -> pom.xml
tool storage -> maven repository
tools -> maven plugins

Your construction plan contains all instruction about what builder should be used, how unit testing should work, and also how the assembly should run.

And it is not some kind of magic to build your own builder. I’ve built the headless designer integration, also a builder to build complete XPages Applications. It’s only hard work, nothing more and nothing less (and also a lot of fun 🙂 )

Maven and XPages Plugin – From Scratch / Part II – The Plugin

22 Dec

The core purpose of org.openntf.base.* is to bring some core plugins to the community. This plugin could be used in conjunction with other plugins, like org.eclipse.core.runtime. The first plugin that I want to build is a JAXB representation of the domino9 dxl. This plugin should offer some basic method to convert any domino object to a java object tree based on the domino dxl definition. This could be used to explore the design of a domino database, but also to represent the content of a single rich text item.

We will focus in this part on how to build the plugin based on the parent, that we have already build in Part 1

As in Part 1, we will do the stuff again with our Eclipse Kepler IDE.

1. Build a Maven module

Go to your parent project and use “right-click” for the context menu. Browse to Maven / New Maven Module Project.

101

The module name should be the same as your plugin id (later).

While you fill out the dialog, it seems that the group id is necessary, but you can delete this later. Be sure that you specify as packaging type: eclipse-plugin. This has a huge impact on the build process and your new maven module will now be handled as eclipse-plugin.

Nice we have now created some folders and files, but unfortunately not the necessary files to handle this project as a plugin project.

Create some files….

That a plugin project is a plugin project, it needs to files.

META-INF/MANIFEST.FM
build.properties

With the right content -> so let’s build this files.

Create the META-INF Folder:

Create the MANIFEST.MF File:

Let’s open the MANIFEST.MF File with the Manifest Editor

And we do this with a right-click on the project and browse to “Plugin Tools / Open manifest”

Lets fill out some base information for the plugin.

Btw. the Version should correspond to the version in the parent’s pom file, instead of SNAPSHOT use qualifier (as the plugin would expect)

Now its a good moment to update the classpath of the plugin project (do it again with a right click on the project) and the go to Plugin Tools / Update classpath

To complete the plugin configuration, we add the dependency to org.eclipse.core.runtime

And we create the file build.properties

We open again our MANIFEST.MF and go to the last tab called build.properties.

There we complete the build.properties with the yellow marked text. (bin.includes and sources.. are needed for the whole plugin build process)

Give the Plugin an Activator

We build now the Activator class for the plugin, by building first the package and then the class.

Creating the class file

Let’s open the MANIFEST.MF again and assign the activator class

Build a run configuration to build the project with Maven

Now its time for the fun part. We build a run configuration, to execute the goal clean and install in the maven build cycle

clean will delete all genearted code
install will compile, test and package all code

Select “Maven Build” as category and click on the blank sheet to build a new run configuration

Please fill out all yellow highlighted fields. Be aware of the goals field. We define with -Dnotes-platform=file:/// the external variable ${notes-platform} for our parent pom file.

Click “Run” to check if all is builded correct the output should look like this:

1 Comment

Posted by guedebyte on December 22, 2014 in Java, Maven, OpenNTF, XPages

Tags: Eclipse, Maven, xpages

Automated build with Jenkins / Some progress

07 Apr

This saturday was dedicated to do some tests with automated build and Jenkins / Maven. Jenkins is a brilliant tool to let a server do some automated tasks. Maven is the tool which delivers a configuration language to describe how to build something. The goal of maven is to do the same thing always in the same way. For me as a highly creative person is doing the same thing always in the same way, a creativity killer. So I think Maven will be my friend, because he is doing all the annoying jobs for me.

But Maven needs some clear instructions to do his stuff right. And like Eclipse needs Maven also a clear environment to work. Based on some research on the SBT Project and with the help of my friend Google, I figured out that I need eclipse.tycho to build plugins, features and update sites. I had prior to saturday already done the following steps:

Setup of Jenkins
Setup of Maven
Setup of Git (for Grabbing the Project direct form the GitHub)

I started with the parent pom.xml file. This file contains all instructions and dependencies for all my plugin. The full file can be read here.

The important thing was to define the following repository:

<id>notes</id>

<url>${notes-platform}</url>

</repository>

</repositories>

As I sad. Maven needs a clear environment to build all the plugins and the eclipse.tycho needs a repository, where all the plugins of the domino runtime are located. Unfortunately such a repository is currently not available. So I had to create a p2 update site. This is in fact the same, as you define your eclipse development environment to use a specific target platform. See the following instruction, how I did that.

As you can see in the repository definition, I’ve nut used in the <url> tag a fix url. It’s a variable, which can be sent to Maven in the command line. This has the good impact that I can use my new update site also as a file resource. To build my POI4XPages Project, I had only to checkout all the code from git, switch to the feature/CIandMavenIntegration branch and go to the root directory of the project:

mvn clean install -Dnotes-platform=file:///D:/updatesite/site.p2/
did the job…. almost 🙂

The next problem was, that Maven uses the standard JDK as Java Environment to compile. So I toke the DominoProg/jvm folder and copied it to my build server. Then I changed the Java Home to my new jvm location. In the mean time, I had also done all the pom.xml files for the plugins. And then, the great moment happens:

Whats next….

I will now make some documentation, how I’ve setup this also on my Jenkins Server
I’ve to think, what should I do with the result of the build (assembly)
Test the same with Notes Application (Martin Pradny has made some good progress)
And learn how to test after the build 🙂 (The next annoying thing….)

1 Comment

Posted by guedebyte on April 7, 2014 in IBM, OpenNTF, Software Entwicklung

Tags: Jenkins, Jenkins Setup, Maven

guedebyte