• Anonymous
  • Login
  • Register

Welcome to OpenNTF.org

The Mission of OpenNTF is to support the open source projects hosted at OpenNTF.Org. OpenNTF provides the framework to develop open source applications which may be freely distributed.

Browse the catalogs to find the latests releases you're looking for which have been made available under the Apache license or under the GPL license. Browse the project area to find the latest project updates before they have been cleared.

OpenNTF Board of Directors – Call for Nominations

Paul Withers | 2:39:17 AM Friday, August 19, 2016 | Full Story and Comments
We invite anyone interested in participating in OpenNTF's Board of Directors to submit their names to ip-manager at openntf.org.

Employees of member organizations may be nominated as a Member Director – with a two-year term.  There are five such board positions open for election.

Contributors may be nominated as a Contributor Director – with a one year term.  There are three such board positions open for election.  

The terms of five Member Directors expire this October,  Members whose terms expire this year may, of course, run again for another two year term. They include:
Serdar Basegmez
Jesse Gallagher
Christian Guedemann
Martin Rolph
Justin Hill

The terms of the three Contributor Directors expire this year.  Again, they have the option of running again.  They include:  
Padraic Edwards
Adam Foster
Fredrik Norling

Election schedule:

Nominations open until September 16.
Circulation of Candidate Statements September 16
Voting online from September 16 to 23rd

The winners take office on Oct 13.

Last Call for Passengers who want to attend the IBM ICS Developer Competition 2016

Christian Guedemann | 6:00:34 AM Friday, June 10, 2016 | Full Story and Comments
Dear Friends

Its so amazing to see that over 10 Teams have registered to this "long term" competition. This means that we have so far over 25 participant. This is very promising! I had also the chance to see the topics, each team has chosen, but my lips are sealed with a BIG SMILE!
But not only a BIG SMILE, also some tears: The WebGate Team can not attend, because we have a conflict of Interest. As Chairman of OpenNTF, Judge in the Contest and CTO of WebGate, this would be unfair. But anyway. If you not a part of one of this Teams, this day is the last day to register.

So please sign up today and participate in the IBM ICS Developer Competition 2016

Have fun

Project Spotlight: OpenLog, XPages OpenLog Logger, XLogBack

Paul Withers | 6:59:34 AM Wednesday, May 25, 2016 | Full Story and Comments
For this month's project spotlight, I wanted to highlight error logging. Firstly, it's worth making a clear distinction, that the projects on OpenNTF help with error logging. But error handling is a completely different topic and no framework, regardless of the language, can ensure errors are appropriately handled for custom applications. Error handling comes down to managing the process in which the error occurs in a way that best supports the user and application, to ensure quality and integrity of data. For example, proper validation on both server-side and client-side would fall under error handling, but if the developer doesn't apply validation correctly in the right places, errors won't be handled adequately. Error logging is designed to aid support, not improve data quality and integrity.

Domino has had logging in-built in its core API for some time via the NotesLog class in LotusScript, corresponding to the Log class in Java. This allows logging to a Domino database, an email, a file or each agent's internal log (accessible via Agent > Log) in Domino Designer. But like the core Java logging mechanism, many (and possibly most) developers have chosen a more extensive open source solution for Domino - Julian Robichaux's excellent OpenLog.

For anyone not familiar with it, OpenLog not only captures logging from LotusScript and Java, but also JavaScript. It captures considerable information, including client versions, user triggering the error, access levels and roles, source of the error and stack trace. This is invaluable for tracking down the actual cause of an issue and has, in the past, allowed me to quickly identify the cause of an issue was an upgrade to a user, when I wasn't even aware upgrades were planned. Logging also allows document links to be added, to help identify document-related causes. In addition, notification profiles can be set up and standard Domino archiving processes can be utilised to keep database sizes manageable.

When XPages came along, a server-side JavaScript version was created for TaskJam by Matt White, but the project was not Apache-licensed, causing a problem for other projects that wanted to utilise it. That is why XPages Help Application included a Java library based on Julian's original OpenLog Java Script Library.

But the opportunity for XPages-specific enhancements increased as XPages and knowledge of the framework matured. This caused its evolution into a separate project XPages OpenLog Logger, by the same author, Paul Withers. XPages OpenLog Logger supported easier use from SSJS, filtering of errors so the same error was not logged for multiple phases of the XPages lifecycle, capturing uncaught exceptions, greater configuration and flexibility using notes.ini or xsp.properties and much more. It also allowed the library to be deployed within each application or server-wide as an OSGi plugin. Full documentation has also more recently been migrated to OpenNTF's Confluence server, in a specific space. The database errors are logged to and form used have not been changed - it still uses the original OpenLog project. But it brings a greater flexibility to error logging.

For those utilising the OpenNTF Domino API ( a growing number of developers), XPages OpenLog Logger comes as part of that plugin, making it available to XPages, to other OSGi plugins and applications, or even beyond Domino, in CrossWorlds.

But beyond the Domino space, Java developers are used to a different standard error logging approach. Historically this has meant log4j, but that has evolved into and been replaced by LogBack. Serdar Basegmez has taken that library and integrated it as a separate OpenNTF project, XLogBack, for a more a more Java-ish way of logging. The documentation (available to browse in the readme file on the Stash repository) gives a nice table of comparison with XPages OpenLog Logger.

So whether you're still developing Notes Client applications or using XPages, DOTS and going beyond Domino, OpenNTF provides best practice options for developers from a variety of backgrounds.

If you're developing or have developed a project with just print statements or no error logging at all, consider working with either Serdar or Paul (or the other project chefs of XPages OpenLog Logger) to leverage proper error logging. XPages OpenLog Logger has already been integrated into projects like Resource Reservations Extended and we would be happy to help include more robust error logging in other OpenNTF projects. And if you are interested in the ICS Developer Contest, having XPages OpenLog Logger or XLogBack integrated by another person would constitute having multiple contributors, and therefore a team!

Build your Team for the IBM Collaboration Solutions Developer Competition 2016

Christian Guedemann | 10:49:39 AM Tuesday, May 24, 2016 | Full Story and Comments
Yes you should really think about participating the "IBM Collaboration Solution Developer Competition 2016". It will be fun and a real good experience.
Before I was the Chairman of OpenNTF, I had the chance to build myWebGate with our Development staff. We where a gang of 6 team members, but if you think 6 Developers... you would be wrong. My Friend Peter was our project manager and delegated from the management team to lead the financial aspects of this project like effort and deliverables. My role was more Enabler and Architect then developer. And to be honest behind the scene was Roman our CEO who had the role of the business sponsor. He was also in a way part of the team.

During my time of building XPages Toolkit and POI4XPages, I get a complete different view of what is my team, because I figured out that best request came from outside of our development team. To be honest for XPages Tookit and POI4XPages, the most important *team members* are the developers who use the framework and builds the applications. They are like the *Business Sponsors*. They know what they really want (If you are using one of this project and you are not part of the corresponding slack channel, join us today).

But now there is this absolute cool IBM Collaboration Developer Contest, which you have to attend as a team. Please rethink "Team". Because we are not talking about a "Team of Developer".... No we are talking about a Team. And I think your Team should contains the following type of members:
- Someone with a clever Idea or a real world need!
- The one who can develop the code for the clever idea
- A real good Tester
- Documentation? Yes documentation.... and there are People who loves to do documentation

So build your team,join the Competition!

Have fun

IBM and OpenNTF present: IBM Collaboration Solutions Developer Competition 2016

Christian Guedemann | 2:04:06 PM Monday, May 9, 2016 | Full Story and Comments

World IP Day

Paul Withers | 9:05:11 AM Tuesday, April 26, 2016 | Full Story and Comments
Earlier today I came across a tweet saying that today is World IP Day. Over the last year we've been looking at the role of OpenNTF, looking at what Apache and Eclipse offer and considering how the changes in personal websites and cloud source control repositories like GitHub and BitBucket offer. These days there are a host of ways open source projects can be made available to the public. But one of the key differentiators we identified that OpenNTF provides is IP clearance of projects. This means projects cleared for inclusion in the Apache catalog have been vetted to ensure there are no intellectual property right infringements and that all contributors are given due credit. Thanks to Peter Tanner for his tireless work over the years as our IP Manager!

Maintenance during the weekend

Christian Guedemann | 9:37:02 AM Friday, April 22, 2016 | Full Story and Comments
Dear Friends

We will do some maintenance on the OpenNTF Infrastructure, starting from Friday April 22. 12:00 EDT until Sunday April 24. 18:00 EDT. This will affect all the tools of the Atlassian Suite. Expect that this services could be down for a short period. We will inform you when all maintenance tasks has been done.

Have fun

Project Spotlight: JsonBeanX and Jackson4XPages

Paul Withers | 7:17:56 AM Monday, April 18, 2016 | Full Story and Comments
A search of OpenNTF projects for the term JSON will return a number of projects over a long period of time. JSON has long been a key data interchange format, being language independent and not requiring a fixed agreed schema. It is this reason in particular that has led to it overtaking SOAP as a data transfer mechanism, enabling microservices to be built and further developed without breaking existing interactions. Anything that delivers JSON data can of course be access via (Client-Side) JavaScript and, if client-side is your preferred approach and you're only interested in consuming and not delivering JSON data on request, there will be standard out-of-the-box approaches that you can leverage.

