Domino 8.5.3 - Create an organization extension library / codestore

1
votes

This is a project I've been working on off and on for months and I feel like I'm pretty close, but I just can't seem to get past the final hurdle.

The goal is to develop an organization extension library that contains both internal and 3rd party code that we frequently rely on.

History

As a test project, I started with Apache Poi because that is already in wide use in our environment. I have a plug-in and feature built just from the Poi .jars that allows me to build our current Poi applications as long as I add the plug-in (from my workspace) to my build path. The apps work on the servers because we have already distributed the Poi .jars by manually copying them.

The next step is taking that plug-in and getting it into an updatesite so that all of the servers and developers can synchronize on one version. I found and followed these two excellent blog articles (that I wish existed when I started this project):

http://www.dalsgaard-data.eu/blog/wrap-an-existing-jar-file-into-a-plug-in/

http://www.dalsgaard-data.eu/blog/deploy-an-eclipse-update-site-to-ibm-domino-and-ibm-domino-designer/

With the caveat that the articles are written for Domino 9 and we are running 8.5.3 here, but that only matters in the last (installation) step.

Current

This brings us to the problem. All of the above seems to have worked great up to a point. I can install my feature to my designer client from the eclipse update site and it works great. However, the install is failing when I import that into our updatesite.nsf database. This means that while the developers can all install from the updatesite if I put it on a network drive, that doesn't deploy updates to our servers.

The problem is that when I try to install from the .nsf update site, the Eclipse Updater just hangs. I've let it go for well over an hour and eventually Notes becomes completely unresponsive.

So the question is, is there anything I might have done wrong, either in the development of the plug-in or server configuration that might be causing this issue?

Additional Info

I'm looking at the osgi console and that is largely unhelpful. I am getting the following errors as I'm trying to install: SEVERE Could not access digest on the site: no protocol: 0/5B004DDD5E38F3FF85257CAF004C72C7/$file/digest.zip ::class.method=unknown ::thread=Worker-7 ::loggername=org.eclipse.update.core

I could generate dumps if that would be useful.

Security is also locked down fairly tight here. It could be a security issue - is there a way to troubleshoot that? Once I get to the hang I'm just stuck guessing.

This has been edited for clarity and to update information

3
eclipseosgixpageslotus-domino
how do you load the update site? - Frantisek Kossuth
So, to make sure I understand. You've successfully got a plugin built and the server knows about it (tell http osgi ss com.yournamespace). You install the plugin into DDE via an update site but you can't build the apps which use POI. Have you checked the checkbox in xsp.properties to include the plugin as a dependency of the nsf? Does your plugin show up there? - keithstric
I'd hoped I was clearer - I'll see if I can edit my question. There is probably too much extraneous information. - Gary Forbis

3 Answers

2
votes

I know that this is post is over 5 years ago but...

for those that find this and are trying to resolve the error

SEVERE Could not access digest on the site: no protocol: "

is due to the update site project not having the URL of the Domino updatesite.nsf not being added to the Archives tab of the site.xml.

I found the updatesite.nsf also needs to be anonymously accessible as no credentials are prompted/passed through to the Domino server hosting the updatesite.nsf database (at least from DDE), YMMV from eclipse. So if Anonymous connections are blocked on the Domino server you will be out of luck.

0
votes

To develop a plug-in you really want to have 3 projects:

  • the plug-in
  • the feature
  • the update site

Of course a feature can contain more than one plug-in (and probably should) and a update site can contain more than one feature (and probably should). Once you have an update site project it features a handy button "build all" that makes sure plug-in, feature and update-site get compiled in one go. And that button is what you really want.

You can point using a setting in your Domino Designer (or local Domino server) to the feature directory. Add a plain text .link file to framework/rcp/eclipse/links, that contains the path to your install site - it then picks up the features and plug-ins from there. After a build you would need to restart designer/server to activate the updated feature.

For the Domino server the approach using an updatesite.nsf and the respective notes.ini setting makes the most sense (to me). http restart required. Lazy people script the whole thing.

0
votes

I still don't have a great answer for this, but I believe the issue is related to the environment here. I don't have the authority to change the environment, even if I were able to conclusively demonstrate it is the cause of this problem, so it is a moot point. All I can say is that at least one administrator computer had no issue installing from the update site.

For me, the solution for distributing the update site is to put it on a network drive and have everyone install it from there. The server has no problem using it from the updatesite.nsf.