Deploying OSGi Servlet to Domino - osgi

I have written a servlet using the directions in this tutorial: http://www.slideshare.net/fiorep/domino-osgi-development slides 34 to 57. This worked well and was easy to debug when deployed via the pde.launch.ini. Now I want to work out how to deploy it to another server.
From what I can figure out, I think the preferred way is to create an OSGi bundle and deploy it via an updatesite.nsf. When I try to add a new local update site to the update site, it prompts me for a site.xml. This is where it falls apart for me - where does that file come from? Have I missed some steps?

When you want go to update site way, you first need to create a feature project, add the required plugins to this project.
Afterwards you need to create an Update site and the Feature project.
Finally click on build or build All.
Then there you have you have your update site somewhere on your local machine.
Point to the site.xml of this update site project when you want to import it in a update site Database.

For your OSGi project you have to create another project of type "Updatesite project". Add your OSGi project and all dependencies to that project and build it. This project will generate/contain the site.xml you need to deploy on Domino via the updatesite.nsf.
https://wiki.eclipse.org/FAQ_How_do_I_create_an_update_site_(site.xml)%3F

Related

how to use XPages: A ClientSide State by Sven Hasselbach in Domino Designer

Could you someone please help me how to use XPages: A ClientSide State by Sven Hasselbach in Domino Designer.
The code provided on the GIT does not have site.xml to install in the domino Designer.
http://hasselba.ch/blog/?p=2115
You have to create your own OSGi Developement environment first, then you can create a new Plugin project and import the following files / folder:
/src
/META-INF
build.properties, plugin.xml
Now you can change the secret keys in
/src/ch/hasselba/xpagesclientstate/application/ClientStateManagerImpl.java
Next you have to create a Feature project, and an Update Site project and click on Build.
Then you have a site.xmlwhich can be imported into Designer & Domino server.
You need to create an update site project. Details are here:
https://wiki.eclipse.org/FAQ_How_do_I_create_an_update_site_(site.xml)%3F
For reference, see the answers to this question Deploying OSGi Servlet to Domino

Alfresco deployment doesn't work

I've created the simple example from here, then packaged it using mvn package, and made an effort to deploy the result amp file as described here. But after restarting Alfresco I didn't see any changes. There were no new variants of workflow to choose. The java -jar alfresco-mmt.jar list <WARFileLocation> executing showed that modules org.alfresco.integrations.google.docs and org.alfresco.vti are installed in the chosen war but not a word about my helloworld workflow
UPD: I looked deeper through the tutorial and found that to add an activiti to the share u first need to add some other activiti to the alfresco. it is told there:
Open a command-line window and switch to
$TUTORIAL_HOME/workflow-tutorial-repo. Run mvn integration-test
-Pamp-to-war -Dmodule.log.level=debug. Your repo tier project will be installed and started on Tomcat running on port 8080. Open a new
command-line window and switch to
$TUTORIAL_HOME/workflow-tutorial-share. Run mvn integration-test
-Pamp-to-war -Dmaven.tomcat.port=8081
why is it so? I can't just deploy the only one project to the share but need to make a progect for the Alfresco first?
By the command you wrote you start repo. Since share and repo running on the same server they should run on different ports, so for share you need to provide another port, which is done by additional parameter: -Dmaven.tomcat.port=8081
UPD
#NikitinMikhail The quote you've added describes how to start share.
Alfresco consists of two projects (according to the maven sdk you use) which are repo and share.
Alfresco Share provides a rich web-based collaboration environment for managing documents, wiki content, blogs and more. Share leverages the Alfresco repository to provide content services and utilises the Alfresco Surf Platform to provide the underlying presentation framework.
In other words share is just separate project which communicates with repo and provides better user interface than repo.

Maven update site creation and deployment

I am trying to build an update site for my plugins built with maven. I have a site project with following entry;
<packaging>eclipse-update-site</packaging>
I get the site.zip in the end containing only site.xml in it even though within target/site I have all the folders i.e features/.jar, plugin/.jar, artefacts.jar, content.jar and site.xml.
Secondly I would like to upload the site.zip (with all the contents) on to the FTP site (delete the old version on remote machine and extract this new zip for DEV, for version releases I would like to keep the older releases)
Could you please point me to right direction as I am new to this whole thing.
Thanks
--
Sjunejo
packaging type eclipse-update-site is deprecated, use eclipse-repository instead which will create a repository zip by default.
For details see http://wiki.eclipse.org/Tycho/Reference_Card#Update_Site

Deploying a pre-built package to Appharbor

I couldn't find any information on Appharbor's website about the possibility to deploy pre-built asp.net (mvc) applications. Does anyone know if that's doable?
Another question I have is wether appharbor's built process supports project that launch an executable (node.exe in this case) that's included in a solution folder as part of a custom build step?
If you're worried about precompilation, that's something AppHarbor does out of the box. If you push a repository without a solution file, we won't build it, but just deploy the contents (see part with no solution file).
You should also be able to run node.exe as part of the build, as long as all dependencies (incl. node.exe) are in the repository.

Jenkins- multiple locations SVN. Is it possible to specify the build version

I am new to Jenkins CI tool and I want to know if it is possible to specify what build to use when there are several projects, on different SVN locations, dependent on one another. For example, if I have the web project on SVN location1 and the backend project on SVN location2 and the web depends on the backend and one of the developers modifies something in backend, when the web developer does a commit, there will be a build failure. Is there the possibility to specify that the build from the web part should take into consideration build x from backend and not the newest build?
Thanks in advance.
yes that can be done. in Jenkins check for the Build Triggers options in your project web-settings and on the line Build after other projects are built you can specify the name of projects you want to build automatically after there has been changes made to the base project.
And similarly, in the Post-build Actions, look for Build other projects, where you can specify that if the base project builds successfully, it will automatically trigger a build on children projects.
Hope this helps.
Your example of building a project against a specific version of another project is a little non-standard, but not impossible.
In your case, I would use Jenkins' ability to execute arbitrary scripts to help. The script would take care of getting the correct version of the project that the one I want to build depends on.
Building on your example of a Web and Backend project, here's how I would do things without using a parametrized build:
Add a file to the repository of the Web project that stores the version of the Backend project to use
Configure a job to build the Web project when the source for the backend project changes in SVN.
The project should check out the latest version of the Web project
The first Build Step for the project would be a script (Execute Shell or Execute Windows Batch Command) that does the following:
Gets the version of the Backend to use from the file containing the version info
Either pulls the appropriate version of the Backend from the Backend's repository; or pulls the source of the appropriate version of the Backend's source
(If you pulled the source only for the Backend, the next Build Step should be to build the Backend next)
Build the Web piece
Do any unit tests

Resources