Bundle selection rules and repo best practices

[Matt Butler]

Hi,

Can someone provide a pointer to, or a quick explanation of, the rules that determine how a bundle is selected from a set of repos ?

My problem is specifically that I have two repos which both contain bundles with the same bsn, with similar version numbers (ie. one is 1.0.0.A6C9D67 and the other is 1.0.0.0134B97  )

I was hoping that the order of the repos in the repositories.bnd file would control which would get picked first, but I fear (and I'm seeing results that tell me ) that's not the case.

Here is what I want to accomplish

- We have two workspaces, one for "common" bundles and one for product specific bundle. (we will eventually have many more product specific repos)

- We have an automated build system such that when things are checked in, they are built and the bundles produced are placed into a "common" repo

- The product workspaces point at the common repo on the build server

Now, if I want to make a change to a common bundle I want to be able to make the change locally and then build and test the product POINTING TO A LOCAL VERSION OF THE MODIFIED BUNDLE

The idea is to have the repositories.bnd file point to both a local repo (which the recently modified bundle(s)) and the remote repo (which contains the previous version of the bundle(s)) and that I can get bnd to pick the local one ahead of the remote one.

Thoughts ?

matt

[BJ Hargrave]

bnd will probably pick the highest version number regardless order of repos. The version ordering includes the qualifier (4th component) so people often use something like build time stamp to order the built bundles in chronological order. I am not sure what your qualifiers are based upon the examples shown. If your qualifier was a build time stamp, then the local version would have been built later than the bundle in the common repo and would be the highest version.

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 

BJ

[Matt Butler]

That 4th qualifier is a Git Hash, so obviously not so good.

matt

[BJ Hargrave]

On May 20, 2015, at 09:46 , Matt Butler <matt.s...@gmail.com> wrote:

That 4th qualifier is a Git Hash, so obviously not so good.

Having the git sha as the qualifier is not good since it has no ordering. But you can add the git sha at then end of the qualifier if the beginning is a build time time stamp (in a format suitable for lexical sorting).

Bundle-Version: 1.0.0.${tstamp;yyyyMMddHHmm}-${system-allow-fail;git rev-list -1 HEAD}

[Ferry Huberts]

On 20/05/15 15:52, BJ Hargrave wrote:

On May 20, 2015, at 09:46 , Matt Butler <matt.s...@gmail.com> wrote:

That 4th qualifier is a Git Hash, so obviously not so good.

Having the git sha as the qualifier is not good since it has no ordering. But you can add the git sha at then end of the qualifier if the beginning is a build time time stamp (in a format suitable for lexical sorting).

Bundle-Version: 1.0.0.${tstamp;yyyyMMddHHmm}-${system-allow-fail;git rev-list -1 HEAD}

Using tstamp is for ordering is not such a good idea, especially when multiple people are building the bundle.
If you use git, the best thing to do is to use

Bundle-Version: 1.0.0.${system-allow-fail;git describe --dirty --always}

That will ensure a properly ordered version qualifier that is guaranteed to be unique.

-- 
Ferry Huberts