ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kieran Shanley <>
Subject Re: IvyDE and retrieving artefacts into project root
Date Wed, 16 Oct 2013 04:46:25 GMT
I looked into it a bit further and here is my suggested fix. Couldn't get
the code to build or run so I can't verify that it works but I think
something like this might solve my problem:

 if (numberOfItemsRetrieved > 0) {
        // Only refresh if we actually retrieved a file.
        if (refreshPath.length() > 0) {
            // refresh folder into which artifact was retrieved
            IFolder retrieveFolder = project.getFolder(refreshPath);
            IvyDEMessage.verbose("Refreshing Eclipse folder " +
            RefreshFolderJob refreshFolderJob = new
        } else {
           // refresh the project

Would refreshLocal() cover both cases ? Maybe it would do too much work and
refreshing a folder is better if just that folder has been updated ? I got
the idea of invoking refreshLocal from a post on stack overflow:

Can somebody try it out for me or give me some tips on how to get the code
to build :)



On Wed, Oct 16, 2013 at 1:59 PM, Kieran Shanley <>wrote:

> Hi Guys,
> I have a problem that looks like an issue with IvyDE. When I perform a
> retrieve I am getting the following error in eclipse:
> Description    Resource    Path    Location    Type
> Error while resolving dependencies for ivy.xml[*] in /EarProject
> Path must include project and resource name: /EarProject    ivy.xml
> /EarProject    Unknown    IvyDE Problem
> More Detail follows:
> When the problem occurs I am trying to retrieve the WAR file which is a
> dependency for my EAR project. The project I am working is using JBOSS7.
> The WAR file needs to be placed in the root of the EAR.
> Here are the ivyDE preferences settings:
> eclipse.preferences.version=1
> org.apache.ivyde.eclipse.standaloneretrieve=<?xml version\="1.0"
> encoding\="UTF-8" standalone\="no"?><setuplist><setup
> name\="JARDependencies"><ivyxml path\="ivy.xml"/><retrieve confs\="default"
> pattern\="lib/[artifact].[ext]" sync\="true"
> types\="jar,bundle"/></setup><setup name\="WARdependencies"><ivyxml
> path\="ivy.xml"/><retrieve confs\="*" pattern\="/[artifact].[ext]"
> sync\="false" types\="war"/></setup></setuplist>
> The problem occurs when retrieving the "WARdependencies"
> I grabbed a copy of the ivyDE code and had a look around. It seems the
> trouble is that IvyDE assumes that all artifacts retrieved are stored in a
> subdirectory of the project. After the retrieve is performed it attempts to
> get a handle to the  "retrieveFolder" and schedule a refresh. In my case
> the artifact is retrieved into the project root and the attempt to locate
> the "retrieveFolder" fails.
> Here is a snippet of code from
>        String refreshPath = IvyPatternHelper.getTokenRoot(retrievePattern);
>         int numberOfItemsRetrieved =
> ivy.retrieve(md.getModuleRevisionId(), pattern, options);
>         if (numberOfItemsRetrieved > 0) {
>             // Only refresh if we actually retrieved a file.
>             IFolder retrieveFolder =
> project.getFolder(refreshPath);                            <==== this looks
> to be the troublesome line in the case where the item has been retrieved
> into the project's root dir
>             RefreshFolderJob refreshFolderJob = new
> RefreshFolderJob(retrieveFolder);
>             refreshFolderJob.schedule();
>         }
> In the case where an artifact is retrieved into the root of the project
> dir the call to getFolder() causes the error seen. I think the code needs a
> guard to check the refresh path and instead of trying to get a sub folder
> maybe it should get a handle to the workspace root and perform a refresh
> from there ???
> I can't work around the problem by moving the WAR file to another location
> as I can't get JBOSS to start successfully :( We would like to roll out the
> move to JBOSS7 to other internal dev teams but we dont want a bunch of
> other guys spending time on this issue. You can get round it by manually
> refreshing the project and then performing another resolve to clear the
> error from eclipse but thats pretty hacky.
> Is anyone able to confirm my diagnosis and or produce a fix ?
> Cheers,
> Kieran

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message