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.
if you create a new maven web app File -> New Project -> Maven -> Web Application now run the application, it will ask you if you which server to use, so I select my Glassfish 3.1 server if you look in the project, netbeans has generated a new glassfish-web.xml.. so I change the the context-root to <context-root>/</context-root>.. clean and deploy.. and its back to the default context-root
oh and I am using Product Version: NetBeans IDE Dev (Build 201106120600) due to the deploy on save bug for EAR maven applications in 7.0
Vince, could you please have a look. Sounds very suspicious. It is second report in last few days. Perhaps something to fix in 7.0.1?
*** Bug 199255 has been marked as a duplicate of this bug. ***
I can duplicate the behavior. It looks like the Clean is thing that is overwriting the context-root element. Here are some steps that I used to verify the situation. 1. create a maven web app. 2. assign the app to run on a gf 3.1 server a glassfish-web.xml file is created, since the CR /maveprojectX-1.0-SNAPSHOT does not match the defaultcr that the GF plugin expected for the project /mavenprojectX. I opened issue 199482 to track this. 3. Edit the Context Path property of the project. the value of context-root in the glassfish-web.xml file is updated. 4. edit the value of the context-root element in glassfish-web.xml the property value for Context Path changes, as expected. 5. Clean the project. the value of context-root reverts to the value that was set when the user did step 3... That is a bit unexpected. At this point, the plugin is 'doing what is told to do' by the Maven project code.
Interesting, for a while I was not able to reproduce it and now it is happening all the time. I'm investigating.
Short term workaround is to permanently associate server with project. In such case this should work fine. I fixed some parts of code which were incorrect but I'm experiencing different issues now so I will have to test this more early next week.
This issue has workaround so it is not a show stopper. I have not found fix yet.
Interestingly enough, this still does happen in recent builds even with having the project permanently associated with a given local Java EE server (Glassfish). Adding to that, however: Initially, in the project there is a "sun-web.xml" (Java EE 5 project, reproducible with both the .war artifacts in http://java.net/projects/jersey/downloads/download/s314285_oauth.zip in example), which gets "regenerated" / refreshed / emptied every time I run the application. Tried to rename the file to "glassfish-web.xml", I saw the file itself remains untouched but an empty "sun-web.xml" is generated which seems to contain no meaningful information. Hard to see which of these, in the end, is about to be used by the server. ;)
And another insight I just used to have: Had glassfish-web.xml and pom.xml open in a newly created (next to empty) project: Did set the desired context root in glassfish-web.xml. Saved. Fine. Edited pom.xml. Saved pom.xml. Saw "something happening" in the glassfish-web.xml editor. Switched there, to see the context root reset to /<artifactId>-<artifactVersion>. Funnily enough, I was editing the <buiLd><finalName> property in pom.xml. Not sure whether this is the same problem, just happened to fall into my current struggle of working around this issue. Product Version: NetBeans IDE Dev (Build 201107250600) Java: 1.6.0_25; Java HotSpot(TM) Client VM 20.0-b11 System: Linux version 2.6.38-10-generic running on i386; UTF-8; de_DE (nb) Userdir: /home/kr/.netbeans/7.0m2
Thanks for all the info kawazu428. That does sound like pain. There is something really rotten and I need to find enough time to dive into that and finally solve it. I wrote a BIG note to myself to look into this issue sometimes next week.
*** Bug 200709 has been marked as a duplicate of this bug. ***
I think I finally got it right: 3b18c64ffab0 I did thorough testing but I would appreciate if somebody could download a dev build with this fix (will be available in a day or two) and verify it. Thanks!
Verified in build 201108170601.
integrated into releases repo: db9a1e9fb701, 9c70f18fe87d