Added: ant/ivy/site/target/history/2.2.0-rc1/terminology.html URL: http://svn.apache.org/viewvc/ant/ivy/site/target/history/2.2.0-rc1/terminology.html?rev=961685&view=auto ============================================================================== --- ant/ivy/site/target/history/2.2.0-rc1/terminology.html (added) +++ ant/ivy/site/target/history/2.2.0-rc1/terminology.html Thu Jul 8 10:00:21 2010 @@ -0,0 +1,168 @@ + + + + + + + + +Terminology | Apache Ivy + + + + + + + + + + +
+ + + + + + + + + + + + + +
+ +
+ +
+ + + + +
+ + +
+ + +
+ + + + + + + +
+
+ +

Terminology

+
Here are some terms used in Ivy, with their definitions in Ivy: + + +

Overview

+The following illustration shows all the key terminology in one diagram:

terminology illustration

+ +

Organisation

+An organisation is either a company, an individual, or simply any group of people that produces software. In principle, Ivy handles only a single level of organisation, meaning that they have a flat namespace in Ivy module descriptors. So, with Ivy descriptors, you can only describe a tree-like organisation structure, if you use a hierarchical naming convention. The organisation name is used for keeping together software produced by the same team, just to help locate their published works.

Often organisations will use their inverted domain name as their organisation name in Ivy, since domain names by definition are unique. A company whose domain name is www.example.com might want to use com.example, or if they had multiple teams, all their organisation names could begin with com.example (e.g. com.example.rd, com.example.infra, com.example.services). The organisation name does neither really have to be an inverted domain name, nor ev en globally unique, but unique naming is highly recommended. Widely recognized trademark or trade name owners may choose to use their brand name instead.

Examples: org.apache, ibm, jayasoft

Note that the Ivy "organisation" is very similar to Maven POM "groupId".
+

Module

+A module is a self-contained, reusable unit of software that, as a whole unit, follows a revision control scheme.

Ivy is only concerned about the module deliverables known as artifacts, and the module descriptor that declares them. These deliverables, for each revision of the module, are managed in repositories. In other words, to Ivy, a module is a chain of revisions each comprising a descriptor and one or more artifacts.

Examples: hibernate-entitymanager, ant

Module Descriptor

+A module descriptor is a generic way of identifying what describes a module: the identifier (organisation, module name, branch and revision), the published artifacts, possible configurations and their dependencies.

The most common module descriptors in Ivy are Ivy Files, xml files with an Ivy specific syntax, and usually called ivy.xml.

But since Ivy is also compatible with maven 2 metadata format (called pom, for Project Object Model), pom files fall into the category of module descriptors.

And because Ivy accepts pluggable module descriptor parsers, you can use almost whatever you want as module descriptors.

Artifact

+An artifact is a single file ready for delivery with the publication of a module revision, as a product of development.

Compressed package formats are often preferred because they are easier to manage, transfer and store. For the same reasons, only one or a few artifacts per module are commonly used. However, artifacts can be of any file type and any number of them can be declared in a single module.

In the Java world, common artifacts are Java archives or JAR files. In many cases, each revision of a module publishes only one artifact (like jakarta-log4j-1.2.6.tar.gz, for instance), but some of them publish many artifacts dependending on the use of the module (like apache-ant binary and source distributions in zip, gz and bz2 package formats, for instance).

Examples: ant-1.7.0-bin.zip, apache-ant-1.7.0-src.tar.gz

Type of an artifact

+The artifact type is a category of a particular kind of artifact specimen. It is a classification based on the intended purpose of an artifact or why it is provided, not a category of packaging format or how the artifact is delivered.

Although the type of an artifact may (rather accidentally) imply its file format, they are two different concepts. The artifact file name extension is more closely associated with its format. For example, in the case of Java archives the artifact type "jar" indicates that it is indeed a Java archive as per the JAR File specification. The file name extension happens to be "jar" as well. On the other hand, with source code distributions, the artifact type may be "source" while the file name extensions vary from "tar.gz", "zip", "java", "c", or "xml" to pretty much anything. So, the type of an artifact is basically an abstract functional category to explain its purpose, while the artifac t file name extension is a more concrete technical indication of its format and, of course, naming.