But for server-side approaches - whether for consuming or delivering on external request - the options available are various. When I initially developed XPages Help Application some years ago, the approach I used was to manually construct strings of JSON data. But the Domino platform has opened up tools for leveraging this, particularly in the 9.0.x timeframe with Domino Access Services and the com.ibm.commons.util.io.json package. Domino Access Services provide out-of-the-box basic CRUD APIs to access Domino databases, including Mail and Calendar. But DAS does not manage validation or manipulation of data types. The com.ibm.commons.util.io.json package provides low-level Java APIs to read to and write from JSON objects, and of course it is also via Server-Side JavaScript, since SSJS classes are actually Java classes under the hood. But every element of the JSON data needs reading or writing individually, which can be verbose.

Following on from his session with Kathy Brown at IBM Connect, Julian Robichaux has contributed a lightweight converter between JSON and Java, JsonBeanX. This is just a JAR file that can be imported into an individual NSF and avoids some of the security restrictions of other Java implementations, which would need amendments to the java.policy (or java.pol) file or would need the code adding to an OSGi plugin. Full details on how to implement it are in the JavaDoc documentation. This is designed to convert between JSON and Java objects, but it's an added incentive if needed to use Java instead of SSJS, to minimise the code you need to write and avoid some of the pitfalls you might otherwise need to (re-)address.

I've attached a simple example in the Java classes below. Within your XPages application, you would just go to Java\Code and import Julian's jar file, like this:

Then it's just a case of creating the Java code to use it. DavidJson is my Java class, which comprises a few properties - name, age, date of birth and characters. In the Utils class there is a method createBean() to create an instance of the class. (In reality, this would be loaded from a Notes Document , ViewEntry or multiple Documents/ViewEntries.)  The outputJson() method then uses just a handful of lines of code to return a String containing the JSON data:

When passed to a Computed Field component, the output is this:

Outside of XPages, the standard library for translating between Java and JSON is Jackson and Frank van der Linden is working on an OSGi plugin, already on OpenNTF's Stash, to wrap this for those who prefer something a bit meatier and can use OSGi plugins. The second output is the same DavidJson Java object outputted using Frank's plugin. Again, it's just a handful of lines of code.

The false parameter passed to the JacksonWrapper tells it to output date/times as date/times rather than converting them to timestamps. There are a variety of options for outputting to files, FileWriters, OutputStreams or just strings (which I use here). And beyond this there is a host of additional functionality from Jackson. Look out for a full release of this project on OpenNTF in the near future or download the source from Stash and get involved (developing, testing, adding feature requests or more).

For a walkthrough of the code, here is a YouTube video.


Survey Results

Paul Withers | 1:22:36 PM Thursday, March 31, 2016 | Full Story and Comments
Thank you to both contributors and consumers for your feedback to the recent survey. It's been a busy couple of weeks with OpenNTF involved in Engage and the Business Partner Bluemix workshop from the last two days. But the "early birds" at Engage last week will have seen some high level highlights of the survey results. Here they are in a bit more depth:

Consumer Survey
There were 79 responses, which is in line with surveys a couple of years ago about Collaboration Today. That figure was the benchmark for me when setting up the survey.

1. Approximately how many OpenNTF projects (full projects, XSnippets, controls, tools) have you used in production?
Over 80% were in the middle range of 1 - 10. 11% used more than 10. Maybe there is some education we need to do, because when I consider things like OpenNTF Domino API, OpenLog, XPages OpenLog Logger, Extension Library, XPages Debug Toolbar, various XSnippets like Fredrik Norling's Standby Dialog Custom Control, Phase Listeners, DateConverters, not forgetting tools like Swiper and others, I think I'm way past 10. There is certainly more that can be done to maximise use.

2. Do you agree OpenNTF projects provide good code?
Over 90% agreed strongly or somewhat, which is encouraging.

3. Do you agree OpenNTF projects provide useful techniques to support training?
78% agreed with this. Certainly the projects that I've developed and the session databases I've created aim to train and provide learning techniques. After all, I'm usually developing them to learn something myself and, if I'm going to spend time on them, it makes sense to try to increase my knowledge at the same time. But maybe there are things we can do to share that more (both from the contributors and from consumers).

