ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William Price (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IVY-1221) ivy won't resolve updated maven SNAPSHOT artifacts with classifiers from local repo
Date Fri, 22 Jun 2012 22:14:43 GMT

    [ 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

        

Mime
View raw message