[jira] [Updated] (IVY-622) ImportBuildModule task to allow for using ivy to resolve a jar file, and import a build.xml build resource.

["Gintas Grigelionis (JIRA)" <ji...@apache.org>]

     [ 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 irrelevant, 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
{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}


> 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 irrelevant, 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)