RSS

Category Archives: Java

Watson Workspace & Work Services needs Code, Code, Code, Community, Code, Code and even more Code and Community….

IBM has give us glimpse of their plans for the future. IBM has understand the power of conversation. Everything mankind has ever done is based on conversation. Ideas, Research, Progress, Contracts, Family, Love and even Dispute, Conflicts and Wars are based on Conversation. Conversations are the base of our human being. You can believe it or not, but God himself use conversation as part of his creation process. God speaks and thing happens. And so we do to. We speak, make plans and then things happens. But Conversation is a chaotic process. Sometimes it follows some rules, but that’s not the nature of conversation. Imagine computer could follow our conversation, could summaries, could give us advises what kind of action we have to do to fulfill our plans. How powerful would this kind of cognitive capabilities be.

Having BigData and the capability to analyse this data is great. Making strong decision based on this result, also great and needed in our world. But understanding conversations…. that’s a complete different story. And IBM has made the first move to enter to this story by releasing the Preview of IBM Watson Workspace. And with the release of IBM Watson Workspace, we as Developers became also access to the public API. And as Developers, we ask always for documentation, and yes there is documentation. But take a look at the following conversation that Paul Withers and I had during developing our first prototype:

The fun part was, that all the info that I gave to Paul came to me by two approaches.

I had read the documentation
I had tinkered with the API and found the solution by myself

But I’ve als to give credits to Luis Benitez who convinced my with his explanations that the way I’ve done it, was the right way. My learning curve and also Paul’s Learning curve where part of a conversation and also part of a community approach.

To unleash the power of Watson Workspace its a must to have a community. Watson Workspace is not “another chat tool”, it should become the place where conversations happens and conversations can be analyzed with the cognitive capabilities of Watson Work Services.

But how to build a community? Do we have to multiply the conversation that Luis, Paul and I had? Writing Blog Posts? What is the UNIQUE and UNIVERSAL Language of an Open Source Community? You wont belief. It’s Code. Code, Samples, Snippets. Code is one of the purest form of conversation. If you write a Unit test, you express yourself what you expect to see that your code will do. To learn an API, we do not need to understand all the concepts and Ideas at first, we need simple, nice and well designed code.

Lets start to build code! Let’s start build a community! Here is my first code sample in Python: https://github.com/OpenCode4Workspace/WWAPI

Have Fun

Christian

One last thing. Watch this video and try to understand why I want to be more focused on providing code:

Leave a comment

Posted by guedebyte on October 28, 2016 in Community, Development, IBM, Java, OpenNTF

XPages Designer Plugin 4 Eclipse – The Basics!

02 Apr

First, and please keep it in mind, I’m talking about XPages. Nothing more, nothing else. Some years ago, in an open discussion between the XPages Community and the XPages Development Team, we agreed that it would have a huge value, to have a XPages Designer which is based on the latest and greatest Eclipse Release and can be installed as Plugin / Addon.

But where to start? Try to make the IBM Domino Designer loadable from Eclipse? Extract the relevant Plugins from the IBM Domino Designer and make them installable? Or? All this approaches seems to be a pain. So I started to RETHINK the whole stuff.

What does the IBM Domino Designer make, when he has to build an XPages Application?

Convert all XPages / CustomControls to Java Files
Compile all Java Files to classes
Attach all the results in the .NSF Files on the right place

You think this is too simple? Things are become complex without our help 🙂 But let’s assume that this is the way how the IBM Domino Designer builds the XPages Stuff. If you want to proof it, open a Notes Application in the navigator view in the IBM Domino Designer and you will find the following:

xpde-01

Adminsettings.xsp becomse Adminsettings.java (xsp Package) and then Adminsettings.class & Adminsettings$AdminsettingsPage.class

So how does the IBM Domino Designer this? And is there some special knowledge needed to figure this out? I try to explain it with a simple example. The XPages is an XML file, which describes the combination of Components. Lets assume we have in that file the component . The IBM Domino Designer parse this file and will hit the tag. Based on the xp the IBM Domino Designer searchs all Plugins that are responsible for the XP prefix. If you build your own Plugin, you have to specify an own namespace, like wgcpoi. wgcpoi holds all tags for POI4XPages. But lets go on with the xp:panel. It will figure out which plugin is responsible and the .xsp-config file in the plugin describes what with a panel tag has to be done. It will figure out that a panel tag is hold be a component and it will also give back the name of the class that is responsible for the xp:panel.