4. Do you agree OpenNTF projects are easy to install?
About two thirds agreed. Yes there is work to do here and I've heard comments from one consumer recently who had some problems with a project but will be putting together things he learned to feed back to improve the project. I think that's an encouraging and important point, that OpenNTF is not a shop for contributors to put code and consumer to use it. It's a community, and if a consumer hits problems with my project , I would want them to feed back "feature requests" for improving the documentation as much as feature requests on the project. They are projects we as a community own, not just donated code. Consumers can contribute to projects in many ways, one of which is proposing improvements on documentation or functionality to improve deployment experience, and I would hope contributors would welcome that.

5. When installing OpenNTF software, are you confident it will work on your server?
Nearly 80% agreed. This question was prompted by my own experience of struggling to install some projects. The figure of 80% is encouraging, but does mean there is still room for improvement. But the improvements can be made by OpenNTF as well as by contributors.

6. Do you agree defects on OpenNTF projects are dealt with in a manner appropriate for open source software?
About two thirds agreed, but there are many ways we can improve this and I would hope to see some during this year. This doesn't mean we'll regularly be expecting much more from contributors and expecting more significant levels of support. And we're conscious that some defects may be because a project is no longer supported for whatever reason, but there's no way for the consumer to see that. But there's no visible way for consumers to seek help other than posting to the project and waiting for a response. There's also no easy way for potential contributors to get involved or for project chefs to easily request more contributors. And only recently have projects embraced open source, allowing developers to fork the code and submit pull requests, if they are confident in doing so. There is some education to be done here, we know.

7. Do you think OpenNTF projects would benefit from larger project teams?
Nearly 85% agreed with this question. We don't want to take kudos away from contributors, but neither do we want them to feel tied to a project forever. OpenNTF is a community and open source should be managed by the community.

8. Do you find it easy to locate OpenNTF projects relevant for you?
Less than 60% agreed and that doesn't surprise us. Look for some initiatives around this and look for requests for involvement from consumers as well as contributors. After all, if you use a project, you know what it does.

9. Do you feel aware of new OpenNTF projects?
10. Which of the following would help you be more aware of new projects?
60% agreed. 50% wanted more blog posts, 21% felt weekly tweets would help, 63% wanted a newsletter and 48% monthly webinars. I only recently became aware that time was being donated to OpenNTF to do some of these areas. The interest in a newsletter was a little surprising, but after some digging into some administrative systems, it appears this used to be done. Some work needs to be done to allow people to opt in / out of newsletters, but it's something we will look at doing. I will also re-iterate that if anyone wants to blog about their project, we're more than happy to post guest blogs, so please get in touch with any of the board on various social media channels or on the Slack chat.

There was some useful feedback around usability of the site. There is definitely work required based on a completely different scope than the website redevelopment a couple of years ago. There are some difficult decisions going forward and I don't think we'll be able to have a single layout to cover older projects and yet also best support brand new ones. There may be the opportunity for new contributors to get involved, so stay tuned.
There was a comment about fixing Team MailBox. We'll take that on board and there's work to be done, but it won't be forgotten though there will not be any immediate action.

Contributor Survey
There were 55 responses. It's hard to gauge whether that's good or bad.

1. When was a release last uploaded for a project you work on?
Just over a third have had a release uploaded in the last year. That's a little disappointing, but is not surprising based on what we're seeing on releases. It also fits in with many projects being single developer projects, which means more effort required per capita per release.

2. Do you agree your projects are adequately tested?
This is admittedly a subjective question, but 78% agreed.

3. Do you agree your projects are adequately documented?
Two thirds agreed. Yes, we're developers: what we do well is develop, documentation is not our best competence. So in a single developer project, it can vary.

4. Are you involved in a multi-developer project? This includes a project that uses a pre-existing OpenNTF project or is used within another OpenNTF project.
With the second sentence in the question, I'm very much thinking of things like the Extension Library, OpenNTF, XPages Debug Toolbar (presumably included in at least one project). Only 25% agreed. This is an area we can help to do something about and avoid single point of failure on projects, support projects where the developer moves to other technologies, and turn consumers into contributors without the huge pressure of having to come up with their own idea or feel the pressure of a level of quality they may not yet feel totally comfortable with.

5. Do you feel you need help on a project you're involve in (e.g. additional developers, testers, for better documentation, someone to take over projects because you are no longer working in that area)?
45% agreed, 55% disagreed. This may not be appropriate for all projects, but may help turn consumers into contributors, help with mentoring etc. We're not saying single developer projects will be banned, but the numbers of contributions and (regular) contributors is not significant - as shown by question 1 - and to have a flourishing open source community, we need to do all we can to increase contribution and consumption.

