This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | [68cat] Add Maven dependency window does nothing to POM.XML | ||
---|---|---|---|
Product: | projects | Reporter: | rdelaplante <rdelaplante> |
Component: | Maven | Assignee: | Antonin Nebuzelsky <anebuzelsky> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | alexpetrov, anebuzelsky, danielharvey, denbo, dsimonek, hmichel, mkleint, mmirilovic |
Priority: | P1 | ||
Version: | 6.x | ||
Hardware: | Sun | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | IDE log |
Description
rdelaplante
2009-06-02 15:57:55 UTC
it seems to work for me on a sample project. The pom editing backend (based on a netbeans XAM api) is however somewhat shaky, a previous error could cause the editor updates to fail within the same IDE session (unfortunately the models are cached within XAM and once broken, stay around). 1. does restarting the IDE help? 2. can you attach the messages.log file to the issue? 3. any prior steps performed? 4. maybe related to the soupui module you have installed (guessing by the other bug report you filed?) *** Issue 166415 has been marked as a duplicate of this issue. *** I uninstalled SoapUI as suggested by #166428 and problem solved. Thanks closing as wontfix then, the issue shall be filed against the soupUI codebase I'm now using NetBeans 6.7 FCS without SoapUI or JasperReports installed. I open my project's pom.xml, put the cursor after <dependencies> then press alt-insert. I search for an artifact that is installed in my local repo only, select the version, and see that the text boxes are filled in above. I press OK, and the window closes. The POM xml editor window scrolls down and places the cursor just before the </dependencies>, but the dependency I just selected was not added into my pom. anything in the IDE log file? steps to reproduce? I've removed a wrong line (which shoudl not harm anything though) and added some more logging. http://hg.netbeans.org/main/rev/62088a01435a Integrated into 'main-golden', will be available in build *200907141401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/62088a01435a User: Milos Kleint <mkleint@netbeans.org> Log: #166414 add more logging and remove wrong call to endTransaction I tried adding a dependency on an artifact that exists only in my local repository (might not matter).. and it worked. It added the dependency just before the </dependencies> even though I had the cursor just after the opening <dependency> when I pressed alt-insert. I pressed ctrl-z to undo and what I saw was confusing.. it looked like major sections of my POM were being removed so I closed the editor and did not save. Sorry I don't remember much detail, I was in a bit of a panic when it was hapening. Next I re-opened and tried to insert the dependency again. It worked. I then manually deleted the dependency and saved. Then I tried to insert it again, and this time it behaved like before. It put the cursor just before the </dependencies> but did not insert the dependency. I tried a few more times and it did not insert the dependency. Next I tried inserting a dependency from the central maven repo (commons-beanutils ?). It did not insert the dependency, and it moved the cursor about 5-10 lines down into the plugins section as if it thought it had inserted some text into the editor. Created attachment 84736 [details]
IDE log
Steps to reproduce: 1) Open a pom.xml file, place the cursor just before </dependency> and press alt-insert. Select "Dependency..." and press enter. 2) Add any dependency, such as ehcache and press OK. The dependency should be added to your pom.xml now. 3) Press save, then close the pom.xml editor. 4) Re-open the pom.xml file, then repeat the steps but select a different dependency. This time it will not insert it into the pom.xml, but will move the cursor down a bunch of lines as if it did insert some new lines. it seems the model gets written correctly (if you look in the navigator's pom model view, it will contain the 2nd dependency entry. Just the swing document won't. reassigning to xml/xam, please evaluate i'm not sure what I could be possibly doing wrong, it looks like a bug in model->document synchronization. The maven code in question is at main/maven.grammar/src/org/netbeans/modules/maven/codegen/DependencyGenerator.java issue #168281 could also be related to this problem *** Issue 173643 has been marked as a duplicate of this issue. *** For me, the situation (Issue 173643) deteriorates as I execute more and more actions on the dependency tree. In my setup, I have <dependency> <groupId>org.jboss.jbossas</groupId> <artifactId>jboss-as-client</artifactId> <type>pom</type> <version>5.1.0.GA</version> <scope>compile</scope> </dependency> from <repository> <id>jboss</id> <name>jboss.org repository</name> <url>http://repository.jboss.org/maven2/</url> <layout>default</layout> </repository> which pulls a large number of dependent artifacts (~170). When I exclude one of these dependent jars, this works well the first time but as I go and exclude more and more, it takes longer for the <exclude> entries to appear in the POM. After about 5..10 excludes it doesn't seem to work any more at all. Therefore, from my point of view, this looks like a performance issue. I see this problem in 6.8M2, this time with a compact Maven web application. I just faced another issue which seems related. After excluding a few dependencies from the setup described in (denbo Tue Oct 6 10:41:30 +0000 2009) my pom.xml at some point I cannot exclude more dependencies. The pom is marked unsaved but when I try to save it manually it does not work (it just remains unsaved). What worries me most is that when I close this unsaved file, NB does not warn me. It simply closes the file and discards the changes. *** Issue 173457 has been marked as a duplicate of this issue. *** The issue was also reported by NetCAT 6.8 participants. Reassign back to maven. slunegov: and ... ? what is the reasoning for reassignment? if it's the ComponentUpdater stuff we discussed offline (or anything else you believe is causing it), please note it here so that we have a good resolution track on the issue. Noone will remember anything when the issue gets reopened a year from now.. thanks reporters: please try out the latest dev builds of 6.8, the issue might have been resolved in trunk. Hi Milos. Below some notes about how XDM/XAM works. I suppose they can be useful for your team. There are two models 1) XDM is low level model and it is very close to the sources level. And even more, I suppose it will be correct enough to say that XDM is sources... parsed sources. 2) XAM is high level model. It allows to work with XML document it terms of "knowledge domain". XDM is base model, XAM is derived. XAM wraps XDM. Therefore synchronization of models is required. How it works: 1) When you change XAM, XDM is changed in the same time 2) When XDM is changed, XAM is synchronized with XDM by ComponentUpdater. When somebody changes sources of XML document, XDM model is changed first. Than sychronization process is ran and XAM model is updated and ComponentUpdater is used here. Please note that synchronization process is ran when user changes sources code in editor and when undo, redo or rollback happens. Undo, redo works on XDM not on XAM. e.g. If you remove some element in XAM and than invoke undo action, new XAM element object will be instantiated and put on place of removed XAM element. As I understand ComponentUpdater allows to provide custom processing of adding and removing elements in XAM during synchronization process. Why there is no default ComponentUpdater for cases, when custom processing is not needed? I don't know. May be the reason is same as in case of visitor pattern: sometimes it is definitely bad approach to have default visitor implementation with empty methods. Just know that is does not exist, that it should be implemented, and that we never developed XAM/XDM, we just use them and fix critical for SOA modules issues. Bugs in ComponentUpdater is typical cause of XAM-XDM synchronization problems, just remember this and when you see that synchronization is broken look for problems in ComponentUpdater first. One more moment is usage of startTransaction/endTransaction(rollbackTransaction) methods. These methods are intended to group couple of changes, than grouped changed can be rolled back (undo) and forward (redo) together. I suppose that access to XAM/XDM by another threads is blocked when transaction is started. So it is definitely bad idea to start transaction when user opens some wizard or dialog, and finish/rollback transaction when user closes wizard or dialog. Transaction should be as quick as it is possible. let's assume now that the issue is fixed in trunk trunk by me fixing the ComponentUpdater v. I just reproduced this bug in NetBeans 6.8 RC2. 1) I opened a pom.xml file then pressed alt-insert to access the Add Dependency window. 2) I added a dependency to the Spring framework. 3) I repeated that step and added a dependency to Hibernate. 4) I pressed the save button and closed the pom.xml editor 5) I re-opened the pom.xml editor and repeated the steps to add new dependencies. When I press OK in the add dependency editor, the cursor in the pom.xml editor moved down a couple lines or so, but no new lines were added. I tried again a second time with the same result. Also, I noticed the editor window did not register that it was changed. I'm using OpenSolaris 2009 06 with JDK 1.6 update 13. Jaro, can you reproduce with the provided steps? Yes, finally I can reproduce, 100%, exactly using steps from rdelaplante. I have further observations: - Step 3) from rdelaplante can be omitted and the bug is still 100% reproducible - bug is reproducible with any artifact being added as dependency, not only example ones - when we add step 6 below to the rdelaplante's steps, we will get IllegalArgumentException: 6) Close pom.xml once more, reopen it and repeat the steps to add new dependency, then following IllegalArgumentException appears: java.lang.IllegalArgumentException: bad position: 930 at javax.swing.text.JTextComponent.setCaretPosition(JTextComponent.java:1650) at org.netbeans.modules.maven.codegen.DependencyGenerator.invoke(DependencyGenerator.java:145) at org.netbeans.modules.editor.codegen.GenerateCodePanel.invokeSelected(GenerateCodePanel.java:159) at org.netbeans.modules.editor.codegen.GenerateCodePanel.listKeyReleased(GenerateCodePanel.java:128) at org.netbeans.modules.editor.codegen.GenerateCodePanel.access$100(GenerateCodePanel.java:60) at org.netbeans.modules.editor.codegen.GenerateCodePanel$2.keyReleased(GenerateCodePanel.java:103) at java.awt.AWTEventMulticaster.keyReleased(AWTEventMulticaster.java:243) at java.awt.Component.processKeyEvent(Component.java:6224) at javax.swing.JComponent.processKeyEvent(JComponent.java:2817) at java.awt.Component.processEvent(Component.java:6040) at java.awt.Container.processEvent(Container.java:2041) at java.awt.Component.dispatchEventImpl(Component.java:4630) at java.awt.Container.dispatchEventImpl(Container.java:2099) at java.awt.Component.dispatchEvent(Component.java:4460) at java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1848) at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusManager.java:704) at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:969) at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:841) at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:668) at java.awt.Component.dispatchEventImpl(Component.java:4502) at java.awt.Container.dispatchEventImpl(Container.java:2099) at java.awt.Window.dispatchEventImpl(Window.java:2475) at java.awt.Component.dispatchEvent(Component.java:4460) [catch] at java.awt.EventQueue.dispatchEvent(EventQueue.java:599) at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:125) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161) at java.awt.EventDispatchThread.run(EventDispatchThread.java:122) ------ Unfortunately this bug has really huge impact once it appears, as only IDE restart will help. Until IDE restart, no pom generation feature works (add plugin, add profile, graph fixing etc.) David Simonek, Which version of NetBeans do you use to reproduce the bug? engineer, please provide changeset of fix. To Vladimir: I used 6.8 version, daily dev build - but I'm almost sure it will be reproducible on recent builds as well. Yes, it's being reproduced on the daily trunk build. XML folks, please note the following observation... After playing with the last mentioned reproducible case (add dep, save, close, reopen, add deps -> IAE) I found out that: * each time the document is reopened in editor, TextEditorSupport creates a new instance of NbEditorDocument for the new opened editor * both ModelSource and AbstractDocumentModel(in this case POMModel) keep a reference to NbEditorDocument * models (in this case POMModel) are cached by AbstractModelFactory.getModel() and when the pom.xml editor is opened the second time, getModel() does not create a new Model for the ModelSource but returns the old model which references the old NbEditorDocument thus operations on the model do correctly modify the model, but the changes are not synced into the document opened in new editor and e.g. the bad position exception is raised when setting caret to a new position based on the updated model in the nonupdated document. I don't know why the models are cached by XAM if they refer to an old document which is closed anyway and cannot be reused next time. Rather a new model should be allowed each time the file is opened with a new NbEditorDocument. I tried disabling the model caching completely in AbstractModelFactory.getModel() and it fixed this bug for me. xml.xam/src/org/netbeans/modules/xml/xam/AbstractModelFactory.java, line 141: - cachedModels.put(key, new WeakReference<M>(model)); +// cachedModels.put(key, new WeakReference<M>(model)); Hi Tonda, thanks for investigation. We'll look at this more -- need to understand why it happens in maven and doesn't happen in other projects. Gays, this is definitely bad idea to disable caches. The problem is in your implementation of getModelSource(...) method. I know, that you saw reference implementation of this method in org.netbeans.modules.xml.retriever.catalog.Utilities, you can see there that it uses Lookups.proxy(Lookup.Provider ...) method to create lookup which "Creates a lookup that delegates to another one but that one can change from time to time. The returned lookup checks every time somebody calls lookup or lookupItem method whether the provider still returns the same lookup. If not, _it_updates_state_ of all Lookup.Results that it created (and that still exists)." Document extracted from this lookup is always up to date. You use another lookup which always returns document which was put in lookup during lookup creation. So to fix problem implement org.netbeans.modules.maven.model.Utilities.createModelSource(FileObject thisFileObj) method in correct way, or use reference implementation from xml.retriever module. Thanks Alexey I am sorry, this is just misprint, of course I meant Guys. That was hilarious :) Alexey, thanks for the hint. The following change fixes the bug for me. core-main #9909a2f2e55d Integrated into 'main-golden', will be available in build *201002120200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/9909a2f2e55d User: Tonda Nebuzelsky <anebuzelsky@netbeans.org> Log: #166414: Add Maven dependency window does nothing to POM.XML Agreed, this should go into patch if possible. And btw thanks for fixing... Note that the fix revealed another problem, filed as issue #180773, and when backporting to a 6.8 patch, also fix of #180773 needs to be backported. v. |