With the knowledge of the class name, the IBM Domino Designer build a function that creates a UIComponent (the root of all components) and instantiate the class like this

private UIComponent createPanel(....) {
         UIPanelEx panel = new UIPanelEx();
         panel.setId("myId");
         panel.setStyleClass("superstyle");
         return panel;
}

For each property that is defined in the XML there is a corresponding setter defined in the .xsp-conf. This is the way how the designer builds the Java .class. I know it sounds simple, but there is some more complexity.

Now this class is be compiled and then the whole package is stored in the .NSF.

Already open sourced!

The fun part now is, that the transformation of .xsp -> .java is already open sourced. It is in the XPages Bazaar available.

XPages Designer Plugin 4 Eclipse

Based on all this I’ve builded an Eclipse Plugin that does the following:

Build an NSF like project structure
Transform .xsp -> .java
Compile .java -> .class
Build a .xpjar of all the files and publish this to a IBM Domino Server with some build instructions

On the IBM Domino Server runs a Plugin that receives the .xpjar File (via http) and does

Parse the build instructions (JSON)
Access or create the target Database
Loop thru the .xpjar and produce the neede “Note” Documents in the NSF to store the produced and compiled files.

While I get you some Insides now, I’m working on the first Alpha release. All I’ve pointed out works like a charm, but the preparation of the environment is not “Alpha” ready. But stay tuned 😉

And have fun

Christian

3 Comments

Posted by guedebyte on April 2, 2016 in Java, OpenNTF, XPages

Building NSF using the maven headlessdesigner plugin from OpenNTF

26 Mar

Sometimes I think it would be good to have an assistant who does finalize all my tasks. Specially the tasks, I was not aware that I did not deliver all information to the community. And what a shame, one of my most favorite project was such an unfinished business. The real bad thing was, I didn’t blog about how to use all the code I’ve developed while I was last time in Ireland to meet my friends at IBM.

But a nice blog post by Eric McCormick (https://edm00se.io/xpages/headless-dde-and-jenkins/) reminds me about my duties. Now Eric, time to explain you how simple you can build full XPages Applications with the headlessdesigner-maven-plugin:

The Project Setup

I’m using the JUnit4XPages Project to explain how to build the example database with the headlessdesigner-maven-plugin. This project is fully mavenized and uses the tycho plugins to build the plugins, feature and the updatesite. The project is with a parent – child structure organized. The following stuff in the parent is relevant for the building of the XPages Application:

ddehd.designerexec and ddehd.notesdata are in this example “externalized” to the environment variables notes-designer and notes-data. Both values are import to invoke the headlessdesigner-maven-plugin. With mvn clean install -Dnotes-designer= -Dnotes-data= can the build be customized.

There is an additional profile, which is only executed if the notes-designer variable is seted. This has the good behavior, that the NSF is only build, if you have specified the location of your IBM Domino Designer. The module org.openntf.junit.odp is with purpose at the end of the sequence, because we need the updatesite first.

The org.openntf.junit.odp contains in the sub directory “on-disk-project” the on-disk representation of the NSF, which means all the code. This Code need the org.openntf.junit.xsp.feature installed on the IBM Domino Designer environment to build. This is the reason, why we build the updatesite before.

The headlessdesigner-maven-plugin supports the deployment of the feature. The pom.xml for org.openntf.junit.xsp.odp looks like this:

ddehd.odpdirectory points to the on-disk-project. Pro Tip: Take this in a subdirectory otherwise the IBM Domino Designer eats your pom.xml ;).

ddehd.targetdatabasename contains the name of your resulting database.

maven.build.timestamp.format is used to build a timestamp that matches the format of the feature.

feature.url points to the file location of the updatesite. This is very powerful, because you can also point to a URL and I think also to a p2 repository. This means for XPages Application, you are capable to point to all the updatesites of the dependencies you have (yes there is a reason why every new plugin project at OpenNTF should have a p2 repository, and why we push them on the openntf.org website, more about this later)

feature.version calculates the current version number. We are using for this the org.codehouse.mojo / build-helper-maven-plugin

In the plugins section is the org.openntf.maven / headlessdesigner-maven-plugin with all additional configurations. I want to point to the features / feature block, where you can define all the features that has to be installed for the headless designer to be able to build your application.

templateBuildNames and templateBuildVersion is a powerful add-on from Jesse Gallagher and results in the following information on the database:

With all that configurations, I’m now able to start the build direct from my eclipse

And it will build the full project:

