IvyDE's workspace resolver taking directory structure into account

[Andrew January <an...@gmail.com>]

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.

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?

Re: IvyDE's workspace resolver taking directory structure into account

[Andrew January <an...@gmail.com>]

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
<ni...@hibnet.org> wrote:

> Le 15 janv. 2014 à 15:37, Andrew January <an...@gmail.com> 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: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org

Re: IvyDE's workspace resolver taking directory structure into account

[Nicolas Lalevée <ni...@hibnet.org>]

Le 15 janv. 2014 à 15:37, Andrew January <an...@gmail.com> 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org