Maven 2.x Tomcat Plugin

Change default web context to artifact id for run goals

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 1.0-beta-1
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

Currently the default web context is the artifact's final name which by default is artifactId-version. It'd be better to default to the artifact id instead, as per jetty's plugin.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Olivier Lamy added a comment -

reopen to set fixed version

Show
Olivier Lamy added a comment - reopen to set fixed version
Hide
Permalink
Dennis Lundberg added a comment -

Mark,

Can you explain in more detail why the default value should be artifactId?

If you take the WAR that is produced and deploy it to Tomcat manually, i.e. without using this plugin, the context path for the app will be finalName. IMO it would be intuitive if the Tomcat Plugin would do the same thing.

Show
Dennis Lundberg added a comment - Mark, Can you explain in more detail why the default value should be artifactId? If you take the WAR that is produced and deploy it to Tomcat manually, i.e. without using this plugin, the context path for the app will be finalName. IMO it would be intuitive if the Tomcat Plugin would do the same thing.
Hide
Permalink
Mark Hobson added a comment -

The main reason was to simplify the URL when accessing the webapp. The run goals are typically using during development, so it becomes cumbersome to type 'http://localhost:8080/mywebapp-1.2.12-SNAPSHOT/' for example. It's also easier on the browser history when spanning multiple versions.

Final name wasn't used because when packaging the artifact the version number suffix is often required.

Show
Mark Hobson added a comment - The main reason was to simplify the URL when accessing the webapp. The run goals are typically using during development, so it becomes cumbersome to type 'http://localhost:8080/mywebapp-1.2.12-SNAPSHOT/' for example. It's also easier on the browser history when spanning multiple versions. Final name wasn't used because when packaging the artifact the version number suffix is often required.
Hide
Permalink
Dennis Lundberg added a comment -

I'm not sure I follow you Mark.

1. In my experience finalName is set to something shorter than artifactId. The reason for it being that the URL will be less cumbersome. An example from a multi module build might clarify. ArtifactId for the webapp module is 'mycompany-product-webapp' and finalName is set to 'product'. This make the URL to the webapp during development 'http://development-server:8080/product'. Nice and clean.

2. The problem I have with the change that was made is that it affects all goals, not only the run goals. It affects all deploy goals as well. So in an environment like ours where the production URL never includes the artifactId, but rather finalName, we have to configure the Tomcat Plugin for every webapp to be able to deploy them.

Show
Dennis Lundberg added a comment - I'm not sure I follow you Mark. 1. In my experience finalName is set to something shorter than artifactId. The reason for it being that the URL will be less cumbersome. An example from a multi module build might clarify. ArtifactId for the webapp module is 'mycompany-product-webapp' and finalName is set to 'product'. This make the URL to the webapp during development 'http://development-server:8080/product'. Nice and clean. 2. The problem I have with the change that was made is that it affects all goals, not only the run goals. It affects all deploy goals as well. So in an environment like ours where the production URL never includes the artifactId, but rather finalName, we have to configure the Tomcat Plugin for every webapp to be able to deploy them.
Hide
Permalink
Mark Hobson added a comment -

In my example I was using the default final name, hence the Tomcat path == finalName == artifactId-version.

I understand your scenario though. How about configuring the Tomcat plugin in a parent POM to set the path to a property, say ${tomcatPath}, and then just supplying a value to this property in child POMs?

If you feel strongly about it then perhaps start a vote on the mojo-dev list and see what the consensus is.

Show
Mark Hobson added a comment - In my example I was using the default final name, hence the Tomcat path == finalName == artifactId-version. I understand your scenario though. How about configuring the Tomcat plugin in a parent POM to set the path to a property, say ${tomcatPath}, and then just supplying a value to this property in child POMs? If you feel strongly about it then perhaps start a vote on the mojo-dev list and see what the consensus is.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.