6. Do you feel you respond in a timely manner to defects and feature requests?
Just over 70% agreed. It takes a lot of honesty to admit if you don't and we're conscious there is more we can do to support those contributors.

7. Have you received reviews or feedback of any of your projects?
About 50% have received feedback on OpenNTF, about 60% outside. There is more we can do around to increase that.

8. Would you feel confident about large organisations using your project(s)?
80% agreed, which is good to hear. Hopefully larger organisations are becoming more open to the use of open source. It's almost certain that they do in some form.

9. Do you use source control for any of your projects?
57% do, another 19% plan on doing so. Admittedly, if you've got a traditional Notes Client solution, this is difficult. This may be new for some developers, but there are some great NotesIn9 episodes covering it and Cameron Gregor's Swiper tool (also on OpenNTF) really helps.

10. Would integrated build management be of benefit to your development process (processing of test suites, automated build and releases)?
40% said yes, 22 % didn't know enough about it. Again, traditional Notes Client solutions may not benefit from this. There's also some education we need to do on the benefits and the infrastructure for it is very new, but it's something we would like to offer. Look out for more about this in the future.

One of the comments about working in groups was admitting a lack of understanding of the tools like Git, Maven, JUnit etc. We'll take that on board for webinars. We're conscious there's a lot that's new to Domino developers and one of the roles of OpenNTF is to educate on tools some of us are starting to consider better practice.
Another comment was about increasing feedback rather than just consumption, something we also feel is important.

Next Steps
The feedback we've received, combined with our own thoughts, means there is a lot of work ahead. There are some clear infrastructure and communication enhancements that the OpenNTF board should make. We need to agree on those as a board and action. Like you all, we also have day jobs, and our next board meeting is not for two weeks, so do not expect immediate announcements.

Beyond that, there are project governance enhancements that we need to discuss, draft and solicit feedback on. OpenNTF is a community so agreement needs to come as a group. We don't want to drive developers away from OpenNTF. We want to increase contribution and consumption, while promoting and valuing what OpenNTF can offer over and above open source repositories like GitHub and BitBucket, both to contributors and to consumers. Details will come out in due course (weeks not days), but if you have any concerns, please reach out to us on the Slack channels or via other social media.
Paul Withers

The PERFECT Open Source Project

Christian Guedemann | 2:44:31 PM Sunday, March 27, 2016 | Full Story and Comments
OpenNTF has during the last year done a lot of research and discussions to figure out what is the PERFECT Open Source Project. Based on our research, we have changed the way we look at Open Source. The result is a complete new Process for our Projects. But let us start with a definition about the PERFECT Open Source Project:

Open Source …
Identifies a problem that needs to be solved, by creating a community of people / companies that have a vested interest in solving the problem.

A Problem...
... is always an opportunity. As OpenNTF addresses primary developer or administrators, our problems are related to coding problems like "export this view to a spreadsheet". With solving this particular problem, the developer or the administrator will be faster in execution of his project. The value is total related to the speed the developer or administrator wins.

A Community of people / companies
I know some companies has this particular illusion that they are the only ones that can solve a problem like writing an Connector to Office365 or a Datasource to use Cloudant. But is that the end customer wants? If you are designing an application that consolidates calendars of your company, you should spend your time in the business logic and how you present the results to the customer and not in the magic how to access the data from the different calendar sources. There are a lot of problems that could be solved together and everybody will have success with his one use case. But anyway. We expect to see in a community of people / companies in particular developers, but that's complete wrong. The most important people in the community are the "users" in our case also developers or administrators. Think about this: The simple view export in POI4XPages would not exist without "users" who have asked for this capability. You as a user (developers / administrator) are important for the success of an Open Source project. And we have made it as easy as possible to get in contact with the developers of a project. Join openntf.slack.org and become part of the discussion. Ask for features and report bugs on jira.openntf.org for the available projects and push us forward to the next release of the project.

A vested Interest
I'm a strong believer in John Nash's addition to Adam Smith's idea about the economy. There are problems, which should be solved by communities of people and companies. It would not make any sense to have a apache-commons implementation from every developer. But every developer is capable to write a StringUtil.isEmpty() as every developer is capable to write an own implementation of a spreadsheet export. So what is the common goal, that we all have? Is it productivity, quality, speed, time to marked? Ask your self. I'm using Open Source Software, because brighter minds than I have solved a problem. If I find a possible improvement, I try to contribute it back to the community.

But at the end of the day, I've to build solutions that makes my customer happy. Using Open Source Software makes me faster in delivery.

Get inspired!
Please join https://openntf.slack.com/archives/new_ideas and share your ideas of Problems that needs to be solved by a community of people!

More News