Defining appropriate artifact types for a module is up to its development organisation. Common choices may include: "jar", "binary", "bin", "rc", "exe", "dll", "source", "src", "config", "conf", "cfg", "doc", "api", "spec", "manual", "man", "data", "var", "resource", "res", "sql", "schema", "deploy", "install", "setup", "distrib", "distro", "distr", "dist", "bundle", etc.

Module descriptors are not really artifacts, but they are comparable to an artifact type, i.e. "descriptor" (an ivy file or a Maven POM).

Electronic signatures or digests are not really artifacts themselves, but can be found with them in repositories. They also are comparable to an artifact type, i.e. "digest" (md5 or sha1).

Artifact file name extension

+In some cases the artifact type already implies its file name extension, but not always. More generic types may include several different file formats, e.g. documentation can contain tarballs, zip packages or any common document formats.

Examples: zip, tar, tar.gz, rar, jar, war, ear, txt, doc, xml, html

Module Revision and Status

+

Module revision

+A unique revision number or version name is assigned to each delivered unique state of a module. Ivy can help in generating revision numbers for module delivery and publishing revisions to repositories, but other aspects of revision control, especially source revisioning, must be managed with a separate version control system.

Therefore, to Ivy, a revision always corresponds to a delivered version of a module. It can be a public, shared or local delivery, a release, a milestone, or an integration build, an alpha or a beta version, a nightly build, or even a continuous build. All of them are considered revisions by Ivy.

Source revision

+Source files kept under a version control system (like Subversion, CVS, SourceSafe, Perforce, etc.) have a separate revisioning scheme that is independent of the module revisions visible to Ivy. Ivy is unaware of any revisions of a module's source files.

In some cases, the SCM's source revision number could be used also as the module revision number, but that usage is very rare. They are still two different concepts, even if the module revision number was wholly or partially copied from the respective source revision number.

Branch

+A branch corresponds to the standard meaning of a branch (or sometimes stream) in source control management tools.
The head, or trunk, or main stream, is also considered as a branch in Ivy.

Status of a revision

+A module's status indicates how stable a module revision can be considered. It can be used to consolidate the status of all the dependencies of a module, to prevent the use of an integration revision of a dependency in the release of your module.

Three statuses are defined by default in Ivy: +
    +
  • integration: revisions builded by a continuous build, a nightly build, and so on, fall in this category
  • +
  • milestone: revisions delivered to the public but not actually finished fall in this category
  • +
  • release: a revision fully tested and labelled fall in this category
  • +
+Since 1.4 This list is configurable in your settings file.

Configurations of a module

+A module configuration is a way to use or construct a module. If the same module has different dependencies based on how it's used, those distinct dependency-sets are called its configurations in Ivy.

Some modules may be used in different ways (think about hibernate which can be used inside or outside an application server), and this way may alter the artifacts you need (in the case of hibernate, jta.jar is needed only if it is used outside an application server).
Moreover, a module may need some other modules and artifacts only at build time, and some others at runtime. All those different ways to use or build a module are called module configurations in ivy.

For more details on configurations and how they are used in ivy, please refer to the main concepts page.

Ivy Settings

+Ivy settings files are xml files used to configure ivy to indicate where the modules can be found and how.

History of settings

+Prior to Ivy 2.0, the settings files were called configuration files and usually named ivyconf.xml. This resulted in confusion between module configurations and Ivy configuration files, so they were renamed to settings files. If you happen to fall on an ivyconf file or something called a configuration file, most of the time it's only unupdated information (documentation, tutorial or article). Feel free to report any problem like this if you find such an inconsistency.

Repository

