RSS

Category Archives: Architektur

Maven and the magic of profiles

Maven and the magic of profiles

POI4XPages has a module called poi.assembly. This module builds the final ZIP file which can be uploaded to the OpenNTF website. One step in the assembly is that the module downloads the source code direct from github. This step takes a lot of time, so each mvn clean build takes a lot of time, because the assembly line is also executed. Fortunately Maven has a concept called profiles. Maven let you define different profiles. In the POI4XPages case, I’ve built two different profiles, which contains different set of modules:

200Each profile has its own id tag. The default_no_assembly profile is activated by default. The <activation> markup let you activate also profile by defining environment variables.

I’ve now to different run configuration in my eclipse client. To run the default profile, I use the following:

201

But if I need the assembly profile, I use the following configuration:

202

Merry christmas!

 
Leave a comment

Posted by on December 24, 2014 in Architektur, Java, Maven, OpenNTF, POI4XPages, XPages

 

Tags:

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

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:

150

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:

151

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

152And we have a new project.

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

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

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

153The 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:

154Now 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.

155

Let’s write the first Test:

156

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

160

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

161

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

162

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

163

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)164

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)

165

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).

166

We build also a dummy implementation of “convert2DocumentFromStream”. 167

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

168

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

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

 
Leave a comment

Posted by on December 23, 2014 in Architektur, Java, Maven, XPages

 

Tags: ,

A word about Maven

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 🙂 )

 
Leave a comment

Posted by on December 23, 2014 in Architektur, Maven

 

Tags:

Ready for todays webinar about OpenNTF Essentials?

I hope that you have already dowloaded OpenNTF Essentials and at least installed on your development computer. If not, it’s a 5 minute job as you can see in this youtube video http://youtu.be/EUrLfJcCQhY (starting 12:00).

In Todays webinar, Mark will cover some cool stuff about debugging and Nathan takes a deep dive into the OpenNTF Domino API. My part will be about some cool @nnotations. Imagine this:

Your are writing a call center application and you have designed the “Call” object as a java object according the java bean specification. With the ObjectData Source from the ExtLib are you know ready to edit each field of this java object, but now you have to save….. and read …. and delete ….. the object from the database.

I will show you in todays webinar how you can do this with writing only “3 or 4” lines of code 🙂

I hope you will join us, today 10:30 EST, register now!

 
Leave a comment

Posted by on December 12, 2013 in Architektur, Design Pattern, Domino, Java, OpenNTF, XPT

 

The “ninja-style” programming model by WebGate

First I’ve to excuse that we are so selfish to call our programming model ninja-style. It was happened based on the fact, that we have programmed ninjas in internal programming course. But the term ninja-style was established and if you gave something a name, it’s very hard to change it (Maybe you have seen Monster.Inc by Pixar, then you know what I mean).

Our intention is to make programming for XPages as much fun as possible.  And fun means in the case of programming: Having success, with less of effort and stress.

But the ninja-style has also to do with leaving the comfort zone and go out from this protected workshop in which the most of the domino developers where living. XPages requires a complete new set of skills. On the front end part are you faced with: HTML5, JavaScript, CSS, DOJO (and that’s only the beginning) and of course SSJS for the binding part. On the backend is Java the most required skills, that you should have. But you have also to learn about data sources, controls, data binding and something called JSF life-cycle.

Definitely a lot of topics to cover and the most of us are not geniuses, specially universal genius. It’s a matter of fact that it is easier to split and separate the topics. Because of this we have introduced the N-Tier architecture to our programming model. We have separated the front end stuff, from the back-end stuff.

The front end covers all the presentation (Presentation Layer)

Typically our front end developers are brilliant in arranging all the controls in the XPages and they are mostly virtuous in JavaScript, CSS and Dojo. They know about the “beans” as far as they have to know how to use them as API to the model and the business logic. They don’t care, how object are loaded and stored, they don’t care about how processes and logic are executed, as long all is working correct.

The backend covers all the model and business logic (Business logic Layer)

The back-end guys do all the brilliant stuff with the model of the data and all the processes. Mostly they are Java Cracks or on the way to it. They care about good backend performance and have read the book “design pattern” by the gang of for. No interface and connection to any backend is to complex for them, but do not let them do any HTML stuff.

But where are the storage guys?

At this point, some of the core features of the XPT cames to action. The DSS of the XPT solves all the storage stuff.

But keep this: Having success with XPages has to be about simplification. Our first step was to separate front end from back-end.

To be continued >>>

Christian

 

Tags: , ,

<xpt:….> – The XPages Tookit – Beta1 released

We have released an early beta of the XPages Toolkit, called beta1 on OpenNTF. A short time before I was going to the hospital for a heart revision task :). But the XPages Toolkit need some explanations about the why and what.

xptStartScreenshot

The XPages Toolkit (in short XPT) is a extendable Extension to the XPages Runtime and the Extension Library. The XPT contains a strong core for a programming model that we have introduced at WebGate as the ninja-style. I will blog later this week about this programming model and I will also make some snippets to this available.

But what contains the XPT:

  • The core (for the ninja-style / hope this name is not protected)
  • RSS Datasource and UIControl -> a ready to use UI-Element so display RSS Feeds
  • Read and write Access to properties files
  • Some missing OneUI Elements (like the aboutbox, the welcomebox and the tipbox)
  • And the XPages Agents with ready to use UI Elements and a replacment for the agents manager

And it is extendable. We have designed the XPT to make it easy to plugin other solutions. I will cover this topic also in a separate blog post. But in short, I think there are some many good things available under apache licence. Or think about the charting in dojox, its one of the things that I miss as a good UI Control. I know that there is a great OpenNTF project available from Julian Buss (YouAtNotes xCharting), but why not integrate the code into a plugin?

All the best
Christian

PS: Heart revision task was successfully completed and I have a good recovery time.

 
1 Comment

Posted by on September 23, 2013 in Architektur, OpenNTF, XPages, XPT

 

Tags: , ,

Accessing Beans from Java Code in XPages (learned by Reading the SourceCode of the ExtensionLibrary)

Hello Java and XPages Fans

During our work for the myWebGate 2.0 OpenNTF Edition i was faced with a very simple Problem. I had to access a public method in one of our managed beans. This managed beans are designed to act as session facade. So the bean name is directory bean and the scope is session. The ClassName is based on our internal guidlines DirectorySessionFasade.

In this class, is a method called getMySelf() witch gives me some information about my current user in context of the myWebGate Framework. The powerfull thing about managed beans is, that the object exists only one time baed on the scope, in this case one time each session.

For our activtystream implementation I have to acces this getMySelf() methode, because all my relations are stored in the returning object. A short google search doesnt help, but I rember that I’ve ready a pattern in the ExtensionLibrary, that maby can help. An voilaz there it was, written by Phillip Riand, I found some thing that I changed to this for my situation:

public static final String BEAN_NAME = “directoryBean”; //$NON-NLS-1$
    
public static DirectorySessionFacade get(FacesContext context) {
        DirectorySessionFacade bean = (DirectorySessionFacade)context.getApplication().getVariableResolver().resolveVariable(context, BEAN_NAME);
        return bean;
    }
    
    public static DirectorySessionFacade get() {
        return get(FacesContext.getCurrentInstance());
    }

This simple codesnipped gives you the capability to execute DirectorySessionFacade.get().getMySelf(). The DirectorySessionFacade.get() Code calls the get( FacesContext context() and there the inmemory Variable directoryBean can be accessed.

What a simple construct to access the same instance in java as in the SSJS and XPAGES. Thanks to IBM for sharing the ExtensionLibrary as OpenSource.