Bugzilla – Full Text Bug Listing
| Summary: | After refreshing Eclipse workspace (F5) opened POM files are marked as dirty. | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Alex Pogrebnyak <alex-pub.eclipse> |
| Component: | m2e | Assignee: | Project Inbox <m2e.core-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | atg.sleepless, igor, matthias.schmalz, robert.munteanu, t-oberlies |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Alex Pogrebnyak
I have the same issue when using Git and switching between branches, with different versions of opened pom files. Those editors are marked dirty, which is annoying. I am using m2e 1.4.0.20130601-0317. 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. Please reopen this bug as it still occurs even with Luna. (In reply to Matthias Schmalz from comment #3) > Please reopen this bug as it still occurs even with Luna. Do you plan to provide a patch in near future? Otherwise, keeping open bugziila noone's going to work on seems rather pointless. Why is nobody working on this? Is the project dead? I'm not a committer here, just hoped to get a fix for this. (In reply to Matthias Schmalz from comment #5) > Why is nobody working on this? Is the project dead? I'm not a committer > here, just hoped to get a fix for this. If this problem is important to you, I suggest you contribute a patch and I'll try my best to review and apply it in timely fashion. Wiki [1] provides information about setting up m2e development environment and patch requirements. You can use m2e git stats [2] and user and dev mailing list activities to decide if you consider the project dead or not. [1] https://wiki.eclipse.org/M2E_Development_Environment [2] http://git.eclipse.org/c/m2e/m2e-core.git/stats/?period=m&ofs=10 WONTFIX means that a project doesn't want a particular problem to be addressed. So WONTFIX and "please provide a patch" doesn't make sense. The project needs to say if it is interested in providing editors that correctly react to resource changes. If the answer is yes, then there is currently a bug that - like all bugs - may be addressed as resources permit. @Tobias does this mean you plan to contribute a patch in a near future? In general, though, in m2e WONTFIX means "this is indeed a problem but there are no plans to fix it", which I think perfectly applies to bugs that sat idle for for over 12 months without any indication that a fix is being worked on. (In reply to comment #8) > In general, though, in m2e WONTFIX means "this is indeed a problem but there are > no plans to fix it", which I think perfectly applies to bugs that sat idle for > for over 12 months without any indication that a fix is being worked on. Well, but this is not the way it appears to most bugzilla users. To me, setting a bug on "WONTFIX" rather appears as a way to gauge the importance of a bug for the community. Not my style, but okay for projects which are keen on keeping their issue tracker clean without spending much effort. So, since you have now found out that this issue is still important to the community, and it has been verified as still being a problem, it can stay open now until it is either fixed or another year passes, right? Took a quick glance at the code and it seems that MavenPomEditor uses UndoManager's command stack to decide about its dirty state. Code dates back to sonatype days, so there's no history, but I'd guess updating it to use sourcePage's isDirty (as is done in wst.xml editor) should probably do the trick. (In reply to Tobias Oberlies from comment #9) > (In reply to comment #8) > > In general, though, in m2e WONTFIX means "this is indeed a problem but there are > > no plans to fix it", which I think perfectly applies to bugs that sat idle for > > for over 12 months without any indication that a fix is being worked on. > > Well, but this is not the way it appears to most bugzilla users. To me, > setting a bug on "WONTFIX" rather appears as a way to gauge the importance > of a bug for the community. Not my style, but okay for projects which are > keen on keeping their issue tracker clean without spending much effort. > > So, since you have now found out that this issue is still important to the > community, and it has been verified as still being a problem, it can stay > open now until it is either fixed or another year passes, right? To me, no fix in 3 years very much means this is not important enough to anybody to actually do anything about it. I prefer to be honest and tell m2e users not to expect a fix in cases like this. (In reply to Igor Fedorenko from comment #11) > To me, no fix in 3 years very much means this is not important enough to > anybody to actually do anything about it. I prefer to be honest and tell m2e > users not to expect a fix in cases like this. Sorry, we are not mind readers and do not know that you changed your development policies to Do-It-Yourself. When I submit a bug to the project maintainer I expect the said maintainer at least acknowledge it and assign a priority. Not having any notes from the maintainer for 3 years and then closing the bug out of the blue, does not strike me as an effective triage process. Yes, I agree, leaving bugs open for years without any action is not helping anybody. This is why I am trying to be more proactive and close the bugs that went stale. (In reply to Igor Fedorenko from comment #13) > Yes, I agree, leaving bugs open for years without any action is not helping > anybody. This is why I am trying to be more proactive and close the bugs > that went stale. Thank you, Igor! I now get your point. In that case could you please at least state why you rate this issue to be that unimportant, that nobody cares about it? It is really anoying to get dirty editors every time I switch my Git branch and from Anton's reply above, it seams to be not that complicated to fix. (In reply to Matthias Schmalz from comment #15) > In that case could you please at least state why you rate this issue to be > that unimportant, that nobody cares about it? > It is really anoying to get dirty editors every time I switch my Git branch > and from Anton's reply above, it seams to be not that complicated to fix. If this bug was important, it would be fixed by now. Or at least there would be a patch attached here waiting for a review. Since nobody provided a patch in such a long time, especially given the fix does not look complicated, the problem is not important enough to anybody to do anything about it. I said it _looks_ easy. One has to be motivated enough to fix something, and most of us have much to do besides that, right? We probably spend more time arguing about the status of the bug than it might take to fix it. Igor, can you take a quick look, I'm not entirely sure that the things I removed weren't used for something else. https://git.eclipse.org/r/33521 (In reply to Anton Tanasenko from comment #10) > Took a quick glance at the code and it seems that MavenPomEditor uses > UndoManager's command stack to decide about its dirty state. > Code dates back to sonatype days, so there's no history, but I'd guess > updating it to use sourcePage's isDirty (as is done in wst.xml editor) > should probably do the trick. If you want to see the history of this code, it is still available in https://github.com/tesla/m2e-core-tests. MoveToEclipse tag corresponds to the first comment at eclipse git repo, iirc. (In reply to Anton Tanasenko from comment #18) > Igor, can you take a quick look, I'm not entirely sure that the things I > removed weren't used for something else. > > https://git.eclipse.org/r/33521 Not trying to give you a hard time, but I think we need a regression test to make sure this problem does not come back in the future. (In reply to Igor Fedorenko from comment #19) > If you want to see the history of this code, it is still available in > https://github.com/tesla/m2e-core-tests. MoveToEclipse tag corresponds to > the first comment at eclipse git repo, iirc. I meant m2e-core itself. There might be some insight as to what the undoManager was used for. > > > Not trying to give you a hard time, but I think we need a regression test to > make sure this problem does not come back in the future. Yes, sure. (In reply to Anton Tanasenko from comment #20) > (In reply to Igor Fedorenko from comment #19) > > If you want to see the history of this code, it is still available in > > https://github.com/tesla/m2e-core-tests. MoveToEclipse tag corresponds to > > the first comment at eclipse git repo, iirc. > I meant m2e-core itself. There might be some insight as to what the > undoManager was used for. m2e-core-tests has m2e core history from before the code moved to eclipse. It does not contain history from original codehaus cvs repository, but it should have all commits since the code was moved to sonatype svn. We used to keep entire codebase in one happy source code repository, which included m2e core, core tests and all m2e extensions. As we prepared to move the code to eclipse, we split extensions to a separate repository. We also had to split m2e core and core tests because eclipse IP process was not flexible enough to accommodate the tests. Oh, good, thanks. By the looks of it, undoManager was added for the, surprise, undo functionality back then. Managing dirty state was its another good use. https://github.com/tesla/m2e-core-tests/commit/f177cb34a6d7e54a8ee6abbf9a211881bc48f4a0 Seems safe to remove since editors framework manages it nowadays automatically. Want to keep m2e 1.6 milestone numbers match corresponding mars milestones. Maven 3.2.4 not released for Mars M3. Punting this issue to Mars M4 |