JSPs Cannot Be Compiled if They Depend on Tag Files

Yes, this is correct, the tag files would need compilation before the jsp compiler can compile against them. Please try the SNAPSHOT version of the jspc plugin to see if this is still an issue. There have been major changes to the SNAPSHOT version.

1.4.5 was released and I do not see this issue. Please check.

This doesnt work for me with 1.4.7-SNAPSHOT. It works if the taglib is defined as a separate artifact and my project depends on it, but not if my project defines the taglib itself.
(note that I'm using the patch in MJSPC-7 here, but I don't think it has any impact?)

Ha, if I move my tld from $

/WEB-INF/tld (where warSourceDirectory is src/main/resources instead of the default in my case) then it works. Seems like I should somehow have $

in jspc's classpath then ... ?

... that's not the case but my META-INF/foobar.tld is still in the classpath since it was copied by resources:resources - sorry for the noise - so it still doesn't work.

Please provide an example of the problem. If you can submit an attachment, then I can see the problem. ATM I cannot reproduce.

sorry, while trying to extract the problem into a simple example, I realized this was because some of our JSPs used the urn:jsptld:path to declare the taglib's namespace, and this, by spec, looks at WEB-INF/tld, which is not what we wanted anyways. Leaves me to wonder how it ever worked in case where we were doing stuff like xmlns:c="urn:jsptld:http://java.sun.com/jsp/jstl/core" but oh well, gotta fix this anyway.

Example where jspc precompilation does not work.

I just added an example where the jspc plugin fails - The zip has two modules with a parent pom. One module contains tags, the other a web app that uses those tags. If the modules do not have the parent relationship set up, the jsp precompilation works fine (the war gets the tlds installed in the local repository). The aggregated condition fails however.

Thanks for the example. I am having a bit of trouble getting this to run due to this:

Missing:
----------
1) taglibs:unstandard:jar:20050910

Does taglibs:unstandard:jar:20050910 even exist? Looking at the maven repo, it does not exist.

Revised example - without the dependencies on unstandard taglib. Sorry about that.

This actually looks like it may be a maven bug, not jspc-maven-plugin. The jspc plugin gets the classpath by asking for the $

. When run individually, by doing a mvn install -X to get the debug output, you will note all is correct:

/Users/mbp/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
/Users/mbp/.m2/repository/taglibs/standard/1.1.2/standard-1.1.2.jar
/Users/mbp/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
/Users/mbp/.m2/repository/tldtestapp/testexttld/1/testexttld-1.jar
/Users/mbp/.m2/repository/javax/servlet/jstl/1.1.2/jstl-1.1.2.jar]

In particular, it find your testexttld-1.jar. Now when run from the top level, it's classpath looks like the following:

/Users/mbp/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar
/Users/mbp/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar
/Users/mbp/.m2/repository/taglibs/standard/1.1.2/standard-1.1.2.jar
/Users/mbp/Desktop/jsp-example/TestTldProject/target/classes
/Users/mbp/.m2/repository/javax/servlet/jstl/1.1.2/jstl-1.1.2.jar]

Notice, it has no jar, but instead is using a path to the classed for the TestTldProject in /Users/mbp/Desktop/jsp-example/TestTldProject/target/classes.

This seems like a maven bug to me since the plugin is simply asking for the jar as a dependency. AFAICT, this needs to be opened on maven.

I opened an issue with the maven guys:

http://jira.codehaus.org/browse/MNG-2720

thanks Jeff -
so it fails because the tags aren't compiled to classes yet? Could this be resolved by precompiling the .tag files so they're in the classes directory, (then they'd be found there? not sure how a tag file class is looked up in this context.)

Nope...thats not it. Its a classpath thing. I tried changing the example to ensure the tag files are in the classes dir (through using the resources dir). The issue is it looks like jspc will only look for the tag files in a jar not a classes dir.

There really should be no reason why running maven from root would produce a different classpath/artifact selection than running them individually. After speaking with Brett on #maven, he said it "sounded like a bug".

the problem is simply that according to jsp specs tlds are loaded automatically only from jars in the classpath, and not from class folders (unexpanded tlds are only read in WEB-INF/lib or subdirectories).
When a project available in a multiproject build is used by another project in the same build maven directly references the project path instead of the installed jar.

This could probably be fixed using a manual dependency resolution (this is done for example in the eclipse plugin) or maybe from the jspc side by making tld files "virtually" deployed into WEB-INF/lib (I did this some time ago in order to make taglibrary projects directly usable in eclipse without deploying them. Such custom DirContext implementation is now available directly in tomcat 6 http://issues.apache.org/bugzilla/show_bug.cgi?id=41260 but I am not sure there is a way to use this when directly calling jspc).

I am in the same situation. My webapp has custom tags and the TLD is stored in the war project's src/main/resources. However, because the plugin searches only web.xml or the classpath, it fails.

This is a shot in the dark, but how packing (java.util.zip) anything found in the project's resource path, write the library to a temp directory, and including it?

FYI, it is evidently wrong to place TLD files in src/main/resources for the war project. This knowledge is based on the JSP spec and a discussion among Tomcat developers:

http://mail-archives.apache.org/mod_mbox/tomcat-dev/200401.mbox/%3C3FFB4883.20703@sun.com%3E

The short summary:
1) It is only necessary to place the TLD in META-INF if the project is a jar
2) For a war project, move the TLD into WEB-INF or some subdirectory thereof – but not /classes or /lib

When the spec and interpretation is followed, this plugin works as expected.

maven treats the target/classes directory as an exploded jar file in some circumstances, and while the above situation (mvn install includes classes directories) may be a bug, there may well be times when this is unavoidable.

for example, if you run mvn compile on a multi-module project (with the above tld problem) there will not be a jar file to reference, and maven will supply the target/classes directory onto the classpath instead.

the code in the jasper compiler (i think it is in the TldLocationsCache) only looks inside jar files, and i assume that will not change.

could we do something like make the plugin search for a jar file or create a temporary one instead?

I'm experiencing the reactor problem again, but this time with a function library (also declared in a tld)

Well; I'm not sure what's going on (or not), but actually the tags are not interpreted/compiled; i.e. in the generated java sources, I get stuff like
out.write("<foo:myTag bar=\"bleh\" ...

That was already the case with 1.4.7 apparently; am now using 2.0-alpha-1

I worked up a patch to fix this issue. For some reason, it resolves artifacts to the jar file that it just built, but the classpath entries resolve to 'target/classes.' Tested using Maven 2.0.8

Here's a simple patch to the 2.0-alpha-2-SNAPSHOT that use the workaround found here
https://issues.apache.org/bugzilla/show_bug.cgi?id=37084#c5

it adds a "cache" configuration parameter which one can set to false
the tags are then loaded successfully

please let me know if this is unclear

David's patch doesn't seem to help - at least in my case - but Kevin's just did ! Can we hope for an alpha-3 soonish ?
¨Thanks guys!

Or an alpha-4 ? Please ?

According to the maven guys... http://jira.codehaus.org/browse/MNG-2720 was fixed in Maven 2.10 (and later). Can I get this verified by some users of the plugin so that I may close this?

I'm running maven 2.0.10 with "[DEBUG] jspc-maven-plugin: resolved to version 2.0-alpha-3 from repository central" and have the issue : one module is a jar of a taglib, and I can compile JSPs when running maven from the webapp module, but it fails from the parent project. I've run with maven -X and indeed it uses the classes directory (instead of the jar when running form the module directory).

But it works with maven 2.2.1.

Fixed MJSPC-21.
This issue will be also fixed.