This is a continuation of a question I asked a few days ago regarding a designer connection for Domino OSGI dev and testing.
In eclipse, I do have the "debugging plug-in" installed (as mentioned by stwissel), and I am fairy certain that it is configured properly.
In a second attempt, I tried to export my plug-in in an update site.
1. import plug-in to feature
2. import feature to update site
3. build update site
I first tried to install using My Widgets in the notes sidebar. I did not get the thing to run with that so, then went into designer and installed it there directly, also nothing.
current stand
I built the update site and deployed using an nsf Update Site as a widget. I use this for openNTF Domino API, the ExtLibs -- it is comfortable and I like it.
I can verify that the feature is available in the application Management window of designer.
3 I expect to see those libraries in the xsp.properties page generation tab, but do not.
questions
1. Am I missing something?
2. Must I add some sort of class/code/flag in order to choose this library/plug-in in designer?
3. How can I best verify that the plug in and not just the feature is installed?
if your XspLibrary is not a 'global' one you probably won't see the activator run until the first nsf that uses it activates it.
seeing as you can't select it in an nsf this is probably why no nsf is ever activating it
can I ask have you correctly defined the library as an extension of com.ibm.commons.Extensions
as type
com.ibm.xsp.Library
if you don't define the extension you will not see it in the list of libraries.
also you must make sure you set the plugin settings to export the XspLibrary class (or package of the class) otherwise designer can't use the class
see this article on the domino designer wiki for an overview of necessary steps to correctly set up the XspLibrary plugin. the manifest.mf / plugin.xml settings are important.
another thing to double check, is to inspect the actual built plugin jar, using something like 7zip. you can open it up like a zip and have a look to make sure the .class files are actually included in the jar. if your build settings are incorrect it may not include them in the jar properly. also make sure the manifest.mf and plugin.xml are in there properly
EDIT from Greg
This should be the link for a non-mobile user
When you setup the debug plugin, it should create an entry in the workspace directory of the Notes client and Domino server (I think down in the RCP directory). This entry points back to the Eclipse workspace. So you don't need to deploy the plug-in. You also should see a warning when loading Notes ( with rparams -console) or Domino on the console about the debug.
Also what I found: auto deployment via Widget works when the update site sits on a server via http or nrpc. It doesn't when it is specified as file:/// so I run a Apache http on local (I need it for other stuff too, so no big deal for me).
I'll check the exact settings when I get back to my Dev workstation
You can identify if a plugin is installed via Help > About IBM Domino Designer, then clicking on the Plug-in Details button in the dialog.
Help > Support > View Log and View Trace should give more details. Trace is more detailed and allows you to write content, as we do for the OpenNTF Domino API. It may allow you to see how far through the code it's going.
That first message is in the XspLibrary class, in the constructor, just using a sysout
/**
* Constructor
*/
public XspLibrary() {
System.out.println("Loading org.openntf.domino.xsp library");
}
Hopefully that should help you see where it's failing.
Related
I'm developing a fully documented framework. In its developing project, the documentation works perfectly. Although, when I add this framework to a project (with SPM or Cocoapods), if I option + click something defined in my framework I am not able to check its full content. The docstrings show up nicely, but the link "Open in Developer Documentation" is not available and if I click on one of the available links (for example, a function parameter type), it says "Page not available".
I have already tried to build the docs on the host app with control + command + shift + d, it builds all of the dependencies of my framework (which are all open-source, i.e the swift files are there) but my Framework doesn't even show up.
It doesn't make sense to me that this is not working, as I said, Xcode can actually find the docs but seems it can't find it when building.
I've found a similar question here on Stackoverflow but it doesn't seem to be the same issue, and there are no answers.
Am I'm missing something? Is there something that I must do in the host app? Or is there some lacking config when building the framework?
For example, in the picture (had to redact some info, sorry), if I click APIEnvironment, which is defined within my framework, I get a message of page not found.
We're using octo.exe to create releases. It starts suddenly giving error saying can't find project. I checked the api/projects and that's true, it is not in the returned json response. But when I look at the dashboard I can see the project. The only thing I did was cloning another project from this one earlier. The cloned project is working fine but not the original project.
It exists in dashboard (web gui) but not in api (hence octa.exe can't find project)
Looks like api is caching the projects. The new projects that I created via GUI not available in api.
Thanks,
I have had the same issue yesterday. It turns out to be something interesting. I believe that your project is still there properly set, but the total number of projects that you have become more than the listed ones in the API, and that's why the Octo.exe couldn't see it anymore.
I have explained here, how I managed to fix that issue quickly.
This is due to how pagination is implemented in Octopus (pretty poorly if you ask me). But you can override it. add this to the URL (at the end).
'?skip=0&take=2147483647'
alternatively, you can watch the json returned, if you find the links.Page.Next property you can use that link to get next page of the api response.
I am trying to install an Eclipse plugin in Domino Designer. There are many useful tutorials how to do it. However, when I enter the remote site in the Application Locations window > Remote Location
http://mercurialeclipse.eclipselabs.org.codespot.com/hg.wiki/update_site/stable
I get this error code:
CWPPR0031W: The requested provisioning operation(s) completed with partial success.
Network connection problems encountered during search.
Unable to access "http://mercurialeclipse.eclipselabs.org.codespot.com/hg.wiki/update_site/stable".
Unable to access site: "http://mercurialeclipse.eclipselabs.org.codespot.com/hg.wiki/update_site/stable" [Server returned HTTP response code: "403 Forbidden"
My company uses a proxy server to access the internet. I suspect, the error is caused By Domino Designer trying to access the link directly. Is there any way to tell Designer to go through our proxy server?
It looks like you're trying to install Mercurial into Domino Designer. I know in the past David Leedy and Declan Lynch had to install older versions, because Domino Designer is based on an older version of Eclipse. I'm not sure of the details for that. But I know both David and Declan now recommend using SourceTree for management of local mercurial source control repositories. It's better documented (several NotesIn9 episodes as well as Show 103 from Connect 2014 which I presented with Declan) and mor Domino developers use it (as well as non-Domino developers) so if you hit problems, there will be more of a cummunity to help.
All of those settings will be handled by the location set in the Notes client.
Go to File>Preferences>Locations> and edit the current location
In the basics tab there is an option for proxy configuration. You should be able to drop in all of your configs right there.
this site helps me to install a eclipse color theme for the domino designer.
http://www.intec.co.uk/update-site-for-eclipse-coloor-themes/
first I had the same proxy problem like you, but this guide helps me, perhaps you to.
background
I have designed many tools in the past year or so that is designed to help me program for XPages. These tools include primarily helper java classes, extended logging (making use of OpenLogger and my own stuff), and a few other things that I personally feel I cannot work without. It has been discussed with my employer, and we feel that it might be a good idea to start publishing these items to openNTF. Since these tools are made up of about 3 .nsfs, all designed to use the same java code, key javascript classes, css, and even a custom control or two, I would like to consolidate key items into a plug-in that can be installed at the server and client level. I want to do this consolidation before I even think about publishing any of the work I've done so far. It would just be far too much work to maintain, not just for me, but for potential users. I have not really found any information on how to do such a thing in google searches. I also have to make sure that I am able to make use of the ExtLib libraries, openNTF Domino API, and the Notes API.
my questions
How does one best go about designing such plug-ins? Must a designer
use eclipse, or is this it possible to do this directly in the Notes
Designer?
How does a designer best go about keeping a server and client up to date while designing and updating the plug-in code? Is this why GitHub is often used?
Where is the best place to get material to get started in this direction? I sort of feel lost in the woods, knowing I need to head north, but not having a compass for that first step.
Thank you very much for your input.
In my experience, I found that diving into plug-in development is a huge PITA until you get used to it, but it's definitely worth it overall.
As for whether you can use Designer for plugin development: yes, but you will likely eventually want to not do so. I started out by using Designer for this sort of thing for a while, presumably with the same sentiment as you: why bother installing another instance of Eclipse when I'm already sitting in one all day? However, between Designer's age (it's roughly equivalent to, I think, Eclipse 3.4), oddities when it comes to working sets between the "Applications" and "Project Explorer" views, and, in my case, my desire to use a Mac app, I ended up switching.
There are two major starting points: the XSP Starter Kit (http://www.openntf.org/internal/home.nsf/project.xsp?name=XSP%20Starter%20Kit) and Niklas Heidloff's video on setting up Eclipse for XPages development (http://www.openntf.org/main.nsf/blog.xsp?permaLink=NHEF-8RVB5H). The latter mentions the XPages SDK (http://www.openntf.org/internal/home.nsf/project.xsp?name=XPages%20SDK%20for%20Eclipse%20RCP), which is also useful. In my setup, I found the video largely useful, but some aspects either difficult to find (IBM's downloads are shifting sands) or optional (debugging, which will depend on whether or not you're using Eclipse on Windows).
Those resources should generally get you set up. The main thing to worry about when setting up your Eclipse environment will be making sure your Plug-In Execution Environment is properly done. If you're following the SDK setup instructions, that SHOULD get you where you need to be.
The next thing to know about is the way plugins are structured. Each plugin you want to install in Designer or Domino will also be paired with a feature project (a feature can house several plugins), and potentially an update site - the last one is optional if you just want to import the features into an Update Site NSF. That's how I often do my normal plugin development: export the paired feature to a directory and then import the feature into the server's Update Site NSF and then install in Designer from there using Application -> Install. You can also set things up so that you deploy into the server's plugin/feature directories instead of taking the step of installing into an update site if you'd prefer. GitHub doesn't really come into play for this aspect - it's more about sharing/collaborating with your code and also having a remote storage location for your git repositories (which I highly advise).
And as for the "lost in the woods" feeling: yep, you'll have that for a good while. There are lots of moving parts and esoteric concepts to get a hold of all at once. If you mostly follow the above links and then start with some basics from the XSP Starter Kit (which is itself a plugin project that you can pair with a feature) - say, printing text in the Activator class and making an implicit global variable just to make sure it works - that should help get your feet wet.
It's best done in Eclipse. You can debug your code running on the server from there, as well as run it directly from there. The editors are also more up-to-date. You want:
Eclipse for RCP and RAP developers
XPages SDK for Eclipse RCP (from OpenNTF)
XPages Debug Plugin (from OpenNTF - basically allows you to load the plugins to the Domino server dynamically, rather than exporting to an Update Site all the time)
XSP Starter Kit on OpenNTF is a good starting point for a plugin. There are various references to the library id, which has to be unique for your plugin. Basically, references to org.openntf.xsp.starter need changing to whatever you want to call your plugin. You're also best advised to remove what you don't need. I tend to work in a copy of the Starter, remove stuff, build and if there are errors with required classes (Activator.java obviously will be required and some others), then paste them back in from the Starter.
XPages OpenLog Logger is a good cross-reference, that was built from XPages Starter Kit. It's pretty much stripped down and you'll be able to see what had to be changed. A lot of the elements of the XSP Starter Kit correspond to Java classes you'll probably be familiar with from your XPages Java development.
GitHub etc tend to be used as source control, which is useful for working out what's changed from time to time.
In an MVC app I am working on, we've recently began using ActiveReports 7 for our report-generating needs. On my local machine, everything works great. However, when we deploy to our Dev server for team-level testing, we get a LicenseException:
License for the SectionReport cannot be found.
We followed the user guide here to attempt different ways to resolve the problem.
What we have done:
Ensured that the licenses.licx file references the assemblies, and that the correct ActiveReports 7 assemblies are being built with and referenced by our project. As it stands, the licenses.licx file looks like this (sans the line-breaks):
GrapeCity.ActiveReports.SectionReport, GrapeCity.ActiveReports.v7, Version=7.0.6158.0, Culture=neutral, PublicKeyToken=cc4967777c49a3ff
GrapeCity.ActiveReports.Export.Pdf.Section.PdfExport, GrapeCity.ActiveReports.Export.Pdf.v7, Version=7.0.6158.0, Culture=neutral, PublicKeyToken=cc4967777c49a3ff
As this is a MVC web project, used the Assembly License Generator that comes with AR7 to create an [Assembly].Web.License.dll library, which we are building with the project in a /lib/ directory at the solution-level. This change had no effect on the License exception.
Used the Web Key Generator to create a key for the App.config file. This change had no effect on the License exception.
What we have not done:
Created some web form, and created an App_License.dll library that gets built with our project. The reason we did not do this is we are not using Web controls for our reports, we are not even using the GrapeCity.ActiveReports.Web assembly, and the error is not coming from any class in that library (which is logical, seeing how we're not using it.)
The only notable detail of all of this is that modifying the licenses.licx file had an early effect as we had a similar license exception on another component; ensuring that licenses.licx had the proper details ensured that that other component was no longer throwing LicenseExceptions in our app. I tentatively think from this that maybe my licenses.licx file still lacks something needed to make this app work.
The only thing remaining I can think to do is to recommend our lead license our server as a developer, but this possibility has already come up, and the direction we've been asked to take is to avoid that route if at all possible. I think it is possible because I have encountered similar posts involving people who followed the steps in the user guide above and presumably were able to solve the issue. Yet, for my team, these steps aren't working.
Question: What am I missing?
Using the Assembly License Generator as you have done should do the trick. Also, make sure that you are using the latest version of AR7 as according to this post on the ActiveReports 7 Support Forums, there was a fix done to some later version of ActiveReports 7 to correct some problem with licensing in this scenario. Specifically the steps given from the previously cited post said that following the below steps with the updated version corrected someone else's problem:
Run the program "ApplicationLicenseGenerator.exe" (as Administrator) from a location similar to "C:\Program Files\Common Files\ComponentOne\ActiveReports Developer 7\"ApplicationLicenseGenerator.exe"
Browse to the compiled ActiveReports DLL.
Press the "Generate" Button.
This generates a satellite assembly similar to yourclasslibraryname.dll.GrapeCity.Licenses.dll
Place the DLL in the bin folder of your web project and/or reference the generated DLL in your web service project.
Answer: for non-licensed users, [Assembly].GrapeCity.License.dll must be added to the web project as a reference!
Licenses.licx matters from a build perspective, though. But the license file was not missing anything.