Thanks John. I provided a patch for the branch comparison code earlier today and will provide a patch for the optional extended revision id this weekend. Given that these features will be available in trunk by no later than Sunday, Feb 14th, I will edit the Jira issues targeting the 2.2.0 release.
Best regards, -J ----- Original Message ---- > From: Jon Schneider <jkschnei...@gmail.com> > To: Ant Developers List <dev@ant.apache.org> > Sent: Fri, February 12, 2010 11:35:42 AM > Subject: Re: Will future IvyDE resolve workspace dependencies on the branch > attribute? > > Jeffrey, > > I reviewed the JIRAs and look forward to a patch. I am moving forward with > the 2.1.0 release of IvyDE without them with the understanding that the > 2.2.0 development cycle will be much shorter. We are doing this 2.1.0 > release with most of the features that we have implemented since 2.0.0, but > one in particular is going to require Eclipse 3.4 support. > > IvyDE 2.1.0 will be announced as the last Eclipse 3.2 compatible > distribution, allowing folks that need this legacy support to take advantage > of new features. However, we intend for 2.2.0 to follow relatively shortly. > We can include your new feature in that release. > > Thanks again, > Jon > > > On Tue, Feb 9, 2010 at 1:45 PM, Jeffrey Metcalf > > wrote: > > > Hi John, > > > > I just created issues in Jira. > > > > https://issues.apache.org/jira/browse/IVYDE-234 (add branch comparison > > to workspace resolution code) > > https://issues.apache.org/jira/browse/IVYDE-235 (add option to use > > extended resolveId in the resolution cache) > > > > I targeted fix revision 2.1.0 since these are really easy feature additions > > and I am willing to work on them this week. In fact, I already implemented > > IVYDE-234 in my copy of trunk. If core team members disagree with that, > > feel free to unschedule them in Jira. I have no problem with it. > > > > Also, if someone wants to see my patches, I can provide them this evening > > and post them as a comment in Jira. Otherwise if deemed appropriate, feel > > free to assign me the issues and I will do some more developer testing and > > commit the code later in the week. > > > > BTW. Based on your use case discussion, it is pretty clear why nobody > > should really be ignoring revision (or branch) in the project comparison. > > Based on my understanding of the risks, I for example would never disable > > them. However I would include the ignore branch option for consistency as I > > mentioned. If the team in the future decides to take away the option on > > revision, then barring a good argument otherwise, I would agree that it > > should probably be removed on branch as well. > > > > Cheers, > > > > -J > > > > > > > > ----- Original Message ---- > > > From: Jon Schneider > > > To: Ant Developers List > > > Sent: Tue, February 9, 2010 11:51:58 AM > > > Subject: Re: Will future IvyDE resolve workspace dependencies on the > > branch attribute? > > > > > > Jeffrey, > > > > > > These all sound like great additions. If you open a JIRA [1] issue for > > > this, discussion can continue there? > > > > > > I don't disagree that adding an "ignore branch" option is the right thing > > to > > > do for the sake of consistency, but I do want to highlight one point, > > just > > > to think about. > > > > > > Currently, we discourage the use of the "ignore version when resolving > > > workspace projects". Here is an example use case highlighting the > > trouble > > > it could cause. For this example we assume "Resolve dependencies in > > > workspace" is enabled. > > > > > > 1. Suppose we are given projects A, B, and C in the workspace. > > > 2. A depends on C version 1.0 > > > 3. B depends on C version 1.1.+ > > > 4. A and B do not depend on one another directly or transitively. > > > 5. C's module descriptor has an info element with status="integration". > > > > > > Without this property checked: > > > > > > 1. A will download the 1.0 version of C from the repository and add it > > to > > > its classpath. > > > 2. B will add a workspace project reference to C. > > > > > > With this property checked: > > > 1. A will add a workspace project reference to C. > > > 2. B will add a workspace project reference to C. > > > > > > I believe that this will surprise most users who aren't really thinking > > > deeply about their set of configuration options. This could be a > > slippery > > > slope we find ourselves on with ignoring certain attributes. > > > > > > Thanks for your work on it, > > > > > > Jon > > > > > > [1] http://issues.apache.org/jira/browse/IVYDE > > > > > > > > > On Tue, Feb 9, 2010 at 8:55 AM, Jeffrey Metcalf > > > > wrote: > > > > > > > Hi Eric, > > > > > > > > Thank you for your suggestion. It also looks to be a good workaround. > > I > > > > am going to go ahead and violate mailing list etiquette rules just for > > this > > > > one reply so that I can crosspost to dev@ant.apache.org for the > > developers > > > > to see this development related discussion. > > > > > > > > I have actually taken the liberty to retrieve IvyDE from the Apache > > > > subversion repository and have begun the process of updating the code > > to > > > > include a branch check in the workspace resolver code in trunk. > > Curently > > > > there is a configuration option to ignore revision in the workspace > > project > > > > dependency comparison, and I have added a similar option for branch to > > > > remain consistent. I am also adding a configuration option to allow > > the > > > > user to optionally specify an extended revision id that includes any > > status, > > > > branch, or revision value found in the project ivy.xml at resolution > > time. > > > > Currently IvyDE uses the default revision id which is 'org-module' for > > use > > > > in the resolution cache. This leads to collisions when more than > > eclipse > > > > project share that revision id and forces the developer to check that > > the > > > > resolved classpaths are correct for their projects and re-resolve them > > if > > > > not. In my case it's not too bad since the classpaths are not > > complicated, > > > > but for > > > > some others it could be a pain. In our automated CI tool we get > > around > > > > this problem since it is possible to specify a custom resolve id (Ivy > > 2.*) > > > > in the ant build.xml file. For my contribution, the IvyDE default > > would be > > > > to not use the extended revision id so that there are no surprising > > entries > > > > for existing users in their resolution cache. You would have to > > explicitly > > > > check if you want to use the extended revision id. > > > > > > > > I understand that I am an unknown commodity to the Apache Ivy team, so > > I > > > > would be more than happy to provide a patch to a core developer so that > > they > > > > can verify the quality and soundness of my code against their working > > > > practices. If they deem my contribution worthy, perhaps I can become a > > > > contributor with commit access to the repository. I would also be more > > than > > > > happy to update the documentation as well to ensure that others achieve > > > > maximum benefit from my contribution. > > > > > > > > Hopefully a developer will reply and give me some guidance. If so, I > > will > > > > keep the correspondence on the development mailing list and post back > > here > > > > if and when the code contribution becomes part of the IvyDE trunk. > > > > > > > > Best regards, > > > > > > > > -J > > > > > > > > > > > > > > > > > >From: Eric Anderson > > > > >To: "ivy-u...@ant.apache.org" > > > > >Sent: Mon, February 8, 2010 6:24:14 PM > > > > >Subject: Re: Will future IvyDE resolve workspace dependencies on the > > > > branch attribute? > > > > > > > > > >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 > > > > >eander...@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 tag. The project in the branch uses the branch > > > > attribute in its module descriptor tag. > > > > >>3. Other eclipse projects may have a dependency on the projects > > > > described in 2. Some depend on the branch project (specified using > > > > branch attribute), others depend on the trunk project > > > > (specified by not using a 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 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 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 . > > > > >>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 org > > > > and module attributes in the module descriptor. > > > > >>1.5 If the 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 . > > > > >>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 > > > > >> > > > > >> > > > > >> > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > > For additional commands, e-mail: dev-h...@ant.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
