mirror of https://github.com/apache/ant-ivy
Check spelling; fix whitespace and links; sort entries in .gitignore
This commit is contained in:
twogee
parent
7e764a320c
commit
b02336b76a
|
|
@ -1,22 +1,21 @@
|
|||
.classpath
|
||||
.DS_Store
|
||||
.idea
|
||||
*.iml
|
||||
.ivy2
|
||||
*~
|
||||
asciidoc/tutorial/log
|
||||
bin
|
||||
build
|
||||
doc/style/.svn
|
||||
doc/xooki/.svn
|
||||
lib
|
||||
test/jar-repos
|
||||
test/test-repo/bundlerepo/*.jar
|
||||
test/test-repo/ivyrepo/org.apache.ivy.osgi
|
||||
.DS_Store
|
||||
doc/samples/target-platform/bundles
|
||||
doc/samples/target-platform/cache
|
||||
*~
|
||||
/test/repositories/checkmodified/ivy-1.0.xml
|
||||
/test/repositories/checkmodified/mod1.1-1.0.jar
|
||||
/test/repositories/norevision/ivy-mod1.1.xml
|
||||
/test/repositories/norevision/mod1.1.jar
|
||||
asciidoc/tutorial/log
|
||||
|
||||
lib
|
||||
test/jar-repos
|
||||
test/repositories/checkmodified/ivy-1.0.xml
|
||||
test/repositories/checkmodified/mod1.1-1.0.jar
|
||||
test/repositories/norevision/ivy-mod1.1.xml
|
||||
test/repositories/norevision/mod1.1.jar
|
||||
test/test-repo/bundlerepo/*.jar
|
||||
test/test-repo/ivyrepo/org.apache.ivy.osgi
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ If you use ant *1.5.1* or superior, you have to define the tasks you use in your
|
|||
<taskdef name="ivy-configure" classname="org.apache.ivy.ant.IvyConfigure"/>
|
||||
<taskdef name="ivy-resolve" classname="org.apache.ivy.ant.IvyResolve"/>
|
||||
<taskdef name="ivy-retrieve" classname="org.apache.ivy.ant.IvyRetrieve"/>
|
||||
<taskdef name="ivy-deliver" classname="org.apache.ivy.ant.IvyDeliver"/>
|
||||
<taskdef name="ivy-deliver" classname="org.apache.ivy.ant.IvyDeliver"/>
|
||||
<taskdef name="ivy-publish" classname="org.apache.ivy.ant.IvyPublish"/>
|
||||
----
|
||||
|
||||
|
|
@ -57,7 +57,7 @@ Once your build file is ok to call ivy tasks, the simplest way to use ivy is to
|
|||
|
||||
[source,xml]
|
||||
----
|
||||
<ivy:retrieve />
|
||||
<ivy:retrieve/>
|
||||
----
|
||||
|
||||
This calls ivy with default values, which might be ok in several projects. In fact, it is equivalent to:
|
||||
|
|
@ -65,11 +65,11 @@ This calls ivy with default values, which might be ok in several projects. In fa
|
|||
[source,xml]
|
||||
----
|
||||
<target name="resolve">
|
||||
<ivy:configure />
|
||||
|
||||
<ivy:resolve file="${ivy.dep.file}" conf="${ivy.configurations}" />
|
||||
|
||||
<ivy:retrieve pattern="${ivy.retrieve.pattern}" conf="${ivy.configurations}" />
|
||||
<ivy:configure/>
|
||||
|
||||
<ivy:resolve file="${ivy.dep.file}" conf="${ivy.configurations}"/>
|
||||
|
||||
<ivy:retrieve pattern="${ivy.retrieve.pattern}" conf="${ivy.configurations}"/>
|
||||
</target>
|
||||
----
|
||||
|
||||
|
|
@ -87,7 +87,7 @@ ivy.project.dir = ${basedir}
|
|||
ivy.lib.dir = ${ivy.project.dir}/lib
|
||||
ivy.build.artifacts.dir = ${ivy.project.dir}/build/artifacts
|
||||
ivy.distrib.dir = ${ivy.project.dir}/distrib
|
||||
|
||||
|
||||
ivy.resolver.default.check.modified = false
|
||||
ivy.default.always.check.exact.revision = true
|
||||
|
||||
|
|
@ -139,33 +139,33 @@ Here is a more complete example of build file using Ivy:
|
|||
<project xmlns:ivy="antlib:org.apache.ivy.ant" name="sample" default="resolve">
|
||||
|
||||
<target name="resolve">
|
||||
<ivy:configure file="../ivysettings.xml" />
|
||||
|
||||
<ivy:resolve file="my-ivy.xml" conf="default, myconf" />
|
||||
|
||||
<ivy:configure file="../ivysettings.xml"/>
|
||||
|
||||
<ivy:resolve file="my-ivy.xml" conf="default, myconf"/>
|
||||
|
||||
</target>
|
||||
|
||||
|
||||
<target name="retrieve-default" depends="resolve">
|
||||
<ivy:retrieve pattern="lib/default/[artifact]-[revision].[ext]" conf="default" />
|
||||
<ivy:retrieve pattern="lib/default/[artifact]-[revision].[ext]" conf="default"/>
|
||||
</target>
|
||||
|
||||
<target name="retrieve-myconf" depends="resolve">
|
||||
<ivy:retrieve pattern="lib/myconf/[artifact]-[revision].[ext]" conf="myconf" />
|
||||
<ivy:retrieve pattern="lib/myconf/[artifact]-[revision].[ext]" conf="myconf"/>
|
||||
</target>
|
||||
|
||||
<target name="retrieve-all" depends="resolve">
|
||||
<ivy:retrieve pattern="lib/[conf]/[artifact]-[revision].[ext]" conf="*" />
|
||||
<ivy:retrieve pattern="lib/[conf]/[artifact]-[revision].[ext]" conf="*"/>
|
||||
</target>
|
||||
|
||||
<target name="deliver" depends="retrieve-all">
|
||||
<ivy:deliver deliverpattern="distrib/[artifact]-[revision].[ext]"
|
||||
pubrevision="1.1b4" pubdate="20050115123254" status="milestone" />
|
||||
pubrevision="1.1b4" pubdate="20050115123254" status="milestone"/>
|
||||
</target>
|
||||
|
||||
<target name="publish" depends="deliver">
|
||||
<ivy:publish resolver="internal"
|
||||
artifactspattern="distrib/[artifact]-[revision].[ext]"
|
||||
pubrevision="1.1b4" />
|
||||
<ivy:publish resolver="internal"
|
||||
artifactspattern="distrib/[artifact]-[revision].[ext]"
|
||||
pubrevision="1.1b4"/>
|
||||
</target>
|
||||
</project>
|
||||
----
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ This is usually not a valid recommendation for open source projects, but for the
|
|||
|
||||
|
||||
* control +
|
||||
The main problem with these kinds of public repositories is that you don't have control over the repository. This means that if a module descriptor is broken you cannot easily fix it. Sure you can use a chain between a shared repository and the public one and put your fixed module descriptor in the shared repository so that it hides the one on the public repository, but this makes repository browsing and maintenance cumbersome.
|
||||
The main problem with these kinds of public repositories is that you don't have control over the repository. This means that if a module descriptor is broken you cannot easily fix it. Sure you can use a chain between a shared repository and the public one and put your fixed module descriptor in the shared repository so that it hides the one on the public repository, but this makes repository browsing and maintenance cumbersome.
|
||||
Even more problematic is the possible updates of the repository. We know that versions published in such repositories should be stable and not be updated, but we also frequently see that a module descriptor is buggy, or an artifact corrupted. We even see sometimes a new version published with the same name as the preceding one because the previous one was simply badly packaged. This can occur even to the best; it occurred to us with Ivy 1.2 :-) But then we decided to publish the new version with a different name, 1.2a. But if the repository manager allows such updates, this means that what worked before can break. It can thus break your build reproducibility.
|
||||
|
||||
* reliability +
|
||||
|
|
@ -54,17 +54,17 @@ Note that using an enterprise repository doesn't mean you have to build it entir
|
|||
|
||||
== Always use patterns with at least organisation and module
|
||||
|
||||
Ivy is very flexible and can accomodate a lot of existing repositories, using the concept of link:concept.html#pattern[patterns]. But if your repository doesn't exist yet, we strongly recommend always using the organisation and the module name in your pattern, even for a private repository where you put only your own modules (which all have the same organisation). Why? Because the Ivy listing feature relies on the token it can find in the pattern. If you have no organisation token in your pattern, Ivy won't be able to list the (only?) organisation in your repository. And this can be a problem for code completion in IvyDE, for example, but also for repository wide tasks like link:use/install.html[install] or link:use/repreport.html[repreport].
|
||||
Ivy is very flexible and can accommodate a lot of existing repositories, using the concept of link:concept.html#pattern[patterns]. But if your repository doesn't exist yet, we strongly recommend always using the organisation and the module name in your pattern, even for a private repository where you put only your own modules (which all have the same organisation). Why? Because the Ivy listing feature relies on the token it can find in the pattern. If you have no organisation token in your pattern, Ivy won't be able to list the (only?) organisation in your repository. And this can be a problem for code completion in IvyDE, for example, but also for repository wide tasks like link:use/install.html[install] or link:use/repreport.html[repreport].
|
||||
|
||||
|
||||
== Public ivysettings.xml with public repositories
|
||||
|
||||
If you create a public repository, provide a URL to the link:settings.html[ivysettings.xml] file. It's pretty easy to do, and if someone wants to leverage your repository, he will just have to load it with link:use/settings.html[settings] with the URL of your ivysettings.xml file, or link:configuration/include.html[include] it in its own configuration file, which makes it really easy to combine several public repositories.
|
||||
If you create a public repository, provide a URL to the link:settings.html[ivysettings.xml] file. It's pretty easy to do, and if someone wants to leverage your repository, he will just have to load it with link:use/settings.html[settings] with the URL of your ivysettings.xml file, or link:settings/include.html[include] it in its own configuration file, which makes it really easy to combine several public repositories.
|
||||
|
||||
|
||||
== Dealing with integration versions
|
||||
|
||||
Very often, especially when working in a team or with several modules, you will need to rely on intermediate, non-finalized versions of your modules. These versions are what we call integration versions, because their main objective is to be integrated with other modules to make and test an application or a framework.
|
||||
Very often, especially when working in a team or with several modules, you will need to rely on intermediate, non-finalized versions of your modules. These versions are what we call integration versions, because their main objective is to be integrated with other modules to make and test an application or a framework.
|
||||
|
||||
If you follow the continuous integration paradigm across modules, these integration versions can be produced by a continuous integration server, very frequently.
|
||||
|
||||
|
|
@ -74,7 +74,7 @@ There are basically two ways to deal with them, both ways being supported by Ivy
|
|||
|
||||
|
||||
* use a naming convention like a special suffix +
|
||||
the idea is pretty simple, each time you publish a new integration of your module you give the same name to the version (in maven world this is for example 1.0-SNAPSHOT). The dependency manager should then be aware that this version is special because it changes over time, so that it does not trust its local cache if it already has the version, but checks the date of the version on the repository and sees if it has changed. In Ivy this is supported using the link:ivyfile/dependency.html[changing attribute] on a dependency or by configuring the link:configuration/resolvers.html[changing pattern] to use for all your modules.
|
||||
the idea is pretty simple, each time you publish a new integration of your module you give the same name to the version (in maven world this is for example 1.0-SNAPSHOT). The dependency manager should then be aware that this version is special because it changes over time, so that it does not trust its local cache if it already has the version, but checks the date of the version on the repository and sees if it has changed. In Ivy this is supported using the link:ivyfile/dependency.html[changing attribute] on a dependency or by configuring the link:settings/resolvers.html[changing pattern] to use for all your modules.
|
||||
|
||||
* automatically create a new version for each +
|
||||
in this case you use either a build number or a timestamp to publish each new integration version with a new version name. Then you can use one of the numerous ways in Ivy to link:ivyfile/dependency.html[express a version constraint]. Usually selecting the very latest one (using 'latest.integration' as version constraint) is enough.
|
||||
|
|
@ -82,7 +82,7 @@ There are basically two ways to deal with them, both ways being supported by Ivy
|
|||
|
||||
So, which way is the best? As often, it depends on your context, and if one of the two was really bad it wouldn't be supported in Ivy :-)
|
||||
|
||||
But usually we recommend using the second one, because using a new version each time you publish a new version better fits the version identity paradigm, and can make *all* your builds reproducible, even integration ones. And this is interesting because it enables, with some work in your build system, the ability to introduce a mechanism to promote an integration build to a more stable status, like a milestone or a release.
|
||||
But usually we recommend using the second one, because using a new version each time you publish a new version better fits the version identity paradigm, and can make *all* your builds reproducible, even integration ones. And this is interesting because it enables, with some work in your build system, the ability to introduce a mechanism to promote an integration build to a more stable status, like a milestone or a release.
|
||||
|
||||
Imagine you have a customer who comes on a Monday morning and asks for the latest version of your software, for testing or demonstration purposes. Obviously he needs it for the afternoon :-) Now if you have a continuous integration process and good tracking of your changes and your artifacts, it may occur to you that you are actually able to fulfill his request without needing the use of a DeLorean to give you some more time :-) But it may also occur to you that your latest version is stable enough to be used for the purpose of the customer, but was actually built a few days ago, because the very latest just broke a feature or introduced a new one you don't want to deliver. You can deliver this 'stable' integration build if you want, but rest assured that a few days, or weeks, or even months later, the customer will ask for a bug fix on this demo only version. Why? Because it's a customer, and we all know how they are :-)
|
||||
|
||||
|
|
@ -95,7 +95,7 @@ On the other hand, the main drawback of this solution is that it can produce a l
|
|||
|
||||
== Inlining dependencies or not?
|
||||
|
||||
With Ivy 1.4 you can resolve a dependency without even writing an ivy file. This pratice is called inlining. But what is it good for, and when should it be avoided?
|
||||
With Ivy 1.4 you can resolve a dependency without even writing an ivy file. This practice is called inlining. But what is it good for, and when should it be avoided?
|
||||
|
||||
Putting ivy dependencies in a separate file has the following advantages:
|
||||
|
||||
|
|
@ -116,12 +116,12 @@ On the other hand, using inline dependencies is very useful when:
|
|||
Without ivy you usually either copy the custom task jar in ant lib, which requires maintenance of your workstation installation, or use a manual copy or download and a taskdef with the appropriate classpath, which is better. But if you have several custom tasks, or if they have themselves dependencies, it can become cumbersome. Using Ivy with an inline dependency is an elegant way to solve this problem.
|
||||
|
||||
* you want to easily deploy an application +
|
||||
If you already build your application and its modules using Ivy, it is really easy to leverage your ivy repository to download your application and all its dependencies on the local filesystem, ready to be executed. If you also put your configuration files as artifacts in your repository (maybee packaged as a zip), the whole installation process can rely on ivy, easing the automatic installation of *any* version of your application available in your repository!
|
||||
If you already build your application and its modules using Ivy, it is really easy to leverage your ivy repository to download your application and all its dependencies on the local filesystem, ready to be executed. If you also put your configuration files as artifacts in your repository (maybe packaged as a zip), the whole installation process can rely on ivy, easing the automatic installation of *any* version of your application available in your repository!
|
||||
|
||||
|
||||
== Hire an expert
|
||||
|
||||
Build and dependency management is often given too low a priority in the software development world. We often see build management implemented by developers when they have time. Even if this may seem like a time and money savings in the short term, it often turns out to be a very bad choice in the long term. Building software is not a simple task, when you want to ensure automatic, tested, fully reproducible builds, releases and installations. On the other hand, once a good build system fitting your very specific needs is setup, it can then only rely on a few people with a good understanding of what is going on, with a constant quality ensured.
|
||||
Build and dependency management is often given too low a priority in the software development world. We often see build management implemented by developers when they have time. Even if this may seem like a time and money savings in the short term, it often turns out to be a very bad choice in the long term. Building software is not a simple task, when you want to ensure automatic, tested, fully reproducible builds, releases and installations. On the other hand, once a good build system fitting your very specific needs is setup, it can then only rely on a few people with a good understanding of what is going on, with a constant quality ensured.
|
||||
|
||||
Therefore hiring a build and dependency expert to analyse and improve your build and release system is most of the time a very good choice.
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@
|
|||
under the License.
|
||||
////
|
||||
|
||||
== JVM compability
|
||||
== JVM compatibility
|
||||
|
||||
|
||||
Up to Ivy 2.3.x, a minimum of Java 1.4 is required.
|
||||
|
|
@ -43,4 +43,3 @@ The required versions of the Apache HttpClient, Jsch or any optional dependency
|
|||
|
||||
|
||||
Ivy does not at this time support multithreaded use. It thus should not be used with the ant `<parallel>` task.
|
||||
|
||||
|
|
|
|||
|
|
@ -54,10 +54,10 @@ For details on how to declare your module configurations, how to declare in whic
|
|||
|
||||
During configuration, ivy allows you to define what are called ivy variables. Ivy variables can be seen as ant properties, and are used in a very similar way. In particular, you use a properties tag in the configuration file to load a properties file containing ivy variables and their values.
|
||||
|
||||
But the main differences between ant properties and ivy variables are that ivy variables can be overridden, whereas ant
|
||||
But the main differences between ant properties and ivy variables are that ivy variables can be overridden, whereas ant
|
||||
properties can't, and that they are defined in separate environments.
|
||||
|
||||
Actually all ant properties are imported into ivy variables when the configuration is done (if you call ivy from ant).
|
||||
Actually all ant properties are imported into ivy variables when the configuration is done (if you call ivy from ant).
|
||||
This means that if you define an ant property after the call to configure, it will not be available as an ivy variable.
|
||||
On the other hand, ivy variables are NOT exported to ant, thus if you define ivy variables in ivy, do not try to use them as ant properties.
|
||||
|
||||
|
|
@ -69,7 +69,7 @@ Finally, it's also important to be aware of the time of substitution of variable
|
|||
|
||||
Moreover, in an ant environment, a bunch of variables are going to be set by default via the ant property file loading mechanism (actually they are first loaded as ant properties and then imported as ivy variables, see link:ant.html[Ant Tasks]), and even in the ant properties themselves there is going to be eager substitution on loading, effectively making it impossible to override some variable purely via the ivysettings.properties file. Some variables will really only be able to be overridden via ant properties because of this.
|
||||
|
||||
Moreover, it's also important to understand the difference between ivy variables and ivy pattern tokens.
|
||||
Moreover, it's also important to understand the difference between ivy variables and ivy pattern tokens.
|
||||
See the Patterns chapter below for what pattern tokens are.
|
||||
|
||||
== [[patterns]]Patterns
|
||||
|
|
@ -81,9 +81,9 @@ First let's give an example. You can for instance configure the file system depe
|
|||
a pattern to find artifacts. This pattern can be like this:
|
||||
myrepository/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]
|
||||
|
||||
This pattern indicates that the repository we use is in a directory called myrepository.
|
||||
This pattern indicates that the repository we use is in a directory called myrepository.
|
||||
|
||||
In this directory we have directories having for name the name of the organisation of the module we look for.
|
||||
In this directory we have directories having for name the name of the organisation of the module we look for.
|
||||
Then we have a directory per module, each having for name the name of the module.
|
||||
Then in module directories we find a directory per artifact type (jars, wars, ivys, ...), in which we find artifacts named by the artifact id, followed by a hyphen, then the revision, a dot, and the artifact extension.
|
||||
Not too difficult to understand is it? That's it, you have understood the pattern concept!
|
||||
|
|
@ -103,7 +103,7 @@ But here are all the tokens currently available:
|
|||
the organisation name
|
||||
|
||||
* [orgPath] *__(since 2.3)__* +
|
||||
the organisation name where '.' has been replaced by '/'. This can be used to configure maven2-like repositories.
|
||||
the organisation name where '.' has been replaced by '/'. This can be used to configure maven2-like repositories.
|
||||
|
||||
* [module] +
|
||||
the module name
|
||||
|
|
@ -140,10 +140,10 @@ So if you surround a token with '(' and ')', any other text which is between the
|
|||
|
||||
For instance, suppose the pattern: "abc(def[type]ghi)"
|
||||
type = "jar" -> the substituted pattern: abcdefjarghi
|
||||
type = null or "" -> the substitued pattern: abc
|
||||
type = null or "" -> the substituted pattern: abc
|
||||
|
||||
A more real life example:
|
||||
The pattern
|
||||
The pattern
|
||||
[source]
|
||||
----
|
||||
[artifact](-[revision]).[ext]
|
||||
|
|
@ -216,7 +216,7 @@ Note also that with any matcher, the character '*' has the special meaning of ma
|
|||
== [[extra]]Extra attributes
|
||||
|
||||
*__since 1.4__*
|
||||
Several tags in ivy xml files are extensible with what is called extra attributes.
|
||||
Several tags in ivy xml files are extensible with what is called extra attributes.
|
||||
The idea is very simple: if you need some more information to define your modules, you can add the attribute you want and you will then be able to access it as any other attribute in your patterns.
|
||||
|
||||
*__since 2.0__*
|
||||
|
|
@ -239,13 +239,13 @@ Here is an ivy file with the attribute 'color' set to blue:
|
|||
|
||||
----
|
||||
|
||||
Then you must use the extra attribute when you declare a dependency on foo. Those extra attributes
|
||||
Then you must use the extra attribute when you declare a dependency on foo. Those extra attributes
|
||||
will indeed be used as identifiers for the module like the org the name and the revision:
|
||||
|
||||
[source]
|
||||
----
|
||||
|
||||
<dependency org="apache" name="foo" e:color="blue" rev="1.5+" />
|
||||
<dependency org="apache" name="foo" e:color="blue" rev="1.5+"/>
|
||||
|
||||
----
|
||||
|
||||
|
|
@ -260,7 +260,7 @@ ${repository.dir}/[organisation]/[module]/[color]/[revision]/[artifact].[ext]
|
|||
|
||||
Note that in patterns you must use the unqualified attribute name (no namespace prefix).
|
||||
|
||||
If you don't want to use xml namespaces, it's possible but you will need to disable ivy file validation, since your files won't fulffill anymore the official ivy xsd. See the link:settings/settings.html[settings documentation] to see how to disable validation.
|
||||
If you don't want to use xml namespaces, it's possible but you will need to disable ivy file validation, since your files won't fulfill anymore the official ivy xsd. See the link:settings/settings.html[settings documentation] to see how to disable validation.
|
||||
|
||||
== [[checksum]]Checksums
|
||||
|
||||
|
|
@ -283,12 +283,12 @@ If you want to change this default, you can set the variable ivy.checksums. Henc
|
|||
=== Supported algorithms
|
||||
|
||||
*__since 1.4__*
|
||||
|
||||
|
||||
|
||||
|
||||
* md5 +
|
||||
|
||||
|
||||
* sha1 +
|
||||
|
||||
|
||||
*__since 2.5__*
|
||||
Starting 2.5 version, in addition to md5 and sha1, Ivy supports SHA-256, SHA-512 and SHA-384 algorithms, if the Java runtime in which Ivy is running, supports those. For example, Java 6 runtime supports SHA-256 and SHA-512 as standard algorithms. If Ivy 2.5 and later versions are run under Java 6 or higher runtimes, these algorithms are supported by Ivy too.
|
||||
|
||||
|
|
@ -298,7 +298,7 @@ Starting 2.5 version, in addition to md5 and sha1, Ivy supports SHA-256, SHA-512
|
|||
*__since 1.4__*
|
||||
When Ivy performs the dependency resolution and some other tasks, it fires events before and after the most important steps. You can listen to these events using Ivy API, or you can even register a trigger to perform a particular action when a particular event occur.
|
||||
|
||||
This is a particularly powerful and flexible feature which allows, for example, you to perform a build of a dependency just before it is resolved, or follow what's happening during the dependency resolution process accuratly, and so on.
|
||||
This is a particularly powerful and flexible feature which allows, for example, you to perform a build of a dependency just before it is resolved, or follow what's happening during the dependency resolution process accurately, and so on.
|
||||
|
||||
For more details about events and triggers, see the link:settings/triggers.html[triggers] documentation page in the configuration section of this documentation.
|
||||
|
||||
|
|
@ -328,7 +328,7 @@ See the link:settings/settings.html[configuration page] to see how to configure
|
|||
|
||||
== Cache and Change Management
|
||||
|
||||
Ivy heavily relies on local caching to avoid accessing remote repositories too often, thus saving a lot of network bandwidth and time.
|
||||
Ivy heavily relies on local caching to avoid accessing remote repositories too often, thus saving a lot of network bandwidth and time.
|
||||
|
||||
|
||||
=== [[cache]]Cache types
|
||||
|
|
@ -338,7 +338,7 @@ An Ivy cache is composed of two different parts:
|
|||
|
||||
* the repository cache +
|
||||
The repository cache is where Ivy stores data downloaded from module repositories, along with some meta information concerning these artifacts, like their original location.
|
||||
This part of the cache can be shared if you use a well suited link:settings/lock-strategies.html[lock strategy].
|
||||
This part of the cache can be shared if you use a well suited link:settings/lock-strategies.html[lock strategy].
|
||||
|
||||
* the resolution cache +
|
||||
This part of the cache is used to store resolution data, which is used by Ivy to reuse the results of a resolve process.
|
||||
|
|
@ -350,7 +350,7 @@ While there is always only one resolution cache, you can link:settings/caches.ht
|
|||
|
||||
=== [[change]]Change management
|
||||
|
||||
To optimize the dependency resolution and the way the cache is used, Ivy assumes by default that a revision never changes. So once Ivy has a module in its cache (metadata and artifacts), it trusts the cache and does not even query the repository. This optimization is very useful in most cases, and causes no problem as long as you respect this paradigm: a revision never changes. Besides performance, there are several link:bestpractices.html[good reasons] to follow this principle.
|
||||
To optimize the dependency resolution and the way the cache is used, Ivy assumes by default that a revision never changes. So once Ivy has a module in its cache (metadata and artifacts), it trusts the cache and does not even query the repository. This optimization is very useful in most cases, and causes no problem as long as you respect this paradigm: a revision never changes. Besides performance, there are several link:bestpractices.html[good reasons] to follow this principle.
|
||||
|
||||
However, depending on your current build system and your dependency management strategy, you may prefer to update your modules sometimes. There are two kinds of changes to consider:
|
||||
|
||||
|
|
@ -374,7 +374,7 @@ So if you want to use changing revisions, use the link:use/publish.html[publish]
|
|||
|
||||
As a dependency manager, Ivy has a lot of file related operations, which most of the time use paths or path patterns to locate the file on the filesystem.
|
||||
|
||||
These paths can obviously be relative or absolute. We recommend to always use absolute paths, so that you don't have to worry about what is the base of your relative paths. Ivy provides some variables which can be used as the base of your absolute paths. For instance, Ivy has a concept of base directory, which is basically the same as for Ant. You have access to this base directory with the ivy.basedir variable. So if you have a path like
|
||||
These paths can obviously be relative or absolute. We recommend to always use absolute paths, so that you don't have to worry about what is the base of your relative paths. Ivy provides some variables which can be used as the base of your absolute paths. For instance, Ivy has a concept of base directory, which is basically the same as for Ant. You have access to this base directory with the ivy.basedir variable. So if you have a path like
|
||||
[source]
|
||||
----
|
||||
${ivy.basedir}/ivy.xml
|
||||
|
|
@ -396,15 +396,15 @@ If you really want to use relative paths, the base directory used to actually lo
|
|||
== [[packaging]]Packaging
|
||||
|
||||
|
||||
Most of the artifacts found in a repository are jars. They can be downoaded and used as is. But some other kind of artifacts required some __unpacking__ after being downloaded and before being used. Such artifacts can be zipped folders and packed jars. Ivy supports that kind of artifact with *packaging*.
|
||||
Most of the artifacts found in a repository are jars. They can be downloaded and used as is. But some other kind of artifacts required some __unpacking__ after being downloaded and before being used. Such artifacts can be zipped folders and packed jars. Ivy supports that kind of artifact with *packaging*.
|
||||
|
||||
A __packaged__ artifact needs to be declared as such in the module descriptor via the attribute link:ivyfile/artifact.html[packaging]. The value of that attribute defined which kind of unpacking algorithm must be used. Here are the list of currently supported algorithms:
|
||||
|
||||
|
||||
|
||||
* `zip`, `jar` or `war`: the artifact will be uncompressed as a folder +
|
||||
|
||||
|
||||
* `pack200`: the artifact will be unpacked to a file via the link:http://docs.oracle.com/javase/7/docs/technotes/tools/share/pack200.html[pack200] algorithm +
|
||||
|
||||
|
||||
* `bundle`: the OSGi artifact will be uncompressed as a folder, and every embedded jar file entry which is packed via the the link:http://docs.oracle.com/javase/7/docs/technotes/tools/share/pack200.html[pack200] algorithm will be unpacked +
|
||||
|
||||
|
||||
|
|
@ -413,10 +413,10 @@ So, if in an `ivy.xml`, there would be declared a such artifact:
|
|||
[source]
|
||||
----
|
||||
|
||||
<artifact name="mymodule" type="jar" ext="jar.pack.gz" packaging="pack200" />
|
||||
<artifact name="mymodule" type="jar" ext="jar.pack.gz" packaging="pack200"/>
|
||||
|
||||
----
|
||||
|
||||
A file `mymodule-1.2.3.jar.pack.gz` would be download into the cache, and also uncompressed in the cache to `mymodule-1.2.3.jar`. Then any post resolve task which supports it, like the link:use/cachepath.html[cachepath], will use the uncompressed file instead of the orginal compressed file.
|
||||
A file `mymodule-1.2.3.jar.pack.gz` would be download into the cache, and also uncompressed in the cache to `mymodule-1.2.3.jar`. Then any post resolve task which supports it, like the link:use/cachepath.html[cachepath], will use the uncompressed file instead of the original compressed file.
|
||||
|
||||
It is possible to chain packing algorithm. The attribute link:ivyfile/artifact.html[packaging] of a artifact expects a comma separated list of packing types, in packing order. For instance, an artifact '`mymodule-1.2.3.jar.pack.gz`' can have the packaging '`jar,pack200`', so it would be uncompressed as a folder '`mymodule-1.2.3`'.
|
||||
|
|
|
|||
|
|
@ -17,4 +17,4 @@
|
|||
under the License.
|
||||
////
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
link:../../settings/caches/cache.html[here].
|
||||
link:../../settings/caches/cache.html[here].
|
||||
|
|
|
|||
|
|
@ -18,4 +18,4 @@
|
|||
////
|
||||
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
link:../../settings/caches/ttl.html[here].
|
||||
link:../../settings/caches/ttl.html[here].
|
||||
|
|
|
|||
|
|
@ -18,4 +18,4 @@
|
|||
////
|
||||
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
link:../../settings/macrodef/attribute.html[here].
|
||||
link:../../settings/macrodef/attribute.html[here].
|
||||
|
|
|
|||
|
|
@ -18,4 +18,4 @@
|
|||
////
|
||||
|
||||
This page has moved. If your browser doesn't automatically redirect to its new location, click
|
||||
link:../../settings/namespace/dest.html[here].
|
||||
link:../../settings/namespace/dest.html[here].
|
||||
|
|
|
|||
|
|
@ -20,11 +20,11 @@
|
|||
|
||||
== Building from source
|
||||
|
||||
To build Ivy from source it's really easy.
|
||||
To build Ivy from source it's really easy.
|
||||
|
||||
=== Requirements
|
||||
|
||||
All you need is
|
||||
All you need is
|
||||
|
||||
|
||||
* an link:http://subversion.tigris.org/[svn] client +
|
||||
|
|
@ -135,7 +135,7 @@ Download the file and unzip its content in your eclipse installation directory.
|
|||
|
||||
=== recommended plugins
|
||||
|
||||
The Ivy project comes with settings for the link:http://eclipse-cs.sourceforge.net/[checkstyle plugin] we recommend to use to avoid introducing new disgression to the checkstyle rules we use.
|
||||
The Ivy project comes with settings for the link:http://eclipse-cs.sourceforge.net/[checkstyle plugin] we recommend to use to avoid introducing new digression to the checkstyle rules we use.
|
||||
If you use this plugin, you will many errors in Ivy. As we said, following strict checkstyle rules is a work in progress and we used to have pretty different code conventions (like using _ as prefix for private attributes), so we still have things to fix. We usually use the filter in the problems view to filter out checkstyle errors from this view, which helps to know what the real compilation problem are.
|
||||
|
||||
Besides this plugin we also recommend to use a subversion plugin, link:http://www.eclipse.org/subversive/[subversive] or link:http://subclipse.tigris.org[subclipse] being the two options currently available in the open source landscape.
|
||||
|
|
|
|||
|
|
@ -92,7 +92,7 @@ You can also do a smoke test with the generated ivy.jar, to see if it is able to
|
|||
|
||||
==== 6. Sign the artifacts
|
||||
|
||||
It's now time to sign the release artifacts and upload them to a location accessible by other Apache commiters.
|
||||
It's now time to sign the release artifacts and upload them to a location accessible by other Apache committers.
|
||||
|
||||
Here is a simple way to sign the files using gnupg:
|
||||
|
||||
|
|
@ -110,7 +110,7 @@ Here is a ruby script you can use to sign the files:
|
|||
|
||||
require 'find'
|
||||
|
||||
Find.find('build/distrib') do |f|
|
||||
Find.find('build/distrib') do |f|
|
||||
`gpg --armor --output #{f}.asc --detach-sig #{f}` if File.file?(f) && ['.zip', '.gz', '.jar', '.pom'].include?(File.extname(f))
|
||||
end
|
||||
|
||||
|
|
@ -154,7 +154,7 @@ ant -f build-release.xml upload-nexus
|
|||
|
||||
----
|
||||
|
||||
Once uploaded, log in https://repository.apache.org/ with your prefered web browser (use your Apache ID).
|
||||
Once uploaded, log in https://repository.apache.org/ with your preferred web browser (use your Apache ID).
|
||||
|
||||
You should find there an __open__ repository with the name of the form `orgapacheant-XXXX`. It should contain the Maven artifacts: the pom, the jar, the sources, the javadocs and the md5 and asc files.
|
||||
|
||||
|
|
@ -179,7 +179,7 @@ And push the changes to the ASF repo
|
|||
[source]
|
||||
----
|
||||
|
||||
git push --tags
|
||||
git push --tags
|
||||
|
||||
----
|
||||
|
||||
|
|
@ -229,13 +229,13 @@ $ svn mv https://dist.apache.org/repos/dist/dev/ant/ivy/$VERSION https://dist.ap
|
|||
|
||||
----
|
||||
|
||||
In order to keep the main dist area of a reasonable size, old releases should be removed. They will disapear from the main dist but will still be available via the link:http://archive.apache.org/dist/ant/ivy/[archive]. To do so, just use the `svn rm` command against the artifacts or folders to remove.
|
||||
In order to keep the main dist area of a reasonable size, old releases should be removed. They will disappear from the main dist but will still be available via the link:http://archive.apache.org/dist/ant/ivy/[archive]. To do so, just use the `svn rm` command against the artifacts or folders to remove.
|
||||
|
||||
|
||||
==== 13. Promote the Maven staging repository
|
||||
|
||||
|
||||
Go log in https://repository.apache.org/ with your prefered web browser (use your Apache ID).
|
||||
Go log in https://repository.apache.org/ with your preferred web browser (use your Apache ID).
|
||||
|
||||
Select the appropriate `orgapacheant-XXXX` repository and select the __Release__ action.
|
||||
|
||||
|
|
@ -293,9 +293,9 @@ ant /all generate-site
|
|||
|
||||
----
|
||||
|
||||
You should verify that the site generated in the production directory is OK. You can open the files with your prefered web browser like it was deployed.
|
||||
You should verify that the site generated in the production directory is OK. You can open the files with your preferred web browser like it was deployed.
|
||||
|
||||
And once your happy with it, commit the changes in the source directory, and in the production directoy to get it actually deployed via svnpubsub.
|
||||
And once your happy with it, commit the changes in the source directory, and in the production directory to get it actually deployed via svnpubsub.
|
||||
|
||||
Tip: lot's of files might need to be 'added' to svn. An handy command to `add` any file which is not yet under version control is the following one:
|
||||
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ Ivy is open source and released under a very permissive link:https://ant.apache.
|
|||
|
||||
Ivy has a lot of powerful link:https://ant.apache.org/ivy/features.html[features], the most popular and useful being its flexibility, integration with ant, and its strong transitive dependencies management engine.
|
||||
|
||||
The transitive dependencies management is a feature which lets you get dependencies of your dependencies, transitively. In order to address this general problem, ivy needs to find metadata about your modules, usually in an link:ivyfile.html[ivy file]. To find the metadata and your dependencies' artifacts (usually jars), Ivy can be configured to use a lot of different link:configuration/resolvers.html[repositories].
|
||||
The transitive dependencies management is a feature which lets you get dependencies of your dependencies, transitively. In order to address this general problem, ivy needs to find metadata about your modules, usually in an link:ivyfile.html[ivy file]. To find the metadata and your dependencies' artifacts (usually jars), Ivy can be configured to use a lot of different link:settings/resolvers.html[repositories].
|
||||
|
||||
|
||||
== About this doc
|
||||
|
|
@ -62,7 +62,7 @@ For earlier versions, we suggest downloading the documentation to browse the doc
|
|||
|
||||
== Other places to go
|
||||
|
||||
Check out Ivy link:https://ant.apache.org/ivy/features.html[features]. +
|
||||
Check out Ivy link:https://ant.apache.org/ivy/features.html[features]. +
|
||||
Read our link:https://ant.apache.org/ivy/faq.html[FAQ]. +
|
||||
Ask for help on our link:https://ant.apache.org/ivy/mailing-lists.html[mailing lists]. +
|
||||
Report a bug or feature request in our link:https://ant.apache.org/ivy/issues.html[issue tracking system]. +
|
||||
|
|
@ -73,15 +73,14 @@ Check link:https://ant.apache.org/ivy/links.html[external tools and resources].
|
|||
|
||||
This documentation is composed of three main parts:
|
||||
|
||||
|
||||
* link:tutorial.html[Tutorials] +
|
||||
The tutorials is the best way to begin to play with Ivy. You will easily and quickly learn the basics of Ivy.
|
||||
|
||||
* link:reference.html[Reference] +
|
||||
The reference documentation gives you all the details of Ivy.
|
||||
The introduction part is particularly useful: it defines some vocabulary, explains main concepts such as dependency resolvers and patterns, and gives an overview of how ivy works internally.
|
||||
It's also in the reference doc that you will find all you always dreamed to know about ivy settings, ivy files, and ivy use (especially with ant).
|
||||
|
||||
* link:dev.html[Developer doc] +
|
||||
The developers's doc is useful for users who would like to extend Ivy or build it from source. It's also the documentation used by the Ivy team, so you will also find information about how we make releases.
|
||||
|
||||
* link:tutorial.html[Tutorials] +
|
||||
The tutorials is the best way to begin to play with Ivy. You will easily and quickly learn the basics of Ivy.
|
||||
|
||||
* link:reference.html[Reference] +
|
||||
The reference documentation gives you all the details of Ivy.
|
||||
The introduction part is particularly useful: it defines some vocabulary, explains main concepts such as dependency resolvers and patterns, and gives an overview of how ivy works internally.
|
||||
It's also in the reference doc that you will find all you always dreamed to know about ivy settings, ivy files, and ivy use (especially with ant).
|
||||
|
||||
* link:dev.html[Developer doc] +
|
||||
The developers's doc is useful for users who would like to extend Ivy or build it from source. It's also the documentation used by the Ivy team, so you will also find information about how we make releases.
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Download the version you want here, unpack the downloaded zip file wherever you
|
|||
If you use ant 1.6.0 or superior, you can then simply go to the src/example/hello-ivy dir and run ant: if the build is successful, you have successfully installed Ivy!
|
||||
|
||||
If you use ant 1.5.1 or superior, you have to modify the build files in the examples:
|
||||
- remove the namespace section at their head: xmlns:ivy="antlib:org.apache.ivy.ant"
|
||||
- remove the namespace section at their head: xmlns:ivy="antlib:org.apache.ivy.ant"
|
||||
- add taskdefs for ivy tasks:
|
||||
|
||||
[source]
|
||||
|
|
@ -35,7 +35,7 @@ If you use ant 1.5.1 or superior, you have to modify the build files in the exam
|
|||
<taskdef name="ivy-configure" classname="org.apache.ivy.ant.IvyConfigure"/>
|
||||
<taskdef name="ivy-resolve" classname="org.apache.ivy.ant.IvyResolve"/>
|
||||
<taskdef name="ivy-retrieve" classname="org.apache.ivy.ant.IvyRetrieve"/>
|
||||
<taskdef name="ivy-publish" classname="org.apache.ivy.ant.IvyPublish"/>
|
||||
<taskdef name="ivy-publish" classname="org.apache.ivy.ant.IvyPublish"/>
|
||||
|
||||
----
|
||||
|
||||
|
|
@ -45,7 +45,7 @@ You can now run the build, if it is successful, you have successfully installed
|
|||
If the build is not successful, check the FAQ to see what might be the problem with the ivyrep resolver.
|
||||
|
||||
|
||||
=== Ivy dependendencies
|
||||
=== Ivy dependencies
|
||||
|
||||
|
||||
One of the two binary versions of Ivy doesn't include the optional dependencies. To download them using Ivy, all you need is to run the Ant build file provided in the distribution. This will use Ivy itself to download the dependencies. Then you should see the Ivy optional dependencies in the lib directory, organized per configuration (see the ivy.xml for details about the configurations and their use).
|
||||
|
|
@ -58,19 +58,19 @@ If you want to use Ivy only in your ant build scripts, and have an internet conn
|
|||
[source]
|
||||
----
|
||||
|
||||
<property name="ivy.install.version" value="2.1.0-rc2" />
|
||||
<property name="ivy.install.version" value="2.1.0-rc2"/>
|
||||
<condition property="ivy.home" value="${env.IVY_HOME}">
|
||||
<isset property="env.IVY_HOME" />
|
||||
<isset property="env.IVY_HOME"/>
|
||||
</condition>
|
||||
<property name="ivy.home" value="${user.home}/.ant" />
|
||||
<property name="ivy.jar.dir" value="${ivy.home}/lib" />
|
||||
<property name="ivy.jar.file" value="${ivy.jar.dir}/ivy.jar" />
|
||||
<property name="ivy.home" value="${user.home}/.ant"/>
|
||||
<property name="ivy.jar.dir" value="${ivy.home}/lib"/>
|
||||
<property name="ivy.jar.file" value="${ivy.jar.dir}/ivy.jar"/>
|
||||
|
||||
<target name="download-ivy" unless="offline">
|
||||
|
||||
<mkdir dir="${ivy.jar.dir}"/>
|
||||
<!-- download Ivy from web site so that it can be used even without any special installation -->
|
||||
<get src="https://repo1.maven.org/maven2/org/apache/ivy/ivy/${ivy.install.version}/ivy-${ivy.install.version}.jar"
|
||||
<get src="https://repo1.maven.org/maven2/org/apache/ivy/ivy/${ivy.install.version}/ivy-${ivy.install.version}.jar"
|
||||
dest="${ivy.jar.file}" usetimestamp="true"/>
|
||||
</target>
|
||||
|
||||
|
|
|
|||
|
|
@ -25,8 +25,7 @@ Here is the simplest ivy file you can write:
|
|||
----
|
||||
<ivy-module version="2.0">
|
||||
<info organisation="myorg"
|
||||
module="mymodule"
|
||||
/>
|
||||
module="mymodule"/>
|
||||
</ivy-module>
|
||||
----
|
||||
|
||||
|
|
@ -39,13 +38,12 @@ For those familiar with xml schema, the schema used to validate ivy files can be
|
|||
[source,xml]
|
||||
----
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<ivy-module version="2.0"
|
||||
<ivy-module version="2.0"
|
||||
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
||||
xsi:noNamespaceSchemaLocation=
|
||||
"http://ant.apache.org/ivy/schemas/ivy.xsd">
|
||||
<info organisation="myorg"
|
||||
module="mymodule"
|
||||
/>
|
||||
module="mymodule"/>
|
||||
</ivy-module>
|
||||
----
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Indicates a public configuration in which enclosing artifact is published.
|
|||
[options="header",cols="15%,50%,35%"]
|
||||
|=======
|
||||
|Attribute|Description|Required
|
||||
|name|the name of the module public configuration in which this artifact is published.
|
||||
|name|the name of the module public configuration in which this artifact is published.
|
||||
|
||||
`$$*$$` wildcard can be used to designate all public configurations of this module|Yes
|
||||
|=======
|
||||
|
|
|
|||
|
|
@ -19,7 +19,9 @@
|
|||
|
||||
*Tag:* exclude *Parent:* link:../ivyfile/dependency.html[dependency]
|
||||
|
||||
This feature gives you more control on a dependency for which you do not control its ivy file. It enables to restrict the artifacts required, by excluding artifacts being published by the dependency or any of its transitive dependencies, even if configuration does not a good separation of published artifacts
|
||||
This feature gives you more control on a dependency for which you do not control its ivy file.
|
||||
It enables to restrict the artifacts required, by excluding artifacts being published by the dependency or any of its transitive dependencies,
|
||||
even if configuration does not a good separation of published artifacts
|
||||
|
||||
The same principle concerning configuration as for include applies to this exclude feature (see the link:../ivyfile/dependency-include.html[include] feature).
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@
|
|||
|
||||
*Tag:* artifact *Parent:* link:../ivyfile/publications.html[publications]
|
||||
|
||||
Declares an artifact published by this module. This is especially useful for other modules dependending on this one. They thus get all published artifacts belonging to the configurations asked. Indeed, each published artifact declares in which public configuration it is published. Thus a module depending on this module only get artifacts marked with the asked configurations, taking into account configurations extension (see link:../ivyfile/conf.html[configuration declaration]).
|
||||
Declares an artifact published by this module. This is especially useful for other modules depending on this one. They thus get all published artifacts belonging to the configurations asked. Indeed, each published artifact declares in which public configuration it is published. Thus a module depending on this module only get artifacts marked with the asked configurations, taking into account configurations extension (see link:../ivyfile/conf.html[configuration declaration]).
|
||||
|
||||
The configurations in which an artifact is published can be configured in two ways:
|
||||
|
||||
|
|
@ -31,7 +31,7 @@ The two are equivalent, it is only a matter of preference. However, do not mix b
|
|||
*__since 1.4__* The artifact element has default values for all its attributes, so if you want to declare a default artifact you can just declare it like that:
|
||||
[source,xml]
|
||||
----
|
||||
<artifact />
|
||||
<artifact/>
|
||||
----
|
||||
|
||||
If this is the only artifact declared, then it's equivalent to having no publication section at all.
|
||||
|
|
@ -69,7 +69,7 @@ If this is the only artifact declared, then it's equivalent to having no publica
|
|||
|
||||
[source,xml]
|
||||
----
|
||||
<artifact />
|
||||
<artifact/>
|
||||
----
|
||||
|
||||
Declares an artifact with the name of the module as name, type and ext jar, and published in all configurations.
|
||||
|
|
@ -78,7 +78,7 @@ Declares an artifact with the name of the module as name, type and ext jar, and
|
|||
|
||||
[source,xml]
|
||||
----
|
||||
<artifact name="foo-src" type="source" ext="zip" conf="src" />
|
||||
<artifact name="foo-src" type="source" ext="zip" conf="src"/>
|
||||
----
|
||||
|
||||
Declares an artifact `foo-src`, of type `source` with extension `zip`, and published in the `src` configuration.
|
||||
|
|
@ -87,7 +87,7 @@ Declares an artifact `foo-src`, of type `source` with extension `zip`, and publi
|
|||
|
||||
[source,xml]
|
||||
----
|
||||
<artifact name="foo" url="http://www.acme.com/repository/barbaz/foo-1.2-bar.jar" />
|
||||
<artifact name="foo" url="http://www.acme.com/repository/barbaz/foo-1.2-bar.jar"/>
|
||||
----
|
||||
|
||||
Declares an artifact `foo`, of type and extension `jar'` located at the url `$$http://www.acme.com/repository/barbaz/foo-1.2-bar.jar$$`. This url will only be used if the artifact cannot be found at its standard location.
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@
|
|||
|
||||
*Tag:* conf *Parent:* link:../ivyfile/configurations.html[configurations]
|
||||
|
||||
Declares a configuration of this module. As described in the reference page, a configuration is a way to use or construct a module. 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 differents ways to use or build a module are called in Ivy module configurations.
|
||||
Declares a configuration of this module. As described in the reference page, a configuration is a way to use or construct a module. 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 in Ivy module configurations.
|
||||
|
||||
The `conf` element in the configurations section declares one configuration. This declaration gives the name of the configuration declared, its visibility and the other configurations of the module it extends.
|
||||
|
||||
|
|
@ -37,7 +37,7 @@ This notion is very helpful to define configurations which are similar with some
|
|||
|`*(private)`|all other private configurations
|
||||
|=======
|
||||
|
||||
*__since 1.4__* A whole configuration can be declared as non transitive, so that all dependencies resolved in this configuration will be resolved with transitivity disabled. Note that the transitivity is disabled for all the configuration dependencies (including those obtained because this conf extends other ones), and only for this configuration (which means that a conf extending this one with transitivityy enabled will get transitive dependencies even for dependencies being part of the non transitive configuration).
|
||||
*__since 1.4__* A whole configuration can be declared as non transitive, so that all dependencies resolved in this configuration will be resolved with transitivity disabled. Note that the transitivity is disabled for all the configuration dependencies (including those obtained because this conf extends other ones), and only for this configuration (which means that a conf extending this one with transitivity enabled will get transitive dependencies even for dependencies being part of the non transitive configuration).
|
||||
This is very useful to build a compile configuration, for instance, forcing the dependency declaration on each direct dependency, with no risk to forget some because of transitivity.
|
||||
|
||||
*__since 1.4__* This tag supports link:../concept.html#extra[extra attributes].
|
||||
|
|
@ -52,8 +52,7 @@ This is very useful to build a compile configuration, for instance, forcing the
|
|||
|visibility|the visibility of the declared configuration.
|
||||
|
||||
`public` means that this configuration can be used by other modules, while `private` means that this configuration is used only in the module itself, and is not exposed to other modules|No, defaults to `public`
|
||||
|extends|a comma separated list of configurations of this module that the
|
||||
current configuration extends|No, defaults to none
|
||||
|extends|a comma separated list of configurations of this module that the current configuration extends|No, defaults to none
|
||||
|transitive|a boolean to indicate if this conf is transitive or not *__since 1.4__*|No, defaults to `true`
|
||||
|deprecated|indicates that this conf has been deprecated by giving the date of the deprecation.
|
||||
|
||||
|
|
@ -64,11 +63,11 @@ It should be given in this format: `yyyyMMddHHmmss`|No, by default the conf is n
|
|||
|
||||
[source,xml]
|
||||
----
|
||||
<conf name="core" visibility="private" />
|
||||
<conf name="compile" extends="core" transitive="false" visibility="private" />
|
||||
<conf name="runtime" extends="compile" description="everything needed to run this module" />
|
||||
<conf name="core" visibility="private"/>
|
||||
<conf name="compile" extends="core" transitive="false" visibility="private"/>
|
||||
<conf name="runtime" extends="compile" description="everything needed to run this module"/>
|
||||
----
|
||||
|
||||
Declares three configurations, `core`, `compile` and `runtime`, with only the `runtime` one accessible from other modules, and with the `compile` one being non transitive.
|
||||
|
||||
Therefore the `core` configuration will only be composed of dependencies declared in the `core` configuration itself, the `compile` configuration will be composed of all dependencies required in either `core` or `compile` configuration, but without transivity (neither for core nor compile dependencies), and `runtime` will be composed of all dependencies, all transitively, including the dependencies declared only in `compile`.
|
||||
Therefore the `core` configuration will only be composed of dependencies declared in the `core` configuration itself, the `compile` configuration will be composed of all dependencies required in either `core` or `compile` configuration, but without transitivity (neither for core nor compile dependencies), and `runtime` will be composed of all dependencies, all transitively, including the dependencies declared only in `compile`.
|
||||
|
|
|
|||
|
|
@ -62,18 +62,18 @@ For instance, say you have:
|
|||
[source,xml]
|
||||
----
|
||||
<configurations defaultconfmapping="conf1->other1;conf2->other2">
|
||||
<conf name="conf1" />
|
||||
<conf name="conf2" extends="conf1" />
|
||||
<conf name="conf1"/>
|
||||
<conf name="conf2" extends="conf1"/>
|
||||
</configurations>
|
||||
<dependencies>
|
||||
<dependency name="other-module" conf="conf1" />
|
||||
<dependency name="other-module" conf="conf1"/>
|
||||
</dependencies>
|
||||
----
|
||||
|
||||
When Ivy parses this file, it will construct the following dependency (in-memory only):
|
||||
[source,xml]
|
||||
----
|
||||
<dependency name="other-module" conf="conf1->other1" />
|
||||
<dependency name="other-module" conf="conf1->other1"/>
|
||||
----
|
||||
|
||||
So, if you now resolve the `conf2` configuration, you will only get the other1 dependencies of your other-module.
|
||||
|
|
@ -82,7 +82,7 @@ But when you set `confmappingoverride` to `true`, Ivy will construct the followi
|
|||
|
||||
[source,xml]
|
||||
----
|
||||
<dependency name="other-module" conf="conf1->other1;conf2->other2" />
|
||||
<dependency name="other-module" conf="conf1->other1;conf2->other2"/>
|
||||
----
|
||||
|
||||
As you can see, the `defaultmappings` of the extending configurations are also added (although you didn't explicitly defined them)
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ There are two things optimized during conflict resolution: download of artifacts
|
|||
That's why the order of dependencies is important for download optimization. Indeed ivy traverses the dependency graph in the order in which dependencies are declared in the ivy files, and each time it encounters a dependency on a module, it first check if there is a conflict on this module, and if this is the case, it asks the conflict manager to resolve the conflict. Then if the module is evicted, it does not download its ivy file, and the whole branch is not traversed, which can saves a lot of time.
|
||||
|
||||
If no specific conflict manager is defined, a default conflict manager is used for all modules.
|
||||
|
||||
|
||||
The current default conflict manager is the `latest-revision` conflict manager.
|
||||
|
||||
== Attributes
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@
|
|||
*__(since 2.0)__* the conflicts section is deprecated. Use the link:../ivyfile/conflict.html[conflict] instead.
|
||||
|
||||
Container for conflict manager elements, used to indicate how conflicts should be resolved
|
||||
for this module.
|
||||
for this module.
|
||||
|
||||
The list of built-in conflict managers available is listed on the link:../settings/conflict-managers.html[conflict manager configuration page].
|
||||
|
||||
|
|
@ -37,13 +37,13 @@ ivy needs to know the dependency graph, and to know the dependency graph, it has
|
|||
ivy files. But ivy is highly optimized on this too, and it tries to evict modules as soon as possible.
|
||||
|
||||
That's why the order of dependencies is important for download optimization. Indeed ivy
|
||||
traverses the dependency graph in the order in which dependencies are declared in the ivy files,
|
||||
and each time it encounters a dependency on a module, it first check if there is a conflict on this module,
|
||||
traverses the dependency graph in the order in which dependencies are declared in the ivy files,
|
||||
and each time it encounters a dependency on a module, it first check if there is a conflict on this module,
|
||||
and if this is the case, it asks the conflict manager to resolve the conflict. Then if the module is evicted,
|
||||
it does not download its ivy file, and the whole branch is not traversed, which can saves
|
||||
a lot of time.
|
||||
|
||||
If this container is not present, a default conflict manager is used for all modules.
|
||||
If this container is not present, a default conflict manager is used for all modules.
|
||||
The current default conflict manager is the `latest-revision` conflict manager.
|
||||
|
||||
== Child elements
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@
|
|||
|
||||
*Tag:* dependencies *Parent:* link:../ivyfile.html[ivy-module]
|
||||
|
||||
Container for dependency elements, used to describe the dependencies of this module.
|
||||
Container for dependency elements, used to describe the dependencies of this module.
|
||||
If this container is not present, it is assumed that the module has no dependency at all.
|
||||
|
||||
This container provides for two similar behaviors. An overview is given here. (See link:../ivyfile/configurations.html[configurations doc page] for more details about these behaviors).
|
||||
|
|
|
|||
|
|
@ -19,8 +19,8 @@
|
|||
|
||||
*Tag:* artifact *Parent:* link:../ivyfile/dependency.html[dependency]
|
||||
|
||||
This feature gives you more control on a dependency for which you do not control its ivy file.
|
||||
It enables to specify the artifacts required, if the dependency has no ivy file.
|
||||
This feature gives you more control on a dependency for which you do not control its ivy file.
|
||||
It enables to specify the artifacts required, if the dependency has no ivy file.
|
||||
|
||||
Indeed, when a module has no ivy file, it is assumed that it publishes exactly one artifact having the same name as the module itself. But when this module publishes more artifacts, or simply does not respect the name rule, and if you cannot deliver an ivy file for it (because you do not control the repository, for instance - think about maven ibiblio repository, to give no name), then this feature let you specify the artifacts names you want to get.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Describes a configuration mapping for a dependency. See also the inline configur
|
|||
[options="header",cols="15%,50%,35%"]
|
||||
|=======
|
||||
|Attribute|Description|Required
|
||||
|name|the name of the master configuration to map.
|
||||
|name|the name of the master configuration to map.
|
||||
|
||||
`$$*$$` wildcard can be used to designate all configurations of this module|Yes
|
||||
|mapped|a comma separated list of dependency configurations to which this master configuration should be mapped|No, default to the same configuration as master one, unless nested mapped elements are specified
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@
|
|||
|
||||
*Tag:* include *Parent:* link:../ivyfile/dependency.html[dependency]
|
||||
|
||||
This feature gives you more control on a dependency for which you do not control its ivy file.
|
||||
This feature gives you more control on a dependency for which you do not control its ivy file.
|
||||
It enables to restrict the artifacts required by including only the artifacts given here, even if configuration does not a good separation of published artifacts.
|
||||
|
||||
Each artifact restriction can be given in the context of particular master configurations. By default, if no configuration is specified, artifacts restriction apply to all master configurations. But you can specify that a restriction applies only to one or several master configurations, using either inline or nested conf specification. In this case, do not forget that if you do not specify any restriction for a particular configuration, then no restriction will apply for this configuration and it will be resolved not taking into account any restriction.
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ The way to determine which revision is the "latest" between two is configurable
|
|||
|
||||
*__since 2.0__* The `dependency` tag supports two revision attributes: `rev`, corresponding to the default required dependency revision, and `revConstraint`, corresponding to a dynamic revision constraint applied on this dependency.
|
||||
|
||||
Depending on the link:../use/resolve.html[resolve mode] used, the actual revision used during dependency resolution may vary. These revisions usually differ only for modules published in a repository. When link:../use/deliver.html[deliver] is used, dynamic version constraints are replaced by a stic version constraint, to help build reproducibility. However, the information of the original version constraint is not lost, but rather put in the `revConstraint` attribute. This both ensure better metadata in the repository while still allowing easier build reproducibility.
|
||||
Depending on the link:../use/resolve.html[resolve mode] used, the actual revision used during dependency resolution may vary. These revisions usually differ only for modules published in a repository. When link:../use/deliver.html[deliver] is used, dynamic version constraints are replaced by a static version constraint, to help build reproducibility. However, the information of the original version constraint is not lost, but rather put in the `revConstraint` attribute. This both ensure better metadata in the repository while still allowing easier build reproducibility.
|
||||
|
||||
== Configurations mapping
|
||||
|
||||
|
|
@ -95,7 +95,7 @@ Example: Let's foo be a module with two configurations, A and B, B extending A.
|
|||
|
||||
If you don't understand really how this works, do not use it :-)
|
||||
|
||||
*__since 1.4__* `%` can be used as left side operand to mean "all the other configurations". This can be usefull when you only have a specific mapping for some configurations and a default mapping for all the others. For instance, `$$test->runtime;%->default$$` means that the `test` configuration is mapped to the `runtime` configuration, but all the other configurations are mapped to the `default` configuration.
|
||||
*__since 1.4__* `%` can be used as left side operand to mean "all the other configurations". This can be useful when you only have a specific mapping for some configurations and a default mapping for all the others. For instance, `$$test->runtime;%->default$$` means that the `test` configuration is mapped to the `runtime` configuration, but all the other configurations are mapped to the `default` configuration.
|
||||
|
||||
*__since 1.3__* a fallback mechanism can be used when you are not sure that the dependency will have the required conf. You can indicate to ivy that you want one configuration, but if it isn't present, use another one.
|
||||
The syntax for specifying this adds the fallback conf between parenthesis right after the required conf.
|
||||
|
|
@ -104,7 +104,7 @@ For instance, `$$test->runtime(default)$$` means that in the test configuration
|
|||
|
||||
*__since 2.1__* It is also possible to define dependencies on configurations intersection. A configuration intersection is defined using a `+` sign to separate the configuration (eg `A+B` means the intersection of configuration A and B). In that case only artifacts and dependencies defined in both configurations in the dependency will be part of the master configuration defining the dependency on the configuration intersection.
|
||||
|
||||
Configuration intersections can also be used when specifying the confs to link:../use/resolve.html[resolve].
|
||||
Configuration intersections can also be used when specifying the confs to link:../use/resolve.html[resolve].
|
||||
|
||||
Moreover, the mapping `$$*->@$$` is handled as a specific case with configuration intersections: it maps also the intersections. So if one resolve conf `A+B` in a module which defines a dependency with mapping `$$*->@$$`, the mapping `$$*->@$$` is interpreted as `$$A+B->A+B$$` so the intersection of A and B will be resolved in the dependency.
|
||||
|
||||
|
|
@ -114,10 +114,10 @@ For instance, if you have:
|
|||
[source,xml]
|
||||
----
|
||||
<configurations>
|
||||
<conf name="red" e:axis="color" />
|
||||
<conf name="blue" e:axis="color" />
|
||||
|
||||
<conf name="windows" e:axis="platform" />
|
||||
<conf name="red" e:axis="color"/>
|
||||
<conf name="blue" e:axis="color"/>
|
||||
|
||||
<conf name="windows" e:axis="platform"/>
|
||||
<conf name="linux" e:axis="platform"/>
|
||||
</configurations>
|
||||
----
|
||||
|
|
@ -148,7 +148,7 @@ See link:../ivyfile/dependency-artifact.html[dependency artifact] for details.
|
|||
|
||||
Finally, the dependency element also supports an a force attribute (since 0.8), which gives an indication
|
||||
to conflicts manager to force the revision of a dependency to the one given here.
|
||||
See link:../ivyfile/conflicts.html[conflicts manager] for details.
|
||||
See link:../ivyfile/conflicts.html[conflicts manager] for details.
|
||||
|
||||
*__since 1.4__* this tag supports link:../concept.html#extra[extra attributes]
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,8 @@
|
|||
|
||||
*Tag:* exclude *Parent:* link:../ivyfile/dependencies.html[dependencies]
|
||||
|
||||
*__since 2.0__* This feature gives you more control on a dependency for which you do not control its ivy file. It allows to exclude artifacts, modules or organizations from the list of dependencies for the whole module.
|
||||
*__since 2.0__* This feature gives you more control on a dependency for which you do not control its ivy file.
|
||||
It allows to exclude artifacts, modules or organizations from the list of dependencies for the whole module.
|
||||
|
||||
It is very similar to the link:../ivyfile/artifact-exclude.html[dependency exclude] element, except that it applies to a whole module, which can be very useful when a lot of dependencies transitively bring a module you don't want.
|
||||
|
||||
|
|
|
|||
|
|
@ -41,8 +41,7 @@ When delivering an ivy file with such an inclusion, the included configuration f
|
|||
----
|
||||
<ivy-module version="1.0">
|
||||
<info organisation="myorg"
|
||||
module="mymodule"
|
||||
/>
|
||||
module="mymodule"/>
|
||||
<configurations>
|
||||
<include file="path/to/included-configurations.xml"/>
|
||||
<conf name="conf3"/>
|
||||
|
|
|
|||
|
|
@ -49,4 +49,3 @@ Gives identification and basic information about the module this ivy file descri
|
|||
|=======
|
||||
|
||||
After the description, you can also place your own tags in your own namespace. This allow to provide some custom information about the module.
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@
|
|||
|
||||
*Tag:* ivyauthor *Parent:* link:../ivyfile/info.html[info]
|
||||
|
||||
Gives information about who has contributed to write this ivy file. It does NOT indicate who
|
||||
Gives information about who has contributed to write this ivy file. It does NOT indicate who
|
||||
is the author of the module itself.
|
||||
|
||||
== Attributes
|
||||
|
|
|
|||
|
|
@ -23,7 +23,11 @@
|
|||
|
||||
Specify a a conflict manager for one or several dependencies.
|
||||
|
||||
The way to specify a conflict manager is by giving indication to which dependencies the conflict manager applies (by giving organisation and module names or name regexp), and then specifying the conflict manager, either by giving its name or by specifying a fixed revision list, in which case a fixed conflicts manager is used.
|
||||
The way to specify a conflict manager is by giving indication to which dependencies
|
||||
the conflict manager applies (by giving organisation and module names or name regexp),
|
||||
and then specifying the conflict manager, either by giving its name or by
|
||||
specifying a fixed revision list, in which case a fixed conflicts manager is used.
|
||||
|
||||
|
||||
See link:../ivyfile/conflicts.html[Conflicts Manager] for details on conflicts manager in general.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Describes a mapped dependency configuration for a master configuration.
|
|||
[options="header",cols="15%,50%,35%"]
|
||||
|=======
|
||||
|Attribute|Description|Required
|
||||
|name|the name of the dependency configuration mapped.
|
||||
|name|the name of the dependency configuration mapped.
|
||||
|
||||
`$$*$$` wildcard can be used to designate all configurations of this module|Yes
|
||||
|=======
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ Note that even though no attribute is required, it makes no sense to set no attr
|
|||
|Attribute|Description|Required
|
||||
|org|the name, or an expression matching the name of organisation to which overriding should be applied (see matcher attribute below)|No, defaults to `$$*$$` (match all)
|
||||
|module|the name, or an expression matching the name of module to which overriding should be applied (see matcher attribute below)|No, defaults to `$$*$$` (match all)
|
||||
|branch|the branch to set for all the overriden dependency descriptors|No, by default branch is not overriden
|
||||
|rev|the revision to set for all the overriden dependency descriptors|No, by default revision is not overriden
|
||||
|branch|the branch to set for all the overridden dependency descriptors|No, by default branch is not overridden
|
||||
|rev|the revision to set for all the overridden dependency descriptors|No, by default revision is not overridden
|
||||
|matcher|the link:../concept.html#matcher[matcher] to use to match the modules for which the conflict manager should be used|No, defaults to `exact`
|
||||
|=======
|
||||
|
|
|
|||
|
|
@ -46,5 +46,3 @@ Johan stuyts, the author of SAnt, also contributed a nice article on his view of
|
|||
|
||||
|
||||
Apache Ivy - Beginners Guide is a step by step guide to assist beginners in understanding basic concepts/tasks and use them straight away in their projects either through Ant build or in Eclipse IDE.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -26,13 +26,13 @@ Since Apache Ivy™ 2.3, some support for OSGi™ dependency management ha
|
|||
WARNING: Note that this feature is considered as *experimental*. It should work with simple configuration but may not in complex ones. If you have any issue with that feature, you are welcomed to come discuss your use case on the link:http://ant.apache.org/ivy/mailing-lists.html[ivy-user] mailing list, or discuss about implementation issues or improvement you may have found, on link:http://ant.apache.org/ivy/mailing-lists.html[ant-dev].
|
||||
|
||||
|
||||
So with a standard ivy.xml, you can express some dependency on some OSGi bundle and every of their trasitive dependencies will be resolved. You can also declare in your ivy.xml some OSGi dependency, like a `Require-Bundle`, an `Import-Package` or an `Import-Service`, miming an OSGi MANIFEST.MF.
|
||||
So with a standard ivy.xml, you can express some dependency on some OSGi bundle and every of their transitive dependencies will be resolved. You can also declare in your ivy.xml some OSGi dependency, like a `Require-Bundle`, an `Import-Package` or an `Import-Service`, miming an OSGi MANIFEST.MF.
|
||||
|
||||
|
||||
== Note on the implementation
|
||||
|
||||
|
||||
With OSGi we can declare different kind of capabilites of a bundle which can match different kind of requirements of some other bundles (`Require-Bundle`/`Bundle-SymbolicName`, `Import-Package`/`Export-Package`, `Import-Service`/`Export-Service`). In Ivy we only have one kind of requirement and one kind of capability: the symbolic name of the bundle. Due to that restriction Ivy may not resolve exactly how we would expect with OSGi. The runtime of Ivy won't be as smart as a pure OSGi dependency manager. But we think that the mapping is working for most of the use cases involing OSGi dependencies management.
|
||||
With OSGi we can declare different kind of capabilities of a bundle which can match different kind of requirements of some other bundles (`Require-Bundle`/`Bundle-SymbolicName`, `Import-Package`/`Export-Package`, `Import-Service`/`Export-Service`). In Ivy we only have one kind of requirement and one kind of capability: the symbolic name of the bundle. Due to that restriction Ivy may not resolve exactly how we would expect with OSGi. The runtime of Ivy won't be as smart as a pure OSGi dependency manager. But we think that the mapping is working for most of the use cases involving OSGi dependencies management.
|
||||
|
||||
Details on the mapping of the OSGi dependency model into Ivy's one can be found in that link:osgi/osgi-mapping.html[page].
|
||||
|
||||
|
|
@ -42,7 +42,7 @@ Details on the mapping of the OSGi dependency model into Ivy's one can be found
|
|||
|
||||
Since the nature of the OSGi dependencies, resolving against a repository cannot be started before acquiring the metadata of every bundle of the repository. To resolve an `Import-Package`, Ivy has to find every bundle which has the proper `Export-Package`. So unlike the usual Ivy resolvers, the OSGi capable ones have to get the descriptor before starting a resolve.
|
||||
|
||||
The descriptor probably being not instantanly downloaded, the descriptor is put in cache. (FIXME not implemented)
|
||||
The descriptor probably being not instantly downloaded, the descriptor is put in cache. (FIXME not implemented)
|
||||
|
||||
|
||||
== Use cases
|
||||
|
|
@ -50,10 +50,9 @@ The descriptor probably being not instantanly downloaded, the descriptor is put
|
|||
|
||||
Here are different use case of using the OSGi capabilities of Ivy:
|
||||
|
||||
|
||||
* link:osgi/eclipse-plugin.html[building an Eclipse™ plugin] +
|
||||
|
||||
* link:osgi/standard-osgi.html[building a standard OSGi bundle] +
|
||||
|
||||
* link:osgi/target-platform.html[managing a "target" platform] +
|
||||
|
||||
* link:osgi/eclipse-plugin.html[building an Eclipse™ plugin] +
|
||||
|
||||
* link:osgi/standard-osgi.html[building a standard OSGi bundle] +
|
||||
|
||||
* link:osgi/target-platform.html[managing a "target" platform] +
|
||||
|
|
|
|||
|
|
@ -39,11 +39,11 @@ In few steps, we will setup a build to compile and package an Eclipse plugin.
|
|||
|
||||
* in the `ivysettings.properties`, specify the location of the plugins folder of your Eclipse target
|
||||
|
||||
* in the `ivy.xml`, change the symbolic name declared in the extends element
|
||||
* in the `ivy.xml`, change the symbolic name declared in the extends element
|
||||
|
||||
* *__(optional)__* by default the `build.xml` is expecting the sources to be in the `src` folder. You may want to edit it if it is not the case
|
||||
* *__(optional)__* by default the `build.xml` is expecting the sources to be in the `src` folder. You may want to edit it if it is not the case
|
||||
|
||||
* *__(optional)__* if Ivy is not in Ant's classpath, link:http://ant.apache.org/ivy/download.cgi[download the Ivy jar] and edit the `build.xml` accordingly (see the comments at the begining of the file)
|
||||
* *__(optional)__* if Ivy is not in Ant's classpath, link:http://ant.apache.org/ivy/download.cgi[download the Ivy jar] and edit the `build.xml` accordingly (see the comments at the beginning of the file)
|
||||
|
||||
|
||||
And that's it ! Now let's use it.
|
||||
|
|
@ -91,8 +91,8 @@ NOTE: For resolution to work correctly, Ivy relies on the aggregated metadata of
|
|||
|
||||
When building an Eclipse plugin, we are relying on a "target platform", the Eclipse installation we want our plugin to be eventually installed into. For Ivy, this will represent the repository of artifacts.
|
||||
|
||||
Ivy needs an aggragation of the OSGi metadata in order to resolve a such repository. The Ant task link:../use/buildobr.html[buildobr] builds a OBR (OSGi Bundle Repository) descriptor file from a set of OSGi bundles. So here we are using this Ant task to gather OSGi metadata from the Eclipse plugins in the "target platform". In the above example, the file is built in `target/repo-eclipse.xml`.
|
||||
Ivy needs an aggregation of the OSGi metadata in order to resolve a such repository. The Ant task link:../use/buildobr.html[buildobr] builds a OBR (OSGi Bundle Repository) descriptor file from a set of OSGi bundles. So here we are using this Ant task to gather OSGi metadata from the Eclipse plugins in the "target platform". In the above example, the file is built in `target/repo-eclipse.xml`.
|
||||
|
||||
The plugin to be built has a `ivy.xml` file describing its depedencies to be used by Ivy. Since the actual depedencies are in the `MANIFEST.MF` file, in the `ivy.xml` file we specify that it extends `META-INF/MANIFEST.MF`. So there not much dependencies specified in the `ivy.xml`. But as Ivy doesn't support the `Bundle-Fragment` OSGi feature, the `ivy.xml` can help specify the missing dependencies.
|
||||
The plugin to be built has a `ivy.xml` file describing its dependencies to be used by Ivy. Since the actual dependencies are in the `MANIFEST.MF` file, in the `ivy.xml` file we specify that it extends `META-INF/MANIFEST.MF`. So there not much dependencies specified in the `ivy.xml`. But as Ivy doesn't support the `Bundle-Fragment` OSGi feature, the `ivy.xml` can help specify the missing dependencies.
|
||||
|
||||
Having this setup, it is then a standard Ant+Ivy build. Ivy computes the classpath to be then used by the `javac` tasks. Note that `javac` is not aware of the OSGi metadata and is then incapable of failing to compile if private packages are accessed.
|
||||
|
|
|
|||
|
|
@ -29,10 +29,10 @@ This page is a description of how OSGi™ dependencies are mapped into Apache
|
|||
|
||||
In OSGi a bundle is identified by its symbolic name. In Ivy there is a notion of organisation and module name.
|
||||
|
||||
The choosen mapping is:
|
||||
The chosen mapping is:
|
||||
|
||||
|
||||
* The organisation is "bundle" (transitive dependencies like pakages or services have their own organisations, "package" and "service") +
|
||||
* The organisation is "bundle" (transitive dependencies like packages or services have their own organisations, "package" and "service") +
|
||||
|
||||
* The module name is the symbolic name +
|
||||
|
||||
|
|
@ -40,12 +40,12 @@ The choosen mapping is:
|
|||
|
||||
[]
|
||||
|=======
|
||||
| *OSGi* | *Ivy*
|
||||
| `Bundle-SymbolicName: com.acme.product.plugin`
|
||||
| *OSGi* | *Ivy*
|
||||
| `Bundle-SymbolicName: com.acme.product.plugin`
|
||||
a|
|
||||
[source, xml]
|
||||
----
|
||||
<info organisation="bundle" module="com.acme.product.plugin" />
|
||||
<info organisation="bundle" module="com.acme.product.plugin"/>
|
||||
----
|
||||
|
||||
|=======
|
||||
|
|
@ -62,13 +62,13 @@ When it comes to version ranges, Ivy will correctly understand fully defined ran
|
|||
|
||||
[]
|
||||
|=======
|
||||
| *OSGi* | *Ivy*
|
||||
| `Bundle-Version: 3.3.3` | `revision="3.3.3"`
|
||||
|`Require-Bundle: com.acme.product.plugin;bundle-version="3.2.1"`
|
||||
| *OSGi* | *Ivy*
|
||||
| `Bundle-Version: 3.3.3` | `revision="3.3.3"`
|
||||
|`Require-Bundle: com.acme.product.plugin;bundle-version="3.2.1"`
|
||||
a|
|
||||
[source, xml]
|
||||
----
|
||||
<dependency org="bundle" name="com.acme.product.plugin" rev="[3.2.1,)" />
|
||||
<dependency org="bundle" name="com.acme.product.plugin" rev="[3.2.1,)"/>
|
||||
----
|
||||
|
||||
|
||||
|
|
@ -79,12 +79,12 @@ a|
|
|||
== Ivy configurations
|
||||
|
||||
|
||||
Ivy has the concept of link:../terminology.html#configurations[module configurations]. OSGi on the other hand, doesn't have such a concept. However, Ivy defines the following configurations, when it comes to dependency mapping for OSGi:
|
||||
Ivy has the concept of link:../terminology.html#configurations[module configurations]. OSGi on the other hand, doesn't have such a concept. However, Ivy defines the following configurations, when it comes to dependency mapping for OSGi:
|
||||
|
||||
|
||||
* `default` : it will contain every required dependency (transitively)
|
||||
* `default` : it will contain every required dependency (transitively)
|
||||
|
||||
* `optional` : it will contain every optional dependency and every required depedency the the first degree dependencies.
|
||||
* `optional` : it will contain every optional dependency and every required dependency the the first degree dependencies.
|
||||
|
||||
* `transitive-optional` : it will contain every optional dependency (optional transitively)
|
||||
|
||||
|
|
@ -107,26 +107,26 @@ Exported package, are declaring capabilities of the bundle in term of package. B
|
|||
|
||||
First, each exported package will be declared in the ivy.xml as a configuration. The name of the configuration will start will `use_` and will end with the name of that package.
|
||||
|
||||
Then each time an exported package is declared to use some other one, it will be mapped as a dependency between the Ivy configurations corresponding to those packages.
|
||||
Then each time an exported package is declared to use some other one, it will be mapped as a dependency between the Ivy configurations corresponding to those packages.
|
||||
|
||||
|
||||
[]
|
||||
|=======
|
||||
| *OSGi* | *Ivy*
|
||||
| `Export-Package: com.acme.product.plugin.utils`
|
||||
| *OSGi* | *Ivy*
|
||||
| `Export-Package: com.acme.product.plugin.utils`
|
||||
a|
|
||||
[source, xml]
|
||||
----
|
||||
<configuration name="use_com.acme.product.plugin.utils" extends="default" />
|
||||
<configuration name="use_com.acme.product.plugin.utils" extends="default"/>
|
||||
----
|
||||
|
||||
|
||||
| `Export-Package: com.acme.product.plugin.utils,com.acme.product.plugin.common;use:=com.acme.product.plugin.utils`
|
||||
| `Export-Package: com.acme.product.plugin.utils,com.acme.product.plugin.common;use:=com.acme.product.plugin.utils`
|
||||
a|
|
||||
[source, xml]
|
||||
----
|
||||
<configuration name="use_com.acme.product.plugin.utils" extends="default" />
|
||||
<configuration name="use_com.acme.product.plugin.common" extends="default,use_com.acme.product.plugin.utils" />
|
||||
<configuration name="use_com.acme.product.plugin.utils" extends="default"/>
|
||||
<configuration name="use_com.acme.product.plugin.common" extends="default,use_com.acme.product.plugin.utils"/>
|
||||
----
|
||||
|
||||
|
||||
|
|
@ -137,7 +137,7 @@ a|
|
|||
== OSGi Requirements / Ivy dependencies
|
||||
|
||||
|
||||
In OSGi there are different kind of dependencies, which is an OSGi bundle repository documentation is called a "requirement". The problem is that Ivy undesrstands only one kind of requirement, so we use here some extra attribute to declare those different kind of dependency.
|
||||
In OSGi there are different kind of dependencies, which is an OSGi bundle repository documentation is called a "requirement". The problem is that Ivy understands only one kind of requirement, so we use here some extra attribute to declare those different kind of dependency.
|
||||
|
||||
|
||||
=== Require-Bundle
|
||||
|
|
@ -150,20 +150,20 @@ If there is the OSGi `resolution` parameter specified to `optional`, then the de
|
|||
|
||||
[]
|
||||
|=======
|
||||
| *OSGi* | *Ivy*
|
||||
| `Require-Bundle: com.acme.product.plugin;bundle-version="3.2.1"`
|
||||
| *OSGi* | *Ivy*
|
||||
| `Require-Bundle: com.acme.product.plugin;bundle-version="3.2.1"`
|
||||
a|
|
||||
[source, xml]
|
||||
----
|
||||
<dependency osgi="bundle" org="" name="com.acme.product.plugin" rev="[3.2.1,)" conf="default->default" />
|
||||
<dependency osgi="bundle" org="" name="com.acme.product.plugin" rev="[3.2.1,)" conf="default->default"/>
|
||||
----
|
||||
|
||||
|
||||
| `Require-Bundle: com.acme.product.plugin;bundle-version="3.2.1";resolution:="optional"`
|
||||
| `Require-Bundle: com.acme.product.plugin;bundle-version="3.2.1";resolution:="optional"`
|
||||
a|
|
||||
[source, xml]
|
||||
----
|
||||
<dependency org="bundle" name="com.acme.product.plugin" rev="[3.2.1,)" conf="optional->default;transitive-optional->transitive-optional" />
|
||||
<dependency org="bundle" name="com.acme.product.plugin" rev="[3.2.1,)" conf="optional->default;transitive-optional->transitive-optional"/>
|
||||
----
|
||||
|
||||
|
||||
|
|
@ -183,20 +183,20 @@ As it is an import package, the configuration of the dependency will be the `use
|
|||
|
||||
[]
|
||||
|=======
|
||||
| *OSGi* | *Ivy*
|
||||
| `Import-Package: com.acme.product.plugin.utils;version="3.2.1"`
|
||||
| *OSGi* | *Ivy*
|
||||
| `Import-Package: com.acme.product.plugin.utils;version="3.2.1"`
|
||||
a|
|
||||
[source, xml]
|
||||
----
|
||||
<dependency org="package" name="com.acme.product.plugin.utils" rev="[3.2.1,)" conf="default->default;use_com.acme.product.plugin.utils->use_com.acme.product.plugin.utils" />
|
||||
<dependency org="package" name="com.acme.product.plugin.utils" rev="[3.2.1,)" conf="default->default;use_com.acme.product.plugin.utils->use_com.acme.product.plugin.utils"/>
|
||||
----
|
||||
|
||||
|
||||
| `Import-Package: com.acme.product.plugin.utils;version="3.2.1";resolution:="optional"`
|
||||
a|
|
||||
| `Import-Package: com.acme.product.plugin.utils;version="3.2.1";resolution:="optional"`
|
||||
a|
|
||||
[source, xml]
|
||||
----
|
||||
<dependency org="package" name="com.acme.product.plugin.utils" rev="[3.2.1,)" conf="optional->default;transitive-optional->transitive-optional;use_com.acme.product.plugin.utils->use_com.acme.product.plugin.utils" />
|
||||
<dependency org="package" name="com.acme.product.plugin.utils" rev="[3.2.1,)" conf="optional->default;transitive-optional->transitive-optional;use_com.acme.product.plugin.utils->use_com.acme.product.plugin.utils"/>
|
||||
----
|
||||
|
||||
|
||||
|
|
@ -212,16 +212,16 @@ The OSGi `Bundle-RequiredExecutionEnvironment` manifest attribute specifies whic
|
|||
|
||||
[]
|
||||
|=======
|
||||
| *OSGi* | *Ivy*
|
||||
| `Bundle-RequiredExecutionEnvironment: JavaSE-1.6`
|
||||
| *OSGi* | *Ivy*
|
||||
| `Bundle-RequiredExecutionEnvironment: JavaSE-1.6`
|
||||
a|
|
||||
[source, xml]
|
||||
----
|
||||
|
||||
<dependencies>
|
||||
<exclude org="package" module="javax.accessibility" />
|
||||
<exclude org="package" module="javax.activation" />
|
||||
<exclude org="package" module="javax.activity" />
|
||||
<exclude org="package" module="javax.accessibility"/>
|
||||
<exclude org="package" module="javax.activation"/>
|
||||
<exclude org="package" module="javax.activity"/>
|
||||
...
|
||||
</dependencies>
|
||||
|
||||
|
|
|
|||
|
|
@ -50,4 +50,3 @@ The immediate consequence of this difference is that the built-in resolver is pr
|
|||
Apache Felix Sigil has its own format about specifying the OSGi dependencies. Whereas Ivy requires an `ivysettings.xml` and an `ivy.xml`, Sigil requires a `sigil-repos.properties` and a `sigil.properties`. Then if you want to use the Sigil resolver in Ivy, you will need 4 files, the 2 Ivy ones and the 2 Sigil ones, as described in the Sigil quickstart link:https://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Sigil+Ivy+Quickstart[here].
|
||||
|
||||
To support OSGi directly in Ivy, you just need to add an extra namespace in the `ivy.xml`, and in the `ivysettings.xml` just declare the proper resolver and latest revision strategy.
|
||||
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ It should work with simple configuration but may not in complex ones. If you hav
|
|||
'''
|
||||
|
||||
|
||||
This page describes how to build an OSGi™ bundle with Apache Ivy™. In this use case, we just basically want to compute a classpath to compile, optionaly one for testing too, and then publish our bundle in a OSGi aware repository.
|
||||
This page describes how to build an OSGi™ bundle with Apache Ivy™. In this use case, we just basically want to compute a classpath to compile, optionally one for testing too, and then publish our bundle in a OSGi aware repository.
|
||||
|
||||
In oder to produce OSGi metadata of sufficient quality and to avoid maintaining them manually, the link:http://bndtools.org/[bnd] tool will be used. The approach taken is then an "Ivy file first" approach. The dependencies will be specified in the `ivy.xml` file, the `MANIFEST.MF` being generated from the computed classpath.
|
||||
|
||||
|
|
@ -49,9 +49,9 @@ In few steps, we will setup a build to compile and publish an OSGi bundle.
|
|||
|
||||
* in the `ivysettings.properties`, specify the location of the plugins folder of your Eclipse target
|
||||
|
||||
* *__(optional)__* by default the `build.xml` is expecting the sources to be in the `src` folder. You may want to edit it if it is not the case
|
||||
* *__(optional)__* by default the `build.xml` is expecting the sources to be in the `src` folder. You may want to edit it if it is not the case
|
||||
|
||||
* *__(optional)__* if Ivy is not in Ant's classpath, link:http://ant.apache.org/ivy/download.cgi[download the Ivy jar] and edit the `build.xml` accordingly (see the comments at the begining of the file)
|
||||
* *__(optional)__* if Ivy is not in Ant's classpath, link:http://ant.apache.org/ivy/download.cgi[download the Ivy jar] and edit the `build.xml` accordingly (see the comments at the beginning of the file)
|
||||
|
||||
To build the project, run:
|
||||
|
||||
|
|
|
|||
|
|
@ -28,11 +28,11 @@ It should work with simple configuration but may not in complex ones. If you hav
|
|||
====
|
||||
|
||||
|
||||
The concept of "target platform" is a concept introduced by Eclipse™ to describe the set of bundles which will run together in an OSGi™ environement. Then when developping an OSGi bundle, we expect it to run in such a "target platform".
|
||||
The concept of "target platform" is a concept introduced by Eclipse™ to describe the set of bundles which will run together in an OSGi™ environment. Then when developing an OSGi bundle, we expect it to run in such a "target platform".
|
||||
|
||||
When developping a single OSGi bundle, a single `ivy.xml` (together with the use of the link:../use/fixdeps.html[fixdeps] task) is sufficent to describe precisely the bundle requirements.
|
||||
When developing a single OSGi bundle, a single `ivy.xml` (together with the use of the link:../use/fixdeps.html[fixdeps] task) is sufficient to describe precisely the bundle requirements.
|
||||
|
||||
But when developping several bundles, it will be error prone to declare for each bundle its dependencies. Because once deployed in an OSGi environement, the bindings are sensitive to the available bundles. So when developping, we must ensure that the set of bundles will be the same set as the one at deploy time.
|
||||
But when developing several bundles, it will be error prone to declare for each bundle its dependencies. Because once deployed in an OSGi environment, the bindings are sensitive to the available bundles. So when developing, we must ensure that the set of bundles will be the same set as the one at deploy time.
|
||||
|
||||
The concept of "target platform" is a perfect fit to describe the set of bundles to resolve against. Here is a recipe to handle it with just Ant+Ivy.
|
||||
|
||||
|
|
@ -50,14 +50,12 @@ First you need a project (basically a folder) in which you will manage your targ
|
|||
* and a link:../samples/target-platform/build.xml[build.xml] with which you'll manage your target platform
|
||||
|
||||
|
||||
In the build there is a target: `update-dependencies`. This target will do a resolve with the `ivy.xml` and will generate an `ivy-fixed.xml` from the resolved depedencies. This `ivy-fixed.xml` file contains only fixed non transitive dependencies (see the link:../use/fixdeps.html[fixdeps] task for further info). With that `ivy-fixed.xml` file, subsequent dependency resolutions are then reproducible and will always generate the same set of artifacts.
|
||||
In the build there is a target: `update-dependencies`. This target will do a resolve with the `ivy.xml` and will generate an `ivy-fixed.xml` from the resolved dependencies. This `ivy-fixed.xml` file contains only fixed non transitive dependencies (see the link:../use/fixdeps.html[fixdeps] task for further info). With that `ivy-fixed.xml` file, subsequent dependency resolutions are then reproducible and will always generate the same set of artifacts.
|
||||
|
||||
Once generated, it is recommended to share that `ivy-fixed.xml` file into you version control system (subversion, git, etc...). The target `update-dependencies` is then to be launched each time you edit the `ivy.xml`, when you want to change the content of your target platform.
|
||||
|
||||
The second target `generate-target-platform` will generate an `obr.xml`, a OSGi Bundle repository descriptor. This file will list every artifact wich has been resolved by the `ivy-fixed.xml`. Then each of your bundles you develop will do its resolve against that `obr.xml` (see the link:../resolver/obr.html[obr resolver]).
|
||||
The second target `generate-target-platform` will generate an `obr.xml`, a OSGi Bundle repository descriptor. This file will list every artifact which has been resolved by the `ivy-fixed.xml`. Then each of your bundles you develop will do its resolve against that `obr.xml` (see the link:../resolver/obr.html[obr resolver]).
|
||||
|
||||
The generated `obr.xml` contains paths to the local filesystem, so it is neither recommended to share it between developers nor commit it to version control system.
|
||||
|
||||
If it is required to develop your plugin with the Eclipse PDE plugin, you can then use the alternative target `generate-retrieved-target-platform`. It has the same principle as the `generate-target-platform` but the artifacts are also retrieved in a single folder, just like the plugins in an Eclipse install. That way you can define your target platform within Eclipse quite easily.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -28,21 +28,21 @@ More details on ant tasks link:ant.html[here].
|
|||
|
||||
== Configure
|
||||
|
||||
Ivy needs to be configured to be able to resolve your dependencies. This configuration is usually done with a settings file, which defines a set of dependency resolvers. Each resolver is able to find ivy files and/or artifacts, given simple information such as organisation, module, revision, artifact name, artifact type and artifact extension.
|
||||
Ivy needs to be configured to be able to resolve your dependencies. This configuration is usually done with a settings file, which defines a set of dependency resolvers. Each resolver is able to find ivy files and/or artifacts, given simple information such as organisation, module, revision, artifact name, artifact type and artifact extension.
|
||||
|
||||
The configuration is also responsible for indicating which resolver should be used to resolve which module. This configuration is dependent only on your environment, i.e. where the modules and artifacts can be found.
|
||||
The configuration is also responsible for indicating which resolver should be used to resolve which module. This configuration is dependent only on your environment, i.e. where the modules and artifacts can be found.
|
||||
|
||||
A default configuration is used by ivy when none is given. This configuration uses an link:resolver/ibiblio.html[ibiblio resolver] pointing to https://repo1.maven.org/maven2/ to resolve all modules.
|
||||
|
||||
== Resolve
|
||||
|
||||
The resolve time is the moment when ivy actually resolves the dependencies of one module. It first needs to access the ivy file of the module for which it resolves the dependencies.
|
||||
The resolve time is the moment when ivy actually resolves the dependencies of one module. It first needs to access the ivy file of the module for which it resolves the dependencies.
|
||||
|
||||
Then, for each dependency declared in this file, it asks the appropriate resolver (according to settings) to find the module (i.e. either an ivy file for it, or its artifacts if no ivy file can be found). It also uses a filesystem based cache to avoid asking for a dependency if it is already in cache (at least if possible, which is not the case with latest revisions).
|
||||
|
||||
If the resolver is a composite one (i.e. a chain or a dual resolver), several resolvers may actually be called to find the module.
|
||||
|
||||
When the dependency module has been found, its ivy file is downloaded to the ivy cache. Then ivy checks if the dependency module has dependencies, in which case it recursilvely traverses the graph of dependencies.
|
||||
When the dependency module has been found, its ivy file is downloaded to the ivy cache. Then ivy checks if the dependency module has dependencies, in which case it recursively traverses the graph of dependencies.
|
||||
|
||||
All over this traversal, conflict management is done to prevent access to a module as soon as possible.
|
||||
|
||||
|
|
@ -78,4 +78,3 @@ This is done with a simple xsl transformation of the xml report generated at res
|
|||
== Publish
|
||||
|
||||
Finally, Ivy can be used to publish a particular version of a module in your repository, so that it becomes available for future resolving. This task is usually called either manually or from a continuous integration server.
|
||||
|
||||
|
|
|
|||
|
|
@ -27,37 +27,37 @@
|
|||
----
|
||||
|
||||
December 21, 2015 - The Apache Ivy project is pleased to announce its 2.5.0 release.
|
||||
|
||||
|
||||
Apache Ivy is a tool for managing (recording, tracking, resolving and
|
||||
reporting) project dependencies, characterized by flexibility,
|
||||
configurability, and tight integration with Apache Ant.
|
||||
|
||||
Key features of this 2.5.0 release are
|
||||
* Ivy now uses BoucyCastle 1.52. Due to the non backward compatibility of that library, earlier versions are not supported.
|
||||
* Ivy now uses BouncyCastle 1.52. Due to the non backward compatibility of that library, earlier versions are not supported.
|
||||
* the minimum Java version required is now Java 7
|
||||
* TODO
|
||||
* TODO
|
||||
|
||||
You can download this 2.5.0 release at:
|
||||
http://ant.apache.org/ivy/download.cgi
|
||||
|
||||
|
||||
Issues should be reported to:
|
||||
https://issues.apache.org/jira/browse/IVY
|
||||
|
||||
|
||||
More information can be found on the website:
|
||||
http://ant.apache.org/ivy/
|
||||
|
||||
----
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
=== List of Changes in this Release
|
||||
|
||||
|
||||
For details about the following changes, check our JIRA install at
|
||||
|
||||
For details about the following changes, check our JIRA install at
|
||||
http://issues.apache.org/jira/browse/ivy
|
||||
|
||||
|
||||
List of changes since Ivy 2.4.0:
|
||||
|
||||
- FIX: Made the maven 'test' configuration public so we can use the test-jar as dependency (link:https://issues.apache.org/jira/browse/IVY-1444[IVY-1444])
|
||||
|
|
@ -390,5 +390,3 @@ Contributors:
|
|||
* Aleksey Zhukov +
|
||||
|
||||
* Zhong Wang +
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -48,11 +48,11 @@ This resolver uses Bintray DaaS (Distribution as a Service) platform to retrieve
|
|||
[source]
|
||||
----
|
||||
|
||||
<bintray />
|
||||
<bintray/>
|
||||
|
||||
----
|
||||
|
||||
A default, defines a link:https://bintray.com/bintray/jcenter[JCenter] bintray resolver.
|
||||
A default, defines a link:https://bintray.com/bintray/jcenter[JCenter] bintray resolver.
|
||||
In most circumstances you won't need any other resolvers as JCenter is already a super-set of many other repositories, including Maven Central.
|
||||
|
||||
|
||||
|
|
@ -68,5 +68,5 @@ In most circumstances you won't need any other resolvers as JCenter is already a
|
|||
|
||||
----
|
||||
|
||||
Defines two resolvers to use a link:https://bintray.com/dsowerby/maven[repository] "maven" of user "dsowerby" (https://dl.bintray.com/dsowerby/maven/)
|
||||
Defines two resolvers to use a link:https://bintray.com/dsowerby/maven[repository] "maven" of user "dsowerby" (https://dl.bintray.com/dsowerby/maven/)
|
||||
and link:https://bintray.com/igelgrun/batrak[repository] "batrak" of user "igelgrun" (https://dl.bintray.com/igelgrun/batrak/).
|
||||
|
|
|
|||
|
|
@ -104,4 +104,3 @@ Same as before, except that if a revision is found in the filesystem then ivyrep
|
|||
----
|
||||
|
||||
Same as first example, except that once a module is found by either filesystem or ivyrep, then it's the whole chain which will be queried to download the artifacts. So in this case ivy file and artifacts may be split across the two resolvers for the same module.
|
||||
|
||||
|
|
|
|||
|
|
@ -43,5 +43,3 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute
|
|||
|Element|Description|Cardinality
|
||||
|any resolver|two resolvers, the first being the ivy resolver, the second the artifact resolver|2
|
||||
|=======
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ The configuration of such a resolver is mainly done through ivy and artifact pat
|
|||
== Atomic publish support
|
||||
|
||||
*__since 2.0__* This resolver supports atomic publish, which is useful for environments with a lot of concurrent publish and resolve actions. The atomic publish relies on the atomicity of the rename operation in the underlying filesystem (which includes NTFS and POSIX based filesystems).
|
||||
In this case the resolver starts by publishing the module according to the pattern, but where a `.part` suffix is appended to the revision. Then the publish is committed with a rename to the final location.
|
||||
In this case the resolver starts by publishing the module according to the pattern, but where a `.part` suffix is appended to the revision. Then the publish is committed with a rename to the final location.
|
||||
|
||||
*Limitations*
|
||||
Atomic publish is currently limited in several ways:
|
||||
|
|
@ -88,5 +88,3 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute
|
|||
|ivy|defines a pattern for ivy files, using the pattern attribute|0..n
|
||||
|artifact|defines a pattern for artifacts, using the pattern attribute|1..n
|
||||
|=======
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@
|
|||
|=======
|
||||
|
||||
|
||||
This resolver usually uses ibiblio to find artifacts.
|
||||
This resolver usually uses ibiblio to find artifacts.
|
||||
|
||||
*__since 1.3__* Using the `m2compatible` attribute, you can benefit from Maven2 repository compatibility (convert dots in organisation into slashes, search for poms, use transitive dependencies of poms). This setting also affects the default place where the resolver looks for its artifacts to point to the Maven2 repository. So setting this attribute to `true` is sufficient to use Maven2 ibiblio repository.
|
||||
|
||||
|
|
@ -87,4 +87,3 @@ Defines a resolver called `maven2` using the Maven2 public repository to find mo
|
|||
----
|
||||
|
||||
Same as above, but doesn't use poms, only artifacts.
|
||||
|
||||
|
|
|
|||
|
|
@ -67,8 +67,8 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute
|
|||
----
|
||||
|
||||
<jar name="my-local-jar-resolver" file="/home/me/myrepo.jar">
|
||||
<ivy pattern="[organisation]/[module]/ivys/ivy-[revision].xml" />
|
||||
<artifact pattern="[organisation]/[module]/[type]s/[artifact]-[revision].[type]" />
|
||||
<ivy pattern="[organisation]/[module]/ivys/ivy-[revision].xml"/>
|
||||
<artifact pattern="[organisation]/[module]/[type]s/[artifact]-[revision].[type]"/>
|
||||
</jar>
|
||||
|
||||
----
|
||||
|
|
@ -82,14 +82,13 @@ A simple local jar repository.
|
|||
----
|
||||
|
||||
<jar name="my-remote-jar-resolver" url="http://www.mywebsite.com/dist/myrepo.jar">
|
||||
<ivy pattern="dir_in_jar/subdir_in_jar/[organisation]/[module]/ivys/ivy-[revision].xml" />
|
||||
<ivy pattern="dir_in_jar/another_subdir_in_jar/[organisation]/[module]/ivys/ivy-[revision].xml" />
|
||||
<artifact pattern="dir_in_jar/subdir_in_jar/[organisation]/[module]/[type]s/[artifact]-[revision].[type]" />
|
||||
<artifact pattern="dir_in_jar/another_subdir_in_jar/[organisation]/[module]/[type]s/[artifact]-[revision].[type]" />
|
||||
<artifact pattern="dir_in_jar/yet_another_subdir_in_jar/[organisation]/[module]/[type]s/[artifact]-[revision].[type]" />
|
||||
<ivy pattern="dir_in_jar/subdir_in_jar/[organisation]/[module]/ivys/ivy-[revision].xml"/>
|
||||
<ivy pattern="dir_in_jar/another_subdir_in_jar/[organisation]/[module]/ivys/ivy-[revision].xml"/>
|
||||
<artifact pattern="dir_in_jar/subdir_in_jar/[organisation]/[module]/[type]s/[artifact]-[revision].[type]"/>
|
||||
<artifact pattern="dir_in_jar/another_subdir_in_jar/[organisation]/[module]/[type]s/[artifact]-[revision].[type]"/>
|
||||
<artifact pattern="dir_in_jar/yet_another_subdir_in_jar/[organisation]/[module]/[type]s/[artifact]-[revision].[type]"/>
|
||||
</jar>
|
||||
|
||||
----
|
||||
|
||||
A remote jar repository with multiple ivy and artifact patterns, patterns pointing in some sub directories in the jar.
|
||||
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute
|
|||
|=======
|
||||
|Attribute|Description|Required
|
||||
|m2compatible|True if this resolver should be maven2 compatible, false otherwise|No, defaults to false
|
||||
|mirrorListUrl|The url where to retrive the list of mirror urls.|Yes
|
||||
|mirrorListUrl|The url where to retrieve the list of mirror urls.|Yes
|
||||
|=======
|
||||
|
||||
|
||||
|
|
@ -75,7 +75,7 @@ And the piece of settings:
|
|||
----
|
||||
|
||||
<mirroredurl name="mirrored-maven" m2compatible="true" mirrorListUrl="file:///Users/me/dev/repo/mavenrepolist.txt">
|
||||
<artifact pattern="[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" />
|
||||
<artifact pattern="[organisation]/[module]/[revision]/[artifact]-[revision].[ext]"/>
|
||||
</mirroredurl>
|
||||
|
||||
----
|
||||
|
|
@ -92,9 +92,8 @@ The mirror list can be retrieved from a geo-location aware url:
|
|||
----
|
||||
|
||||
<mirroredurl name="mirrored-asf" mirrorListUrl="http://www.apache.org/dyn/closer.cgi">
|
||||
<ivy pattern="repo/[organisation]/[module]/[revision]/ivy.xml" />
|
||||
<artifact pattern="repo/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" />
|
||||
<ivy pattern="repo/[organisation]/[module]/[revision]/ivy.xml"/>
|
||||
<artifact pattern="repo/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]"/>
|
||||
</mirroredurl>
|
||||
|
||||
----
|
||||
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute
|
|||
The requirement strategy is defining how the resolver should behave in front of several choices. In the OSGi dependency model, an `Import-Package` requirement can be satisfied by several different bundles. So when resolving such requirement, Ivy will first look into the already resolved bundles if one provides that package. If it fails to find one, then two behaviours can occur:
|
||||
|
||||
|
||||
* if the requirement strategy is `first`, among the bundles statifying the requirement, it will shoose the first one. A warn will be logged ahout the choice Ivy has to arbitrarily do. +
|
||||
* if the requirement strategy is `first`, among the bundles satisfying the requirement, it will choose the first one. A warning will be logged about the choice Ivy has to arbitrarily do. +
|
||||
|
||||
* if the requirement strategy is `noambiguity`, Ivy will make the resolution fail. +
|
||||
|
||||
|
|
@ -62,7 +62,7 @@ The requirement strategy is defining how the resolver should behave in front of
|
|||
[source, xml]
|
||||
----
|
||||
|
||||
<obr name="felix-repo" repoXmlURL="http://felix.apache.org/obr/releases.xml" />
|
||||
<obr name="felix-repo" repoXmlURL="http://felix.apache.org/obr/releases.xml"/>
|
||||
|
||||
----
|
||||
|
||||
|
|
@ -74,9 +74,8 @@ A simple repository configured to use the Felix OBR.
|
|||
[source, xml]
|
||||
----
|
||||
|
||||
<obr name="my-osgi-repo" repoXmlFile="${ivy.settings.dir}/obr/obr.xml" requirementStrategy="first" />
|
||||
<obr name="my-osgi-repo" repoXmlFile="${ivy.settings.dir}/obr/obr.xml" requirementStrategy="first"/>
|
||||
|
||||
----
|
||||
|
||||
A local repository which is trusted to always provide correct dependency for the `Import-Package` requirements.
|
||||
|
||||
|
|
|
|||
|
|
@ -50,14 +50,13 @@ As sub element, this resolver accept any kind of OSGi resolver: link:../resolver
|
|||
[source, xml]
|
||||
----
|
||||
|
||||
<updatesite name="ivyde-updatesite" url="http://www.apache.org/dist/ant/ivyde/updatesite" />
|
||||
<obr name="felix-repo" repoXmlURL="http://felix.apache.org/obr/releases.xml" />
|
||||
<updatesite name="ivyde-updatesite" url="http://www.apache.org/dist/ant/ivyde/updatesite"/>
|
||||
<obr name="felix-repo" repoXmlURL="http://felix.apache.org/obr/releases.xml"/>
|
||||
<osgi-agg name="all-osgi">
|
||||
<resolver ref="ivyde-updatesite" />
|
||||
<resolver ref="felix-repo" />
|
||||
<resolver ref="ivyde-updatesite"/>
|
||||
<resolver ref="felix-repo"/>
|
||||
</osgi-agg>
|
||||
|
||||
----
|
||||
|
||||
An aggregated OSGi reporsory composed of the Apache IvyDE Eclipse update site and the Felix OBR.
|
||||
|
||||
An aggregated OSGi repository composed of the Apache IvyDE Eclipse update site and the Felix OBR.
|
||||
|
|
|
|||
|
|
@ -39,10 +39,10 @@ The Packager resolver supports a "resource cache", where downloaded archives can
|
|||
|
||||
The packaging instructions are contained in "packager.xml" in a simple XML format. At resolve time this file gets converted into a "build.xml" file via XSLT and then executed using link:https://ant.apache.org/[Ant]. Therefore, Ant must be available as an executable on the platform. The ant task executes in a separate ant project and so is not affected by properties, etc. that may be set in any existing ant environment in which Ivy is running. However, Ivy will define a few properties for convenience; see the "Properties" listed below.
|
||||
|
||||
For security reasons, the XSLT transform ensures that
|
||||
For security reasons, the XSLT transform ensures that
|
||||
|
||||
a. all downloaded archives have verified SHA1 checksums (including cached resources); and
|
||||
|
||||
a. all downloaded archives have verified SHA1 checksums (including cached resources); and
|
||||
|
||||
b. only a very limited set of ant tasks can be performed during the artifact "build" phase; currently these include move, copy, mkdir, zip, unzip, tar, and untar (this restriction may be overridden however; see below).
|
||||
|
||||
|
||||
|
|
@ -104,22 +104,22 @@ Configure a resourceURL in situations where you don't want to rely on (or wait f
|
|||
|
||||
----
|
||||
|
||||
Defines a packager resolver which points to the `http://ivyroundup.googlecode.com/` online repository. Builds will occur in a subdirectory of
|
||||
Defines a packager resolver which points to the `http://ivyroundup.googlecode.com/` online repository. Builds will occur in a subdirectory of
|
||||
[source]
|
||||
----
|
||||
${user.home}/.ivy2/packager/build
|
||||
----
|
||||
|
||||
downloaded resources will be cached in
|
||||
downloaded resources will be cached in
|
||||
[source]
|
||||
----
|
||||
${user.home}/.ivy2/packager/cache
|
||||
----
|
||||
|
||||
and the mirror site
|
||||
and the mirror site
|
||||
[source]
|
||||
----
|
||||
ftp://mirror.example.com/pub/resources/[organisation]/[module]/
|
||||
ftp://mirror.example.com/pub/resources/[organisation]/[module]/
|
||||
----
|
||||
|
||||
will be tried first for all resources.
|
||||
|
|
@ -259,7 +259,7 @@ The m2resource XML tag supports the following attributes:
|
|||
|groupId|Maven group ID|No; defaults to ${ivy.packager.organisation}
|
||||
|artifactId|Maven artifact ID|No; defaults to ${ivy.packager.module}
|
||||
|version|Maven version|No; defaults to ${ivy.packager.revision}
|
||||
|repo|Maven repository URL|No; defaults to https://repo1.maven.org/maven2/
|
||||
|repo|Maven repository URL|No; defaults to https://repo1.maven.org/maven2/
|
||||
|=======
|
||||
|
||||
|
||||
|
|
@ -299,4 +299,3 @@ Below is an example of packaging instructions for the link:http://commons.apache
|
|||
</packager-module>
|
||||
|
||||
----
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@
|
|||
|
||||
*__since 1.4__*
|
||||
|
||||
This resolver can be used when your ivy repository is located on a server accessible via sftp. The secured nature of sftp and its widespread implementation on most *nix servers makes this resolver a very good candidate in an enterprise environment.
|
||||
This resolver can be used when your ivy repository is located on a server accessible via sftp. The secured nature of sftp and its widespread implementation on most *nix servers makes this resolver a very good candidate in an enterprise environment.
|
||||
|
||||
If your server supports ssh but not sftp, there is also an link:../resolver/ssh.html[ssh resolver].
|
||||
|
||||
|
|
@ -42,7 +42,7 @@ e.g. pattern="sftp://user:geheim@myserver.com:8022/path/to/my/repos/[artifact].[
|
|||
|
||||
|
||||
|
||||
Note that the authentication features of this resolver are exactly the same as the ssh resolver. Choosing between the two is often a matter of server implementation. If your server supports sftp, usually it's preferrable.
|
||||
Note that the authentication features of this resolver are exactly the same as the ssh resolver. Choosing between the two is often a matter of server implementation. If your server supports sftp, usually it's preferable.
|
||||
|
||||
Internally this resolver relies on link:http://www.jcraft.com/jsch/[jsch] as ssh client, which is a popular java ssh client, used for example in Eclipse.
|
||||
|
||||
|
|
@ -86,7 +86,7 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute
|
|||
<sftp user="myuser" host="myhost.com">
|
||||
<ivy pattern="/path/to/ivy/[module]/ivy.xml"/>
|
||||
<artifact pattern="/path/to/[organisation]/[module]/[artifact].[ext]"/>
|
||||
</sftp>
|
||||
</sftp>
|
||||
|
||||
----
|
||||
|
||||
|
|
@ -149,4 +149,3 @@ Will connect to yourserver.com on port 8022 with user 'user' and use keyFile `pa
|
|||
----
|
||||
|
||||
Will connect to the host named by myhost according to the config file in `/path/to/.ssh/config`, using the hostname, username, and optionally IdentityFile specified in the config section "Host myhost". For example, if the corresponding Host section contains "Hostname yourserver.com" and "User myremoteusername", it will connect to yourserver.com using username myremoteusername.
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@
|
|||
|
||||
*__since 1.4__*
|
||||
|
||||
This resolver can be used when your ivy repository is located on a server accessible via ssh. The secured nature of ssh and its widespread implementation on most *nix servers makes this resolver a very good candidate in an enterprise environment.
|
||||
This resolver can be used when your ivy repository is located on a server accessible via ssh. The secured nature of ssh and its widespread implementation on most *nix servers makes this resolver a very good candidate in an enterprise environment.
|
||||
|
||||
If your server supports sftp, you can consider using the link:../resolver/sftp.html[sftp resolver].
|
||||
|
||||
|
|
@ -75,7 +75,7 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute
|
|||
<ssh user="myuser" host="myhost.com">
|
||||
<ivy pattern="/path/to/ivy/[module]/ivy.xml"/>
|
||||
<artifact pattern="/path/to/[organisation]/[module]/[artifact].[ext]"/>
|
||||
</ssh>
|
||||
</ssh>
|
||||
|
||||
----
|
||||
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute
|
|||
The requirement strategy is defining how the resolver should behave in front of several choices. In the OSGi dependency model, an `Import-Package` requirement can be satisfied by several different bundles. So when resolving such requirement, Ivy will first look into the already resolved bundles if one provides that package. If it fails to find one, then two behaviours can occur:
|
||||
|
||||
|
||||
* if the requirement strategy is `first`, among the bundles statifying the requirement, it will shoose the first one. A warn will be logged ahout the choice Ivy has to arbitrarily do. +
|
||||
* if the requirement strategy is `first`, among the bundles satisfying the requirement, it will choose the first one. A warning will be logged about the choice Ivy has to arbitrarily do. +
|
||||
|
||||
* if the requirement strategy is `noambiguity`, Ivy will make the resolution fail. +
|
||||
|
||||
|
|
@ -64,7 +64,7 @@ The requirement strategy is defining how the resolver should behave in front of
|
|||
[source, xml]
|
||||
----
|
||||
|
||||
<updatesite name="ivyde-updatesite" url="http://www.apache.org/dist/ant/ivyde/updatesite" />
|
||||
<updatesite name="ivyde-updatesite" url="http://www.apache.org/dist/ant/ivyde/updatesite"/>
|
||||
|
||||
----
|
||||
|
||||
|
|
|
|||
|
|
@ -62,9 +62,9 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute
|
|||
----
|
||||
|
||||
<url name="two-patterns-example">
|
||||
<ivy pattern="http://ivyrep.mycompany.com/[module]/[revision]/ivy-[revision].xml" />
|
||||
<artifact pattern="http://ivyrep.mycompany.com/[module]/[revision]/[artifact]-[revision].[ext]" />
|
||||
<artifact pattern="http://ivyrep.mycompany.com/[module]/[revision]/[artifact].[ext]" />
|
||||
<ivy pattern="http://ivyrep.mycompany.com/[module]/[revision]/ivy-[revision].xml"/>
|
||||
<artifact pattern="http://ivyrep.mycompany.com/[module]/[revision]/[artifact]-[revision].[ext]"/>
|
||||
<artifact pattern="http://ivyrep.mycompany.com/[module]/[revision]/[artifact].[ext]"/>
|
||||
</url>
|
||||
|
||||
----
|
||||
|
|
|
|||
|
|
@ -52,11 +52,10 @@ This resolver shares the link:../settings/resolvers.html#common[common attribute
|
|||
----
|
||||
|
||||
<vfs name="vfs-resolver">
|
||||
<ivy pattern="sftp://username:password@host/[organisation]/[module]/[revision]/ivy.xml" />
|
||||
<artifact pattern="sftp://username:password@host/[organisation]/[module]/[revision]/[artifact].[ext]" />
|
||||
</vfs>
|
||||
<ivy pattern="sftp://username:password@host/[organisation]/[module]/[revision]/ivy.xml"/>
|
||||
<artifact pattern="sftp://username:password@host/[organisation]/[module]/[revision]/[artifact].[ext]"/>
|
||||
</vfs>
|
||||
|
||||
----
|
||||
|
||||
Access ivy and artifacts files using sftp.
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@
|
|||
////
|
||||
|
||||
Ivy is sending http headers when downloading files.
|
||||
The User-Agent http header can be controlled using a
|
||||
The User-Agent http header can be controlled using a
|
||||
[source]
|
||||
----
|
||||
http.agent
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@
|
|||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
<head>
|
||||
|
|
@ -30,12 +30,12 @@
|
|||
<a href="http://ant.apache.org/ivy/"><img src="http://ant.apache.org/ivy/images/logo.png"></a>
|
||||
</div>
|
||||
<h1>
|
||||
<a name="apache-hello-ivy"></a><span id="module">hello-ivy</span>
|
||||
by
|
||||
<a name="apache-hello-ivy"></a><span id="module">hello-ivy</span>
|
||||
by
|
||||
<span id="organisation">apache</span>
|
||||
</h1>
|
||||
<div id="date">
|
||||
resolved on
|
||||
resolved on
|
||||
2007-10-21 17:24:25</div>
|
||||
<ul id="confmenu">
|
||||
<li>
|
||||
|
|
@ -49,14 +49,14 @@
|
|||
<td class="title">Modules</td><td class="value">3</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="title">Revisions</td><td class="value">4
|
||||
<td class="title">Revisions</td><td class="value">4
|
||||
(0 searched <img src="http://ivy.jayasoft.org/images/searched.gif" alt="searched" title="module revisions which required a search with a dependency resolver to be resolved">,
|
||||
0 downloaded <img src="http://ivy.jayasoft.org/images/downloaded.gif" alt="downloaded" title="module revisions for which ivy file was downloaded by dependency resolver">,
|
||||
1 evicted <img src="http://ivy.jayasoft.org/images/evicted.gif" alt="evicted" title="module revisions which were evicted by others">,
|
||||
0 errors <img src="http://ivy.jayasoft.org/images/error.gif" alt="error" title="module revisions on which error occurred">)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="title">Artifacts</td><td class="value">3
|
||||
<td class="title">Artifacts</td><td class="value">3
|
||||
(0 downloaded,
|
||||
0 failed)</td>
|
||||
</tr>
|
||||
|
|
@ -288,7 +288,7 @@
|
|||
0 kB in cache)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="title">Evicted by</td><td class="value">2.0
|
||||
<td class="title">Evicted by</td><td class="value">2.0
|
||||
in <b>latest-revision</b> conflict manager
|
||||
</td>
|
||||
</tr>
|
||||
|
|
|
|||
|
|
@ -14,32 +14,32 @@
|
|||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
under the License.
|
||||
-->
|
||||
|
||||
<!--
|
||||
This build script is used to download dependencies for a freshly downloaded
|
||||
binary distribution of Ivy without dependencies.
|
||||
|
||||
|
||||
To use it, you only need to have this script in the directory where you
|
||||
have unzipped your binary distribution of Ivy, and to call it using
|
||||
ant -f build-install.xml
|
||||
|
||||
|
||||
If you don't want to download all optional dependencies, you can set
|
||||
the conf attribute value in the ivy:retrieve task, to select only
|
||||
the configuration you want (check the ivy.xml for details about
|
||||
which configurations are available, and what they are useful for).
|
||||
-->
|
||||
<project name="ivy-bin-install" default="download-deps"
|
||||
<project name="ivy-bin-install" default="download-deps"
|
||||
xmlns:ivy="antlib:org.apache.ivy.ant">
|
||||
<target name="init-ivy-settings">
|
||||
<echo file="${basedir}/ivysettings.xml">
|
||||
<![CDATA[
|
||||
<ivysettings>
|
||||
<include url="${ivy.default.conf.dir}/ivyconf-local.xml"/>
|
||||
<settings defaultResolver="public" />
|
||||
<settings defaultResolver="public"/>
|
||||
<resolvers>
|
||||
<!--
|
||||
<!--
|
||||
we use ivyrep for ivy and some artifacts, and ibiblio for other artifacts
|
||||
The reason for that is that commons vfs is still not released, thus we depend on an integration
|
||||
version only available on ivyrep, but not on ivyrep
|
||||
|
|
@ -52,10 +52,10 @@
|
|||
</url>
|
||||
</resolvers>
|
||||
</ivysettings>
|
||||
]]>
|
||||
]]>
|
||||
</echo>
|
||||
</target>
|
||||
|
||||
|
||||
<target name="init-ivy" depends="init-ivy-settings">
|
||||
<path id="ivy.lib.path">
|
||||
<fileset dir="${basedir}" includes="*.jar" excludes="ivy-core-*.jar"/>
|
||||
|
|
@ -63,10 +63,10 @@
|
|||
<taskdef resource="org/apache/ivy/ant/antlib.xml"
|
||||
uri="antlib:org.apache.ivy.ant" classpathref="ivy.lib.path"/>
|
||||
</target>
|
||||
|
||||
|
||||
<target name="download-deps" depends="init-ivy">
|
||||
<ivy:retrieve
|
||||
conf="*"
|
||||
<ivy:retrieve
|
||||
conf="*"
|
||||
pattern="${basedir}/lib/[conf]/[artifact]-[revision].[ext]"/>
|
||||
</target>
|
||||
</project>
|
||||
|
|
|
|||
|
|
@ -14,38 +14,38 @@
|
|||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
under the License.
|
||||
-->
|
||||
<project name="go-ivy" default="go" xmlns:ivy="antlib:org.apache.ivy.ant">
|
||||
<!--
|
||||
this build file is a self contained project: it doesn't require anything else
|
||||
<!--
|
||||
this build file is a self contained project: it doesn't require anything else
|
||||
that ant 1.6.2 or greater and java 1.4 or greater properly installed.
|
||||
|
||||
|
||||
It is used to showcase how easy and straightforward it can be to use Ivy.
|
||||
|
||||
This is not an example of the best pratice to use in a project, especially
|
||||
|
||||
This is not an example of the best practice to use in a project, especially
|
||||
for the java source code "generation" :-) (see generate-src target)
|
||||
|
||||
|
||||
To run copy this file in an empty directory, open a shell or a command window
|
||||
in this directory and run "ant". It will download ivy and then use it to resolve
|
||||
in this directory and run "ant". It will download ivy and then use it to resolve
|
||||
the dependency of the class which is itself "contained" in this build script.
|
||||
|
||||
|
||||
After a successful build run "ant" again and you will see the build will be
|
||||
much faster.
|
||||
|
||||
|
||||
More information can be found at http://ant.apache.org/ivy/
|
||||
-->
|
||||
|
||||
<!-- here is the version of ivy we will use. change this property to try a newer
|
||||
version if you want -->
|
||||
<property name="ivy.install.version" value="2.0.0-beta1" />
|
||||
<property name="ivy.jar.dir" value="${basedir}/ivy" />
|
||||
<property name="ivy.jar.file" value="${ivy.jar.dir}/ivy.jar" />
|
||||
|
||||
<property name="build.dir" value="build" />
|
||||
<property name="src.dir" value="src" />
|
||||
|
||||
|
||||
<!-- here is the version of ivy we will use. change this property to try a newer
|
||||
version if you want -->
|
||||
<property name="ivy.install.version" value="2.0.0-beta1"/>
|
||||
<property name="ivy.jar.dir" value="${basedir}/ivy"/>
|
||||
<property name="ivy.jar.file" value="${ivy.jar.dir}/ivy.jar"/>
|
||||
|
||||
<property name="build.dir" value="build"/>
|
||||
<property name="src.dir" value="src"/>
|
||||
|
||||
|
||||
<target name="download-ivy" unless="skip.download">
|
||||
<mkdir dir="${ivy.jar.dir}"/>
|
||||
<!-- download Ivy from web site so that it can be used even without any special installation -->
|
||||
|
|
@ -53,9 +53,9 @@
|
|||
<get src="https://repo1.maven.org/maven2/org/apache/ivy/ivy/${ivy.install.version}/ivy-${ivy.install.version}.jar"
|
||||
dest="${ivy.jar.file}" usetimestamp="true"/>
|
||||
</target>
|
||||
|
||||
<!-- =================================
|
||||
target: install-ivy
|
||||
|
||||
<!-- =================================
|
||||
target: install-ivy
|
||||
this target is not necessary if you put ivy.jar in your ant lib directory
|
||||
if you already have ivy in your ant lib, you can simply remove this
|
||||
target and the dependency the 'go' target has on it
|
||||
|
|
@ -70,44 +70,44 @@
|
|||
</path>
|
||||
<taskdef resource="org/apache/ivy/ant/antlib.xml"
|
||||
uri="antlib:org.apache.ivy.ant" classpathref="ivy.lib.path"/>
|
||||
</target>
|
||||
|
||||
<!-- =================================
|
||||
</target>
|
||||
|
||||
<!-- =================================
|
||||
target: go
|
||||
Go ivy, go!
|
||||
================================= -->
|
||||
<target name="go" depends="install-ivy, generate-src"
|
||||
<target name="go" depends="install-ivy, generate-src"
|
||||
description="--> resolve dependencies, compile and run the project">
|
||||
<echo message="using ivy to resolve commons-lang 2.1..."/>
|
||||
<!-- here comes the magic line: asks ivy to resolve a dependency on
|
||||
<!-- here comes the magic line: asks ivy to resolve a dependency on
|
||||
commons-lang 2.1 and to build an ant path with it from its cache -->
|
||||
<ivy:cachepath organisation="commons-lang" module="commons-lang" revision="2.1"
|
||||
<ivy:cachepath organisation="commons-lang" module="commons-lang" revision="2.1"
|
||||
pathid="lib.path.id" inline="true"/>
|
||||
|
||||
|
||||
<echo message="compiling..."/>
|
||||
<mkdir dir="${build.dir}" />
|
||||
<javac srcdir="${src.dir}" destdir="${build.dir}" classpathref="lib.path.id" />
|
||||
|
||||
<mkdir dir="${build.dir}"/>
|
||||
<javac srcdir="${src.dir}" destdir="${build.dir}" classpathref="lib.path.id"/>
|
||||
|
||||
<echo>
|
||||
We are now ready to execute our simple program with its dependency on commons-lang.
|
||||
Let's go!
|
||||
</echo>
|
||||
<java classname="example.Hello">
|
||||
<classpath>
|
||||
<path refid="lib.path.id" />
|
||||
<path location="${build.dir}" />
|
||||
<path refid="lib.path.id"/>
|
||||
<path location="${build.dir}"/>
|
||||
</classpath>
|
||||
</java>
|
||||
</target>
|
||||
|
||||
<!-- =================================
|
||||
<!-- =================================
|
||||
target: generate-src
|
||||
'Generates' the class source. It actually just echo a simple java
|
||||
'Generates' the class source. It actually just echo a simple java
|
||||
source code to a file. In real life this file would already be
|
||||
present on your file system, and this target wouldn't be necessary.
|
||||
================================= -->
|
||||
<target name="generate-src">
|
||||
<mkdir dir="${src.dir}/example" />
|
||||
<mkdir dir="${src.dir}/example"/>
|
||||
<echo file="${src.dir}/example/Hello.java">
|
||||
package example;
|
||||
|
||||
|
|
@ -117,35 +117,35 @@ public class Hello {
|
|||
public static void main(String[] args) {
|
||||
String message = "hello ivy !";
|
||||
System.out.println("standard message : " + message);
|
||||
System.out.println("capitalized by " + WordUtils.class.getName()
|
||||
System.out.println("capitalized by " + WordUtils.class.getName()
|
||||
+ " : " + WordUtils.capitalizeFully(message));
|
||||
}
|
||||
}
|
||||
</echo>
|
||||
</target>
|
||||
|
||||
<!-- =================================
|
||||
target: clean
|
||||
|
||||
<!-- =================================
|
||||
target: clean
|
||||
================================= -->
|
||||
<target name="clean" description="--> clean the project">
|
||||
<delete includeemptydirs="true" quiet="true">
|
||||
<fileset dir="${src.dir}" />
|
||||
<fileset dir="${build.dir}" />
|
||||
<fileset dir="${src.dir}"/>
|
||||
<fileset dir="${build.dir}"/>
|
||||
</delete>
|
||||
</target>
|
||||
|
||||
<!-- =================================
|
||||
target: clean-ivy
|
||||
|
||||
<!-- =================================
|
||||
target: clean-ivy
|
||||
================================= -->
|
||||
<target name="clean-ivy" description="--> clean the ivy installation">
|
||||
<delete dir="${ivy.jar.dir}"/>
|
||||
</target>
|
||||
|
||||
<!-- =================================
|
||||
target: clean-cache
|
||||
|
||||
<!-- =================================
|
||||
target: clean-cache
|
||||
================================= -->
|
||||
<target name="clean-cache" depends="install-ivy"
|
||||
<target name="clean-cache" depends="install-ivy"
|
||||
description="--> clean the ivy cache">
|
||||
<ivy:cleancache />
|
||||
<ivy:cleancache/>
|
||||
</target>
|
||||
</project>
|
||||
|
|
|
|||
|
|
@ -14,64 +14,64 @@
|
|||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
under the License.
|
||||
-->
|
||||
<project name="eclipse-plugin-build" xmlns:ivy="ivy">
|
||||
|
||||
<!-- Load Ivy ant tasks -->
|
||||
<taskdef uri="ivy" resource="org/apache/ivy/ant/antlib.xml" />
|
||||
<!-- If Ivy is not in Ant's classpath, get the jar of Ivy and use the folowing -->
|
||||
<taskdef uri="ivy" resource="org/apache/ivy/ant/antlib.xml"/>
|
||||
<!-- If Ivy is not in Ant's classpath, get the jar of Ivy and use the following -->
|
||||
<!-- taskdef rather than the above one -->
|
||||
<!--path id="ivy.classpath">
|
||||
<!--path id="ivy.classpath">
|
||||
<fileset dir="${basedir}">
|
||||
<include name="ivy.jar" />
|
||||
<include name="ivy.jar"/>
|
||||
</fileset>
|
||||
</path>
|
||||
<taskdef uri="ivy" resource="org/apache/ivy/ant/antlib.xml" classpathref="ivy.classpath" /-->
|
||||
|
||||
<!-- Load the properties where is defined the eclipse home -->
|
||||
<property file="${basedir}/ivysettings.properties" />
|
||||
<property file="${basedir}/ivysettings.properties"/>
|
||||
|
||||
<target name="clean" description="Clean the build directory">
|
||||
<delete dir="${basedir}/target" />
|
||||
<delete dir="${basedir}/target"/>
|
||||
</target>
|
||||
|
||||
<target name="buildobr" description="Build the obr index">
|
||||
<!-- build the repo.xml which aggregate every metadata of the Eclipse plugins -->
|
||||
<mkdir dir="${basedir}/target" />
|
||||
<ivy:buildobr baseDir="${eclipse.home}" basePath="${eclipse.home}" out="${basedir}/target/repo-eclipse.xml" indent="true" />
|
||||
<mkdir dir="${basedir}/target"/>
|
||||
<ivy:buildobr baseDir="${eclipse.home}" basePath="${eclipse.home}" out="${basedir}/target/repo-eclipse.xml" indent="true"/>
|
||||
</target>
|
||||
|
||||
<target name="ivy:configure">
|
||||
<!-- classical ivy configuration -->
|
||||
<ivy:configure file="ivysettings.xml" />
|
||||
<ivy:configure file="ivysettings.xml"/>
|
||||
</target>
|
||||
|
||||
<target name="ivy:resolve" depends="ivy:configure">
|
||||
<!-- classical resolve and cache-path -->
|
||||
<ivy:resolve file="ivy.xml" conf="*" />
|
||||
<ivy:cachepath pathid="compile.classpath" conf="compile" useOrigin="true" />
|
||||
<ivy:resolve file="ivy.xml" conf="*"/>
|
||||
<ivy:cachepath pathid="compile.classpath" conf="compile" useOrigin="true"/>
|
||||
</target>
|
||||
|
||||
<target name="compile" depends="ivy:resolve" description="Compile the Eclipse plugin">
|
||||
<mkdir dir="${basedir}/target/classes" />
|
||||
<mkdir dir="${basedir}/target/classes"/>
|
||||
<!-- simple javac (WARNING: contrary to the JDT, javac doesn't understand OSGi's accessibility (private packages)) -->
|
||||
<javac srcdir="${basedir}/src" classpathref="compile.classpath" destdir="${basedir}/target/classes" debug="true" includeAntRuntime="false" />
|
||||
<javac srcdir="${basedir}/src" classpathref="compile.classpath" destdir="${basedir}/target/classes" debug="true" includeAntRuntime="false"/>
|
||||
<copy todir="${basedir}/target/classes">
|
||||
<fileset dir="${basedir}/src">
|
||||
<include name="**" />
|
||||
<exclude name="**/*.java" />
|
||||
<exclude name="**/package.html" />
|
||||
<include name="**"/>
|
||||
<exclude name="**/*.java"/>
|
||||
<exclude name="**/package.html"/>
|
||||
</fileset>
|
||||
<fileset dir="${basedir}">
|
||||
<include name="plugin.xml" />
|
||||
<include name="plugin.xml"/>
|
||||
</fileset>
|
||||
</copy>
|
||||
</target>
|
||||
|
||||
<target name="build" depends="compile" description="Build the Eclipse plugin">
|
||||
<!-- simple jaring -->
|
||||
<jar basedir="${basedir}/target/classes" destfile="${basedir}/target/${ant.project.name}.jar" manifest="META-INF/MANIFEST.MF" />
|
||||
<jar basedir="${basedir}/target/classes" destfile="${basedir}/target/${ant.project.name}.jar" manifest="META-INF/MANIFEST.MF"/>
|
||||
</target>
|
||||
|
||||
</project>
|
||||
|
|
|
|||
|
|
@ -15,25 +15,25 @@
|
|||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
under the License.
|
||||
-->
|
||||
<ivy-module version="2.2" xmlns:o="http://ant.apache.org/ivy/osgi">
|
||||
<info organisation="bundle" module="myplugin">
|
||||
<extends organisation="bundle" module="com.acme.myplugin" revision="1.0.0.qualifier" location="META-INF/MANIFEST.MF" />
|
||||
<extends organisation="bundle" module="com.acme.myplugin" revision="1.0.0.qualifier" location="META-INF/MANIFEST.MF"/>
|
||||
</info>
|
||||
<configurations>
|
||||
<conf name="compile" extends="default,embedded" description="Dependencies for the compilation" />
|
||||
<conf name="embedded" description="Dependencies embedded into the plugin's jar" />
|
||||
<conf name="win32" extends="compile" description="To run on Microsoft Windows" />
|
||||
<conf name="macos" extends="compile" description="To run on Mac OS X" />
|
||||
<conf name="linux" extends="compile" description="To run on Linux" />
|
||||
<conf name="compile" extends="default,embedded" description="Dependencies for the compilation"/>
|
||||
<conf name="embedded" description="Dependencies embedded into the plugin's jar"/>
|
||||
<conf name="win32" extends="compile" description="To run on Microsoft Windows"/>
|
||||
<conf name="macos" extends="compile" description="To run on Mac OS X"/>
|
||||
<conf name="linux" extends="compile" description="To run on Linux"/>
|
||||
</configurations>
|
||||
<dependencies>
|
||||
<!-- example of a dependency that we can't declare in the MANIFEST.MF because we want it to be embedded -->
|
||||
<!--dependency osgi="bundle" org="" module="org.apache.commons.httpcore" rev="4.1.0" conf="embedded->default" /-->
|
||||
<!-- Ivy-Osgi doesn't understand bundle fragment -->
|
||||
<dependency org="bundle" name="org.eclipse.swt.win32.win32.x86" rev="3.+" conf="win32->default" />
|
||||
<dependency org="bundle" name="org.eclipse.swt.cocoa.macosx.x86_64" rev="3.+" conf="macos->default" />
|
||||
<dependency org="bundle" name="org.eclipse.swt.gtk.linux.x86" rev="3.+" conf="linux->default" />
|
||||
<dependency org="bundle" name="org.eclipse.swt.win32.win32.x86" rev="3.+" conf="win32->default"/>
|
||||
<dependency org="bundle" name="org.eclipse.swt.cocoa.macosx.x86_64" rev="3.+" conf="macos->default"/>
|
||||
<dependency org="bundle" name="org.eclipse.swt.gtk.linux.x86" rev="3.+" conf="linux->default"/>
|
||||
</dependencies>
|
||||
</ivy-module>
|
||||
|
|
|
|||
|
|
@ -6,9 +6,9 @@
|
|||
# * to you under the Apache License, Version 2.0 (the
|
||||
# * "License"); you may not use this file except in compliance
|
||||
# * with the License. You may obtain a copy of the License at
|
||||
# *
|
||||
# *
|
||||
# * http://www.apache.org/licenses/LICENSE-2.0
|
||||
# *
|
||||
# *
|
||||
# * Unless required by applicable law or agreed to in writing,
|
||||
# * software distributed under the License is distributed on an
|
||||
# * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
|
|
|
|||
|
|
@ -14,23 +14,23 @@
|
|||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
under the License.
|
||||
-->
|
||||
<ivysettings>
|
||||
<!-- Load the properties where is defined the eclipse location -->
|
||||
<properties file="ivysettings.properties" />
|
||||
<properties file="ivysettings.properties"/>
|
||||
|
||||
<!-- We need to define the Ivy Osgi latest strategy as the default one -->
|
||||
<settings defaultResolver="eclipse" defaultLatestStrategy="latest-osgi" />
|
||||
<settings defaultResolver="eclipse" defaultLatestStrategy="latest-osgi"/>
|
||||
|
||||
<!-- These are usual cache setup -->
|
||||
<caches resolutionCacheDir="${ivy.settings.dir}/cache/resolution" useOrigin="true">
|
||||
<cache name="eclipse" basedir="${ivy.settings.dir}/cache/eclipse" />
|
||||
<cache name="eclipse" basedir="${ivy.settings.dir}/cache/eclipse"/>
|
||||
</caches>
|
||||
|
||||
<!-- We just need to define our Ivy OSGi resolver -->
|
||||
<resolvers>
|
||||
<obr name="eclipse" repoXmlFile="${ivy.settings.dir}/target/repo-eclipse.xml" />
|
||||
<obr name="eclipse" repoXmlFile="${ivy.settings.dir}/target/repo-eclipse.xml"/>
|
||||
</resolvers>
|
||||
|
||||
</ivysettings>
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@
|
|||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
under the License.
|
||||
-->
|
||||
<xsl:stylesheet version="1.0"
|
||||
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
|
||||
|
|
@ -35,10 +35,10 @@ xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
|
|||
<html>
|
||||
<head>
|
||||
<title><xsl:value-of select="info/@module"/> by <xsl:value-of select="info/@organisation"/> :: Ivy description</title>
|
||||
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />
|
||||
<meta http-equiv="content-language" content="en" />
|
||||
<meta name="robots" content="index,follow" />
|
||||
<link rel="stylesheet" type="text/css" href="ivy-style.css" />
|
||||
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"/>
|
||||
<meta http-equiv="content-language" content="en"/>
|
||||
<meta name="robots" content="index,follow"/>
|
||||
<link rel="stylesheet" type="text/css" href="ivy-style.css"/>
|
||||
</head>
|
||||
<body>
|
||||
<div id="logo"><a href="http://ant.apache.org/ivy/"><img src="http://ant.apache.org/ivy/images/logo.png"/></a><br/><a id="rep" href="http://www.jayasoft.fr/org/ivyrep/">Ivy Repository</a></div>
|
||||
|
|
@ -48,13 +48,13 @@ xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
|
|||
<xsl:attribute name="href">http://www.jayasoft.fr/org/ivyrep/<xsl:value-of select="info/@organisation"/>/<xsl:value-of select="info/@module"/>/</xsl:attribute>
|
||||
<xsl:value-of select="info/@module"/>
|
||||
</xsl:element>
|
||||
</span>
|
||||
by
|
||||
</span>
|
||||
by
|
||||
<span id="organisation">
|
||||
<xsl:element name="a">
|
||||
<xsl:attribute name="href">http://www.jayasoft.fr/org/ivyrep/<xsl:value-of select="info/@organisation"/>/</xsl:attribute>
|
||||
<xsl:value-of select="info/@organisation"/>
|
||||
</xsl:element>
|
||||
</xsl:element>
|
||||
</span></h1>
|
||||
<div id="revision"><span id="revision">Revision: </span><xsl:value-of select="info/@revision"/></div>
|
||||
<table class="header">
|
||||
|
|
@ -95,7 +95,7 @@ xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
|
|||
</td></tr>
|
||||
<tr><td class="title">Description</td><td class="value"><xsl:copy-of select="info/description"/></td></tr>
|
||||
</table>
|
||||
|
||||
|
||||
<xsl:if test="count($repositories) > 0">
|
||||
<div id="repositories">
|
||||
<h2>Public Repositories</h2>
|
||||
|
|
@ -128,7 +128,7 @@ xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
|
|||
</table>
|
||||
</div>
|
||||
</xsl:if>
|
||||
|
||||
|
||||
<div id="public-confs" class="conf">
|
||||
<h2>Public Configurations</h2>
|
||||
<table>
|
||||
|
|
@ -157,7 +157,7 @@ xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
|
|||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
|
||||
|
||||
<xsl:if test="count($deprecated.conf) > 0">
|
||||
<div id="deprecated-confs" class="conf">
|
||||
<h2>Deprecated Configurations</h2>
|
||||
|
|
@ -181,7 +181,7 @@ xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
|
|||
</table>
|
||||
</div>
|
||||
</xsl:if>
|
||||
|
||||
|
||||
<xsl:if test="count($private.conf) > 0">
|
||||
<div id="deprecated-confs" class="conf">
|
||||
<h2>Private Configurations</h2>
|
||||
|
|
@ -205,7 +205,7 @@ xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
|
|||
</table>
|
||||
</div>
|
||||
</xsl:if>
|
||||
|
||||
|
||||
<div id="artifacts">
|
||||
<h2>Published Artifacts</h2>
|
||||
<table>
|
||||
|
|
@ -224,13 +224,13 @@ xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
|
|||
<td>
|
||||
<xsl:value-of select="@conf"/>
|
||||
<xsl:for-each select="conf">
|
||||
<xsl:if test="position() > 1">,
|
||||
<xsl:if test="position() > 1">,
|
||||
</xsl:if>
|
||||
<xsl:value-of select="@name"/>
|
||||
</xsl:for-each>
|
||||
<xsl:if test="not(@conf) and count(conf) = 0">
|
||||
<i>all</i>
|
||||
</xsl:if>
|
||||
</xsl:if>
|
||||
</td>
|
||||
</tr>
|
||||
</xsl:for-each>
|
||||
|
|
@ -242,7 +242,7 @@ xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
|
|||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
|
||||
|
||||
<xsl:if test="count($dependencies) > 0">
|
||||
<div id="dependencies">
|
||||
<h2>Dependencies</h2>
|
||||
|
|
@ -273,8 +273,8 @@ xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
|
|||
</table>
|
||||
</div>
|
||||
</xsl:if>
|
||||
|
||||
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
</xsl:template>
|
||||
|
|
|
|||
|
|
@ -18,13 +18,13 @@
|
|||
|
||||
body {
|
||||
font-family:"Trebuchet MS",Verdana,Geneva,Arial,Helvetica,sans-serif;
|
||||
font-size:small;
|
||||
font-size:small;
|
||||
}
|
||||
|
||||
div#logo {
|
||||
float: right;
|
||||
padding-left: 10px;
|
||||
padding-bottom: 10px;
|
||||
float: right;
|
||||
padding-left: 10px;
|
||||
padding-bottom: 10px;
|
||||
background: white;
|
||||
text-align: center;
|
||||
}
|
||||
|
|
@ -36,13 +36,13 @@ div#logo {
|
|||
div#date {
|
||||
font-style: italic;
|
||||
padding-left: 60px;
|
||||
padding-bottom: 40px;
|
||||
padding-bottom: 40px;
|
||||
}
|
||||
|
||||
|
||||
h1 {
|
||||
margin-bottom:2px;
|
||||
|
||||
|
||||
border-color:#7A9437;
|
||||
border-style:solid;
|
||||
border-width:0 0 3px 0;
|
||||
|
|
@ -64,13 +64,13 @@ span#organisation {
|
|||
margin: 12px 0px 0px 0px;
|
||||
padding: 0px;
|
||||
z-index: 1;
|
||||
padding-left: 10px
|
||||
padding-left: 10px
|
||||
}
|
||||
|
||||
#confmenu li {
|
||||
display: inline;
|
||||
overflow: hidden;
|
||||
list-style-type: none;
|
||||
list-style-type: none;
|
||||
}
|
||||
|
||||
#confmenu a, a.active {
|
||||
|
|
@ -79,7 +79,7 @@ span#organisation {
|
|||
font: bold 1em "Trebuchet MS", Arial, sans-serif;
|
||||
border: 2px solid black;
|
||||
padding: 2px 5px 0px 5px;
|
||||
text-decoration: none;
|
||||
text-decoration: none;
|
||||
}
|
||||
|
||||
/*
|
||||
|
|
@ -95,20 +95,20 @@ background: #DEE4CD
|
|||
|
||||
#confmenu a:hover {
|
||||
color: #fff;
|
||||
background: #ADC09F;
|
||||
background: #ADC09F;
|
||||
}
|
||||
|
||||
#confmenu a:visited {
|
||||
color: #DEDECF;
|
||||
color: #DEDECF;
|
||||
}
|
||||
|
||||
#confmenu a.active:visited {
|
||||
color: #7A9437;
|
||||
color: #7A9437;
|
||||
}
|
||||
|
||||
#confmenu a.active:hover {
|
||||
background: #DEE4CD;
|
||||
color: #DEDECF;
|
||||
color: #DEDECF;
|
||||
}
|
||||
|
||||
#content {
|
||||
|
|
@ -116,23 +116,23 @@ background: #DEE4CD
|
|||
padding: 20px;
|
||||
border: 2px solid black;
|
||||
border-top: none;
|
||||
z-index: 2;
|
||||
z-index: 2;
|
||||
}
|
||||
|
||||
#content a {
|
||||
text-decoration: none;
|
||||
color: #E8E9BE;
|
||||
color: #E8E9BE;
|
||||
}
|
||||
|
||||
#content a:hover {
|
||||
background: #898B5E;
|
||||
#content a:hover {
|
||||
background: #898B5E;
|
||||
}
|
||||
|
||||
|
||||
h2 {
|
||||
margin-bottom:2px;
|
||||
font-size:medium;
|
||||
|
||||
|
||||
border-color:#7A9437;
|
||||
border-style:solid;
|
||||
border-width:0 0 2px 0;
|
||||
|
|
@ -151,7 +151,7 @@ h4 {
|
|||
margin-bottom:2px;
|
||||
margin-top:2px;
|
||||
font-size:medium;
|
||||
|
||||
|
||||
border-color:#7A9437;
|
||||
border-style:dashed;
|
||||
border-width:0 0 1px 0;
|
||||
|
|
@ -276,4 +276,3 @@ td.title:first-letter {
|
|||
color:#7A9437;
|
||||
background-color:transparent;
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@
|
|||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
under the License.
|
||||
-->
|
||||
<ivy-module version="2.0">
|
||||
<info organisation="myorg"
|
||||
|
|
@ -24,15 +24,15 @@
|
|||
revision="myrev"
|
||||
status="integration"
|
||||
publication="20041101110000">
|
||||
|
||||
|
||||
<license name="MyLicense" url="http://www.my.org/mymodule/mylicense.html"/>
|
||||
|
||||
|
||||
<ivyauthor name="jayasoft" url="http://www.jayasoft.org/"/>
|
||||
<ivyauthor name="myorg" url="http://www.myorg.org/"/>
|
||||
|
||||
<repository name="ivyrep" url="http://www.jayasoft.fr/org/ivyrep/" pattern="[organisation]/[module]/ivy-[revision].xml" ivys="true" artifacts="false"/>
|
||||
|
||||
<description homepage="http://www.my.org/mymodule/">
|
||||
<description homepage="http://www.my.org/mymodule/">
|
||||
This module is <b>great</b> !<br/>
|
||||
You can use it especially with myconf1 and myconf2, and myconf4 is not too bad too.
|
||||
</description>
|
||||
|
|
@ -41,7 +41,7 @@
|
|||
<conf name="myconf1" description="desc 1"/>
|
||||
<conf name="myconf2" description="desc 2" visibility="public"/>
|
||||
<conf name="myconf3" description="desc 3" visibility="private"/>
|
||||
<conf name="myconf4" description="desc 4" extends="myconf1, myconf2"/>
|
||||
<conf name="myconf4" description="desc 4" extends="myconf1, myconf2"/>
|
||||
<conf name="myoldconf" description="my old desc" deprecated="20050115"/>
|
||||
</configurations>
|
||||
<publications>
|
||||
|
|
@ -79,7 +79,7 @@
|
|||
<dependency org="yourorg" name="yourmodule8" rev="8.1">
|
||||
<artifact name="yourartifact8-1" type="jar"/>
|
||||
<artifact name="yourartifact8-2" type="jar"/>
|
||||
</dependency>
|
||||
</dependency>
|
||||
|
||||
<dependency org="yourorg" name="yourmodule9" rev="9.1" conf="myconf1,myconf2,myconf3->default">
|
||||
<artifact name="yourartifact9-1" type="jar" conf="myconf1,myconf2"/>
|
||||
|
|
@ -87,14 +87,14 @@
|
|||
<conf name="myconf2"/>
|
||||
<conf name="myconf3"/>
|
||||
</artifact>
|
||||
</dependency>
|
||||
</dependency>
|
||||
|
||||
<dependency org="yourorg" name="yourmodule10" rev="10.1">
|
||||
<include name="your.*" type="jar"/>
|
||||
<include ext="xml"/>
|
||||
<exclude name="toexclude"/>
|
||||
</dependency>
|
||||
|
||||
|
||||
<conflict org="yourorg" module=".*" manager="all"/>
|
||||
<conflict org="theirorg" module="theirmodule1" rev="1.0, 1.1"/>
|
||||
</dependencies>
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@
|
|||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
under the License.
|
||||
-->
|
||||
<ivy-module version="2.0">
|
||||
<info organisation="myorg"
|
||||
|
|
@ -23,15 +23,15 @@
|
|||
revision="myrev"
|
||||
status="integration"
|
||||
publication="20041101110000">
|
||||
|
||||
|
||||
<license name="MyLicense" url="http://www.my.org/mymodule/mylicense.html"/>
|
||||
|
||||
|
||||
<ivyauthor name="jayasoft" url="http://www.jayasoft.org/"/>
|
||||
<ivyauthor name="myorg" url="http://www.myorg.org/"/>
|
||||
|
||||
<repository name="ivyrep" url="http://www.jayasoft.fr/org/ivyrep/" pattern="[organisation]/[module]/ivy-[revision].xml" ivys="true" artifacts="false"/>
|
||||
|
||||
<description homepage="http://www.my.org/mymodule/">
|
||||
<description homepage="http://www.my.org/mymodule/">
|
||||
This module is <b>great</b> !<br/>
|
||||
You can use it especially with myconf1 and myconf2, and myconf4 is not too bad too.
|
||||
</description>
|
||||
|
|
@ -40,7 +40,7 @@
|
|||
<conf name="myconf1" description="desc 1"/>
|
||||
<conf name="myconf2" description="desc 2" visibility="public"/>
|
||||
<conf name="myconf3" description="desc 3" visibility="private"/>
|
||||
<conf name="myconf4" description="desc 4" extends="myconf1, myconf2"/>
|
||||
<conf name="myconf4" description="desc 4" extends="myconf1, myconf2"/>
|
||||
<conf name="myoldconf" description="my old desc" deprecated="20050115"/>
|
||||
</configurations>
|
||||
<publications>
|
||||
|
|
@ -78,7 +78,7 @@
|
|||
<dependency org="yourorg" name="yourmodule8" rev="8.1">
|
||||
<artifact name="yourartifact8-1" type="jar"/>
|
||||
<artifact name="yourartifact8-2" type="jar"/>
|
||||
</dependency>
|
||||
</dependency>
|
||||
|
||||
<dependency org="yourorg" name="yourmodule9" rev="9.1" conf="myconf1,myconf2,myconf3->default">
|
||||
<artifact name="yourartifact9-1" type="jar" conf="myconf1,myconf2"/>
|
||||
|
|
@ -86,14 +86,14 @@
|
|||
<conf name="myconf2"/>
|
||||
<conf name="myconf3"/>
|
||||
</artifact>
|
||||
</dependency>
|
||||
</dependency>
|
||||
|
||||
<dependency org="yourorg" name="yourmodule10" rev="10.1">
|
||||
<include name="your.*" type="jar"/>
|
||||
<include ext="xml"/>
|
||||
<exclude name="toexclude"/>
|
||||
</dependency>
|
||||
|
||||
</dependency>
|
||||
|
||||
<conflict org="yourorg" module=".*" manager="all"/>
|
||||
<conflict org="theirorg" module="theirmodule1" rev="1.0, 1.1"/>
|
||||
</dependencies>
|
||||
|
|
|
|||
|
|
@ -18,13 +18,13 @@
|
|||
|
||||
body {
|
||||
font-family:"Trebuchet MS",Verdana,Geneva,Arial,Helvetica,sans-serif;
|
||||
font-size:small;
|
||||
font-size:small;
|
||||
}
|
||||
|
||||
div#logo {
|
||||
float: right;
|
||||
padding-left: 10px;
|
||||
padding-bottom: 10px;
|
||||
float: right;
|
||||
padding-left: 10px;
|
||||
padding-bottom: 10px;
|
||||
background: white;
|
||||
text-align: center;
|
||||
}
|
||||
|
|
@ -46,7 +46,7 @@ a#rep:hover {
|
|||
|
||||
h1 {
|
||||
margin-bottom:2px;
|
||||
|
||||
|
||||
border-color:#7A9437;
|
||||
border-style:solid;
|
||||
border-width:0 0 3px 0;
|
||||
|
|
@ -76,7 +76,7 @@ span#organisation a:hover {
|
|||
h2 {
|
||||
margin-bottom:2px;
|
||||
font-size:medium;
|
||||
|
||||
|
||||
border-color:#7A9437;
|
||||
border-style:solid;
|
||||
border-width:0 0 2px 0;
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@
|
|||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
under the License.
|
||||
-->
|
||||
<ivysettings>
|
||||
<settings defaultResolver="ivyrep"/>
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@
|
|||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
under the License.
|
||||
-->
|
||||
<html>
|
||||
|
||||
|
|
@ -32,12 +32,12 @@
|
|||
<a href="http://ant.apache.org/ivy/"><img src="../images/logo.png"></a>
|
||||
</div>
|
||||
<h1>
|
||||
<a name="jayasoft-ivyrep-example"></a><span id="module">ivyrep-example</span>
|
||||
by
|
||||
<a name="jayasoft-ivyrep-example"></a><span id="module">ivyrep-example</span>
|
||||
by
|
||||
<span id="organisation">jayasoft</span>
|
||||
</h1>
|
||||
<div id="date">
|
||||
resolved on
|
||||
resolved on
|
||||
2005-04-08 13:33:40</div>
|
||||
<ul id="confmenu">
|
||||
<li>
|
||||
|
|
@ -51,14 +51,14 @@
|
|||
<td class="title">Modules</td><td class="value">3</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="title">Revisions</td><td class="value">4
|
||||
<td class="title">Revisions</td><td class="value">4
|
||||
(0 searched <img title="module revisions which required a search with a dependency resolver to be resolved" alt="searched" src="../images/searched.gif">,
|
||||
0 downloaded <img title="module revisions for which ivy file was downloaded by dependency resolver" alt="downloaded" src="../images/downloaded.gif">,
|
||||
1 evicted <img title="module revisions which were evicted by others" alt="evicted" src="../images/evicted.gif">,
|
||||
0 errors <img title="module revisions on which error occurred" alt="error" src="../images/error.gif">)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="title">Artifacts</td><td class="value">3
|
||||
<td class="title">Artifacts</td><td class="value">3
|
||||
(0 downloaded,
|
||||
0 failed)</td>
|
||||
</tr>
|
||||
|
|
@ -281,7 +281,7 @@
|
|||
0 kB in cache)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="title">Evicted by</td><td class="value">2.0
|
||||
<td class="title">Evicted by</td><td class="value">2.0
|
||||
in <b>latest-revision</b> conflict manager
|
||||
</td>
|
||||
</tr>
|
||||
|
|
|
|||
|
|
@ -14,70 +14,70 @@
|
|||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
under the License.
|
||||
-->
|
||||
<project name="standard-osgi" xmlns:ivy="ivy" xmlns:bnd="bnd">
|
||||
|
||||
<!-- Load Ivy ant tasks -->
|
||||
<taskdef uri="ivy" resource="org/apache/ivy/ant/antlib.xml" />
|
||||
<!-- If Ivy is not in Ant's classpath, get the jar of Ivy and use the folowing -->
|
||||
<taskdef uri="ivy" resource="org/apache/ivy/ant/antlib.xml"/>
|
||||
<!-- If Ivy is not in Ant's classpath, get the jar of Ivy and use the following -->
|
||||
<!-- taskdef rather than the above one -->
|
||||
<!--path id="ivy.classpath">
|
||||
<!--path id="ivy.classpath">
|
||||
<fileset dir="${basedir}">
|
||||
<include name="ivy.jar" />
|
||||
<include name="ivy.jar"/>
|
||||
</fileset>
|
||||
</path>
|
||||
<taskdef uri="ivy" resource="org/apache/ivy/ant/antlib.xml" classpathref="ivy.classpath" /-->
|
||||
|
||||
<!-- Load Bnd ant tasks -->
|
||||
<taskdef uri="bnd" resource="org/apache/ivy/ant/antlib.xml" />
|
||||
<!-- If Bnd is not in Ant's classpath, get the jar of Bnd and use the folowing -->
|
||||
<taskdef uri="bnd" resource="org/apache/ivy/ant/antlib.xml"/>
|
||||
<!-- If Bnd is not in Ant's classpath, get the jar of Bnd and use the following -->
|
||||
<!-- taskdef rather than the above one -->
|
||||
<!--path id="bnd.classpath">
|
||||
<!--path id="bnd.classpath">
|
||||
<fileset dir="${basedir}">
|
||||
<include name="bnd.jar" />
|
||||
<include name="bnd.jar"/>
|
||||
</fileset>
|
||||
</path>
|
||||
<taskdef uri="bnd" resource="aQute/bnd/ant/taskdef.properties" classpathref="bnd.classpath" /-->
|
||||
|
||||
<target name="clean" description="Clean the build directory">
|
||||
<delete dir="${basedir}/target" />
|
||||
<delete dir="${basedir}/target"/>
|
||||
</target>
|
||||
|
||||
<target name="ivy:configure">
|
||||
<!-- classical ivy configuration -->
|
||||
<ivy:configure file="${basedir}/ivysettings.xml" />
|
||||
<ivy:configure file="${basedir}/ivysettings.xml"/>
|
||||
</target>
|
||||
|
||||
<target name="ivy:resolve" depends="ivy:configure">
|
||||
<ivy:resolve file="ivy.xml" conf="*" />
|
||||
<ivy:cachepath pathid="compile.classpath" conf="default" useOrigin="true" />
|
||||
<ivy:resolve file="ivy.xml" conf="*"/>
|
||||
<ivy:cachepath pathid="compile.classpath" conf="default" useOrigin="true"/>
|
||||
</target>
|
||||
|
||||
<target name="compile" depends="ivy:resolve" description="Compile the OSGi bundle">
|
||||
<mkdir dir="${basedir}/target/classes" />
|
||||
<mkdir dir="${basedir}/target/classes"/>
|
||||
<!-- simple javac (WARNING: contrary to the JDT, javac doesn't understand OSGi's accessibility (private packages)) -->
|
||||
<javac srcdir="${basedir}/src" classpathref="compile.classpath" destdir="${basedir}/target/classes" debug="true" includeAntRuntime="false" />
|
||||
<javac srcdir="${basedir}/src" classpathref="compile.classpath" destdir="${basedir}/target/classes" debug="true" includeAntRuntime="false"/>
|
||||
<copy todir="${basedir}/target/classes">
|
||||
<fileset dir="${basedir}/src">
|
||||
<include name="**" />
|
||||
<exclude name="**/*.java" />
|
||||
<exclude name="**/package.html" />
|
||||
<include name="**"/>
|
||||
<exclude name="**/*.java"/>
|
||||
<exclude name="**/package.html"/>
|
||||
</fileset>
|
||||
<fileset dir="${basedir}">
|
||||
<include name="plugin.xml" />
|
||||
<include name="plugin.xml"/>
|
||||
</fileset>
|
||||
</copy>
|
||||
</target>
|
||||
|
||||
<target name="generate-manifest" depends="ivy:resolve">
|
||||
<mkdir dir="META-INF" />
|
||||
<bnd:bnd classpath="${toString:compile.classpath}" sourcepath="${basedir}/src" eclipse="false" files="org.apache.ivy.sample.standard-osgi.bnd" />
|
||||
<mkdir dir="META-INF"/>
|
||||
<bnd:bnd classpath="${toString:compile.classpath}" sourcepath="${basedir}/src" eclipse="false" files="org.apache.ivy.sample.standard-osgi.bnd"/>
|
||||
</target>
|
||||
|
||||
<target name="build" depends="compile,generate-manifest" description="Build the OSGi app">
|
||||
<!-- simple jaring -->
|
||||
<jar basedir="${basedir}/target/classes" destfile="${basedir}/target/${ant.project.name}.jar" manifest="META-INF/MANIFEST.MF" />
|
||||
<jar basedir="${basedir}/target/classes" destfile="${basedir}/target/${ant.project.name}.jar" manifest="META-INF/MANIFEST.MF"/>
|
||||
</target>
|
||||
|
||||
</project>
|
||||
|
|
|
|||
|
|
@ -14,11 +14,11 @@
|
|||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
under the License.
|
||||
-->
|
||||
<ivy-module version="2.0">
|
||||
<info organisation="com.acme" module="local-osgi-repo" />
|
||||
<info organisation="com.acme" module="local-osgi-repo"/>
|
||||
<dependencies>
|
||||
<dependency org="javax.servlet" name="com.springsource.javax.servlet" rev="2.4.0" />
|
||||
<dependency org="javax.servlet" name="com.springsource.javax.servlet" rev="2.4.0"/>
|
||||
</dependencies>
|
||||
</ivy-module>
|
||||
</ivy-module>
|
||||
|
|
|
|||
|
|
@ -14,21 +14,21 @@
|
|||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
under the License.
|
||||
-->
|
||||
<ivysettings>
|
||||
|
||||
<!-- We need to define the Ivy Osgi latest strategy as the default one -->
|
||||
<settings defaultResolver="osgi-bundles" defaultLatestStrategy="latest-osgi" />
|
||||
<settings defaultResolver="osgi-bundles" defaultLatestStrategy="latest-osgi"/>
|
||||
|
||||
<!-- These are usual cache setup -->
|
||||
<caches resolutionCacheDir="${ivy.settings.dir}/cache/resolution" useOrigin="true">
|
||||
<cache name="osgi-bundles" basedir="${ivy.settings.dir}/cache/osgi-bundles" />
|
||||
<cache name="osgi-bundles" basedir="${ivy.settings.dir}/cache/osgi-bundles"/>
|
||||
</caches>
|
||||
|
||||
<!-- We just need to define our Ivy Osgi resolver -->
|
||||
<resolvers>
|
||||
<obr name="osgi-bundles" repoXmlFile="${ivy.settings.dir}/../repo/repo.xml" />
|
||||
<obr name="osgi-bundles" repoXmlFile="${ivy.settings.dir}/../repo/repo.xml"/>
|
||||
</resolvers>
|
||||
|
||||
</ivysettings>
|
||||
|
|
|
|||
|
|
@ -1,18 +1,18 @@
|
|||
# ***************************************************************
|
||||
# * Licensed to the Apache Software Foundation (ASF) under one
|
||||
# * or more contributor license agreements. See the NOTICE file
|
||||
# * distributed with this work for additional information
|
||||
# * regarding copyright ownership. The ASF licenses this file
|
||||
# * to you under the Apache License, Version 2.0 (the
|
||||
# * "License"); you may not use this file except in compliance
|
||||
# * with the License. You may obtain a copy of the License at
|
||||
# *
|
||||
# * http://www.apache.org/licenses/LICENSE-2.0
|
||||
# *
|
||||
# * Unless required by applicable law or agreed to in writing,
|
||||
# * software distributed under the License is distributed on an
|
||||
# * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
# * KIND, either express or implied. See the License for the
|
||||
# * specific language governing permissions and limitations
|
||||
# * under the License.
|
||||
# ***************************************************************
|
||||
# ***************************************************************
|
||||
# * Licensed to the Apache Software Foundation (ASF) under one
|
||||
# * or more contributor license agreements. See the NOTICE file
|
||||
# * distributed with this work for additional information
|
||||
# * regarding copyright ownership. The ASF licenses this file
|
||||
# * to you under the Apache License, Version 2.0 (the
|
||||
# * "License"); you may not use this file except in compliance
|
||||
# * with the License. You may obtain a copy of the License at
|
||||
# *
|
||||
# * http://www.apache.org/licenses/LICENSE-2.0
|
||||
# *
|
||||
# * Unless required by applicable law or agreed to in writing,
|
||||
# * software distributed under the License is distributed on an
|
||||
# * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
# * KIND, either express or implied. See the License for the
|
||||
# * specific language governing permissions and limitations
|
||||
# * under the License.
|
||||
# ***************************************************************
|
||||
|
|
|
|||
|
|
@ -14,43 +14,43 @@
|
|||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
under the License.
|
||||
-->
|
||||
<project name="target-platform" xmlns:ivy="ivy">
|
||||
|
||||
<!-- Load Ivy ant tasks -->
|
||||
<taskdef uri="ivy" resource="org/apache/ivy/ant/antlib.xml" />
|
||||
<!-- If Ivy is not in Ant's classpath, get the jar of Ivy and use the folowing -->
|
||||
<taskdef uri="ivy" resource="org/apache/ivy/ant/antlib.xml"/>
|
||||
<!-- If Ivy is not in Ant's classpath, get the jar of Ivy and use the following -->
|
||||
<!-- taskdef rather than the above one -->
|
||||
<!--path id="ivy.classpath">
|
||||
<!--path id="ivy.classpath">
|
||||
<fileset dir="${basedir}">
|
||||
<include name="ivy.jar" />
|
||||
<include name="ivy.jar"/>
|
||||
</fileset>
|
||||
</path>
|
||||
<taskdef uri="ivy" resource="org/apache/ivy/ant/antlib.xml" classpathref="ivy.classpath" /-->
|
||||
|
||||
<target name="update-dependencies" description="Update the dependencies">
|
||||
<ivy:configure file="${basedir}/ivysettings.xml" />
|
||||
<ivy:resolve file="ivy.xml" conf="*" />
|
||||
<ivy:fixdeps tofile="ivy-fixed.xml" />
|
||||
<ivy:configure file="${basedir}/ivysettings.xml"/>
|
||||
<ivy:resolve file="ivy.xml" conf="*"/>
|
||||
<ivy:fixdeps tofile="ivy-fixed.xml"/>
|
||||
</target>
|
||||
|
||||
<!--
|
||||
Two choices: either the jars stas in the cache, or they are retrive in a dedicated folder
|
||||
Having the bundle retrieved in a folder is helpfull to manage target platforms with the PDE of Eclipse
|
||||
Two choices: either the jars stays in the cache, or they are retrieved in a dedicated folder
|
||||
Having the bundle retrieved in a folder is helpful to manage target platforms with PDE
|
||||
-->
|
||||
|
||||
<target name="generate-target-platform" description="Generate the obr.xml of the target platform">
|
||||
<ivy:configure file="${basedir}/ivysettings.xml" />
|
||||
<ivy:resolve file="ivy-fixed.xml" conf="*" />
|
||||
<ivy:buildobr out="obr.xml" />
|
||||
<ivy:configure file="${basedir}/ivysettings.xml"/>
|
||||
<ivy:resolve file="ivy-fixed.xml" conf="*"/>
|
||||
<ivy:buildobr out="obr.xml"/>
|
||||
</target>
|
||||
|
||||
<target name="generate-retrieved-target-platform" description="Generate the obr.xml of the retrieved target platform">
|
||||
<ivy:configure file="${basedir}/ivysettings.xml" />
|
||||
<ivy:resolve file="ivy-fixed.xml" conf="*" />
|
||||
<ivy:retrieve pattern="${basedir}/bundles/[type]s/[artifact]_[revision].[ext]" />
|
||||
<ivy:buildobr basedir="${basedir}/bundles" out="obr.xml" />
|
||||
<ivy:configure file="${basedir}/ivysettings.xml"/>
|
||||
<ivy:resolve file="ivy-fixed.xml" conf="*"/>
|
||||
<ivy:retrieve pattern="${basedir}/bundles/[type]s/[artifact]_[revision].[ext]"/>
|
||||
<ivy:buildobr basedir="${basedir}/bundles" out="obr.xml"/>
|
||||
</target>
|
||||
|
||||
</project>
|
||||
|
|
|
|||
|
|
@ -14,11 +14,11 @@
|
|||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
under the License.
|
||||
-->
|
||||
<ivy-module version="2.0">
|
||||
<info organisation="com.acme" module="target-platform" />
|
||||
<info organisation="com.acme" module="target-platform"/>
|
||||
<dependencies>
|
||||
<dependency org="bundle" name="org.eclipse.jdt.core" rev="3.8.3.v20130121-145325" />
|
||||
<dependency org="bundle" name="org.eclipse.jdt.core" rev="3.8.3.v20130121-145325"/>
|
||||
</dependencies>
|
||||
</ivy-module>
|
||||
</ivy-module>
|
||||
|
|
|
|||
|
|
@ -14,20 +14,20 @@
|
|||
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
KIND, either express or implied. See the License for the
|
||||
specific language governing permissions and limitations
|
||||
under the License.
|
||||
under the License.
|
||||
-->
|
||||
<ivysettings>
|
||||
|
||||
<settings defaultResolver="eclipse-juno" defaultLatestStrategy="latest-osgi" />
|
||||
<settings defaultResolver="eclipse-juno" defaultLatestStrategy="latest-osgi"/>
|
||||
|
||||
<!-- These are usual cache setup -->
|
||||
<caches resolutionCacheDir="${ivy.settings.dir}/cache/resolution" useOrigin="true">
|
||||
<cache name="eclipse-juno" basedir="${ivy.settings.dir}/cache/eclipse-juno" />
|
||||
<cache name="eclipse-juno" basedir="${ivy.settings.dir}/cache/eclipse-juno"/>
|
||||
</caches>
|
||||
|
||||
<!-- The resolvers from which we will find our bundles -->
|
||||
<resolvers>
|
||||
<updatesite name="eclipse-juno" url="http://download.eclipse.org/releases/juno" cache="eclipse-juno" requirementStrategy="first" />
|
||||
<updatesite name="eclipse-juno" url="http://download.eclipse.org/releases/juno" cache="eclipse-juno" requirementStrategy="first"/>
|
||||
</resolvers>
|
||||
|
||||
</ivysettings>
|
||||
|
|
|
|||
|
|
@ -29,18 +29,18 @@ Here is an example of the settings file:
|
|||
----
|
||||
|
||||
<ivysettings>
|
||||
<properties file="${ivy.settings.dir}/ivysettings-file.properties" />
|
||||
<settings defaultResolver="ibiblio" />
|
||||
<caches defaultCacheDir="${cache.dir}" checkUpToDate="false" />
|
||||
<properties file="${ivy.settings.dir}/ivysettings-file.properties"/>
|
||||
<settings defaultResolver="ibiblio"/>
|
||||
<caches defaultCacheDir="${cache.dir}" checkUpToDate="false"/>
|
||||
<resolvers>
|
||||
<ibiblio name="ibiblio" />
|
||||
<ibiblio name="ibiblio"/>
|
||||
<filesystem name="internal">
|
||||
<ivy pattern="${repository.dir}/[module]/ivy-[revision].xml" />
|
||||
<artifact pattern="${repository.dir}/[module]/[artifact]-[revision].[ext]" />
|
||||
<ivy pattern="${repository.dir}/[module]/ivy-[revision].xml"/>
|
||||
<artifact pattern="${repository.dir}/[module]/[artifact]-[revision].[ext]"/>
|
||||
</filesystem>
|
||||
</resolvers>
|
||||
<modules>
|
||||
<module organisation="jayasoft" name=".*" resolver="internal" />
|
||||
<module organisation="jayasoft" name=".*" resolver="internal"/>
|
||||
</modules>
|
||||
</ivysettings>
|
||||
|
||||
|
|
|
|||
|
|
@ -75,9 +75,9 @@ cache to another place in your filesystem). Usually it is a good thing to check
|
|||
----
|
||||
|
||||
<caches>
|
||||
<cache name="mycache" basedir="path/to/my/cache/1" />
|
||||
<cache name="mycache2" basedir="path/to/my/cache/2" />
|
||||
</caches>
|
||||
<cache name="mycache" basedir="path/to/my/cache/1"/>
|
||||
<cache name="mycache2" basedir="path/to/my/cache/2"/>
|
||||
</caches>
|
||||
|
||||
----
|
||||
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ By default also, the parsed module descriptor read from the cache are kept in a
|
|||
|basedir|the path of the base directory to use to put repository cache data. *This should not point to a directory used as a repository!*|No, defaults to repositoryCacheDir defined in link:../../settings/caches.html[caches]
|
||||
|ivyPattern|the pattern to use to store cached ivy files|No, defaults to default cache ivy pattern as configured in link:../../settings/caches.html[caches]
|
||||
|artifactPattern|the pattern to use to store cached artifacts|No, defaults to default cache artifact pattern as configured in link:../../settings/caches.html[caches]
|
||||
|useOrigin|true to avoid the copy of local artifacts to the cache and use directly their original location, false otherwise.
|
||||
|useOrigin|true to avoid the copy of local artifacts to the cache and use directly their original location, false otherwise.
|
||||
To know if an artifact is local ivy asks to the resolver. Only filesystem resolver is considered local by default, but this can be disabled if you want to force the copy on one filesystem resolver and use the original location on another. Note that it is safe to use useOrigin even if you use the cache for some non local resolvers. In this case the cache will behave as usual, copying files to the cache. Note also that this only applies to artifacts, not to ivy files, which are still copied in the cache.|No. defaults to the default value configured in link:../../settings/caches.html[caches]
|
||||
|lockStrategy|the name of the link:../../settings/lock-strategies.html[lock strategy] to use for this cache|No, defaults to default lock strategy as configured in link:../../settings/caches.html[caches]
|
||||
|defaultTTL|the default link:../../settings/caches/ttl.html[TTL] to use when no specific one is defined|No, defaults to ${ivy.cache.ttl.default}
|
||||
|
|
@ -66,19 +66,18 @@ To know if an artifact is local ivy asks to the resolver. Only filesystem resolv
|
|||
[source, xml]
|
||||
----
|
||||
|
||||
<cache name="mycache"
|
||||
<cache name="mycache"
|
||||
basedir="/path/to/mycache"
|
||||
ivyPattern="[module]/ivy-[revision].xml"
|
||||
ivyPattern="[module]/ivy-[revision].xml"
|
||||
artifactPattern="[module]/[artifact]-[revision].[ext]"
|
||||
lockStrategy="no-lock"
|
||||
defaultTTL="1s">
|
||||
<ttl revision="latest.integration" duration="200ms" />
|
||||
<ttl organisation="org1" duration="10m 20s" />
|
||||
<ttl organisation="org2" duration="5h" />
|
||||
<ttl organisation="org3" duration="2d 12h" />
|
||||
<ttl revision="latest.integration" duration="200ms"/>
|
||||
<ttl organisation="org1" duration="10m 20s"/>
|
||||
<ttl organisation="org2" duration="5h"/>
|
||||
<ttl organisation="org3" duration="2d 12h"/>
|
||||
</cache>
|
||||
|
||||
----
|
||||
|
||||
Defines a cache called `mycache`, storing files in the `/path/to/mycache` directory using `[module]/ivy-[revision].xml` as pattern to store Ivy files and `[module]/[artifact]-[revision].[ext]` as pattern to store other artifacts. The lock strategy used by this cache is the `no-lock` strategy, which does not perform any locking. The defaultTTL used is of 1s, meaning that by default dynamic revision result will be stored and used for one second. TTL rules then define that all `latest.integration` revisions will be stored and used for 200ms, while other dynamic revisions from `org1` `org2` and `org3` modules will be stored respectively for 10 minutes 20 seconds; 5 hours; and 2 days and 12 hours.
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@
|
|||
|
||||
*Tag:* ttl
|
||||
|
||||
*__Since 2.0__*
|
||||
*__Since 2.0__*
|
||||
|
||||
Defines a TTL (Time To Live) rule for resolved revision caching.
|
||||
|
||||
|
|
@ -42,7 +42,7 @@ XXd XXh XXm XXs XXXms
|
|||
|
||||
Where 'd' stands for days, 'h' for hours, 'm' for minutes, 's' for seconds and 'ms' for milliseconds. Any part of the specification can be omitted, so '12d', '2h 5m' and '1d 5ms' are all valid.
|
||||
|
||||
The TTL duration can also be set to `eternal`, in which case once resolved the revision is always use, except when resolving in refresh mode.
|
||||
The TTL duration can also be set to `eternal`, in which case once resolved the revision is always use, except when resolving in refresh mode.
|
||||
|
||||
Using a 0ms TTL disable resolved revision caching for the given rule.
|
||||
|
||||
|
|
@ -60,5 +60,3 @@ Using a 0ms TTL disable resolved revision caching for the given rule.
|
|||
|matcher|the link:../../concept.html#matcher[matcher] to use to match the modules to which the resolver should be applied|No, defaults to exact
|
||||
|duration|the TTL to apply (see above for format)|Yes
|
||||
|=======
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -79,4 +79,3 @@ Here is a list of conflict manager types available, which can be used to define
|
|||
|Element|Description|Cardinality
|
||||
|any conflict manager|adds a conflict manager to the list of available conflict managers|0..n
|
||||
|=======
|
||||
|
||||
|
|
|
|||
|
|
@ -35,4 +35,3 @@ Configures HTTP authentication credentials. *__since 2.0__*.
|
|||
|username|the username|Yes
|
||||
|passwd|the password|Yes
|
||||
|=======
|
||||
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@ The included ivysettings defines a resolver named default, which is an ivyrep re
|
|||
<resolvers>
|
||||
<mymacro name="includeworks" mymainrep="included/myrep" mysecondrep="included/secondrep"/>
|
||||
</resolvers>
|
||||
</ivysettings>
|
||||
</ivysettings>
|
||||
|
||||
----
|
||||
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ Here is an example of how you can do so:
|
|||
<specialMeaning name="QA" value="4"/>
|
||||
<specialMeaning name="PROD" value="5"/>
|
||||
</latest-revision>
|
||||
</latest-strategies>
|
||||
</latest-strategies>
|
||||
|
||||
----
|
||||
|
||||
|
|
@ -94,7 +94,6 @@ Example:
|
|||
<specialMeaning name="rc" value="2"/>
|
||||
<specialMeaning name="prod" value="3"/>
|
||||
</latest-revision>
|
||||
</latest-strategies>
|
||||
</latest-strategies>
|
||||
|
||||
----
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ The following strategies are registered by default:
|
|||
|
||||
* *artifact-lock* +
|
||||
This strategy acquires a lock whenever a module descriptor or an artifact is downloaded to the cache, which makes a good solution when you want to share your repository cache.
|
||||
Note that this strategy is based on file locking, performed by default using the `java.io.File.createNewFile()` atomicity (which is documented as atomic in the javadoc, but not recommended to perform locks).
|
||||
Note that this strategy is based on file locking, performed by default using the `java.io.File.createNewFile()` atomicity (which is documented as atomic in the javadoc, but not recommended to perform locks).
|
||||
|
||||
|
||||
* *artifact-lock-nio (__since 2.4__)* +
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ This task eases the process of creating a new dependency resolver, because it av
|
|||
|
||||
It is generally used in combination with the link:../settings/include.html[include] feature to help reuse a macro in multiple settings files.
|
||||
|
||||
A macro is defined by declaring an existing resolver within it. Then you can use attributes to pass parameters to the newly defined resolver type. Attributes are defined with a name, and optionally a default value, and are used using the following syntax:
|
||||
A macro is defined by declaring an existing resolver within it. Then you can use attributes to pass parameters to the newly defined resolver type. Attributes are defined with a name, and optionally a default value, and are used using the following syntax:
|
||||
|
||||
[source]
|
||||
----
|
||||
|
|
@ -57,14 +57,14 @@ Example:
|
|||
<ivysettings>
|
||||
<macrodef name="mymacro">
|
||||
<chain>
|
||||
<ibiblio name="ex1" />
|
||||
<ibiblio name="ex2.@{name}" m2compatible="true" />
|
||||
<ibiblio name="ex1"/>
|
||||
<ibiblio name="ex2.@{name}" m2compatible="true"/>
|
||||
</chain>
|
||||
</macrodef>
|
||||
|
||||
|
||||
<resolvers>
|
||||
<mymacro name="default" />
|
||||
<mymacro name="other" />
|
||||
<mymacro name="default"/>
|
||||
<mymacro name="other"/>
|
||||
</resolvers>
|
||||
</ivysettings>
|
||||
|
||||
|
|
@ -78,12 +78,12 @@ This is equivalent to:
|
|||
<ivysettings>
|
||||
<resolvers>
|
||||
<chain name="default">
|
||||
<ibiblio name="default-ex1" />
|
||||
<ibiblio name="ex2.default" m2compatible="true" />
|
||||
<ibiblio name="default-ex1"/>
|
||||
<ibiblio name="ex2.default" m2compatible="true"/>
|
||||
</chain>
|
||||
<chain name="other">
|
||||
<ibiblio name="other-ex1" />
|
||||
<ibiblio name="ex2.other" m2compatible="true" />
|
||||
<ibiblio name="other-ex1"/>
|
||||
<ibiblio name="ex2.other" m2compatible="true"/>
|
||||
</chain>
|
||||
</resolvers>
|
||||
</ivysettings>
|
||||
|
|
@ -97,7 +97,7 @@ This is equivalent to:
|
|||
[options="header",cols="15%,50%,35%"]
|
||||
|=======
|
||||
|Attribute|Description|Required
|
||||
|name|name of the resover type created|Yes
|
||||
|name|name of the resolver type created|Yes
|
||||
|=======
|
||||
|
||||
|
||||
|
|
@ -164,15 +164,14 @@ A complete example:
|
|||
</filesystem>
|
||||
</chain>
|
||||
</macrodef>
|
||||
|
||||
|
||||
<resolvers>
|
||||
<mymacro name="default" mymainrep="path/to/myrep" mysecondrep="path/to/secondrep"/>
|
||||
<mymacro name="other"
|
||||
mymainrep="path/to/myrep"
|
||||
mysecondrep="path/to/secondrep"
|
||||
<mymacro name="other"
|
||||
mymainrep="path/to/myrep"
|
||||
mysecondrep="path/to/secondrep"
|
||||
myseconddirlayout="[module]/[type]s"/>
|
||||
</resolvers>
|
||||
</ivysettings>
|
||||
|
||||
----
|
||||
|
||||
|
|
|
|||
|
|
@ -32,6 +32,3 @@ Defines a macrodef attribute. See link:../macrodef.html[macrodef] for details.
|
|||
|name|the name of the attribute|Yes
|
||||
|default|the default value of the attribute if none is specified|No, by default attribute are required
|
||||
|=======
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@
|
|||
|
||||
*Tag:* module
|
||||
|
||||
Define a module set rule. The tag defines a module set, by giving an expression and the matcher to use for organisation, name, revision and any extra attribute identifying your modules. The rule matching is performed in order, and is using a pattern matcher. Hence you can use `*` to specify all, or simply avoid specifying the attribute.
|
||||
Define a module set rule. The tag defines a module set, by giving an expression and the matcher to use for organisation, name, revision and any extra attribute identifying your modules. The rule matching is performed in order, and is using a pattern matcher. Hence you can use `*` to specify all, or simply avoid specifying the attribute.
|
||||
|
||||
The revision and extra attributes are only used for rules defining the resolver to use. For other settings, use only organisation and module name.
|
||||
|
||||
|
|
@ -107,7 +107,7 @@ Uses `myapachecommonsresolver` for all modules from `apache` beginning with `com
|
|||
----
|
||||
|
||||
<modules>
|
||||
<module organisation="apache" name="ivy*" matcher="glob" conflict-manager="latest-time"/>
|
||||
<module organisation="apache" name="ivy*" matcher="glob" conflict-manager="latest-time"/>
|
||||
</modules>
|
||||
|
||||
----
|
||||
|
|
@ -121,10 +121,9 @@ Uses `latest-time` conflict manager for all modules from `apache` whose name beg
|
|||
----
|
||||
|
||||
<modules>
|
||||
<module organisation="apache" name="ivy*" matcher="glob" branch="fix-103"/>
|
||||
<module organisation="apache" name="ivy*" matcher="glob" branch="fix-103"/>
|
||||
</modules>
|
||||
|
||||
----
|
||||
|
||||
Uses `fix-103` as default branch for all modules from `apache` whose name begins with `ivy`.
|
||||
|
||||
|
|
|
|||
|
|
@ -38,5 +38,3 @@ NOTE: You can greatly improve the performance of dependency resolution by config
|
|||
|Element|Description|Cardinality
|
||||
|link:../settings/module.html[module]|defines a module set rule|1..n
|
||||
|=======
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -126,6 +126,3 @@ There are two main possibilities for using these rules. By default, a namespace
|
|||
</namespace>
|
||||
|
||||
----
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -55,4 +55,3 @@ For details about regexp and groups, see the link:https://docs.oracle.com/javase
|
|||
----
|
||||
|
||||
Matches modules from `systemorg2` which have a name beginning with `system` followed by a `minus` and anything else, and translate it to organisation `B` and module the part following `system-` of the original name.
|
||||
|
||||
|
|
|
|||
|
|
@ -32,5 +32,3 @@ Defines a one way translation rule, i.e. a translation from system namespace to
|
|||
|link:../../settings/namespace/src.html[src]|defines a source name which can be accepted|1..n
|
||||
|link:../../settings/namespace/dest.html[dest]|defines the translation to apply when a name is accepted by an src pattern|1
|
||||
|=======
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -35,4 +35,3 @@ See the link:../../settings/namespace.html[namespace] doc for details.
|
|||
|link:../../settings/namespace/fromtosystem.html[fromsystem]|defines the translation to apply from the system namespace to the defined namespace|1
|
||||
|link:../../settings/namespace/fromtosystem.html[tosystem]|defines the translation to apply from the defined namespace to the system namespace|1
|
||||
|=======
|
||||
|
||||
|
|
|
|||
|
|
@ -33,5 +33,3 @@ Defines the acceptation part of a translation rule. If a name matches this src,
|
|||
|module|the module name to match as a regexp|No, defaults to .*
|
||||
|rev|the revision to match as a regexp|No, defaults to .*
|
||||
|=======
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -45,5 +45,3 @@ This very powerful feature is thoroughly used in the link:../tutorial/build-repo
|
|||
|Element|Description|Cardinality
|
||||
|link:../settings/namespace.html[namespace]|defines a new namespace|0..n
|
||||
|=======
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@
|
|||
|
||||
*Tag:* outputters
|
||||
|
||||
Defines a list of report outputters usable in ivy.
|
||||
Defines a list of report outputters usable in ivy.
|
||||
|
||||
A report outputter is used at the end of the resolve process to generate a report of how the resolve has been performed.
|
||||
|
||||
|
|
@ -61,4 +61,3 @@ To see how to define your own report outputter see link:../extend.html[Extending
|
|||
|Element|Description|Cardinality
|
||||
|any report outputter|adds a report outputter to the list of available ones|0..n
|
||||
|=======
|
||||
|
||||
|
|
|
|||
|
|
@ -44,5 +44,3 @@ this parser is able to parse Maven2 `pom` files
|
|||
|Element|Description|Cardinality
|
||||
|any module descriptor parser|adds a module descriptor parser to the list of available parsers|0..n
|
||||
|=======
|
||||
|
||||
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue