ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew January" <>
Subject Re: IvyDE's workspace resolver taking directory structure into account
Date Wed, 22 Jan 2014 08:11:43 GMT
util-1 and util-2 are checked out and have the same content.

Then a feature in project-1 requires an api incompatible change in util, so the developer
makes those changes in util-1.

Unfortunately, because of our workflow, those changes might be sitting around uncommitted
on the developers machine while they then need to make unrelated changes to project-2. (For
example, the changes are waiting to be unreviewed, and we can't check in unreviewed code.)

We need to be able to keep working on project-2 and keep building it without it being polluted
by the local changes in util-1

Our ant scripts deal with this by using ivy:buildlist with a fileset of ../**/build.xml and
calling a target that builds and publishes to a file system repository local to the project
which we call the project-group repo. When the next project builds, it picks up the previous
one through the project-group repo.

It would be nice if the workspace resolver could somehow mirror this setup.

We currently have a version that allows you to specify a relative path in the resolver settings
(in our case '..') and the resolver only considers projects that are inside that location.

It would be more preferable to have the setting on the class path container, but that would
require changing to a resolver-per-container model rather than the current resolver-per-project
model. We haven't looked at the plausibility of that yet.

On Wed, Jan 22, 2014 at 12:06 AM, Nicolas Lalevée
<> wrote:

> Le 15 janv. 2014 à 15:37, Andrew January <> a écrit :
>> Has there been any previous discussion around optionally taking directory
>> structure into account in IvyDE's workspace resolver?
>> Our project structure is set up as:
>>    project-1/
>>        project-1
>>        util-1
>>    project-2/
>>        project-2
>>        util-2
>> Where util-1 and util-2 are checked out from the same scm location, and so
>> publish the same revision of the same module.
>> Currently we can use the workspace resolver and close util-2 when working
>> on project-1, and vice-versa.
>> The problem is this can be error prone, and people tend to forget, end up
>> referencing the wrong project and get confused.
> If util-1 and util-2 come from the same scm location, why do you need to switch ? util-1
and util-2 should have the same content, right ?
>> We have been contemplating modifying IvyDE to walk through all projects in
>> the workspace, and pick the one whose location URI is the closest match.
>> We only have a maximum of a dozen projects in a workspace, so it seems like
>> this wouldn't be a huge performance issue.
>> Has this been tried or discussed before? What were the drawbacks?
>> If we were to go ahead and do this, would a patch be considered?
> I would need to understand your use case before going forward. Maybe there is a simpler
solution. I would prefer keep thing as simple as possible.
> As soon as we agree on a solution for your use case, any patch will be welcomed. :)
> Nicolas
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message