+What is called a repository in Ivy is a distribution site location where Ivy is able to find your required modules' artifacts and descriptors (i.e. Ivy files in most cases).
Ivy can be used with complex repositories configured very finely. You can use Dependency Resolvers to do so.
+
+
+ + + + + + + + + + + + +
+ + Propchange: ant/ivy/site/target/history/2.2.0-rc1/terminology.html ------------------------------------------------------------------------------ svn:mime-type = text/plain Added: ant/ivy/site/target/history/2.2.0-rc1/textual.html URL: http://svn.apache.org/viewvc/ant/ivy/site/target/history/2.2.0-rc1/textual.html?rev=961685&view=auto ============================================================================== --- ant/ivy/site/target/history/2.2.0-rc1/textual.html (added) +++ ant/ivy/site/target/history/2.2.0-rc1/textual.html Thu Jul 8 10:00:21 2010 @@ -0,0 +1,196 @@ + + + + + + + + +Text Conventions | Apache Ivy + + + + + + + + + + +
+ + + + + + + + + + + + + +
+ +
+ +
+ + + + +
+ + +
+ + +
+ + + + + + + +
+
+ +

Text Conventions

+
Very often some concepts discussed in Ivy here, and especially those involving modules and dependencies, require to be discussed by text (e-mail, textual doc, console, ...), and so benefit from convention in this area.

The conventions have been adopted with Ivy 2.0 are the following: + + + + + + + + + + + + + + + + + + + + + + + + + + +
+what
+pattern
+example
+a module without revision
+[organisation]#[module]
+org.apache.ant#ant
+a module with revision
+[organisation]#[module];[revision]
+org.apache.ant#ant;1.7.0
+a module with (some) configurations
+[organisation]#[module][ [confs] ]
+org.apache.ant#ant[master,compile,build]
+a module with revision and (some) configurations
+[organisation]#[module];[revision][ [confs] ]
+org.apache.ant#ant;1.7.0[master,compile,build]
+a module's artifact
+[organisation]#[module]![artifact].[ext]([type])
+org.apache.ant#ant!ant.jar(source)
+a module's artifact with revision
+[organisation]#[module];[revision]![artifact].[ext]([type])
+org.apache.ant#ant;1.7.0!ant.jar(source)
+
+Another usual text representation used is to represent dependencies using a dash followed by greater than sign: ->

To group a set of set of modules, we recommend using curly braces { }

With these conventions, it's easy to give a concise and detailed overview of a set of modules and their dependencies.

For instance: +
+#A;2-> { #B;[1.0,1.5] #C;[2.0,2.5] }
#B;1.4->#D;1.5
#B;1.5->#D;2.0
#C;2.5->#D;[1.0,1.6] +
+In full words here is how it could be written: +
+module A revision 2 depends on module B with the version constraint [1.0,1.5], and on module C with the version constraint [2.0,2.5].
module B revision 1.4 depends on module D revision 1.5.
module B revision 1.5 depends on module D revision 2.0.
module C revision 2.5 depends on module D with the version constraint [1.0,1.6]. +
+ +As you can see, using text conventions is much more concise.

Another benefit is that these conventions are usually used in Ivy console output, and can also be used in some cases to be parsed into Ivy objects (we use it for test cases for instance). To make sure text parsing works fine, we recommend using only a limited range of characters for each attributes of your module identifiers.

Here is the recommended characters set for each attribute: +
    +
  • organisation
  • a-z A-Z 0-9 - / . _ + = +
  • module
  • a-z A-Z 0-9 - / . _ + = +
  • branch
  • a-z A-Z 0-9 - / . _ + = +
  • revision
  • a-z A-Z 0-9 - / . _ + = , [ ] { } ( ) : @ +
  • artifact
  • a-z A-Z 0-9 - / . _ + = +
  • extension
  • a-z A-Z 0-9 - / . _ + = +
  • type
  • a-z A-Z 0-9 - / . _ + = +
+ +
+
+ + + + + + + + + + + + +
+ + Propchange: ant/ivy/site/target/history/2.2.0-rc1/textual.html ------------------------------------------------------------------------------ svn:mime-type = text/plain Added: ant/ivy/site/target/history/2.2.0-rc1/tutorial.html URL: http://svn.apache.org/viewvc/ant/ivy/site/target/history/2.2.0-rc1/tutorial.html?rev=961685&view=auto ============================================================================== --- ant/ivy/site/target/history/2.2.0-rc1/tutorial.html (added) +++ ant/ivy/site/target/history/2.2.0-rc1/tutorial.html Thu Jul 8 10:00:21 2010 @@ -0,0 +1,152 @@ + + + + + + + + +Tutorials | Apache Ivy + + + + + + + + + + +
+ + + + + + + + + + + + + +
+ +
+ +
+ + + + +
+ + +
+ + +
+ + + + + + + +
+
+ +

Tutorials

+
The best way to learn is to practice! That's what the ivy tutorials will help you to do, to discover some of the great ivy features.

Here is the very first tutorial, it doesn't even require to install Ivy, and should not take more than 30 seconds if you already have ant and a jdk properly installed: +
    +
  • make sure you have ant 1.6.0 or greater and a jdk properly installed
  • +
  • copy this build file in an empty directory on your local filesystem (and make sure you name it build.xml)
  • +
  • open a console in this directory and run "ant". That's it!
  • +
+If you have any trouble, check the FAQ, it may be related to your internet connection (proxy anyone?).

OK, you've seen how easy it is to make your first step with ivy? Go ahead with the other tutorials, but before make sure you have properly installed ivy and downloaded the tutorials sources (included in all ivy distributions, in the src/example directory).

The following tutorials are available: + + +
+
+ + + + + + + + + + + + +
+ + Propchange: ant/ivy/site/target/history/2.2.0-rc1/tutorial.html ------------------------------------------------------------------------------ svn:mime-type = text/plain Added: ant/ivy/site/target/history/2.2.0-rc1/tutorial/build-repository.html URL: http://svn.apache.org/viewvc/ant/ivy/site/target/history/2.2.0-rc1/tutorial/build-repository.html?rev=961685&view=auto ============================================================================== --- ant/ivy/site/target/history/2.2.0-rc1/tutorial/build-repository.html (added) +++ ant/ivy/site/target/history/2.2.0-rc1/tutorial/build-repository.html Thu Jul 8 10:00:21 2010 @@ -0,0 +1,133 @@ + + + + + + + + +Building a repository | Apache Ivy + + + + + + + + + + +
+ + + + + + + + + + + + + +
+ +
+ +
+ + + + +
+ + +
+ + +
+ + + + + + + +
+
+ +

Building a repository

+
The install task let you copy a module or a set of modules from one repository to another one. This is very useful to build and maintain a enterprise or a team repository. If you don't want to give access to the public maven 2 repository to the developers in your team (to keep control over which modules are in use in your company or your team for instance), it can sometimes become tiresome to answer the developers request to add new modules or new versions by hand.

Fortunately the install task is here to help: you can use specific settings for your repository maintenance build which will be used to maintain your target enterprise repository. These settings will point to another repository (for instance the maven 2 public repository) so that you will just have to ask Ivy to install the modules you want with a simple command line.

To demonstrate this we will first use some basic ivy settings files to show how it works, and then we will use the advanced namespaces feature to demonstrate how to deal with naming mismatch between the source and target repository.

The project used

+The project that we will use is pretty simple.
It is composed of an ant build file, and some ivy settings files.

Here are the accessible target that we will use : +
+Z:\ivy-repository>ant -p
Buildfile: build.xml

Main targets:

clean-cache --> clean the cache
clean-repo --> clean the destination repository
maven2 --> install module from maven 2 repository
maven2-deps --> install module from maven 2 repository with dependencies
maven2-namespace --> install module from maven 2 using namespaces
maven2-namespace-deps --> install module with dependencies from maven2 repo using namespaces
Default target: basic +
+

+The project is accessible in the src/example/build-a-ivy-repository

Next steps:
Basic repository copy
Using namespaces


+
+
+ + + + + + + + + + + + +
+ + Propchange: ant/ivy/site/target/history/2.2.0-rc1/tutorial/build-repository.html ------------------------------------------------------------------------------ svn:mime-type = text/plain