Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@ant.apache.org
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type;
  b=nMRLQVbv6uefSyymgNLmQpy4M0warltsAs/gm4YKfwRX+wspHUb+oKYlSHSJEFRqCq69Li+vI8UoSsS8uomKh6F8roKQ3d3fePes4ftF27U0JNd+tkrABCKwi0saBb1iHHQWHXwGJ+EGVHhWGikez18oZqXAgCZeraXbzw9pogU=;
Message-ID: <194952.22522.qm@web81103.mail.mud.yahoo.com>
Date: Thu, 4 Feb 2010 13:46:34 -0800 (PST)
From: Jeffrey Metcalf <jeffrey_m_metcalf@yahoo.com>
Subject: Will future IvyDE resolve workspace dependencies on the branch
 attribute?
To: ivy-user@ant.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hi,

I am new to IvyDE but rather experienced with Ivy.  I find the IvyDE tool exceptional.  The developers have done a great job and it seems quite stable and feature rich with the 2.0.0 version.

I have read through the documentation, the FAQ, and browsed the Jira project, and despite some related discussion in Jira, I was unable to determine if it is possible or if it is planned to leverage the branch attribute on a module descriptor and dependency descriptor to help identify the eclipse project to build a dependency against.  Here are my needs:

1.  I work on projects where I can be called upon to simultaneously work on code in the trunk and branch (bug fix).  Consequently I often have both code bases open simultaneously as Eclipse projects in the workspace.
2.  The project in the trunk does not use the branch attribute in its module descriptor <info /> tag.  The project in the branch uses the branch attribute in its module descriptor <info /> tag.
3.  Other eclipse projects may have a dependency on the projects described in 2.  Some depend on the branch project (specified using <dependency /> branch attribute), others depend on the trunk project (specified by not using a <dependency /> branch attribute).
4.  When I resolve the IvyDE classpath for the projects in 3 as needed, the proper dependent project in 2 is not resolved.

It seems there are three possible workarounds each less than ideal.

a.  The dependency matching algorithm seems to use revision ranges which can work, but the problem is we generally use latest.integration as the revision in the <dependency /> tag for the projects in 3 for both trunk and branch code undergoing development (both can appear in our CI instance).
b.  I can close the eclipse project I don't want to match on, but it can be problematic if I want to access the closed project.
c.  Use separate workspaces for trunk and branch code.  A case can be made for good development practice here, but switching between workspaces is even more inconvenient than opening and closing projects in a single workspace (workaround 2).

It seems that adding a comparison on the branch attribute would probably be quite simple if I understand the current algorithm correctly.  I assume that it goes something like this:

1.  Look for candidate projects that match against the <dependency/> org and module attributes in the module descriptor.
2.  If more than one match is found among the candidates, check to see if a value for revision is set in the module
descriptor and compare that to the range for revision in <dependency/>.
3.  If a match is found in 2, select the project for classpath dependency.  Otherwise just select the first found project match after step 1.

Therefore it seems to add a match on branch, just one additional comparison needs to be done between 1 and 2:

1.   Look for candidate projects that match against the <dependency/> org and module attributes in the module descriptor.
1.5 If the <dependency/> also contains the branch attribute, eliminate all those candidates from 1 that do not define the same value of branch in the module descriptor.
2.   If more than one match is found among the (remaining) candidates, check to see if a value for revision is set in the module
descriptor and compare that to the range for revision in <dependency/>.
3.   If a match is found in 2, select the project for classpath dependency.  Otherwise just select the first found project match after step 1.5.

As I said above, I found some discussion on the matching algorithm in the Jira issues and there was a minor mention about the branch attribute, so I am not sure if there plans to include the value in the workspace dependency code for a future release.  If so, I can wait.  If not, would it be appropriate to add a new feature request in Jira?

Thanks,

-J