2009-12-08 6 views
3

Je développe une petite interface Web dans Grails. Il s'agit essentiellement d'une application cliente "ultra-légère" qui est connectée en mode asynchrone via JMS.Grails et dépendances locales de Maven

J'ai deux dépendances dans le projet que je voudrais tirer d'un dépôt Maven. Ils sont activemq et acme-adapter-api, une dépendance interne, non disponible dans le référentiel distant.

Je mis mon BuildConfig.groovy (Grails 1.2M4) fichier comme celui-ci, afin d'accéder à mes dépendances:

repositories { 
    grailsPlugins() 
    grailsHome() 
    mavenCentral() 
    mavenRepo('D:/maven-repo') 
} dependencies { 
    compile 'org.apache.activemq:apache-activemq:4.1.1' 
    compile 'com.acme:acme-adapter-api:1.3-SNAPSHOT' 
} 

Quand je lance grails dependency-report, je peux voir cette ligne sur la acme-adapter-api, par exemple :

acme-adapter-api by com.acme 
108 kB (0 kB downloaded, 108 kB in cache) 

Lorsque je tente de lancer grails compile, je ne reçois pas de chance, car il se plaint alors il est incapable de résoudre les classes de la com.acme groupe.

Fait intéressant les dépendances activemq ne semblent pas être un problème ...

La différence est que les dépendances de Acme ne sont pas en mavenCentral(), mais seulement dans mavenRepo("D:/maven-repo"). Alors j'ai pensé: "Peut-être que ça ne le prend pas sur le disque local alors ..." et a changé la version en une valeur amusante (1.999-SNAPSHOT) qui n'existe pas dans le fichier BuildConfig.groovy. Lors de l'exécution grails compile à nouveau, la commande a expiré, en disant que la version n'a pas pu être trouvé:

UNRESOLVED DEPENDENCIES 
D:/maven-repo: unable to get resource for com/acme#acme-adapter-api;1.999-SNAPSHOT 

Alors, évidemment, la dépendance locale se résoudre, mais en quelque sorte pas appliqué à l'étape suivante, la compilation ...

Répondre

0

Il avéré que le problème était alors cache non vide pour l'artefact. Bien que le fichier activemq jar n'ait pas été modifié, le fichier acme-adapter-api.jar a en fait été plusieurs fois modifié, mais sans augmenter l'identifiant de construction maven, 1.3, dans le cas ci-dessus.

je pouvais réparer, quand j'augmenté le nombre de construction à 1,4 Snapshot ...

Deux questions demeurent:

  1. est-ce pas le contrat de Maven pour toujours chercher versions SNAPSHOT, pour la même raison?
  2. Comment vider le cache avec force? Et où est-ce?

je vais ouvrir une nouvelle question pour répondre à la partie 2 here

+0

Je viens de rencontrer le même problème. Les dépendances SNAPSHOT ne sont pas rechargées après la première fois. C'est un énorme problème au cours du développement. :/Grrr. – Mike

+0

https://github.com/alkemist/grails-snapshot-dependencies-fix pour un travail autour –

5

Grails 1.3.6 a été mis à jour avec Ivy 2.2 (qui a indiqué qu'il a appliqué un correctif pour https://issues.apache.org/jira/browse/IVY-938) et je peux obtenir des mises à jour de versions SNAPSHOT si je spécifie "changing = true", comme dans:

dependencies { 
    runtime ('groupId:artifactId:version-SNAPSHOT') { 
    changing = true 
    } 
} 
Questions connexes