Allow the user to control which dependencies can be resolved from the workspace

[marco.madrid]

that's a very good idea.

instead, we think it could be better to disable the workspace
dependencies resolution
by default, what i think is the normal state of a maven project
(that's we expect in
most cases), and if u want to refer to any workspace project, simply
be able to do it
through project configuration.

we have a huge number of dependent projects (sub-projects of a main
project)and, in most cases, we want to test only one of them, instead
of all at the same time, so we prefer to be able to select witch
workspace projects include as dependency and get the others from maven
repository (team synchronized stable versions).

what do u think about it?

[marco.madrid]

More information at Issue 169

[pretonik]

I think marco.madrid gets the point. usually you are working in a
enterprise project
where many developers participate. You don't want to be working with
your local
version of other modules of the project that other developers could
have updated
previously. It's desirable to work with all latest module versions. If
anyone wants
the other functionality, maybe can be selected by a check in project
maven plugin
options, but not as a default behaviour (this can drive into errors)

[Abel Muiño]

My experience is that if you have a project (say PA) in your workspace is because you're working on it.
If any other project (PB) is on your workspace and has a dependency to PA (with the same version!), you'll want to get that version of the source code when compiling PB to avoid problems later (when PA is released and you realize that the changes in PB are not compatible).

Note that, with this setup I'm assuming that PA and PB have "-SNAPSHOT" versions.

If PB depends on PA 1.0, but PA 1.1-SNAPSHOT is on the workspace, it will use the stable, non workspace, 1.0 version.

So, in general... I think that resolving dependencies from the workspace by default is a good idea. Disabling them on demand might be useful in some cases.

I would like to hear use cases for disabling the workspace resolution. I have the impression that the need is is related to an specific development process, so I would like to really understand your needs.

--
Abel Muiño - http://ramblingabout.wordpress.com/

[marco.madrid]

ok, let’s think about it (all based on workspace project resolution):

case 1:
you have PA and PB local projects (PA has a dependency to PB) and you
are developing two non related tasks, one in each project. Only if you
finish the two unrelated task on each project will be able to deploy
any of the project. If you finish PA task but PB is still in
developing state (non stable or compilation errors), simply you cant
deploy PA.
case 2:
you have same PA and PB (with same dependency). You have been working
on a PB task and, suddenly arrives a PA urgent task. You have to stop
PB task to accomplish PA one. And when you try to deploy PA, you cant
because PA "requires" dependent PB to be perfectly compilable,
testable and deployable.

I think that the basic target of maven is the artefact & version
management, but when you are forced to use workspace resolution, you
lose this powerful feature, mostly when you are working in a big
developing team. All of us know maven, have experience working on it,
and use to expect certain behaviours to stay unchanged.

We think that it’s necessary to be able to choose to use or not
workspace resolution feature.

thanks!

On Jun 12, 12:30 pm, "Abel Muiño" <amu...@gmail.com> wrote:
> My experience is that if you have a project (say PA) in your workspace is
> because you're working on it.
> If any other project (PB) is on your workspace and has a dependency to PA
> (with the same version!), you'll want to get that version of the source code
> when compiling PB to avoid problems later (when PA is released and you
> realize that the changes in PB are not compatible).
>
> Note that, with this setup I'm assuming that PA and PB have "-SNAPSHOT"
> versions.
>
> If PB depends on PA 1.0, but PA 1.1-SNAPSHOT is on the workspace, it will
> use the stable, non workspace, 1.0 version.
>
> So, in general... I think that resolving dependencies from the workspace by
> default is a good idea. Disabling them on demand might be useful in some
> cases.
>
> I would like to hear use cases for disabling the workspace resolution. I
> have the impression that the need is is related to an specific development
> process, so I would like to really understand your needs.
>

> On Thu, Jun 12, 2008 at 12:13 PM, pretonik <julio.munoz.galla...@gmail.com>

[pretonik]

totally agree with last post. this samples are similars to mine

[lord]

yes, I think that is one of the most important feature to include in
next version, we have same problems and have to close dependent
projects to be able to deploy (really tedious and unnecessary step) .

[Abel Muiño Vizcaino]

Thanks for the quick reply!

I agree that allowing to disable workspace resolution can be useful. My main concern was about if that's a good default.

The two cases you list are good examples and have helped in understanding your use cases. However, those are "exceptional" and not part of a typical workflow (more like interruptions of it). 

As you know, there's currently the workaround of closing the project to avoid resolving it from the workspace (which would be similar to disabling workspace resolution, and probably faster -i.e. less mouse clicks needed-).

I still think that the problem should be addressed by appropriate versioning and maybe tagging/branching for maintenance. My team recently addressed a situation like the one described on case 2. The situation was:

PA 1.0 was released and in production (tagged in svn as TAG_PA_10)

PB 1.0 was also released and in production (tagged in svn as TAG_PB_10)

Current development was against PA 1.1-SNAPSHOT and PB 1.1-SNAPSHOT

New change request against the production version of PA

Create a branch BRANCH_PA_10 from TAG_PA_10

Check out BRANCH_PA_10

Apply the change request on BRANCH_PA_10

Tag and release PA 1.0.1

Merge change in trunk (PA 1.1-SNAPSHOT)

This allows working with projects open on the workspace (since the development and maintenance artifact versions are different) and, at the same time, fix urgent problems on released versions (without releasing changes already done and that should only go in the next version).

Maybe something similar can also work for you?

In any case, we agree that the user must be on charge and control wether Workspace resolution should be enabled or not.

--

Abel Muiño Vizcaino - http://ramblingabout.wordpress.com

[marco.madrid]

thanks for your reply.

the root of our problems could be that we are now in the project
startup phase, so we don't have released artifacts, but we alwais work
with snapshots versions.

but I like to be agree with you about including workspace resolving
enable/disable configuration.

so the next ask is, when do you plan to include this feature? (we hope
to be early :)

thanks a lot Abel

> Abel Muiño Vizcaino -http://ramblingabout.wordpress.com

[Abel Muiño]

Disabling maven artifact resolution could be added quite fast (a general preference and updating the artifact resolver).

Locating other spots where the code is assuming that workspace resolution is in place and setting up a different strategy might a bit more of work (Classpath container, cascade updates, etc...).

The best way to have it resolved soon is to contribute a patch, of course :-).
Other than that, it will help if you could checkout q4e and run it from trunk and help in debugging and tracing this as we make any changes.

[Erle Mantos]

My question on this would be

Should this be granular ? Should we be able to control whether it is
resolved on the
workspace or local repository for EVERY dependency ? Or do we have
just a single
preference wherein we indicate if all dependencies are resolved from
the workspace
or from the local repository ?

On Jun 13, 6:22 pm, "Abel Muiño" <amu...@gmail.com> wrote:
> Disabling maven artifact resolution could be added quite fast (a general
> preference and updating the artifact resolver).
>
> Locating other spots where the code is assuming that workspace resolution is
> in place and setting up a different strategy might a bit more of work
> (Classpath container, cascade updates, etc...).
>
> The best way to have it resolved soon is to contribute a patch, of course
> :-).
> Other than that, it will help if you could checkout q4e and run it from
> trunk and help in debugging and tracing this as we make any changes.
>

> On Fri, Jun 13, 2008 at 12:03 PM, marco.madrid <marco.mad...@gmail.com>

[Abel Muiño]

As a first step, I would go towards an all-or-nothing approach.

However, I think there's very little added value in q4e if it only enables dependency management for installed artifacts (essentially, that's what mvn eclipse:eclipse does).