| Re: [tycho-user] Conditional checkout of component prior to build |
|
The way I see it is that SCM is something which should be handled outside of the mvn build, e.g. by a Jenkins job. There is one case (build timestamps) where
the build reads information from the SCM history, but it certainly shouldn’t perform any writing SCM operations. Things that you want to build together should also be in one SCM repository. Then, the SCM checkout shouldn’t be a big deal. Regards Tobias From: tycho-user-bounces@xxxxxxxxxxx [mailto:tycho-user-bounces@xxxxxxxxxxx]
On Behalf Of Alex Kravets Hello, In the past I asked this question on this mailing list and other forums, but couldn't find the solution that I needed. Consider the following scenario. Product you are building consist of usual svn structure: branches, tags and trunk. Your main line code is in the trunk that consists of pluginA and pluginB. In order to add a feature you branch pluginB to
branchB. When you build your product you need to define where components are coming from. The obvious way to build product so that pluginA comes from trunk and pluginB comes from branch is to define two SCM locations in Jenkins for example that reference pluginA
from trunk and pluginB from branchB. This might work fine for small projects, but what about projects that consist of 100+ components? In our product we have 103 Eclipse plugins/features that we build with Tycho in Jenkins, and having 103 SCM locations is
just not practical. As I said, I don't if conditional checkout exists in Maven/Tycho in form of a plugin - I couldn't find one. Prior to switching to Tycho we were building our Eclipse product using Buckminster. One of the nice features that Buckminster has is a notion of advisors. For a quick example on what advisors do please refer to a blog post I wrote a while
back [1]. For my Tycho builds I decided to replicate notion of advisors. A basic diagram of the conditional checkout is shown here [2]. The idea is as follows: 1. Jenkins calls build.xml as pre-execution step, before parent POM is executed 2. build.xml prepares properties for groovy script and calls it 3. Collection of modules (modules[]) from parent POM is created, this collection will be used for checkout 4. Groovy script reads .query file and constructs map of modules:branches[] 5. For each modules[i] in collection in (3) svn url is created from branches[i] created in (4). 6. Created url is tested by executing svn info command and if there is no exception it means such location exists and will be used as a checkout url for module being tested. If it does not exist (exception) next branches[i] is considered
for this modules[i]. Once all branches[i] were tested and no svn location exists for it, location from trunk will be used as svn url for checkout 7. For the rest of modules[i] steps 5 and 6 is repeated and eventually workspace is populated with components from trunk and branch(es). In my example pluginA will be from trunk and pluginB will be from branchB I tried to comment my script as much as possible and it's tailored to my setup where parent POM along with the groovy script, build.xml and .query file reside in plugin that ends with .parent. Here is the list of script file and supporting files: groovy script: http://paste.ubuntu.com/5986357/ build.xml: http://pastebin.mozilla.org/2855957 advisors.query: http://pastebin.mozilla.org/2855960 The reason I wrote this email is to suggest, again if it does not exist, a proposal for such conditional checkout prior to Tycho build execution. This can be done as Maven plugin and I think this would be beneficial to some users. Some
enhancements can be done, such use of regular expressions in advisor.query for easier component match, as well as eventually addition of tags location in addition to branches. Lastly, I was trying to add execution of the Groovy script to be part of parent POM rather than an ANT script, so if someone can give me pointers on how to do this, I would really appreciate it. Regards, Alex |