[jira] Commented: (IVY-742) Support ivy.xml parent mechanism

["Juha Ranta (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IVY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773914#action_12773914 ] 

Juha Ranta commented on IVY-742:
--------------------------------

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.

> Support ivy.xml parent mechanism
> --------------------------------
>
>                 Key: IVY-742
>                 URL: https://issues.apache.org/jira/browse/IVY-742
>             Project: Ivy
>          Issue Type: New Feature
>          Components: Core
>         Environment: Any
>            Reporter: Neil Lott
>         Attachments: extendsIvyFile-ivy-r709181.patch
>
>
> Here's the email that details this feature:
> On Thu, Feb 21, 2008 at 11:22 PM, Neil Lott <ne...@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/

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