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 [email protected] | 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 > > >
smime.p7s
Description: S/MIME cryptographic signature
