Changes between Version 1 and Version 2 of BuildPhilosophy


Ignore:
Timestamp:
12/15/12 22:39:42 (7 years ago)
Author:
welberge
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BuildPhilosophy

    v1 v2  
    1 == Build philosophy == 
     1= Build philosophy = 
    22It is often necessary to (re)build projects, even by persons who didn’t develop that project. Since many different tools are being used, we have to agree on a number of basic conventions and procedures. 
    33 
     
    2929and error prone. Instead, we use a dependency manager, 
    3030[[http://ant.apache.org/ivy/|Ivy]]. 
     31 
     32== How does it work? == 
     33Every project has an "ivy.xml" file that describes project dependencies. The 
     34ant build files, relying on the Ivy system, use these so called "ivy's" for resolving 
     35the contents of the project's lib directory. The system is based upon the 
     36notion of configurations, versions, and status of versions. For example, our 
     37build system uses "alpha", "daily build", and "release" as possible status of some 
     38jar version. The ordering of these statuses is relevant. For instance, when you 
     39ask for a "latest beta" version of some module Ivy will choose the latest amongst 
     40published daily releases and release (but not alpha) versions of that module. Similarly, if 
     41you ask for a "latest alpha", anything is acceptable, but if you ask for a "latest 
     42release", then only versions classified as "release" are taken into consideration. 
     43Ivy allows for several "configurations" of the project, each with its own set 
     44of dependencies. Currently, we have configurations for producing alpha, daily build, 
     45and release versions of the project itself, and a "test" configuration for (extra) 
     46dependencies needed for running tests. (For technical reasons we have two more 
     47configurations, called "master" and "default", which are discussed below) The 
     48workflow is roughly as follows: first move the project into either the alpha, 
     49beta or release configuration, second do your development, including testing 
     50etc, third publish an alpha, beta or normal release based upon the current 
     51configuration. When you actually publish, we attach a version number to the 
     52jar file. Also, the Ivy system records metadata concerning published modules 
     53based upon version numbers, to be used later on, when resolving for other 
     54projects. It does so by publishing not just a "jar" file (or other "artifacts", as 
     55they are called by Ivy), but also an accompanying ivy.xml file, derived from 
     56the project's ivy at the moment of publication. In this way, the Ivy system 
     57knows not only about direct dependencies, but is also capable of resolving 
     58recursive dependencies. This means that, for instance, when my module X 
     59declares (just) a dependency on the !HmiGraphics package, the resolve process 
     60will look into the dependencies of !HmiGraphics. The result is that project 
     61X will receive jar files for !HmiGraphics, but also for !HmiAnimation, !HmiXml, 
     62!HmiMath, and !HmiUtil, because of (recursive) dependencies. When some jar 
     63file is required more than once, say via a direct dependency and also via some 
     64indirect dependency, and the versions required are not consistent, then Ivy 
     65delivers the "latest" version. So, for instance, in the example above, if project 
     66X declares (direct) dependencies on the alpha version of !HmiGraphics and the 
     67release version of !HmiXml, while the alpha version of !HmiGraphics declares itself 
     68a dependency on the beta version of !HmiXml, then project X will receive that 
     69beta version of !HmiXml. That should be ok: since we are asking for some alpha 
     70version (of !HmiGraphics, we should allow other alpha and/or beta versions if 
     71!HmiGraphics actually needs them, even if our own project would be satisfied 
     72with the most recent release version.