Ivy
  1. Ivy
  2. IVY-968

FileSystem resolver with m2compatible=true throws error when publishing modules with dotted organisation names

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-RC2, 2.1.0
    • Fix Version/s: 2.2.0-RC1
    • Component/s: Core
    • Labels:
      None
    • Environment:

      Windows XP, JDK 1.6

      Description

      When you try to publish an artifact with a "." (dot) in its organisationname to a maven2 compatible file system resolver you get:

      Ant Output
      install-local:
      :: delivering :: org.test#testlib;working@kebap :: 0.0-dev-20081114110649 :: integration :: Fri Nov 14 11:06:53 CET 2008
      	delivering ivy file to D:\workspace\testlib\dist\ivys\ivy.xml
      :: publishing :: org.test#testlib
      	published testlib to C:\Dokumente und Einstellungen\kebe\.ivy2/local/org/test/testlib/0.0-dev-20081114110649.part/testlib-0.0-dev-20081114110649.jar
      	published ivy to C:\Dokumente und Einstellungen\kebe\.ivy2/local/org/test/testlib/0.0-dev-20081114110649.part/ivy.xml
      
      BUILD FAILED
      XXXXXXXXXXXXXXXXXx-common.ant:459: impossible to publish artifacts for org.test#testlib;working@kebap: java.lang.IllegalStateException: no current transaction!

      Here is the settings snippet:

      From ivysettings.xml
      <filesystem name="local" m2compatible="true">
        <ivy pattern="${repository.local.path}/[organisation]/[module]/[revision]/ivy.xml" />
        <artifact pattern="${repository.local.path}/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" />
      </filesystem>
      

      Publishing with organisation without a "." works. If you set transactional of the filesystem resolver to false it works, too.

        Activity

        Hide
        Jason Trump added a comment -

        I ran into this problem today. It looks like the cause is fairly straightforward – the transaction logic in FileSystemResolver doesn't consistently do the m2compatible org translation when computing artifact paths.

        I've written a failing junit test case, I'll attach it shortly.

        Show
        Jason Trump added a comment - I ran into this problem today. It looks like the cause is fairly straightforward – the transaction logic in FileSystemResolver doesn't consistently do the m2compatible org translation when computing artifact paths. I've written a failing junit test case, I'll attach it shortly.
        Hide
        Jason Trump added a comment -

        failing junit test case, demonstrates incompatibility between m2compatible="true" and transactional="true"

        Show
        Jason Trump added a comment - failing junit test case, demonstrates incompatibility between m2compatible="true" and transactional="true"
        Hide
        Maarten Coene added a comment -

        Fixed in trunk, please give it a try if possible.

        Thanks for the patch Jason.
        Even though I didn't add your junit test, your input was very helpfull fixing this issue!

        Maarten

        Show
        Maarten Coene added a comment - Fixed in trunk, please give it a try if possible. Thanks for the patch Jason. Even though I didn't add your junit test, your input was very helpfull fixing this issue! Maarten
        Hide
        Jason Trump added a comment -

        hey Maarten,

        Transaction issue resolved, many thanks. Your test case is much cleaner than the one in the patch.

        Only one problem: latest build seems to be leaving a couple of stale *.lck files in my cache after resolve. I do not think it's related to this issue. I'll sync again and see if I can track it down.

        jt

        Show
        Jason Trump added a comment - hey Maarten, Transaction issue resolved, many thanks. Your test case is much cleaner than the one in the patch. Only one problem: latest build seems to be leaving a couple of stale *.lck files in my cache after resolve. I do not think it's related to this issue. I'll sync again and see if I can track it down. jt
        Hide
        Jason Trump added a comment -

        ok, the cache lock issue I mention is definitely not related. I logged a separate issue for that:

        https://issues.apache.org/jira/browse/IVY-1145

        thanks for the fix!

        Show
        Jason Trump added a comment - ok, the cache lock issue I mention is definitely not related. I logged a separate issue for that: https://issues.apache.org/jira/browse/IVY-1145 thanks for the fix!

          People

          • Assignee:
            Maarten Coene
            Reporter:
            Michael Kebe
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development