Done…. (btw. the headlessdesigner-maven-plugin is available in the maven central repository, no installation needed for this, only the IBM Domino Designer must be installed).

Have Fun!

Christian

2 Comments

Posted by guedebyte on March 26, 2016 in Java, Maven, OpenNTF, XPages

Another nice journey with Maven – or how to sign a jar file

26 Nov

Yes I love Maven, for sure. Maven gives you the capability to build project everytime the same and in every environment. I often explain Maven as a brilliant facility manager, who is able to put all the build, test, package and delivery instruments togehter and then build all the stuff according to your building instructions.

But what if I have to sign a JAR file with a code signer certificat? And this certificate is owned by another company, and they will not provide this certifacte to me. How can I setup a project with Maven that let me build and sign the project by a selfsigned certifacte, while my customer other my build server can use the code cert?

First step…

I need a selfsigned code certificat in a keystore. Read the following tutorial on how you can do this http://www.jade-cheng.com/uh/ta/signed-applet-tutorial/. Add this keystore now to the project. My keystore is named awfstore

Once we have done this, let the Maven project know that we want to sign the jar file by adding the following snipped to the build section in the pom.xml.

mj1

We are using the “maven-jarsigner-plugin”. The configuration is done by some variables, starting with “sign.”. The values for this variables are definied in the properties:

mj2

You can build now the project and it will sign your project with the certificat awf from the awfstore. Replace this values, with your values. But how can we achieve that a Buildserver like Jenkins or Atlassian Bamboo can use other values?

Add the following definition to your pom.xml:

mj5

This will activate the Profile compSignerKeyStore, which will override the variables with new settings. This settings can be placed in the setting.xml of your Buildserver or of any developer. It can looks like this:

mj4

Have fun

Christian

Leave a comment

Posted by guedebyte on November 26, 2015 in Java, Maven, OpenNTF

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

31 Dec

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”

Leave a comment

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

Tags: Maven

Maven and the magic of profiles

24 Dec

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:

Each 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:

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

Merry christmas!

Leave a comment

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

Tags: Maven Profiles

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

Leave a comment

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

Tags: Maven, OpenNTF

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

Maven and XPages Plugin – From Scratch / Part I – The Parent

22 Dec

Is it a good Idea to start writing a blog series about Maven, XPages Plugin with the topic “The Parent” on your birthday? I don’t know but the birthday reminds me a lot about my parents. About my father and mother who gave me the base structure of my life and lot of my being. But also my heavenly father, the creator of heaven and earth. The same it is with “The parent” in a Maven based project.

But let me first explain something about Maven. Maven is an absolute brilliant idea. Maven is a bit like God. Maven is an Open Build Tool. Maven can create everything you can imagine…. or Maven ban build nothing. The architecture of Maven is plugin (not to be confused with OSGI plugin or FireFox plugins) based. This means that Maven needs a Plugin for each type of code or project Maven can build. But at this point there are no boundaries.

The POM.xml contains the magic….. or it’s simply the build plan

Like with Lego, it is good to have a build plan. Software is become so complex that it needs build instructions. The main File for this build instructions is the pom.xm. One of the strength of Maven is, that it can build different modules in the right order and combine it to a ship able package. Because of that, there is a Parent file needed. This parent file is normally in the root folder of the Maven project structure. To illustrate this process, I’ve built a folder called D:\EGit\org.openntf.base. I’ve also setup Eclipse Kepler, which contains the m2eclipse Plugin (the Maven integration 4 Eclipse). Unlike to other tutorial, I try to explain all steps directly from Eclipse, without any command line magic 😉

1. Create a new Maven Project

Select “Create a simple project” and select the project location

Give a group ID like you know it from the OSGI Plugin development and also an artifact ID (The artifact ID will be the project name)

Please select “POM” as Packaging Type. This type is used for parent POM files or for pom files that contains instructions for a group of other modules

2. Setup the POM.xml File for our modules

Please open the pom.xml file and add some properties:

For all text sample that you now use, please refer to this file -> https://github.com/OpenNTF/BuildAndTestPattern4Xpages/blob/develop/testpatterns/org.openntf.junit.xsp.parent/pom.xml and copy / paste the fragments.

The properties contain values, which are used in this pom or the child poms.

tycho-version is the version of the Tycho Framework
compiler is the version of the java compiler
project.build.sourceEncoding and project.reporting.outputEncoding controls the charset of the build / reporting process

The repositories

