| Re: [m2e-dev] Project refreshes and rebuilds/autobuilds |
Normal "edit pom while refresh is disabled" should already be handled by
Maven builder.
Let me clarify. I think it'd be nice to get rid of background refresh
On 2014-05-03, 17:42, Anton Tanasenko wrote:
I do get the problem with closed/deleted projects. It's just that my
first idea was to only disable (postpone) refreshes on pom changes,
close/delete would've still triggered them as they currently do.
And you already propose turning everything off until build time. Hence
the confusion : )
job but this is not a requirement. If you have a proposal that provides
"don't update project dependencies" behaviour without any side effects,
this will be a good improvement even if background refresh job still
handles edge cases like project delete.Not sure.
Alright, from what I understand, replacement of that job should queue
open/close/delete events as MavenUpdateRequests and fire refreshes prior
to build. File changes would be automatically picked up by builders, but
we can also do that here for consistency.
Normal "edit pom while refresh is disabled" should already be handled by
Maven builder.
"Manual build while refresh is disabled" case can be handled by the same
builder. Actually, now thinking about it, this case is likely already
handled by the builder, i.e. it resolves all dependent projects and
sends appropriate events, so most likely only new unit test is needed here.
As for "delete/close project while refresh is disabled", I am fine
keeping this functionality in the refresh job for now. We can clean this
up later.I think these should stay the same. If a client wants to run dependency
There is also an asynchronous
IMavenProjectRegistry().refresh(MavenUpdateRequest) which promises
refresh to happen right after it is invoked. Callers include 'Update on
workbench start' option, 'Enable workspace resolution' project action,
settings.xml actions on preference page, etc. Some extensions might also
use it. Should it keep behaving the same? Maybe for some actions it
could happen at build time?
resolution, there is no reason m2e should reject this... which I suppose
means background refresh job has to stay. Oh, well, I guess I was wrong
and you were right. Lets go with your original proposal. Just make sure
to add unit tests for the three cases, i.e. "regular pom change",
"manual build after pom change" and "project close/delete".
And to answer your earlier question. m2e tests disabled autobuild to
avoid interference with background builds, not for performance reasons.
This may not be necessary any more, but I still prefer to have more
control over what happens during my tests and async builds introduce too
much volatility.
--
Regards,
Igor
<mailto:igor@xxxxxxxxxxxxxx>> wrote:
On 2014-05-03, 12:43, Anton Tanasenko wrote:
On Sat, May 3, 2014 at 6:13 PM, Igor Fedorenko
<igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx><mailto:igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>>> wrote:
This is the part that might be tricky. Like I said, there
are two
interesting cases, when projects are closed or removed and when
individual projects are built explicitly with workspace
autobuild off.
In both cases, some other projects may be affected and require
resolution and rebuild when autobuild is turned on.
Sorry, I'm confused, I meant to leave the code that handles
those cases
intact. There is actually a third case in there that handles newly
created projects.
I only propose to skip reaction to pom file changes, which will be
reacted upon during next build.
I am not sure not reacting to pom file changes is sufficient, see below.
One way to achieve this is to touch affected projects'
pom.xml files
during resolution. This I believe will create pending
resource change
events that'll trigger build of the corresponding projects when
autobuild is turned on.
There would be nothing to touch in case of a closed project.
Closed projects may affect resolution of other projects. For example, if
project A depends on B and B is closed while autobuild is off, A should
be rebuild when autobuild is turned back on.
Manual rebuild can have the same result. If B/pom.xml changes while
autobuild is off and B is rebuilt manually, A should be rebuilt when
autobuild is turned on. This is where I think your proposal does not
work because workspace change will be "consumed" by manual build.
But I think this is easy to solve. When B is built, m2e should resolve B
and all other projects that depend on B. This is the same as the current
implementation, only without dedicated background job.
So I think closed/removed projects is the only problem left before we
can get rid of background refresh job.
--
Regards,
Igor
Another possibility is to maintain "pending update" queue
somewhere in
m2e and act on these updates when autobuild is turned on.
There is a PRE_BUILD workspace event broadcast prior to every build,
which could trigger refresh of the queued projects.
The listeners part of ProjectRegistryRefreshJob could then
manage that
queue.
But this change will required a more thorough testing.
Talking of which, m2e-core-tests currently run with autobuild
disabled,
there is an explicit call in AbstractMavenProjectTestCase. I
guess this
is for performance reasons.
ProjectRegistryManagerTest would result in a lot of fails in
particular.
There are probably other ways to do this, I am not attached to
particular approach at the moment, as long as the final
solution works
reliably and does not introduce any performance regressions.
If we can figure out how to make this work, however, I
think we will be
able to remove ProjectRegistryRefreshJob and do all
resolution as part
of project build or configuration update.
--
Regards,
Igor
On 2014-05-03, 9:38, Anton Tanasenko wrote:
When autobuild is on, ProjectRegistryRefreshJob doesn't
actually
react
to file changes at all (only to project open/close/delete,
comments at
around line 156 also reflect that), refresh in this
case happens
as part
of MavenBuilder invocation.
If we make the same when autobuild is off, MavenBuilder
(along
with the
refresh) will be invoked as soon as autobuild gets
turned on.
On Sat, May 3, 2014 at 2:28 PM, Igor Fedorenko
<igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>
<mailto:igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>>
<mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx> <mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>>>> wrote:
On 2014-05-03, 5:52, Anton Tanasenko wrote:
And what about your stance on project
refreshes with
autobuild
off? Can
it be some option, that allows projects to become
out-of-date on pom
changes until autobuild is turned back on?
It really depends on how complicated the
implementation
will get. I like
the idea in general, but I think reconciliation of
the out
of sync state
when autobuild is turned on might be tricky. Haven't
thought much about
it though, so maybe I am wrong and there isn't
much to it.
--
Regards,
Igor
_________________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>
https://dev.eclipse.org/__mailman/listinfo/m2e-dev
<https://dev.eclipse.org/mailman/listinfo/m2e-dev>
_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-dev
_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-dev