Doing a build hierarchy resolution of dependencies at the validate is standard maven.
When a plugin runs, it will perform *another* dependency resolution that includes the entire project build hierarchy + plugin itself's downstream dependencies + any user configured plugin dependencies from the build hierarchy as well (all while taking scope of execution into account).
The jetty jspc maven plugin executes way down at the process-classes phase (this is declared in the jetty jspc maven plugin's metadata), the parent pom resolution will have occurred already at this point.
You can always see what the resolution is with the dependency plugin on the command line.
$ mvn dependency:tree
This incidentally runs at the validate phase (again, this phase is declared in the dependency tree's metadata)
Now, back to your situation, the dependencies that are not being found by the jetty jspc maven plugin, were those declared with default scope? or something else? (like system scope or provided or runtime?)
--
Developer advice, services and support
from the Jetty & CometD experts.
On Fri, Oct 5, 2012 at 7:09 AM, Gert-Jan van de Streek
<g.j.streek@xxxxxxxx> wrote:
Turns out that dependencies declared in a parent pom do not get found by jspc. Simply repeating them in the pom, or plugin dependencies works around that.
On Oct 5, 2012, at 3:23 PM, Gert-Jan van de Streek wrote:
The compiled jsp's however contain unresolved tags: <div><tiles:insertAttribute name="body" /></div>
The
tiles one obviously hurts the most. It resembles what is described in JETTY-1480, but I assume that was correctly merged for Jetty 8.
jetty version <jetty.version>8.1.7.v20120910</jetty.version>
jscp version same as jetty.version
Thanks,
Gert-Jan van de Streek
jetty-users mailing list
jetty-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-users
