Bug 427762 - m2e makes Eclipse useless while dependency are downloaded -> smarter import required
Summary: m2e makes Eclipse useless while dependency are downloaded -> smarter import r...
Status: CLOSED WONTFIX
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: m2e (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 major with 2 votes (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords: bugday, helpwanted
Depends on:
Blocks:
 
Reported: 2014-02-10 00:21 EST by Paul Verest CLA
Modified: 2021-04-19 13:23 EDT (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Verest CLA 2014-02-10 00:21:33 EST
From time to time I (or any user) needs to import maven project into Eclipse IDE. When project is new for this PC, m2e needs to download dependencies.
However while dependencies are downloaded Eclipse is useless: the project is in unusable state (Eclipse can't be used as viewer), any other operation will be blocked (waiting for user operation to finish). The only thing to do is to wait all this unknown time (Eclipse just reports 94% completed, and that figure stays so during all downloads)

There should be some stage in maven project import when all files are brows-able (without validation of course) and dependencies downloads should go on in separate process. Not all users enjoy quick and reliable access to maven Central, 
and is some cases it maybe 10-20 minutes.

Yes of course, one solution is to use `mvn` command to build outside of Eclipse.
But that is so cumbersome: clone, build, then import in Eclipse. Most users would prefer just do it in one operation, but that makes user wait 2-5 minutes, unable to do anything else without risk of making Eclipse unresponsive.
Comment 1 Igor Fedorenko CLA 2014-02-10 07:36:32 EST
Only user operations that modify workspace, like file save, are supposed to block during project import or build. If read-only operations block, I will need to see an example project and exact steps to reproduce the problem.

It should be possible to split m2e import operation in two "chained" operations. First just creates general workspace project(s) without any natures or configurations. Second will essentially run project configuration update without any workspace locks until very last moment. Most likely the second operation will need to collect all resolved MavenProject instances first, then do actual configuration update.

This will only improve m2e responsiveness during project import and does not help with project build and configuration update. For example, workspace build will take the same 10-20 minutes after local repository is deleted and the workspace will be unavailable for modifications during entire build.

So another approach is to rework Platform/Resources locking to allow any user operations, including operations that modify workspace, while project import or build is running. Although this is much bigger and riskier change, personally I think this is preferable solution as it solves one of fundamental Eclipse limitations and makes Eclipse better development platform overall.

Having said that, I have no immediate plans to work on either of the suggested solutions unless a quality patch is provided (via Gerrit).
Comment 2 Eclipse Genie CLA 2015-02-11 07:14:40 EST
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 3 Paul Verest CLA 2015-02-11 10:50:31 EST
Well, That is case when network is slow.

To reproduce you should throttle your Internet connection to a speed that would make downloading last for several minutes. 

The real worlds scenario is looking at some open-source project first time.

Because of this issue I don't import Eclipse project with tycho as Maven projects.
Comment 4 Meng Xin Zhu CLA 2015-05-21 08:09:25 EDT
I'm suffering a very annoying behavior.

There is a Gradle project already in my workspace. Then I import an existing Maven project into the same workspace. The m2e starts to resolve the maven project and download the necessary dependencies from remote repo.

At the same time I modify the existing build.gradle in my Gradle based project and save the modification. The save change is blocked by the long run maven downloading(it might be quite long due to the network unstable).

Blocking the saving operation in other projects really does not make sense for end user.

(In reply to Igor Fedorenko from comment #1)
> Only user operations that modify workspace, like file save, are supposed to
> block during project import or build. If read-only operations block, I will
> need to see an example project and exact steps to reproduce the problem.
> 
> It should be possible to split m2e import operation in two "chained"
> operations. First just creates general workspace project(s) without any
> natures or configurations. Second will essentially run project configuration
> update without any workspace locks until very last moment. Most likely the
> second operation will need to collect all resolved MavenProject instances
> first, then do actual configuration update.
> 
> This will only improve m2e responsiveness during project import and does not
> help with project build and configuration update. For example, workspace
> build will take the same 10-20 minutes after local repository is deleted and
> the workspace will be unavailable for modifications during entire build.
> 
> So another approach is to rework Platform/Resources locking to allow any
> user operations, including operations that modify workspace, while project
> import or build is running. Although this is much bigger and riskier change,
> personally I think this is preferable solution as it solves one of
> fundamental Eclipse limitations and makes Eclipse better development
> platform overall.
> 
> Having said that, I have no immediate plans to work on either of the
> suggested solutions unless a quality patch is provided (via Gerrit).
Comment 5 Mickael Istria CLA 2015-08-31 11:17:26 EDT
While working on an alternative import strategy, I also suffered from this issue: the workpsace is locked by the UpdateMavenProjectJob, that mostly performs non-workpsace operations such as downloading dependencies. As a consequence, import of other projects or other workspace operations, which have higher priority for good usage, are stuck for minutes.

This Job should be refactored to only take a workspace lock while it's changing resources, not when it's downloading dependencies.

Ref:
* https://wiki.eclipse.org/E4/UI/Smart_Import
* https://issues.jboss.org/browse/JBIDE-20343
Comment 6 Eclipse Genie CLA 2016-08-31 16:38:28 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 7 Mickael Istria CLA 2016-09-01 02:29:21 EDT
@Anton: earlier you mentioned an open ticket about improving dependency resolution to avoid downloading in a WorkspaceJob. Is this this one you referred to? If so, should we reopen it? If not, what is the better one then (we could add a link).
Comment 8 Anton Tanasenko CLA 2016-09-01 03:19:30 EDT
Reopening it means somebody going to fix it. I doubt anyone of us has any time/plans on doing so in the near future.
The problem isn't going anywhere so whenever somebody is annoyed enough to do something about it, this bug could be reopened.
Comment 9 Mickael Istria CLA 2016-09-01 03:44:59 EDT
(In reply to Anton Tanasenko from comment #8)
> Reopening it means somebody going to fix it. I doubt anyone of us has any
> time/plans on doing so in the near future.

Well, we have a different definition of an Open bug: to me open/reopen means that it's a real issue or thing to improved, the problem is still open for consideration.
To show that people have plans, they should assign themselves and/or set a target milestone, that's a bit different.

> The problem isn't going anywhere so whenever somebody is annoyed enough to
> do something about it, this bug could be reopened.

I'm annoyed to enough to hope I'll do something about it one day; does that count?
Comment 10 Anton Tanasenko CLA 2016-09-01 03:50:14 EDT
(In reply to Mickael Istria from comment #9)
> I'm annoyed to enough to hope I'll do something about it one day; does that
> count?

Then please reopen.

The genie mechanism to close everything off after a year of inactivity is to clean up bugs which nobody cares about anymore.
Comment 11 Mickael Istria CLA 2016-09-01 03:56:53 EDT
Ok, thanks.
I'm also raising the priority and adding some "enticing" keywords since interrupting user for a long time is really something we want to (and can) avoid in the IDEs in general.
Comment 12 Igor Fedorenko CLA 2016-09-01 09:42:43 EDT
(In reply to Mickael Istria from comment #9)
> (In reply to Anton Tanasenko from comment #8)
> > Reopening it means somebody going to fix it. I doubt anyone of us has any
> > time/plans on doing so in the near future.
> 
> Well, we have a different definition of an Open bug: to me open/reopen means
> that it's a real issue or thing to improved, the problem is still open for
> consideration.
> To show that people have plans, they should assign themselves and/or set a
> target milestone, that's a bit different.
> 

Not sure who you mean by "we", but m2e project considers "Open" bugs that have a chance of getting fixed/implemented in foreseeable future. Everything else is just noise in bugzilla. If nobody felt motivated enough enough to fix this problem since 2014, the current behaviour clearly good enough and the likelihood this bug will be looked at is next to zero.
Comment 13 Igor Fedorenko CLA 2016-09-01 09:43:52 EDT
(meant to reset Status to NEW so the bug is autoclosed in 12 months)
Comment 14 Eclipse Genie CLA 2018-03-29 02:33:39 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 15 Denis Roy CLA 2021-04-19 13:23:44 EDT
Moved to https://github.com/eclipse-m2e/m2e-core/issues/