Ivy
  1. Ivy
  2. IVY-742

Support ivy.xml parent mechanism

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.2.0-RC1
    • Component/s: Core
    • Labels:
      None
    • Environment:

      Any

      Description

      Here's the email that details this feature:

      On Thu, Feb 21, 2008 at 11:22 PM, Neil Lott <neilmatthewlott@yahoo.com>
      wrote:

      Let's say I have multiple modules each with their own ivy.xml

      <ivy-module version="2.0">
      <info organisation="$

      {organization.name}

      " module="$

      {interface.jar.prefix}"/>

      <configurations>
      <conf name="interface" description="dependencies for
      interface"/>
      <include file="path/to/included-configurations.xml"/>
      </configurations>

      <publications>
      <artifact name="${interface.jar.prefix}

      " type="jar"
      conf="interface" ext="jar"/>
      </publications>

      <dependencies>
      <dependency org="twc" name="mas-core" rev="$

      {mas.version}

      "
      conf="interface->server"/>
      </dependencies>
      </ivy-module>

      and I want them all to share an inherited configuration found in a
      file: included-configurations.xml

      <configuration>
      <conf name="test"/>
      </configuration>

      <dependencies>
      <dependency name="testng" rev="5.7" conf="test"/>
      </dependencies>

      so in the inherited configurations file I'd also like to include a
      dependency that goes along with that configuration.

      Is something like this possible?

      No, this is not possible in Ivy, but you can use text or xml processing
      tools to recompose your Ivy file before asking Ivy to resolve the
      dependencies of your module.

      Alternatively, since what you ask is close to maven 2 parent mechanism, I
      think it could be a nice addition to Ivy feature set. So feel free to open
      an issue, and even provide a patch

      Xavier

      Thanks,

      Neil


      Xavier Hanin - Independent Java Consultant
      http://xhab.blogspot.com/
      http://ant.apache.org/ivy/
      http://www.xoocode.org/

      1. extendsIvyFile-ivy-r709181.patch
        11 kB
        Jean-Louis Boudart
      2. extendsIvyFile-ivy-r920176.patch
        141 kB
        Jason Trump

        Activity

        Hide
        Chi Lang added a comment -

        This look great. Any reason why <publications> is not included in the inheritance ?
        From my experience, it is as repetitive as <configurations>, e.g. most module will have standard jar, javadoc, source artifacts.

        Show
        Chi Lang added a comment - This look great. Any reason why <publications> is not included in the inheritance ? From my experience, it is as repetitive as <configurations>, e.g. most module will have standard jar, javadoc, source artifacts.
        Hide
        Maarten Coene added a comment -

        I've committed your patch. I've made 1 modification: the default of the merge attribute is "true" instead of "false".
        Please give current version from trunk a try to check if it is still working.

        Thanks a lot for the contribution!
        Maarten

        Show
        Maarten Coene added a comment - I've committed your patch. I've made 1 modification: the default of the merge attribute is "true" instead of "false". Please give current version from trunk a try to check if it is still working. Thanks a lot for the contribution! Maarten
        Hide
        Maarten Coene added a comment -

        Thanks Jason, I'll try to take a look at it in the next coming weeks.
        It would be great if we could add this before making a new Ivy release.

        Show
        Maarten Coene added a comment - Thanks Jason, I'll try to take a look at it in the next coming weeks. It would be great if we could add this before making a new Ivy release.
        Hide
        Jason Trump added a comment -

        updated patch, with bugfixes and support for merge-on-publish

        Show
        Jason Trump added a comment - updated patch, with bugfixes and support for merge-on-publish
        Hide
        Jason Trump added a comment - - edited

        Hey everybody,

        Jean-Louis and I have been working on this patch a little bit to implement the "merge-on-publish" behavior that was last discussed by Maarten and Xavier. It was a little tricky. I'll attach an updated version of the patch, which includes a number of tests.

        The merged descriptor comments out the <extends> element, and adds descriptive comments to imported elements. so a merged descriptor looks something like this:

        <ivy-module version="2.0">
        
        	<info organisation="net.foo" module="baz" revision="1.0">
        		<!-- <extends organisation="net.foo" module="bar" revision="1.0"/> -->
        		<description>Some complicated project.</description>
        	</info>
        
        	<configurations>
        		<conf name="extra" description="not defined on parent"/>
        
        		<!-- configurations inherited from net.foo#bar;1.0 -->
        		<conf name="default"/>
        		<conf name="test"/>
        	</configurations>
        	
        	<dependencies>
        		<dependency org="commons-logging" name="commons-logging" rev="1.1.1"/>
        
        		<!-- dependencies inherited from net.foo#bar;1.0 -->
        		<dependency org="junit" name="junit" rev="4.7" conf="test"/>
        	</dependencies>
        	
        </ivy-module>
        

        What do you think?

        jt

        Show
        Jason Trump added a comment - - edited Hey everybody, Jean-Louis and I have been working on this patch a little bit to implement the "merge-on-publish" behavior that was last discussed by Maarten and Xavier. It was a little tricky. I'll attach an updated version of the patch, which includes a number of tests. The merged descriptor comments out the <extends> element, and adds descriptive comments to imported elements. so a merged descriptor looks something like this: <ivy-module version= "2.0" > <info organisation= "net.foo" module= "baz" revision= "1.0" > <!-- <extends organisation= "net.foo" module= "bar" revision= "1.0" /> --> <description> Some complicated project. </description> </info> <configurations> <conf name= "extra" description= "not defined on parent" /> <!-- configurations inherited from net.foo#bar;1.0 --> <conf name= "default" /> <conf name= "test" /> </configurations> <dependencies> <dependency org= "commons-logging" name= "commons-logging" rev= "1.1.1" /> <!-- dependencies inherited from net.foo#bar;1.0 --> <dependency org= "junit" name= "junit" rev= "4.7" conf= "test" /> </dependencies> </ivy-module> What do you think? jt
        Hide
        Juha Ranta added a comment -

        By the way, has any further work been done on this issue?

        Lately, I've been working with Maven multimodules with parent poms and I'm starting to think it provides some useful features which currently can't be easily replicated with Ivy.

        First of all, let's suppose we have a multimodule Ivy project, each submodule having its own ivy.xml. One example of such a multimodule is a project consisting of an ear, wars, ejbs and jars. The submodules have common dependencies, for instance a jar project depends on dom4j.jar to compile and the ear project depends on dom4j.jar to include it inside. In this case, both the jar project and the ear project clearly have a dependency on dom4j.jar:

        jar:
        <dependency name="dom4j" org="apache" conf="compile" rev="1.4.1"/>
        ..

        ear:
        <dependency name="dom4j" org="apache" conf="runtime" rev="1.4.1"/>

        For instance, the revision of dom4j is included in several places and when you need to change the revision, you need to change it in many places.

        In Maven, you can define the revisions in parent pom's dependencyManagement block in this manner (note that this isn't Maven's syntax, I'm just trying to explain the idea):

        <dependencyManagement>
        <dependency name="dom4j" org="apache" rev="1.4.1"/>
        </dependencyManagement>

        After this the subproject can use dependencies like this, omitting the rev:

        <parent name="myparent" rev="1.0"/>

        <dependencies>
        <dependency name="dom4j" org="apache" conf="compile"/>
        </dependencies>

        If you want to change the version of dom4j, you just change the version in the parent pom.

        Another thing that the parent pom provides is that if it finds the right revision in some path ("../pom.xml" by default), it will use that instead of the published on in repository. This is really useful when developing in IDEs or otherwise, because it's often too slow, cumbersome or even impossible to go.

        1. publish parent ivy
        2. resolve submodules

        That's just my experience. I've used a submodule which defines some common dependencies in an ivy.xml but I don't find it as useful as the parent project of Maven. Thoughts?

        Oh, and third opinion about including the parent vs. resolving it from a repository: If you just include it, the submodule cannot be reliably rebuit again as a single entity. For instance, if you checkout just the submodule with a some tag or certain branch, you don't really know which revision, if any, is in "../ivy.xml" or "../parent/ivy.xml". I don't think is issue is necessarily about whether the published metadata is merged or not, it's more about how the parent ivy is found while doing a resolve.

        In Maven, if the parent pom on the directory has a revision "1.10-SNAPSHOT" and the child refers to parent "1.10-SNAPSHOT", then Maven uses the file on the directory, otherwise it searches the repository. I'm not sure how exactly it should work with Ivy's static and latest.* revisions, but in my opinion, while developing on a local workstation, you often want it to be included, but when building official builds on a CI server or doing release builds, you want it to use the published version from repository.

        Going on this issue even further, well, even in Maven it's really hard to publish the parent pom alone or to publish only a subgroup of the projects. For instance, since the parent pom resides in the root directory, if you tag it, the SCM system usually tags all the submodules in the directory tree as well, etc. With the current build tools, it seems it's very hard to make a build system which supports large multimodule projects where you sometimes want to handle the multiproject as a whole and sometimes publish only parts of it.

        Show
        Juha Ranta added a comment - By the way, has any further work been done on this issue? Lately, I've been working with Maven multimodules with parent poms and I'm starting to think it provides some useful features which currently can't be easily replicated with Ivy. First of all, let's suppose we have a multimodule Ivy project, each submodule having its own ivy.xml. One example of such a multimodule is a project consisting of an ear, wars, ejbs and jars. The submodules have common dependencies, for instance a jar project depends on dom4j.jar to compile and the ear project depends on dom4j.jar to include it inside. In this case, both the jar project and the ear project clearly have a dependency on dom4j.jar: jar: <dependency name="dom4j" org="apache" conf="compile" rev="1.4.1"/> .. ear: <dependency name="dom4j" org="apache" conf="runtime" rev="1.4.1"/> For instance, the revision of dom4j is included in several places and when you need to change the revision, you need to change it in many places. In Maven, you can define the revisions in parent pom's dependencyManagement block in this manner (note that this isn't Maven's syntax, I'm just trying to explain the idea): <dependencyManagement> <dependency name="dom4j" org="apache" rev="1.4.1"/> </dependencyManagement> After this the subproject can use dependencies like this, omitting the rev: <parent name="myparent" rev="1.0"/> <dependencies> <dependency name="dom4j" org="apache" conf="compile"/> </dependencies> If you want to change the version of dom4j, you just change the version in the parent pom. Another thing that the parent pom provides is that if it finds the right revision in some path ("../pom.xml" by default), it will use that instead of the published on in repository. This is really useful when developing in IDEs or otherwise, because it's often too slow, cumbersome or even impossible to go. 1. publish parent ivy 2. resolve submodules That's just my experience. I've used a submodule which defines some common dependencies in an ivy.xml but I don't find it as useful as the parent project of Maven. Thoughts? Oh, and third opinion about including the parent vs. resolving it from a repository: If you just include it, the submodule cannot be reliably rebuit again as a single entity. For instance, if you checkout just the submodule with a some tag or certain branch, you don't really know which revision, if any, is in "../ivy.xml" or "../parent/ivy.xml". I don't think is issue is necessarily about whether the published metadata is merged or not, it's more about how the parent ivy is found while doing a resolve. In Maven, if the parent pom on the directory has a revision "1.10-SNAPSHOT" and the child refers to parent "1.10-SNAPSHOT", then Maven uses the file on the directory, otherwise it searches the repository. I'm not sure how exactly it should work with Ivy's static and latest.* revisions, but in my opinion, while developing on a local workstation, you often want it to be included, but when building official builds on a CI server or doing release builds, you want it to use the published version from repository. Going on this issue even further, well, even in Maven it's really hard to publish the parent pom alone or to publish only a subgroup of the projects. For instance, since the parent pom resides in the root directory, if you tag it, the SCM system usually tags all the submodules in the directory tree as well, etc. With the current build tools, it seems it's very hard to make a build system which supports large multimodule projects where you sometimes want to handle the multiproject as a whole and sometimes publish only parts of it.
        Hide
        Xavier Hanin added a comment -

        I agree with Gilles, publishing merged metadata is much cleaner and safer. If you need to update metadata a few month later, publish a new revision. If you really need to update your published module metadata, you still can use ivy:publish again with overwrite=true. So I don't think supporting the publication of non merged metadata is necessary, even as an option.

        Show
        Xavier Hanin added a comment - I agree with Gilles, publishing merged metadata is much cleaner and safer. If you need to update metadata a few month later, publish a new revision. If you really need to update your published module metadata, you still can use ivy:publish again with overwrite=true. So I don't think supporting the publication of non merged metadata is necessary, even as an option.
        Hide
        Maarten Coene added a comment -

        Maybe we should support both and make the default behiour to let Ivy publish the merged result, which is the safest solution.
        IMO, publishing a non-merged result is dangerous and can lead to unwanted dependency-changes when the parent module gets updated.
        But maybe in some usecases it can be usefull to not publish the merged result if you know what you are doing and what the side-effects of an update of the parent-module are...

        Show
        Maarten Coene added a comment - Maybe we should support both and make the default behiour to let Ivy publish the merged result, which is the safest solution. IMO, publishing a non-merged result is dangerous and can lead to unwanted dependency-changes when the parent module gets updated. But maybe in some usecases it can be usefull to not publish the merged result if you know what you are doing and what the side-effects of an update of the parent-module are...
        Hide
        Jean-Louis Boudart added a comment -

        Currently when we publish / deliver ivy file with the extends element in it and not the merged result.

        Even if i agree Gilles Scokart that a published element should be as much self containing as possible, i think that publishing the merged result is not the solution.

        I think that publishing with the extends element is more "refactorable".

        I'll give an example :
        Suppose we have a parent like

         
        <ivy-module version="2.0">
            <info organisation="foobar" module="parent">
                <license name="GPL" url="..."/>
            </info>
            <configurations defaultconfmapping="conf1->other1;conf2->other2">
               <conf name="conf1" />
               <conf name="conf2" extends="conf1" />
            </configurations>
            <dependencies>
                <dependency name="other-module" conf="conf1" rev="1.0" />
            </dependencies>
        </ivy-module>
        

        And a subproject (or a child) like

        <ivy-module version="2.0">
             <info organisation="foobar" module="child">
                 <parent organisation="foobar" module="child" revision="latest.integration"/>
             </info>
             <!-- where conf1 is inherited from parent -->
             <dependencies>
                 <dependency name="meow" conf="conf1" />
             </dependencies>
        </ivy-module>
        

        A few month later my project need to update from other-module rev1.0 to other-module rev2.0.
        In case where we publish the merged result, i'm not sure i'll want to publish / update ALL my subproject to update this revision.

        IMHO, keeping the extends element on published artifacts allow us a flexibility.

        What do you think about that?

        Show
        Jean-Louis Boudart added a comment - Currently when we publish / deliver ivy file with the extends element in it and not the merged result. Even if i agree Gilles Scokart that a published element should be as much self containing as possible, i think that publishing the merged result is not the solution. I think that publishing with the extends element is more "refactorable". I'll give an example : Suppose we have a parent like <ivy-module version= "2.0" > <info organisation= "foobar" module= "parent" > <license name= "GPL" url= "..." /> </info> <configurations defaultconfmapping= "conf1-> other1;conf2->other2" > <conf name= "conf1" /> <conf name= "conf2" extends= "conf1" /> </configurations> <dependencies> <dependency name= "other-module" conf= "conf1" rev= "1.0" /> </dependencies> </ivy-module> And a subproject (or a child) like <ivy-module version= "2.0" > <info organisation= "foobar" module= "child" > <parent organisation= "foobar" module= "child" revision= "latest.integration" /> </info> <!-- where conf1 is inherited from parent --> <dependencies> <dependency name= "meow" conf= "conf1" /> </dependencies> </ivy-module> A few month later my project need to update from other-module rev1.0 to other-module rev2.0. In case where we publish the merged result, i'm not sure i'll want to publish / update ALL my subproject to update this revision. IMHO, keeping the extends element on published artifacts allow us a flexibility. What do you think about that?
        Hide
        Gilles Scokart added a comment -

        I'm -1 to publish it with the extends element. The published element should be as much self-containing as possible.
        I would very much preffer the result to be merged.

        One thing that maybe unclear from the interface is is wether the included/extended ivy file is resolved from a repository or if it is taken from local file system, and when it does one or the other.

        In maven, releasing a parent pom is a nightmare.
        I wonder if it would not be simpler to only allow includes of local ivy.xml, instead of resolving it.

        Show
        Gilles Scokart added a comment - I'm -1 to publish it with the extends element. The published element should be as much self-containing as possible. I would very much preffer the result to be merged. One thing that maybe unclear from the interface is is wether the included/extended ivy file is resolved from a repository or if it is taken from local file system, and when it does one or the other. In maven, releasing a parent pom is a nightmare. I wonder if it would not be simpler to only allow includes of local ivy.xml, instead of resolving it.
        Hide
        Maarten Coene added a comment -

        Thank you a lot for this contribution!

        I have a question: what will happen when we publish/deliver such an ivy.xml file? Will we publish/deliver it with the extends element in it, or will we publish/deliver the merged result?

        Show
        Maarten Coene added a comment - Thank you a lot for this contribution! I have a question: what will happen when we publish/deliver such an ivy.xml file? Will we publish/deliver it with the extends element in it, or will we publish/deliver the merged result?
        Hide
        Jean-Louis Boudart added a comment -

        Updating the supplied patch, add some code flexibility to easily override merge mechanism.

        Show
        Jean-Louis Boudart added a comment - Updating the supplied patch, add some code flexibility to easily override merge mechanism.
        Hide
        Jean-Louis Boudart added a comment - - edited

        I've made a small patch as a POC that allow you to extends ivy files.

         
        <extends organisation="foobar" module="child" revision="latest.integration" location="../ivy.xml" extendType="configurations,dependencies"/>
        

        Location defines where ivy should look on filesystem before asking repository. This attribute is not mandatory. By default this attribute is set to "../ivy.xml"

        extendType attribute defines what you want to include. This is not a mandantory attribute.
        possible values for extendType :

        • all
        • configurations
        • dependencies
        • description
        Show
        Jean-Louis Boudart added a comment - - edited I've made a small patch as a POC that allow you to extends ivy files. <extends organisation= "foobar" module= "child" revision= "latest.integration" location= "../ivy.xml" extendType= "configurations,dependencies" /> Location defines where ivy should look on filesystem before asking repository. This attribute is not mandatory. By default this attribute is set to "../ivy.xml" extendType attribute defines what you want to include. This is not a mandantory attribute. possible values for extendType : all configurations dependencies description
        Hide
        Xavier Hanin added a comment -

        That sounds like a much more flexible and interesting way to provide parent import mechanism! While thinking about it, I'm wondering if using the parent concept isn't limiting itself. Why wouldn't we call this import as the import in Ant (or extends as we call it in EasyAnt)? Then we could imagine importing multiple ivy files, controlling for each one what is really imported. More flexible, and not really harder to implement and document if we fix what happens when the same dependency is defined multiple times in imported modules with different versions / conf mapping. I guess we could say that the last (or first?) definition takes precedence.

        WDYT?

        Show
        Xavier Hanin added a comment - That sounds like a much more flexible and interesting way to provide parent import mechanism! While thinking about it, I'm wondering if using the parent concept isn't limiting itself. Why wouldn't we call this import as the import in Ant (or extends as we call it in EasyAnt)? Then we could imagine importing multiple ivy files, controlling for each one what is really imported. More flexible, and not really harder to implement and document if we fix what happens when the same dependency is defined multiple times in imported modules with different versions / conf mapping. I guess we could say that the last (or first?) definition takes precedence. WDYT?
        Hide
        Jean-Louis Boudart added a comment - - edited

        In my humble opinion parent mechanism is not only related to dependencies.

        We could imagine that "parent support" allow you to inherit dependencies / configurations / licences / homeurl / etc ...

        Example :
        parent:

         
        <ivy-module version="2.0">
            <info organisation="foobar" module="parent">
                <license name="GPL" url="..."/>
            </info>
            <configurations defaultconfmapping="conf1->other1;conf2->other2">
               <conf name="conf1" />
               <conf name="conf2" extends="conf1" />
            </configurations>
            <dependencies>
                <dependency name="other-module" conf="conf1" />
            </dependencies>
        
        </ivy-module>
        

        child :

         
        <ivy-module version="2.0">
             <info organisation="foobar" module="child">
                 <parent organisation="foobar" module="child" revision="latest.integration"/>
             </info>
             <!-- where conf1 is inherited from parent -->
             <dependencies>
                 <dependency name="meow" conf="conf1" />
             </dependencies>
        </ivy-module>
        

        Parent tag should support something to look up on filesystem before asking repositories maybe an attribute like "location". This value should be set as ".." for default value
        exemple :

         
        <parent organisation="foobar" module="child" revision="latest.integration" location="../myParent"/>
        

        And to keep ivy flexibility we could add an attribute to choose what we want to import from parent
        Something like :

         
        <parent organisation="foobar" module="child" revision="latest.integration" location="../myParent" import="configurations,dependencies"/>
        

        What do You think about it?

        Show
        Jean-Louis Boudart added a comment - - edited In my humble opinion parent mechanism is not only related to dependencies. We could imagine that "parent support" allow you to inherit dependencies / configurations / licences / homeurl / etc ... Example : parent: <ivy-module version= "2.0" > <info organisation= "foobar" module= "parent" > <license name= "GPL" url= "..." /> </info> <configurations defaultconfmapping= "conf1-> other1;conf2->other2" > <conf name= "conf1" /> <conf name= "conf2" extends= "conf1" /> </configurations> <dependencies> <dependency name= "other-module" conf= "conf1" /> </dependencies> </ivy-module> child : <ivy-module version= "2.0" > <info organisation= "foobar" module= "child" > <parent organisation= "foobar" module= "child" revision= "latest.integration" /> </info> <!-- where conf1 is inherited from parent --> <dependencies> <dependency name= "meow" conf= "conf1" /> </dependencies> </ivy-module> Parent tag should support something to look up on filesystem before asking repositories maybe an attribute like "location". This value should be set as ".." for default value exemple : <parent organisation= "foobar" module= "child" revision= "latest.integration" location= "../myParent" /> And to keep ivy flexibility we could add an attribute to choose what we want to import from parent Something like : <parent organisation= "foobar" module= "child" revision= "latest.integration" location= "../myParent" import= "configurations,dependencies" /> What do You think about it?
        Hide
        Xavier Hanin added a comment -

        Works for me too, except that I don't like the _ in the xml elements: we already suffer from some inconsistencies in xml element names in Ivy, let's avoid introducing a new separator

        Show
        Xavier Hanin added a comment - Works for me too, except that I don't like the _ in the xml elements: we already suffer from some inconsistencies in xml element names in Ivy, let's avoid introducing a new separator
        Hide
        Neil Lott added a comment -

        Works for me.

        Show
        Neil Lott added a comment - Works for me.
        Hide
        Łukasz Kurek added a comment - - edited

        core-deps.xml:

        <dependencies>
             <dependency org="apache" name="commons-lang" revision="2.0" force="true" conf="default"/>
             <dependency name="mymodule" revision="latest.integration" conf="test->default"/>
        </dependencies>
        

        ivy.xml:

        <dependencies>
             <include_deps file="core-deps.xml" />
        
             <!-- redefinition (of revision number): -->
             <dependency org="apache" name="commons-lang" revision="1.0" force="true" conf="default"/>
        
             <!-- included dependency excluded: -->
             <exclude_deps dependency name="mymodule" revision="latest.integration" />
        
             <!-- some deps added, as usual: -->
             <dependency org="jayasoft" name="swtbinding" branch="fix-103" revision="latest.integration"/>
             <dependency org="foo" name="bar" revision="3.0" transitive="false" conf="default->@;runtime,test->runtime"/>
        </dependencies>
        

        What do You think?

        Show
        Łukasz Kurek added a comment - - edited core-deps.xml: <dependencies> <dependency org= "apache" name= "commons-lang" revision= "2.0" force= " true " conf= " default " /> <dependency name= "mymodule" revision= "latest.integration" conf= "test-> default " /> </dependencies> ivy.xml: <dependencies> <include_deps file= "core-deps.xml" /> <!-- redefinition (of revision number): --> <dependency org= "apache" name= "commons-lang" revision= "1.0" force= " true " conf= " default " /> <!-- included dependency excluded: --> <exclude_deps dependency name= "mymodule" revision= "latest.integration" /> <!-- some deps added, as usual: --> <dependency org= "jayasoft" name= "swtbinding" branch= "fix-103" revision= "latest.integration" /> <dependency org= "foo" name= "bar" revision= "3.0" transitive= " false " conf= " default ->@;runtime,test->runtime" /> </dependencies> What do You think?
        Hide
        Xavier Hanin added a comment -

        How do you distinguish inclusion from inheritance in this case?

        Show
        Xavier Hanin added a comment - How do you distinguish inclusion from inheritance in this case?
        Hide
        Niklas Matthies added a comment -

        Here is a similar proposal I made on the ivy-user mailing list:

        Provide an inclusion facility for ivy files to semantically include/merge the contents of some other ivy file, similar as "include" for the settings files. Possibly add an attribute to choose what to do in case of conflicting/non-mergeable specs.

        I believe that it's more useful to do this as inclusion rather than as inheritance. It would also be in anology the the inclusion mechanism of ivy settings files.

        Show
        Niklas Matthies added a comment - Here is a similar proposal I made on the ivy-user mailing list: Provide an inclusion facility for ivy files to semantically include/merge the contents of some other ivy file, similar as "include" for the settings files. Possibly add an attribute to choose what to do in case of conflicting/non-mergeable specs. I believe that it's more useful to do this as inclusion rather than as inheritance. It would also be in anology the the inclusion mechanism of ivy settings files.
        Hide
        Gilles Scokart added a comment -

        I don't think that adding a maven-like parent construction in our ivy files would be a good thing.

        I think this kind of structure uselessly add some complexity to the parsing.

        I think you can already have something very close now. You can include the configuration file, and put a dependency to your "parent" module (=a generic test module) into which you can place all your test dependencies.

        Show
        Gilles Scokart added a comment - I don't think that adding a maven-like parent construction in our ivy files would be a good thing. I think this kind of structure uselessly add some complexity to the parsing. I think you can already have something very close now. You can include the configuration file, and put a dependency to your "parent" module (=a generic test module) into which you can place all your test dependencies.

          People

          • Assignee:
            Maarten Coene
            Reporter:
            Neil Lott
          • Votes:
            5 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development