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.

Bug 199255 - make setting maven2 webapp context name deterministic
Summary: make setting maven2 webapp context name deterministic
Status: RESOLVED DUPLICATE of bug 199478
Alias: None
Product: javaee
Classification: Unclassified
Component: Maven (show other bugs)
Version: 7.1
Hardware: PC Linux
: P2 normal (vote)
Assignee: David Konecny
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-08 09:14 UTC by kawazu428
Modified: 2011-06-16 22:39 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description kawazu428 2011-06-08 09:14:26 UTC
Using current nightly builds to work with NetBeans-created maven2/javaee6 webapps, running them in a local Glassfish instance through the IDE (using the "Run" feature). At the moment, again and again I feel unable to easily set the application specific context path. There are some places in which I would set it:

- Project properties - "Run" - "Context Path". This seems IDE specific and dealing with how the IDE behaves when running a maven2 project on a registered server?

- Using <finalName> in the maven2 build properties, assuming this will result in a <finalName>.war which, unless otherwise configured, will be deployed / run on an application server just using <finalName> as application name / context path.

- Messing with settings in (sun-)web.xml to set context/application name or path. I am not sure how this relates to running a maven2 project from within the IDE.

At the moment, I more or less randomly messed with all of these settings in no particular order, just to experience my webapps again and again got started using

/<groupid>-<artifactid>-<packaging>-<version>

as context path, no matter how I configured project properties or any of the other settings outlined above. In some situations, restarting the IDE seems to change this, in some situations it seems to behave different if I do not always just "run" the project but do a "clean and build" once in a while in between - it overally seems highly non-deterministic. Desired outcome, in this case, would be to set Context Path in Project Properties and be sure that, as long as running from inside the IDE / a registered app server, this is the very context path the application actually makes use of.
Comment 1 David Konecny 2011-06-08 20:24:59 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?
Comment 2 kawazu428 2011-06-09 06:08:00 UTC
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
Comment 3 kawazu428 2011-06-10 06:54:48 UTC
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?
Comment 4 kawazu428 2011-06-10 06:59:40 UTC
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/?
Comment 5 David Konecny 2011-06-15 01:36:51 UTC
(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.
Comment 6 David Konecny 2011-06-16 22:39:17 UTC
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 ***