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: | make setting maven2 webapp context name deterministic | ||
---|---|---|---|
Product: | javaee | Reporter: | kawazu428 <kawazu428> |
Component: | Maven | Assignee: | David Konecny <dkonecny> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | pjiricka |
Priority: | P2 | ||
Version: | 7.1 | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
kawazu428
2011-06-08 09:14:26 UTC
What NB version are you referring to? In latest dev build which should be very similar to NB7.0 I tried this: * create new Maven Web Project and open Project Props - Run: Context Path field is disabled and says that server must be selected first. That's correct because Web Context is not stored in web.xml but in server specific deployment file (in GlassFish's case it is sun-web.xml or glassfish-web.xml)(not 100% sure about filenaming). * I set the server to GF (in the same Run panel) and Context Path is enabled with default value like "/mavenproject101-1.0-SNAPSHOT". I close props and run the project (right click project node and Run action) and I can see that app is opened at "/mavenproject101-1.0-SNAPSHOT/" * I open proj props again and change the value in Run Panel to "/something" and confirm and rerun project and it is opened at "/something/" Does this works for you? Well, yes, that's more or less what I would expect to happen, yet it doesn't work like this here. Did everything just like you outlined - setting target server, assigning Context Path, "run"ning the app - and still seeing the app deployed to listen at /<groupId>-<artifactId>-<packaging>-<version> . There also aren't any server-specific DDs around (neither sun- nor glassfish-web.xml). Doing manual (un)deployment from/to the local server also didn't change much. Asides this, however, my second thought on this is whether or not there is a way of unifying this configuration parameter within maven2 projects as there is quite a bunch of different ways on how to set the context path effective as soon as the application gets deployed to some server. Shouldn't be <build> -> <finalName> be the ultimate source of configuration in a pom- based development approach? I am not sure here, yet at the moment it feels somewhat inconvenient. Build info at the moment (trying to update to recent nightlies more or less regularly): Product Version: NetBeans IDE Dev (Build 201105160400) Java: 1.6.0_25; Java HotSpot(TM) Client VM 20.0-b11 System: Linux version 2.6.38-8-generic running on i386; UTF-8; de_DE (nb) Userdir: /home/kr/.netbeans/7.0m2 On a closer look things are interesting: - It seems that, while setting "Context Path" in project properties, nothing happens if no sun-web.xml is present. - If sun-web.xml is present (it appears to have been created automatically yesterday in course of adding JMS stuff to my app), it will be changed when setting Context Path in project properties. Also noticed this seeing the SVN managed file turned "blue" (changed locally) - However, as soon as I do a "clean and build" on the project, the sun-web.xml is "black" again (unchanged locally), and the Context Path I introduced earlier is removed again. Why? I assume this is not the way it should be, is it? I actually can _watch_ this process having sun-web.xml opened while "clean and build"'ing the project - at a sudden point after build has completed, the <context-root> tag has been removed again, plus the file itself looks different in terms of code formatting. Is sun-web.xml automatically generated out of other parameters and configuration options? If so, out of which one? Considering this a DEFECT, should maven clean/build actually mess with any user-modified files in src/main/? (In reply to comment #4) > Considering this a DEFECT, should maven clean/build actually mess with any > user-modified files in src/main/? It depends on what is in your pom.xml - it is Maven who is running the build. Not NetBeans. Could you attach please very simple project on which I could reproduce the problem? Also try it without your versioning control system - likely culprit. I know think that this is a NetBeans issue and it does not depend on VCS etc. *** This bug has been marked as a duplicate of bug 199478 *** |