You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-commits@incubator.apache.org by "Matt Inger (JIRA)" <ji...@apache.org> on 2007/10/17 02:38:50 UTC

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

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


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>

    

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Posted by "Matt Inger (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/IVY-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Inger updated IVY-622:
---------------------------

    Attachment: importbuildmodule.diff

SVN diff file contains task code, configuration changes for the antlib.xml, documentation file, and changes to the documentation index.

Unit tests will follow sometime soon.

> 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
>         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
> <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>
>     

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.