On Thu, Jan 15, 2009 at 3:43 PM, Wayne Fay <[email protected]> wrote:
> > For now I've worked around the issue by using the applicationXml > > configuration to point to my own application.xml with the context-root > being > > set, instead of using the generated one. I'd still like to know if this > is > > just broken for everyone, or if there's something I'm missing so I can > > decide how to file a bug. > > Take a look at the source code: > > http://svn.apache.org/viewvc/maven/plugins/trunk/maven-ear-plugin/src/main/java/org/apache/maven/plugin/ear/WebModule.java?revision=728546&view=markup > > If I were you, I'd debug that class/method in an IDE or add some > System.out's to see what's going on during the execution of the code. > (This assumes you pull down the entire plugin and rebuild it with a > new version eg 2.3.99 which you'd build and install locally, and then > specify it in your pom.xml file -- make sure you delete it later!) > Without doing that, I'm not sure if there's a bug here or not. > > Wayne > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > I don't see anything in the source code that looks like it gets the contextRoot from the configuration. The one method that mentions it 1) checks for null, and then sets it to the default if it's still null, even though the constructor initializes it the default, 2) that method (resolveArtifact) is never called. I don't really understand how nested configuration elements like this are supposed to be set. I'd be willing to try to debug the issue further if I knew where to start. -- Stephen Duncan Jr www.stephenduncanjr.com