Maven is an Open Build platform and we are using the Tycho Framework to build the Eclipse Plugins and Features. For this reason it is important to have a repository defined, where all the plugins for the compilation and test cycle are. We define 2 repository. The first repository called “notes” points to the local location of the IBM Domino UpdateSite for BuildManagement. This local location can be different on each developer machine. For this reason I use a ${notes-platform} variable, which can be defined outside. I will show later, how I do this. It is definitely needed to do so, if your plugin should be build via Jenkins or Bamboo.

The build section

As you have already recognized, the pom.xml has several section, which represents parts of the build/life-cycle. We start now to pre fill the build section. The first plugin, is the java compiler. As you see in the definition, the section starts with …. each plugin has its own section. The compiler has also ${compiler} variables, which points back to the properties. This means that all compilations based on the version 1.6 and we can at one point change this to a more accurate Java version, as soon, as Domino supports JDK 1.7 or 1.8

The Tycho Plugins!

The next plugins, that we add are the Tycho plugins. This plugins, developed by SAP helps us to build eclipse-plugins, eclipse-features and eclipse-updatesites.

One of the important parts of the Tycho plugins is the target-plattform-configuration. I wanna point specially to the extra-requirements because this section contains the magic to include the notes.jar! It points back to a part of the notes repository. 008 And last, but not least some stuff to complete the build configuration

All done for the <plugins> section….

… BUT we are working with eclipse

And I hope that I’ve understood this part right, but Eclipse needs some instructions how to manage all the plugins, for this we have the following definition, which gives clear instructions to org.eclipse.m2e how to handle maven and some build jobs.

Yes and now we are ready to build our first plugin in this project…..

2 Comments

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

Reading and writing Resource Bundles – an alternative approach

06 Sep

Dan Soares explains at NotesIn9 a nice way to read and write resource bundles. It’s a good read so enjoy his work. I was also faced with the problem of reading and a specially writing properties files, because Switzerland is multilingual and my idea was to give the power of translation to the hands of the business project leaders. But how to write properties files, and how to do it in am more productive way? I did go the same way as Dan, I did also find some sample from Sven Hasselbach, but the I asked my self, how can I provide this in an easy to consume way to my developers and to the community. This was the birth of a new part in the XPages Toolkit.

Btw. we started with the development of the XPages Tookit one year before we mad it public available on OpenNTF. And we want to be shure that we provide something useful and approved by our own developer team.

The result is a very easy to use API (requirement: Install the XPages Toolkit):

SSJS:
to get the properties as java.util.Properties object:
var properties = xptPropertiesBean.getProperties( databaseFilePath,
                               fileNameOfyourProperties );
to save the properties:
var success = xptPropertiesBean.saveProperties( databaseFilePath, 
                               fileNameOfYourProperties, properties);

Or to use in Java:
XPTPropertiesBean bean = org.openntf.xpt.properties.beans.XPTPropertiesBean.get();
Properties props = bean.getProperties( databaseFilePath, 
                                fileNameOfyourProperties ); 
int success = bean.saveProperties( databaseFilePath, 
                                fileNameOfYourProperties, properties);

But be aware of the following. Each change to properties seems to reload your application on the server.

To stay informed about the recent development on the XPages Toolkit, please register here and discuss ideas and give feedback.

Leave a comment

Posted by guedebyte on September 6, 2014 in Domino, Java, OpenNTF, XPages

guedebyte

Category Archives: Java

Watson Workspace & Work Services needs Code, Code, Code, Community, Code, Code and even more Code and Community….

XPages Designer Plugin 4 Eclipse – The Basics!

What does the IBM Domino Designer make, when he has to build an XPages Application?

Already open sourced!

XPages Designer Plugin 4 Eclipse

Building NSF using the maven headlessdesigner plugin from OpenNTF

Another nice journey with Maven – or how to sign a jar file

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

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

Maven and the magic of profiles

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

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

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

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

Let’s write the first Test:

JAXB Import of the domino xsd

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

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

1. Build a Maven module

Create some files….

Give the Plugin an Activator

Build a run configuration to build the project with Maven

Maven and XPages Plugin – From Scratch / Part I – The Parent

The POM.xml contains the magic….. or it’s simply the build plan

1. Create a new Maven Project

2. Setup the POM.xml File for our modules

The repositories

The build section

The Tycho Plugins!

… BUT we are working with eclipse

Reading and writing Resource Bundles – an alternative approach

The code

Suchen

Kategorien

Archiv

Blogroll

GuedeWebGate

Meta