ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Anderson <eander...@palantirtech.com>
Subject Re: Will future IvyDE resolve workspace dependencies on the branch attribute?
Date Mon, 08 Feb 2010 23:24:14 GMT
This would be fantastic!

Currently the way my company gets around this is as follows:

Product A is comprised of 5 "core" projects and many many non core (changed infrequently)
projects. I created an "eclipse" configuration in the ivy files that brings in everything
except those 5 projects. Then we depend on those 5 via ".classpath".

This gets us moving on the core projects.

Lets say you need to debug a fix to a non core project. Just add it to your ".classpath" and
bump up the order so that your local project is above the ivy stuff.

Hope this helps
_________________________________________________________
Eric Anderson
Palantir Technologies | Engineering Team Lead
eanderson@palantirtech.com | 520.440.3773
_________________________________________________________

On Feb 4, 2010, at 1:46 PM, Jeffrey Metcalf wrote:

> 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
> 
> 
> 


Mime
View raw message