Mojo

New goal 'run', which starts an embedded tomcat

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: tomcat
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    1

Description

This patch adds a 'run' goal, which starts an embedded tomcat, using the project's classpath, and the src/main/webapp directory as context root. The advantage of this goal is that you don't need an installation of Tomcat, the mojo handles everything for you

Activity

Hide
Sam Wilson added a comment -

Has this patch been applied at all?

This functionality would be incredibly useful.

Show
Sam Wilson added a comment - Has this patch been applied at all? This functionality would be incredibly useful.
Hide
Matt Raible added a comment -

I'd love to see this patch applied, so it'd be possible to do "tomcat:run" like you do "jetty:run". I'd also like to see a run-war if possible, so merging WARs with the war-plugin works.

Show
Matt Raible added a comment - I'd love to see this patch applied, so it'd be possible to do "tomcat:run" like you do "jetty:run". I'd also like to see a run-war if possible, so merging WARs with the war-plugin works.
Hide
Valerio Schiavoni added a comment -

this patch is very useful to early evaluate the cross-application-server compatibility of your webapps. please apply it

Show
Valerio Schiavoni added a comment - this patch is very useful to early evaluate the cross-application-server compatibility of your webapps. please apply it
Hide
Mark Hobson added a comment -

Apologies for the inactivity, I'll try to find some time to apply the patch soon.

Show
Mark Hobson added a comment - Apologies for the inactivity, I'll try to find some time to apply the patch soon.
Hide
Mark Hobson added a comment -

Applied with changes, thanks!

I've opened MOJO-567 for tomcat:run-war.

Show
Mark Hobson added a comment - Applied with changes, thanks! I've opened MOJO-567 for tomcat:run-war.
Hide
Valerio Schiavoni added a comment -

i've just tested it (from the latest mojo snapshot). the new goal works just fine, but it introduces a minor problem (for me, at least): compiled classes and all the files needed to launch the applications are kept on the main sources tree. This causes a mix of sources and compiled class files in the same directory.

would it be possible to clean them on exit ?

Show
Valerio Schiavoni added a comment - i've just tested it (from the latest mojo snapshot). the new goal works just fine, but it introduces a minor problem (for me, at least): compiled classes and all the files needed to launch the applications are kept on the main sources tree. This causes a mix of sources and compiled class files in the same directory. would it be possible to clean them on exit ?
Hide
Mark Hobson added a comment -

I'm not sure I understand your scenario - which sources and classes are being mixed?

Show
Mark Hobson added a comment - I'm not sure I understand your scenario - which sources and classes are being mixed?
Hide
Valerio Schiavoni added a comment -

sorry Mark,
i've confused the files i was looking at as being part of the sources tree. please ignore my previous comment.

Show
Valerio Schiavoni added a comment - sorry Mark, i've confused the files i was looking at as being part of the sources tree. please ignore my previous comment.
Hide
Valerio Schiavoni added a comment -

ok, this is a concrete issue: using tomcat:run, the application is deployed in an 'anonymous' context, that is the finalName property (specified in the pom) is being ignored.
Even forcing it with:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>tomcat-maven-plugin</artifactId>
<configuration>
<path>/my-webapp</path>
</configuration>
</plugin>

once tomcat starts, the application is available at:
http://localhost:8080/index.jsp

and not
http://localhost:8080/my-webapp/index.jsp

as I was expecting. is this intended ? If so..why ?

Show
Valerio Schiavoni added a comment - ok, this is a concrete issue: using tomcat:run, the application is deployed in an 'anonymous' context, that is the finalName property (specified in the pom) is being ignored. Even forcing it with: <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>tomcat-maven-plugin</artifactId> <configuration> <path>/my-webapp</path> </configuration> </plugin> once tomcat starts, the application is available at: http://localhost:8080/index.jsp and not http://localhost:8080/my-webapp/index.jsp as I was expecting. is this intended ? If so..why ?
Hide
Mark Hobson added a comment -

Yep I noticed this too - this was how the original patch worked. I was going to add support for finalName and path soon. Is this a blocker for you right now?

Show
Mark Hobson added a comment - Yep I noticed this too - this was how the original patch worked. I was going to add support for finalName and path soon. Is this a blocker for you right now?
Hide
Valerio Schiavoni added a comment -

actually it is: i have some paths used by ajax invocation, and i hard-coded (poor me) the context name as part of the URL..

Show
Valerio Schiavoni added a comment - actually it is: i have some paths used by ajax invocation, and i hard-coded (poor me) the context name as part of the URL..
Hide
Mark Hobson added a comment -

Okay, I'll try to fix it sometime today for you.

Show
Mark Hobson added a comment - Okay, I'll try to fix it sometime today for you.
Hide
Mark Hobson added a comment -

Fixed and deployed - see new 'path' config param:

http://mojo.codehaus.org/tomcat-maven-plugin/run-mojo.html

Show
Mark Hobson added a comment - Fixed and deployed - see new 'path' config param: http://mojo.codehaus.org/tomcat-maven-plugin/run-mojo.html
Hide
Matt Raible added a comment -

Does this plugin have a scanInterval setting like the Jetty Plugin does?

<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<configuration>
<scanIntervalSeconds>3</scanIntervalSeconds>
</configuration>
</plugin>

Show
Matt Raible added a comment - Does this plugin have a scanInterval setting like the Jetty Plugin does? <plugin> <groupId>org.mortbay.jetty</groupId> <artifactId>maven-jetty-plugin</artifactId> <configuration> <scanIntervalSeconds>3</scanIntervalSeconds> </configuration> </plugin>
Hide
Mark Hobson added a comment -

Not yet, but feel free to open a new JIRA issue for this enhancement.

Show
Mark Hobson added a comment - Not yet, but feel free to open a new JIRA issue for this enhancement.
Hide
Valerio Schiavoni added a comment -

thanks mark, it works as expected now.

Show
Valerio Schiavoni added a comment - thanks mark, it works as expected now.
Hide
Sam Wilson added a comment -

Great work.

I had to jump through some hoops to be able to run my app against POJOs instead of EJBs when deployed this way. Now that I've got it working, things are so much easier.

Thanks for making it happen on this end. This will save me a ton of time.

Show
Sam Wilson added a comment - Great work. I had to jump through some hoops to be able to run my app against POJOs instead of EJBs when deployed this way. Now that I've got it working, things are so much easier. Thanks for making it happen on this end. This will save me a ton of time.
Hide
Martin Davidsson added a comment -

I'm having difficulties using this plugin with root context. I've tried the following 3 configurations

<path>/</path>
<path></path>
<path>ROOT</path>

The first one almost works. The server response at http://localhost:8080/ but any links on the page generated using the <c:url /> tag have an extra leading slash. For an example, <c:url value="/link"> will output "//link". Is there a way to get around this? Thanks

Show
Martin Davidsson added a comment - I'm having difficulties using this plugin with root context. I've tried the following 3 configurations <path>/</path> <path></path> <path>ROOT</path> The first one almost works. The server response at http://localhost:8080/ but any links on the page generated using the <c:url /> tag have an extra leading slash. For an example, <c:url value="/link"> will output "//link". Is there a way to get around this? Thanks

People

Vote (4)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: