I'm looking for an automatic update mechanism in my Equinox environment.
I am developing bundles which use remote Services. So I have multiple clients which communicates with each other.
Now I'm looking for a way which automatically installs the new Version of a Bundle when I deployed it in Eclipse.
At the moment I'm doing it the following way:
Increase Versionnumber
Deploy in eclipse
Start a script to sync the bundles to all my clients
On each client: Uninstall old version, install new version.
But I would like to have it like this, which would save me a lot of work:
Increase Versionnumber
Deploy in eclipse
Start a script
Each client automatically uninstalls the old version and installs and starts the new version.
I already tried Felix Fileinstaller which worked partly. The problem there was, that Fileinstaller didn't uninstalled the old version and did no autostart of the Bundle.
I also had the Problem that after a while there were many Bundleversions in my load directory and when I restart the environment each bundle in there is installed.
If you use Equinox you should take a look at p2. It's the provisioning mechanism used inside Eclipse for updating Eclipse and installing new Eclipse bundles. It also works in a headless server environment.
We use p2 in the Eclipse Gyrex project to perform the automatic installation. The process is as follows:
Apply versioning manually in Eclipse (increase version number)
Export bundles into p2 repository (either from Eclipse or using Tycho/Maven)
Deploy p2 repository to web server
Client install update automatically
Each client periodically checks a p2 repository for updates and installs any available updates. The p2 repository is made available on an internal web server.
There are alternative options available for OSGi. For example, OBR is the approach recommended by the OSGi alliance. Unfortunately, p2 doesn't support OBR yet. But if you are using Apache Felix, you should be able to use OBR for your purposes.
Related
I've seen Building and deploying native code using Maven - but can't get this (very similar) deployment working as I'd like..
I have a C++ project that builds with Maven, and the Maven CMake Plugin. This involves several Maven profiles, to select the correct settings for the various C++ compilers I use on the platforms I'm building on. (Windows 10, Ubuntu 16.04, Ubuntu 18.04, CentOS 7, Raspbian, macOS High Sierra). I use Jenkins to run this build on the various VMs/Raspberry Pi - yielding a .tar.gz or .zip via the Maven Assembly Plugin. The final result is six archive files, that vary in their classifier/type. They all have the same groupId/artifactId.
I wanted each of these jobs to deploy its archive to Sonatype's OSSRH Nexus system, using the nexus-staging-maven-plugin.
I had this plugin configured to not automatically close the repository, so that the multiple builds could run via Jenkins (sequentially), and deploy to the same repo. I would then review this in the web UI, then Release or Drop it appropriately.
This worked fine, when the project had a version number of 0.0.1-SNAPSHOT. However, when I decided to (manually) release this, by setting the version to 0.0.1, and run my Jenkins builds... the deployment behaviour was different to what I'd seen when it was a SNAPSHOT.
Each platform-specific deployment created its own staging repository in the OSSRH Snapshots repo.
After reading https://github.com/sonatype/nexus-maven-plugins/tree/master/staging/maven-plugin, I have tried a variety of these settings, but nothing seems to work:
<skipStagingRepositoryClose>true</skipStagingRepositoryClose>
<skipStaging>true</skipStaging>
<autoReleaseAfterClose>false</autoReleaseAfterClose>
<stagingRepositoryId>${project.artifactId}-${project.version}-repo</stagingRepositoryId>
The nexus-staging:rc-open goal looks like it might help, allowing me to open a named staging repository (as I tried to do with stagingRepositoryId, above) - but it requires a staging profile id - I've used the rc-list-profiles goal to find mine - but when I give this to rc-open, it's reported as "missing or invalid".
It looks like this should be possible: https://github.com/sonatype/nexus-maven-plugins/blob/master/staging/maven-plugin/WORKFLOWS.md - this suggests that you can't create a new staging profile id; that they're allocated by Nexus.
Why is this mechanism different between SNAPSHOT and non-SNAPSHOT deployments?
Kind regards, Matt
I've updated https://stackoverflow.com/a/40954957/14731. Per point 6.6, SNAPSHOTs cannot be released atomically. There is no known workaround.
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.
I've developed a project that has a bundle whose only purpose is to write a file to a certain location on all of the containers running it.
This file will change often, but does not really constitute an increase in version number. I also don't want to have 100 versions of this bundle in my repository. So I have left it as a snapshot. This question would also apply if I was doing active development on a project for fuse fabric.
Once built, I deploy the bundle to my fabric's maven proxy with:
mvn deploy:deploy-file -Dfile=target/file-1.0-SNAPSHOT.jar -DartifactId=file -DgroupId=com.some.id -Dversion=1.0.0 -Dtype=bundle -Durl=http:// username:password#hostname:port/maven/upload
I can then add my bundle to a profile with:
mvn:com.some.id/file/1.0.0
This works the first time.
Then I make a change to the file, rebuild the bundle, and deploy with exactly the same command. I remove the bundle from the profile and add it back in. The maven proxy on the fabric server has the new bundle in it if I check $FUSE_HOME/data/maven/proxy/com/some/id/file/1.0.0/
But on all of the containers running the profile on a separate server, the bundle is not updated. I assume because the version has not changed. However, fabric should be smart enough to tell the difference, as the md5 should be different.
For now I can change the version number and my problem is solved, or clear the maven proxy by hand. But in production I will not be able to clear the proxy on every server, nor can I expect someone to come up with a unique version for the bundle every time they make a small change to this file (which should happen often).
I have already tried adding updatePolicy=always to the fabric maven configuration, but I believe that only affects repositories that it is pulling from, not the proxy.
Any advice on the best way to solve this problem is welcome.
If you are using containers, your old artefacts must be cached in
$FUSE_HOME/instances/CONTAINER_NAME/data/maven/agent/
Delete the old artefacts from here and stop/start your container.
I am working on a custom feature and did install it the Identity Server. After some fixes I wanted to re-install the feature, so what I did was 1) uninstall the feature, 2) restart server (graceful) 3) install the feature. The repository points to my local p2-repos which is generated in the build of maven.
The Identity Server does NOT accept the new feature. It is NOT showing any error in the console, neither in the web-admin. But when I test the feature I can see in the console and my debug outputs that the install-manager did not renew the jars.
My workaround now is to delete the whole server and do the install-process each time I want to try my code.
Can anyone confirm this bug?
If your feature is correctly installed, you can see your new jars in /repository/components/plugins directory. If not, Please copy all OSGI (jar files) in your feature in to /repository/components/dropins directory and restart the server. Also. you can use OSGI console to check whether bundles are properly activated.
Just start server with --DosgiConsole option. then you would promote a OSGI console. you can check whether new bundles are active or not.
I am new in Java and Continuous Integration. I want to setup a development environment using IntelliJ, Maven, GIT and JRebel (this was strongly recommended by a friend of mine). Tomcat Server is on AWS, not on my local Mac OS X machine. Is it possible to use GIT / JRebel and 'update' the remote project on the fly (after saving the files?). Which modules should I install on my Mac and which on Tomcat? Do I need Jenkins as well?
With JRebel Remoting, it is possible to push the changes to the remote applications, without having to configure any extra ports even. This is applicable if you would like to code something in the IDE, and then just push the changes to the remote application. But if you'd like to run the full test suite, then it is better to do via CI and then you will have quite different process - you will have to wait a bit longer until your changes become visible in the running app.