Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

ISSUE : Wrong Bundle Location in Felix Console after Deployment

Avatar

Level 2

Hello

When i do a deployment on my servers, the bundle location is the following: jcrinstall:/apps/all/install/all-libs-8.0.0-SNAPSHOT.jar . But the actual version is 9.1.1.SNAPSHOT. So shouldnt the bundle location not be jcrinstall:/apps/all/install/all-libs-9.1.1-SNAPSHOT.jar ? That the bundle work, i have to uninstall it and reinstall it by hand then it works and the path is correct. But by building it automaticly the path is incorrect.

Does any one have an idea why it is like that?

1 Accepted Solution

Avatar

Correct answer by
Employee

The bundle location should be a treated as an opaque identifier. Don't think of it "pointing" to anything. The version of the bundle should be determined by using the version, not the location.

View solution in original post

9 Replies

Avatar

Employee

This is the expected behavior. Performing an *update* on a bundle does not change its location. See http://dev.day.com/content/ddc/blog/2010/01/bundleidentification.html

Avatar

Level 2

But i deploy my bundles with maven clean install. So actually, i am not doing an update. But it does not change.

Avatar

Employee

Right, but you already have the bundle installed. So when you install a new version, the bundle is being updated. Both the Content Packages and the OSGI Console will automatically choose to perform an update if possible.

Avatar

Level 2

So you mean to solve this problem i always have to uninstall the bundles and reinstall them ? or do you know another way to solve it ? Or can i force the OSGI Console to install it new and not to update?

Avatar

Employee

As I said - you are seeing the expected behavior. In what way is this problematic?

Avatar

Level 2

We're building the CQ Project with Jenkins on a development server. It's an automated build (every 1 hour, if there is a svn change). The Problem also exist, when i install the package manually on our productive servers.

Avatar

Employee

I think you're missing my point. The fact that the bundle location does not change during your deployments is expected and is not a problem. If the bundle location changed during a deployment, that would be a problem as it would be specification violation.

Avatar

Level 2

So do we always have the latest sourcecode even if the bundle location doesnt point on the latest version ?

Avatar

Correct answer by
Employee

The bundle location should be a treated as an opaque identifier. Don't think of it "pointing" to anything. The version of the bundle should be determined by using the version, not the location.