You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Jeffrey Metcalf <je...@yahoo.com> on 2010/02/04 22:46:34 UTC
Will future IvyDE resolve workspace dependencies on the branch attribute?
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
Re: Will future IvyDE resolve workspace dependencies on the branch attribute?
Posted by Jeffrey Metcalf <je...@yahoo.com>.
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 <jk...@gmail.com>
> To: Ant Developers List <de...@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-user@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
> > > > >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 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-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Will future IvyDE resolve workspace dependencies on the branch
attribute?
Posted by Jon Schneider <jk...@gmail.com>.
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 <jeffrey_m_metcalf@yahoo.com
> 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 <jk...@gmail.com>
> > To: Ant Developers List <de...@ant.apache.org>
> > 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-user@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
> > > >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 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-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: Will future IvyDE resolve workspace dependencies on the branch attribute?
Posted by Jeffrey Metcalf <je...@yahoo.com>.
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 <jk...@gmail.com>
> To: Ant Developers List <de...@ant.apache.org>
> 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-user@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
> > >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 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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Will future IvyDE resolve workspace dependencies on the branch
attribute?
Posted by Jon Schneider <jk...@gmail.com>.
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 <jeffrey_m_metcalf@yahoo.com
> 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 <ea...@palantirtech.com>
> >To: "ivy-user@ant.apache.org" <iv...@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
> >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
> >>
> >>
> >>
> >>
> >
>
>
>
Re: Will future IvyDE resolve workspace dependencies on the branch attribute?
Posted by Jeffrey Metcalf <je...@yahoo.com>.
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 <ea...@palantirtech.com>
>To: "ivy-user@ant.apache.org" <iv...@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
>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
>>
>>
>>
>>
>
Re: Will future IvyDE resolve workspace dependencies on the branch attribute?
Posted by Jeffrey Metcalf <je...@yahoo.com>.
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 <ea...@palantirtech.com>
>To: "ivy-user@ant.apache.org" <iv...@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
>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
>>
>>
>>
>>
>
Re: Will future IvyDE resolve workspace dependencies on the branch
attribute?
Posted by Eric Anderson <ea...@palantirtech.com>.
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
>
>
>