Jetty

Allow run-exploded goal to pick up resource changes in src/main/webapp

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Not A Bug
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: Maven
  • Labels:
    None
  • Number of attachments :
    0

Description

The run goal of the maven-jetty-plugin automatically picks up changes in src/main/webapp automatically so that changes on JSPs, CSS and other stuff are available instantly after editing the files. Now suppose a scenario where we have to work with WAR overlays so that the central maven project is created by an overlay over another artifact. Running this scenario can be achieved with jetty:run-exploded easily. In this case the Jetty plugin assembles the app to deploy in target/$

{finalName}

by default. Thus Jetty runs with this path to lookup static resources. The problem is that changes to the static resources now don't get picked up as they only affect files in src/main/webapp.

So what I am looking for is a simple hot replacement of static resources in overlay projects as a redeploy or restart of the app is not necessary actually.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jan Bartel added a comment -

Oliver,

WIth jetty 6.1.20, you should be able to use mvn jetty:run with a webapp project that uses overlays. We look at the dependencies, and if they are war files, we add their resources into the webapp's resource base. So you should be able to change resources in src/main/webapp and pick them up without a redeploy. If, however, you change any of the war dependencies that would cause a redeploy.

Let me know if this works for you, if so, we can close this issue.

cheers
Jan

Show
Jan Bartel added a comment - Oliver, WIth jetty 6.1.20, you should be able to use mvn jetty:run with a webapp project that uses overlays. We look at the dependencies, and if they are war files, we add their resources into the webapp's resource base. So you should be able to change resources in src/main/webapp and pick them up without a redeploy. If, however, you change any of the war dependencies that would cause a redeploy. Let me know if this works for you, if so, we can close this issue. cheers Jan
Hide
Permalink
Oliver Gierke added a comment -

Hey Jan,

that sounds cool. I just tried it and it seems to fix this issue. Nevertheless I don't think I get around using run-exploded as the run goal assumes src/main/webapp as webapp root which causes subtle issues with the overlays:

We have a tag implemented to render HTML output to include all CSS files inside {{$

{webroot}

/css}} by invoking pageContext.getServletContext().getRealPath(CSS_FOLDER). While this points to already overlayed folder during run-exploded and thus includes resources served by dependants, using run only returns resources within src/main/resources which is understandable but breaks the way for us. Effectively this breaks direct resource access.

I tried to work around this issue by using the approach suggested here but I hardly want to hard code the path to these resources into the pom.

Regards,
Ollie

Show
Oliver Gierke added a comment - Hey Jan, that sounds cool. I just tried it and it seems to fix this issue. Nevertheless I don't think I get around using run-exploded as the run goal assumes src/main/webapp as webapp root which causes subtle issues with the overlays: We have a tag implemented to render HTML output to include all CSS files inside {{$ {webroot} /css}} by invoking pageContext.getServletContext().getRealPath(CSS_FOLDER) . While this points to already overlayed folder during run-exploded and thus includes resources served by dependants, using run only returns resources within src/main/resources which is understandable but breaks the way for us. Effectively this breaks direct resource access. I tried to work around this issue by using the approach suggested here but I hardly want to hard code the path to these resources into the pom. Regards, Ollie
Hide
Permalink
Jan Bartel added a comment -

Hi Oliver,

What about using ServletContext.getResourcePaths ("/css") ? Does that list out all of the css files that come from the overlayed wars as well as the one in src/main/webapp/css?

cheers
Jan

Show
Jan Bartel added a comment - Hi Oliver, What about using ServletContext.getResourcePaths ("/css") ? Does that list out all of the css files that come from the overlayed wars as well as the one in src/main/webapp/css? cheers Jan
Hide
Permalink
Oliver Gierke added a comment -

Hi Jan,

this solves the problem indeed. So for me this fixes the issue.

Regards,
Ollie

Show
Oliver Gierke added a comment - Hi Jan, this solves the problem indeed. So for me this fixes the issue. Regards, Ollie

People

  • Assignee:
    Jan Bartel
    Reporter:
    Oliver Gierke
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: