JBTIS-471 instead of hardcoding the build...

[nickboldt]

JBTIS-471 instead of hardcoding the build number as 212, let Jenkins set it dynamically and omit it for local builds

[psiroky]

Thanks for the fix @nickboldt!

I have few questions:

1. this needs to be hooked up into our Jenkins, correct (e.g. the isn't some other JBoss Tools Jenkins that would be building this as well)?
2. does the build number have to be unique? What happens if, for whatever reason, the counter is restarted? (e.g. the build job is lost and re-created from scratch and thus the build number starts from 1 again).
3. Should this be applied to all our SNAPSHOT builds? e.g. every single time we deploy we should increment?
4. What happens if we are deploying from local machine? Do we have to keep in mind to set those properties?

[nickboldt]

1. Yes, you need to set the profile when calling maven from Jenkins
2. The build number WILL be unique unless you delete the job and create a new one under the same name, thus resetting the counter. In that unlikely scenario, the datestamp will still be incremented so you'll still get unique (and newer) bits which OSGi will see as an update.
3. Yes. Why not?
4. If you deploy from your own machine, you can manually set a value of -DBUILD_NUMBER=1234 but IMHO you should never deploy from your own machine because there's no record of it and it's not reproduceable. You should deploy from Jenkins so there's a log & it's reproduceable.

[psiroky]

Thansk @nickboldt! As we talked on IRC I generally agree with this change. However, after playing a bit with this locally I'll need to figure out one more thing. We currently use tycho-versions:set-version -DnewVersion=<release-version> when changing versions for release. The <release-version> can be e.g. 6.4.0.CR1. This overrides the strings 6.4.0.qualifier in the category.xml. So in the end, the version of the bundles is 6.4.0.CR1 instead of 6.4.0.CR1-v'yyyyMMdd-HHmm. I'll try to look at this and in case I would get stuck, I'll ping you again :)

[nickboldt]

With the above second commit you get:

[INFO] Installing /home/nboldt/eclipse/workspace-eclipse/droolsjbpm-tools/drools-eclipse/org.drools.updatesite/target/org.drools.updatesite-6.4.0.Final.zip to /home/nboldt/.m2/repository1/org/drools/org.drools.updatesite/6.4.0.Final/org.drools.updatesite-6.4.0.Final.zip

So the resulting update site in nexus should be correctly named (assuming BUILD_ALIAS = Final).

---

Note that when dealing with tycho-built osgi plugins and features, instead of using

    mvn versions:set -DnewVersion=6.4.0.CR1

you want

    mvn -Dtycho.mode=maven org.eclipse.tycho:tycho-versions-plugin:0.24.0:set-version \
    -DnewVersion=6.4.0.CR1-SNAPSHOT

[psiroky]

Thanks @nickboldt, after our very long discussion I finally see all the things that need to happen. We should very likely separate the tooling build from the runtime one (for many reasons, which I will write up and share later...).

[kie-qe-ci]

Can one of the admins verify this patch?

[kie-qe-ci]

Can one of the admins verify this PR? Comment with 'ok to test' to start the build.