[
https://issues.apache.org/jira/browse/IVY-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gintas Grigelionis updated IVY-622:
-----------------------------------
Description:
The submitted task will perform an inline ivy resolution of either an .xml
file, or a jar compressed archive (the file extension is irrelvant, as long as
the ant <expand> task can deal with it). It will then, if necessary, extract
the downloaded archive.
Finally, it will pick a specified resource (defaults to build.xml) and import
it into the current ant project.
This allows us to create reusable build modules, which can be located and
imported using ivy. This can allow an organisation to maintain a single set of
build scripts which can handle all their modules, and publish the latest
version to the ivy repository. The individual module build scripts can then
import them. A relatively simple example follows
{code:xml}
<ivy:importbuildmodule
url="http://path/to/ivysettings.xml";
organisation="myorg"
module="build"
revision="latest.integration" />
{code}
The net effect of this is to:
# Create an ivy settings with it's own reference id (so it does not affect
other ivy tasks)
# Perform an inline resolution using the ivy settings, and build a fileset
with the resolution results (in fact, this task actually extends the
IvyCacheFileset task).
# The first artifact in the resolution is then processed.
#- If it is an xml file, it is imported from the cache directory using the ant
<import> task
#- Otherwise, the entire artifact is expanded in the cache using the ant
<expand> task, and then a specific resource (which defaults to "build.xml",
but can be changed via an attribute) is imported from the extracted archive.
The main caveat is that your build module has to follow the same rules as when
you use the <import> task. Ie.
to reference a "build.properties" that is packaged with your build module:
{code:xml}
<project name="build">
<dirname property="build.basedir" file="${ant.file.build}" />
<property file="${build.basedir}/build.properties" />
</project>
{code}
was:
The submitted task will perform an inline ivy resolution of either an .xml
file, or a jar compressed archive (the file extension is irrelvant, as long as
the ant <expand> task can deal with it). It will then, if necessary, extract
the downloaded archive.
Finally, it will pick a specified resource (defaults to build.xml) and import
it into the current ant project.
This allows us to create reusable build modules, which can be located and
imported using ivy. This can allow an organisation to
maintain a single set of build scripts which can handle all their modules, and
publish the latest version to the ivy repository. The individual
module build scripts can then import them. A relatively simple example follows
<ivy:importbuildmodule
url="http://path/to/ivysettings.xml";
organisation="myorg"
module="build"
revision="latest.integration" />
The net effect of this is to:
1. Create an ivy settings with it's own reference id (so it does not affect
other ivy tasks)
2. Perform an inline resolution using the ivy settings, and build a fileset
with the resolution
results (in fact, this task actually extends the IvyCacheFileset task).
3. The first artifact in the resolution is then processed.
a. If it is an xml file, it is imported from the cache directory using
the ant <import> task
b. Otherwise, the entire artifact is expanded in the cache using the ant
<expand> task, and then a specific
resource (which defaults to "build.xml", but can be changed via an
attribute) is imported
from the extracted archive.
The main caveat is that your build module has to follow the same rules as when
you use the <import> task. Ie.
to reference a "build.properties" that is packaged with your build module:
<project name="build">
<dirname property="build.basedir" file="${ant.file.build}" />
<property file="${build.basedir}/build.properties" />
</project>
> ImportBuildModule task to allow for using ivy to resolve a jar file, and
> import a build.xml build resource.
> -----------------------------------------------------------------------------------------------------------
>
> Key: IVY-622
> URL: https://issues.apache.org/jira/browse/IVY-622
> Project: Ivy
> Issue Type: New Feature
> Components: Ant
> Affects Versions: 2.0.0-alpha-2
> Reporter: Matt Inger
> Labels: patch
> Attachments: importbuildmodule.diff
>
>
> The submitted task will perform an inline ivy resolution of either an .xml
> file, or a jar compressed archive (the file extension is irrelvant, as long
> as the ant <expand> task can deal with it). It will then, if necessary,
> extract the downloaded archive.
> Finally, it will pick a specified resource (defaults to build.xml) and import
> it into the current ant project.
> This allows us to create reusable build modules, which can be located and
> imported using ivy. This can allow an organisation to maintain a single set
> of build scripts which can handle all their modules, and publish the latest
> version to the ivy repository. The individual module build scripts can then
> import them. A relatively simple example follows
> {code:xml}
> <ivy:importbuildmodule
> url="http://path/to/ivysettings.xml";
> organisation="myorg"
> module="build"
> revision="latest.integration" />
> {code}
> The net effect of this is to:
> # Create an ivy settings with it's own reference id (so it does not affect
> other ivy tasks)
> # Perform an inline resolution using the ivy settings, and build a fileset
> with the resolution results (in fact, this task actually extends the
> IvyCacheFileset task).
> # The first artifact in the resolution is then processed.
> #- If it is an xml file, it is imported from the cache directory using the
> ant <import> task
> #- Otherwise, the entire artifact is expanded in the cache using the ant
> <expand> task, and then a specific resource (which defaults to "build.xml",
> but can be changed via an attribute) is imported from the extracted archive.
> The main caveat is that your build module has to follow the same rules as
> when you use the <import> task. Ie.
> to reference a "build.properties" that is packaged with your build module:
> {code:xml}
> <project name="build">
> <dirname property="build.basedir" file="${ant.file.build}" />
> <property file="${build.basedir}/build.properties" />
> </project>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
