Sure, it can be closed, I already commented on that :
https://issues.apache.org/jira/browse/JSPWIKI-651?focusedCommentId=13609060&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13609060
I don't care how the JIRA items are divided, just as long as we get them done.

Glen

On 04/04/2013 06:04 PM, Juan Pablo Santos Rodríguez wrote:
:-) we should update
http://incubator.apache.org/jspwiki/development/building.html to reflect
the (initial) maven support.

One last thing, I've just created a bunch of JIRAs related to maven
support, could we close JSPWIKI-651 right now?


cheers,
juan pablo

On Thu, Apr 4, 2013 at 11:47 PM, Glen Mazza <glen.ma...@gmail.com> wrote:

tomcat7:run-war seems to work fine with me!  I'm just about to update the
pom.xml w/some comments...


On 04/04/2013 04:50 PM, Glen Mazza wrote:

Great! I'll be looking at it soon.

You may wish to try mvn clean install tomcat7:run-war
-Dmaven.test.skip=true instead of tomcat7:run (I've never liked the latter,
it reads from the src and not the target directory). If a person on an
immediate SVN checkout can go to localhost:8080/jspwiki OOTB with mvn
tomcat:run-war without needing to set up a standalone Tomcat that would be
a nice simplifier for the project.

Glen

On 04/04/2013 04:44 PM, Juan Pablo Santos Rodríguez wrote:

both :-) the pity is that tomcat7:run isn't fine yet, it's assuming JSPs
are under src/main/webapp and some other things, but a mvn clean install
is
doable

I'm opening a few jiras regarding the mvn build and retargetting
JSPWIKI-651 as "initial maven support", so it can be closed after this
change and we can track maven support more easily (JSPWIKI-651 is
somewhat
bloated right now)


br,
juan pablo

On Thu, Apr 4, 2013 at 9:07 PM, Glen Mazza <glen.ma...@gmail.com> wrote:

  Which "problem", that of Jaxen bringing in a dozen or so
sub-dependencies
or the fact that the Maven WAR wasn't working properly OOTB as I had
mentioned below?  I had assumed you were talking about the former
problem,
which of course would be solved by making the dependency exclusions you
mentioned, but if you meant the latter, awesome!

Glen


On 04/04/2013 02:48 PM, Juan Pablo Santos Rodríguez wrote:

  Hi Glen,
was able to test, the problem went away when excluding the transitive
dependencies from jaxen. Haven't committed that change yet b/c still
need
to do some tests (have some issues with encoding, most probably
unrelated
to this issue, but I'd better check), so feel free to do it if you want

br,
juan pablo

On Wed, Apr 3, 2013 at 9:43 PM, Juan Pablo Santos Rodríguez <
juanpablo.san...@gmail.com> wrote:

   Hi Glen,

the precompile JSPs option is available through the *-tomcat targets
(line
1124 onwards) on build.xml, and are meant to enable running the webapp
with
only a JRE, instead of a JDK. They're not part of the main build, so
it
doesn't seem related to me.

The org.gjt.xpp seems odd to me though, where does it comes from
(maybe
the xerces jars)? Can you try specifying the jaxen dependency as:

           <dependency>
               <groupId>jaxen</groupId>
               <artifactId>jaxen</artifactId>
               <version>1.1-beta-6</version>
               <exclusions>
                 <exclusion>
                   <groupId>*</groupId>
                   <artifactId>*</artifactId>
                 </exclusion>
               </exclusions>
           </dependency>

to see if it helps? Right now I'm not on my pc so I'm unable to try it

HTH,
juan pablo


On Wed, Apr 3, 2013 at 12:00 AM, Glen Mazza <glen.ma...@gmail.com>
wrote:

   Hi folks, "mvn clean install" and "ant war" will now create nearly

identical WARs (differing only in the WEB-INF/lib folder) -- but ATM
only
the latter still works. I think it's something related to the
precompiled
JSPs (which the Maven WAR doesn't rely on presently, but I'm not sure
where
they are in the Ant WAR, so???)  When running the Mavenized version,
   the
JSPWiki log files are reporting:

2013-04-02 17:29:51,149 [http-bio-8080-exec-6] WARN
org.apache.wiki.tags.
**WikiTagBase JSPWiki:/JSPWiki/ 
JSPWiki:http://localhost:8080/****<http://localhost:8080/**>
**JSPWiki/ <http://localhost:8080/****JSPWiki/<http://localhost:8080/**JSPWiki/>
<http://localhost:**
8080/JSPWiki/ 
<http://localhost:8080/**JSPWiki/<http://localhost:8080/JSPWiki/>>>-
Including failed, got
a servlet exception from sub-page. Rethrowing the

exception to the JSP engine.
org.apache.jasper.******JasperException: <h3>Validation error
messages
from
TagLibraryValidator for fmt in /templates/default/UserBox.******
jsp</h3><p>null:

org.xml.sax.SAXParseException; lineNumber: 206; columnNumber: 15;
parsing
error: org.gjt.xpp.******XmlPullParserException: end tag name
should be

wiki:Translate not fmt:message at line 206 and column 15 seen
"...</jsp:text>\n</fmt:******message"... (parser state END_TAG)</p>
       at org.apache.jasper.compiler.*****
*DefaultErrorHandler.jspError(*****
*
DefaultErrorHandler.java:56)
       at org.apache.jasper.compiler.*****
*ErrorDispatcher.dispatch(**
ErrorDispatcher.java:410)
       at org.apache.jasper.compiler.*****
*ErrorDispatcher.jspError(**
ErrorDispatcher.java:75)

and

       at java.lang.Thread.run(Thread.******java:722)

2013-04-02 17:29:51,833 [http-bio-8080-exec-6] WARN
org.apache.wiki.tags.
**WikiTagBase JSPWiki:/JSPWiki/ 
JSPWiki:http://localhost:8080/****<http://localhost:8080/**>
**JSPWiki/ <http://localhost:8080/****JSPWiki/<http://localhost:8080/**JSPWiki/>
<http://localhost:**
8080/JSPWiki/ 
<http://localhost:8080/**JSPWiki/<http://localhost:8080/JSPWiki/>>>-
Including failed, got
a servlet exception from sub-page. Rethrowing the

exception to the JSP engine.
org.apache.jasper.******JasperException: java.lang.****
ClassNotFoundException:
org.apache.jsp.templates.******default_.UserBox_jsp
       at org.apache.jasper.servlet.******
JspServletWrapper.getServlet(******
JspServletWrapper.java:177)
       at org.apache.jasper.servlet.******
JspServletWrapper.service(**

JspServletWrapper.java:369)

The Mavenized version of http://localhost:8080/JSPWiki will still
activate but the front page text is not visible (only the headers and
footers show).  I'll look into this next but if anyone can see what's
immediately wrong with the Maven WAR (and optionally wants to fix
it),
please go ahead.

Another issue the WEB-INF/libs/*.JARs are mostly but not completely
identical between the Ant and Maven WARs because with Maven
dependency
resolution, additional JARs needed by those declared dependencies are
brought in (unless we explicitly exclude them) while our Ant scripts
will
not use JARs that we don't manually configure.  In particular the
Jaxen
dependency ends up bringing in 11 additional dependencies that the
Ant
build skips (upping the JAR count from 31 jars to 43), here are some
but
not all of them (you can see them by running mvn dependency:tree):

[INFO] +- jaxen:jaxen:jar:1.1-beta-6:******compile

[INFO] |  +- dom4j:dom4j:jar:1.5.2:compile
[INFO] |  |  \- jaxme:jaxme-api:jar:0.3:******compile
[INFO] |  +- xerces:xmlParserAPIs:jar:2.6.******2:compile
[INFO] |  +- xerces:xercesImpl:jar:2.4.0:******compile

[INFO] |  \- xom:xom:jar:1.0b3:compile
[INFO] |     +- com.ibm.icu:icu4j:jar:2.6.1:******compile

[INFO] |     +- xalan:xalan:jar:2.6.0:compile
[INFO] |     |  \- xml-apis:xml-apis:jar:1.0.b2:******compile
[INFO] |     \- org.ccil.cowan.tagsoup:******
tagsoup:jar:0.9.7:compile


Do we need Jaxen today in JSPWiki anyway?  I just see RPCHandlerTest
failing if I don't include it.  As I understand, Jaxen was best in
the
pre-JDK 5.0 days when there was no default XPath parser in the JDK.
  If
we
can rely on what the JDK supplies by default for XPath processing we
can
remove a lot of extra JARs from the Maven-built WAR.

Besides these, there are 4 more JARs that Maven is determining
necessary:
jakarta-regexp-1.4.jar used by lucene-queries,
lucene-queries used by lucene-highlighter, xpp3 used by sandler, and
xerces used by nekohtml.

Finally, IIRC we had earlier determined that Stripes was not needed
in
the WAR (it's just used during running the test cases), so I removed
it
from the "war" task in the Ant build.xml.  If I'm incorrect on this,
we
can
put it back in.

Regards,
Glen





Reply via email to