ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Metcalf <jeffrey_m_metc...@yahoo.com>
Subject Re: Will future IvyDE resolve workspace dependencies on the branch attribute?
Date Tue, 09 Feb 2010 14:55:16 GMT
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 <eanderson@palantirtech.com>
>To: "ivy-user@ant.apache.org" <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
<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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message