I'm having troubles updating my bundle from the gogo shell.
I have a gogo shell running on terminal. My bundles are active in there.
Now when I make changes to the code, what steps are necessary to forward these changes into the running OSGi framework?
I ran update <bundleId> but nothing happens. It still runs the same version which was compiled when I started the framework.
Before the update command I opened another terminal and ran mvn clean install (I'm using maven-bundle-plugin along with pax-construct).
When working with Maven, my workflow for checking updated code involves two terminals.
After updating the code, I run mvn install from the project which will build the actual bundle. Keep track of the absolute location on your system where the target bundle is built.
In the running framework, I update the bundle, giving it a URL; something like update 25 file:///Users/you/project/bundle/target/bundle.jar
If you're free not to use Maven and Pax Runner, you can also take a look at bndtools, which is an Eclipse plugin. You can then still take the bundles that bndtools builds for you, and run them with Pax Runner.
Another try is via OBR local repo as follows:
- assume artifact is called test-api, then
a)g! deploy test-api deployed under id: 25
after further changes made to the code and mvn clean install do:
1)g! update 252)g! refreshif no result then before step 1) try g! repos refresh file:///c:/Users/.m2/repository.xml to refresh local OBR repo
Related
So I have a Maven project and I'd like to deploy it on Heroku via Github. To be more precise I want to use automatic deployments where when I push to my master branch only then is it deployed. The only thing I found for Maven is that I add a dependency and it would deploy to Heroku from my machine (which I essentially don't want).
I really don't know what else to say as I had 0 progress. For now I am just pushing my target as well and then just running the target jar file. But I'd like to just send over my source code and for Heroku to build the project.
Alright, so I found my solution.
I saw an example (I can't find it now, no luck) for Heroku that build the project with a thing called mvnw script which is a Maven wrapper when it's not installed on the system. I added it and the .mvn directory but it didn't start by itself like how it is written on Heroku (it should run it when it's detected), no problem really.
I then edited my Procfile and instead of:
web: java -jar target/my-file.jar
I am using:
web: ./mvnw clean package; java -jar target/my-file.jar
And everything works well!
You only need to integrate your GitHub repository on Heroku, and define the automated deployment of the master branch (each push will trigger a deployment).
Heroku will build the JAR and take care of the deployment, you need though to define the Java version in a system.properties and create an Uber-Jar (ie including all dependencies).
I have eclipse ide with m2e plugin, maven and weblogc app server running from my local box.
I have imported someone else's multiple maven projects from bitbucket to my box. I was told that one of them is main and rest are dependencies in which I never seen anything like that before. I have always dealt with single maven project. Anyhow from the instruction, it says I have to run maven command such as "clean install -U".
In the IDE so I touched run configuration for each mvn project by setting goal as "clean install -U". By reading maven guide, I kind understand what each term means but when you combine together with a passing parameter, what does it do actually? I didn't expect a jar (web app) to be deployed to an application server but it did also.
-U forces maven to check any external dependencies (third party dependencies) that might need to be updated based on your POM files.
clean install are both basic maven lifecycle phases (https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html).
install normally would simply take the artifact that is built and put it in the local repository, i.e. a directory on the box you are building on (.m2 directory most of the time). It would not do a deployment to a server - typically the deploy phase would be used to do that.
However, developers can override and add to what maven does in the various phases, so just like in the days of ant things can easily devolve into chaos no one can understand on complex projects ;-).
sometimes in the integration-test phase, developers will tell maven to start up a container temporarily to run the web app on, so that tests can be run against it, and then that container is shut down when the integration-test phase completes.
I have created a Fuse integration project in developer studio 9.0.2 and I'm using jboss-fuse-karaf-6.3.0 as the runtime container.
I want to deploy this project using Maven, but not able to figure out -
How and where to give server URL, user name and password for the deployment ?
Does project gets deployed to fabric or karaf ?
Will appreciate if anybody can help with some pointers.
Thanks in advance.
Is that server running locally or remote?
Locally you can simply define the server in the servers view and then use Add context menu to deploy your project.
it gets deployed to Karaf
When building projects with Maven I use osgi:install and dev:watch commands (available in both JBoss Fuse and vanilla Karaf). The following setup works well for a development machine.
First build with Maven using install goal, so the artifact gets installed in local repository.
Then issue osgi:install (see Manual Deployment in JBoss Fuse docs) command in your container to install your bundle. Job done!
> osgi:install mvn:it.your.package/your-artifact/1.0.0
Once the bundle is installed you will see a message like
Bundle ID: 352
This is the ID of the bundle installed. Issue the following command:
> dev:watch 352
Watched URLs/IDs:
352
Now every time you rebuild with Maven, the bundle gets redeployed automatically.
Watch out some settings to be changed if dev:watch does not reload bundles on JBoss Fuse 6.3.0
edit: use -SNAPSHOT in your version with this setup. Regular versionsmay not redeploy correctly because the container sees the version is the same and may use previously loaded classes, thus causing classloading issues.
I've created by first project for karaf (4.0.1). So far I've got the following:
an application bundle built with the maven-bundle-plugin. There are going to be more...
a karaf feature created with the karaf-maven-plugin.
a karaf-assembly created with the same plugin
So I'm ready to deliver to the customer - but I'm stuck over the development process. This question answered almost all my remaining questions save one:
After having built my project by running maven install I think I should be able to to get my feature running on a local karaf instance using something like the command feature:install.
I can install my application bundle from local maven by using bundle:install but then I'm down to managing dependencies myself.
Really can't figure out while bundle:install works against my local maven repository and feature:install doesn't.
Found the soloution here. I knew I'd need feature:repo-add - but the name of this command and the official documentation sent me thinking in entirely the wrong direction.
This command does not add a (maven) repository, but adds the location of a feature in the maven repository chain (so I'm thinking the old name addUrl was probably easier to understand).
Anyway - using feature:repo-add mvn:<groupId>/<artifactId>/<version>/xml/features works.
I've just had the similar issue and I've found solution here: http://karaf.922171.n3.nabble.com/Add-additional-local-maven-repository-how-td4028299.html
I've edited the etc/org.ops4j.pax.url.mvn.cfg and uncommented the option org.ops4j.pax.url.mvn.localRepository, setting it to my local repository location:
org.ops4j.pax.url.mvn.localRepository=C:/data/maven-repo
Before installing a feature, you have to register the features repository that provides the feature using feature:repo-add
using feature:repo-add mvn:<groupId>/<artifactId>/<version>/xml
I decided to build an application on top of OSGI and Karaf - I really like this stuff. However, I'm struggling a bit with a daily deployment on my local, development machine. I mean.. I make a change and then I would like to test it on my local Karaf instance. And it can happen like couple times per hour.
The way I'm doing it now is a maven build that creates a JAR bundle and then it's copied into the Karaf's deploy directory. I think that it isn't elegant at all.
I was trying to find a way around (google). I read about Karaf's features but it seems that despite the fact that it is a nice mechanism for deploying whole app, it doesn't solve my problem. As I understand it right, it does not check whether new version of my SNAPSHOT jar appeared in my local maven repo, right?
The key to make the update mechanism of karaf work is to deploy from maven instead of using the deploy folder.
Install you bundle like this:
install -s mvn:groupid/artifactID/version
or
install -s mvn:groupid/artifactID/version/typeOfMavenArtifact
Second one is useful for installing for example war/wab artifacts. Full maven protocol specification can be found here.
Then Karaf knows where the bundle came from. You can also check this using la -u. This makes karaf show the update location which now should be a maven uri. You will not that all karaf bundles have an update location like this.
When you now create a new build of your project using maven it will end up in you local maven repository.
Then simply run
update <bundleid>
This makes karaf check the update location (in your case you local maven repo) and reload the bundle from there.
You can even further automate this by using
dev:watch
or for karaf 3+
bundle:watch
This will make karaf check you maven repo for changes in SNAPSHOT bundles it has deployed and automatically redeploy these.
This also works very well together with the remote debugging. Use
export KARAF_DEBUG=true
before starting karaf. It then will listen for a debugger on port 5005.
You can then start a remote debug eclipse session on the same port and nicely debug your application in karaf. This works very well even if you change your bundle using one of the approaches above. So you can debug, find your problem, change the code, build and continue debugging with the changed version.
I also use this frequently when I work at the karaf code base itself as this also works for most of karaf's own bundles.