ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Saunders (JIRA)" <>
Subject [jira] Created: (IVY-1154) More than one rule matched while retrieving parent POM
Date Tue, 22 Dec 2009 09:38:29 GMT
More than one rule matched while retrieving parent POM

                 Key: IVY-1154
             Project: Ivy
          Issue Type: Bug
    Affects Versions: 2.1.0
         Environment: Windows 7, Sun JDK 1.6.0_16, Ant 1.7.1
            Reporter: Ryan Saunders

In trying to build an Ivy repository with a sensible org/module hierarchy, I seem to have
stumbled over a bug in the namespace translation code. In the following Ivy configuration,
I'm trying to map all apache commons projects into the "org.apache.commons" organization,
locally, even though many of them have the module name as the org name in the maven2 repo.
The second and third rules in this namespace _ought_ to be equivalent in their effect, but
they are not...if I use the rule with the regex, it appears to match the "commons-parent",
which it shouldn't, because commons-parent is matched by the first rule in the namespace ("chainrules"
is false).

If you comment out rule #3 and uncomment rule #2, it works just fine, because rule #2 cannot
match "commons-parent".


  <property name="ibiblio-maven2-root" value="" override="false"

    The ibiblio Maven2 repository has some funky historical ways of organizing projects. Specifically,
    projects are not filed under "org.apache", as you'd expect them to be...instead, the org
name is the name
    of the project (e.g., "commons-lang"). This namespace definition converts all known Apache
projects to the
    more normal organization, by mapping them to an org name of "org.apache".
    <namespace name="ibiblio-maven2">

      <!-- After a certain point in time, it appears that new Apache projects were properly
placed under
           org/apache/... commons-parent is one of these. This rule should match any request
           org.apache.commons#commons-parent;*. It is first in the list because we want it
to match commons-parent,
           rather than the commons-.+ regex of the next rule. -->
          <src org="org\.apache\.commons" module="commons-parent"/>
          <dest org="org.apache.commons" module="$m0"/>
          <src org="org\.apache\.commons" module="commons-parent"/>
          <dest org="org.apache.commons" module="$m0"/>

           commons-math, on the other hand, lives in the "old" place, with the module name
instead of the org name
           as the directory. If I write a rule that specifically translates org.apache.commons#commons-math;*
           "commons-math"/"commons-math", everything works fine, and we can resolve both commons-math
and also
           commons-parent. -->
          <src org="org\.apache\.commons" module="commons-math"/>
          <src org="org\.apache\.commons" module="commons-logging"/>
          <src org="org\.apache\.commons" module="commons-discovery"/>
          <dest org="$m0" module="$m0"/>
          <src org="commons-math" module="commons-math"/>
          <src org="commons-logging" module="commons-logging"/>
          <src org="commons-discovery" module="commons-discovery"/>
          <dest org="org.apache.commons" module="$m0"/>

           Things go to crap, on the other hand, if I try to use a regex to match any commons-
prefixed project.
           In theory, since I put an explicit rule to match commons-parent earlier in the
rule sequence, commons-parent
           should never get to here. In practice, it seems to, and the lookup for commons-parent
fails, because it's
           looking for,
which does not
           exist. -->
          <src org="org\.apache\.commons" module="commons-.+"/>
          <dest org="$m0" module="$m0"/>
          <src org="commons-.+" module="commons-.+"/>
          <dest org="org.apache.commons" module="$m0"/>


  <!-- We want the "all versions" conflict manager, so that newer versions don't evict
old ones from the repo -->
  <settings defaultConflictManager="all" />

    <filesystem name="ivy-repository">
      <ivy pattern="${ivy.repo.dir}/[organisation]/[module]/ivys/ivy-[revision].xml"/>
      <artifact pattern="${ivy.repo.dir}/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"/>
    <ibiblio name="ibiblio-maven2-repository" 


Here is the corresponding build.xml for controlling this from Ant. If you want to run this,
adjust the value of the ivy.repo.dir property for your system, and then run "ant install".

<project name="ivy-repository" xmlns:ivy="antlib:org.apache.ivy.ant">

  <property name="from.resolver" value="ibiblio-maven2-repository"/>
  <property name="to.resolver" value="ivy-repository"/>
  <property name="ivy.repo.dir" value="C:/Users/jediry/repo"/>
  <target name="install">
    <delete dir="${ivy.repo.dir}"/>
    <mkdir dir="${ivy.repo.dir}"/>
    <ivy:settings id="ivy.instance" file="ivysettings.xml"/>
    <ivy:install from="${from.resolver}" to="${to.resolver}" transitive="true"
                 organisation="org.apache.commons" module="commons-math" revision="1.2"/>


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

View raw message