ant-dev 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 Fri, 12 Feb 2010 17:02:45 GMT
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 <jkschneider@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-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


Mime
View raw message