Changes between Version 79 and Version 80 of BuildSystem


Ignore:
Timestamp:
12/15/12 22:39:08 (6 years ago)
Author:
welberge
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BuildSystem

    v79 v80  
    1919== IDE integration 
    2020 * [[UsingAsapRealizerInEclipse|Eclipse]] 
    21  * [[UsingTheBuildSystemInNetBeans|!NetBeans]] 
    22  * [[UsingTheBuildSystemInIntelliJ|!IntelliJ]] 
    23  
    24 === How does it work? === 
    25 Every project has an "ivy.xml" file that describes project dependencies. The 
    26 ant build files, relying on the Ivy system, use these so called "ivy's" for resolving 
    27 the contents of the project's lib directory. The system is based upon the 
    28 notion of configurations, versions, and status of versions. For example, our 
    29 build system uses "alpha", "daily build", and "release" as possible status of some 
    30 jar version. The ordering of these statuses is relevant. For instance, when you 
    31 ask for a "latest beta" version of some module Ivy will choose the latest amongst 
    32 published daily releases and release (but not alpha) versions of that module. Similarly, if 
    33 you ask for a "latest alpha", anything is acceptable, but if you ask for a "latest 
    34 release", then only versions classified as "release" are taken into consideration. 
    35 Ivy allows for several "configurations" of the project, each with its own set 
    36 of dependencies. Currently, we have configurations for producing alpha, daily build, 
    37 and release versions of the project itself, and a "test" configuration for (extra) 
    38 dependencies needed for running tests. (For technical reasons we have two more 
    39 configurations, called "master" and "default", which are discussed below) The 
    40 workflow is roughly as follows: first move the project into either the alpha, 
    41 beta or release configuration, second do your development, including testing 
    42 etc, third publish an alpha, beta or normal release based upon the current 
    43 configuration. When you actually publish, we attach a version number to the 
    44 jar file. Also, the Ivy system records metadata concerning published modules 
    45 based upon version numbers, to be used later on, when resolving for other 
    46 projects. It does so by publishing not just a "jar" file (or other "artifacts", as 
    47 they are called by Ivy), but also an accompanying ivy.xml file, derived from 
    48 the project's ivy at the moment of publication. In this way, the Ivy system 
    49 knows not only about direct dependencies, but is also capable of resolving 
    50 recursive dependencies. This means that, for instance, when my module X 
    51 declares (just) a dependency on the !HmiGraphics package, the resolve process 
    52 will look into the dependencies of !HmiGraphics. The result is that project 
    53 X will receive jar files for !HmiGraphics, but also for !HmiAnimation, !HmiXml, 
    54 !HmiMath, and !HmiUtil, because of (recursive) dependencies. When some jar 
    55 file is required more than once, say via a direct dependency and also via some 
    56 indirect dependency, and the versions required are not consistent, then Ivy 
    57 delivers the "latest" version. So, for instance, in the example above, if project 
    58 X declares (direct) dependencies on the alpha version of !HmiGraphics and the 
    59 release version of !HmiXml, while the alpha version of !HmiGraphics declares itself 
    60 a dependency on the beta version of !HmiXml, then project X will receive that 
    61 beta version of !HmiXml. That should be ok: since we are asking for some alpha 
    62 version (of !HmiGraphics, we should allow other alpha and/or beta versions if 
    63 !HmiGraphics actually needs them, even if our own project would be satisfied 
    64 with the most recent release version. 
     21 * [[UsingTheBuildSystemInNetBeans|NetBeans]] 
     22 * [[UsingTheBuildSystemInIntelliJ|IntelliJ]] 
    6523 
    6624== More ==