You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by "William Price (JIRA)" <ji...@apache.org> on 2012/06/23 00:14:43 UTC

[jira] [Commented] (IVY-1221) ivy won't resolve updated maven SNAPSHOT artifacts with classifiers from local repo

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

William Price commented on IVY-1221:
------------------------------------

Okay, our organization recently hit this and it became a showstopper.  I think I can explain and offer a fix.

Maven's POM metadata doesn't describe all published files.  For example, "*-javadoc.jar" and "*-sources.jar" classifiers may be *implied* by <packaging>jar</packaging> but not explicitly stated.  Similarly, if your ivy.xml file declares <artifact> child elements of <dependency> elements, those <artifacts> (as documented) are assumed to have NO METADATA.

Looking at the Ivy source code, the snapshot cleanup routine in DefaultRepositoryCacheManager
enumerates all declared Ivy configurations and attempts to clean the cache for all artifacts
that are "published" under those configurations.  Again, Maven POMs don't explicitly declare
all publications, and that also doesn't solve the manually declared <artifact>s.  Once Ivy
sees that the module metadata and "primary" artifact in the cache are up-to-date, it ASSUMES
that any other artifacts cached for the same module are also out of date.

That assumption is INCORRECT.  The resulting behavior is the "primary" artifact
(usually the JAR) is refreshed, but other artifacts (m:classifier, manual <artifact>
definitions) remain stale.

My proposed solution (and what seems to work in brief testing) is to clean ALL
known artifacts from the cache, using the *.properties data from the local cache and
NOT rely on the published/cached metadata at all.  Ivy already records information
about EVERY file it caches, so Ivy should enumerate them and clean them ALL* when
the module is found to be out-of-date.

* In testing, I found that if you clean the metadata, too, Ivy tends to think that
  the module is ALWAYS out of date; so my workaround is to NOT clean things that look
  like Ivy/POM files (or the "original" versions of those).  Ivy seems to be handling
  those correctly already.
                
> ivy won't resolve updated maven SNAPSHOT artifacts with classifiers from local repo
> -----------------------------------------------------------------------------------
>
>                 Key: IVY-1221
>                 URL: https://issues.apache.org/jira/browse/IVY-1221
>             Project: Ivy
>          Issue Type: Bug
>          Components: Maven Compatibility
>    Affects Versions: 2.2.0-RC1
>         Environment: Mac OS X 10.6, Ant 1.7.1, Maven 2.2.1
>            Reporter: Nick Bonatsakis
>
> The situation I'm running into is as follows: I have a maven project that produces two artifacts foo-SNAPSHOT.jar and foo-SNAPSHOT-tests.jar. When I resolve these via ivy, they are both pulled properly initially, however with the following ivysettings ibiblio, only the foo-SNAPSHOTS.jar is getting updated on resolve after re-installing via maven.
> <ibiblio name="local_m2_repo" 
>                  m2compatible="true"
>                  usepoms="true"
>                  changingPattern=".*-SNAPSHOT.*"
>                  changingMatcher="regexp"
>                  checkmodified="true"
>                  root="${localm2repo.url}"/>
> I started out trying the pattern ".*-SNAPSHOT" which I would have expected to pick up the tests jar, but tried this in the hopes of getting it to work, which of course it did not. This doesn't seem to be a retrieve issue either, the modified date of the foo-SNAPSHOT.jar in the local ivy cache is being updated while foo-SNAPSHOT-test.jar is not. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira