Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.9.1
    • Component/s: Build system
    • Labels:

      Description

      Hello there, I was hoping to maybe one day contribute to the JSPWiki project and after having checked out the trunk code and played around somewhat I was thinking it would be very nice if this project used Maven.

      I'm sure most of you are familiar with Maven in one way or another, you might even have a really good reason for not doing this to JSPWiki.

      Update 04/04/2013: retargetting issue so Maven support can be easily tracked. The scope of this issue should include importing JSPWiki as Maven project and being able to deploy an OOTB war by doing an mvn clean install

      1. pom.xml
        16 kB
        Glen Mazza

        Activity

        Hide
        Janne Jalkanen added a comment -

        Personally, I think Maven is one of the most horrendous contraptions ever invented by humanity, but if someone else wants to do the work and agree to maintain it, go right ahead . The reason really is that nobody has yet really needed Maven for anything...

        (However, I've been playing with Apache Ivy quite a lot lately, and that seems much more approachable than Maven and it has really nice Ant integration.)

        Show
        Janne Jalkanen added a comment - Personally, I think Maven is one of the most horrendous contraptions ever invented by humanity, but if someone else wants to do the work and agree to maintain it, go right ahead . The reason really is that nobody has yet really needed Maven for anything... (However, I've been playing with Apache Ivy quite a lot lately, and that seems much more approachable than Maven and it has really nice Ant integration.)
        Hide
        Daniel Johansson added a comment -

        Fair enough, the main reason I brought this up was that I was looking at the current ant build script as I was trying to set up my development machine and I couldn't really figure out how to easily start the wiki up after compiling so I rewrote the war build target to copy all the content that's supposed to go into the war file into the build/war directory, then I added a context file for the wiki in my tomcat setup so now I can just build it and start tomcat without having to copy/extract the war file.

        There might be an easier way which I'm not aware of, the documentation said something about a build target called opened-war which doesn't exist.

        One idea I had in mind was, why not try to integrate Jetty into the war file so you could run the war file using a main class that starts up the Jetty server and deploys the content for you. Maven has a plugin for this which is really nice.

        I would be willing to maintain something like this however if another build system is preferred by the developers then Maven would be a step in the wrong direction.

        On another note, I've not looked into Ivy that much (yet), but I shall have a look at it.

        I just think the development phase needs to be simpler for the developer unless you could point me in the right direction on where I can find information on how to run the wiki locally and debug the source, I might just have missed this somewhere. Thanks.

        Show
        Daniel Johansson added a comment - Fair enough, the main reason I brought this up was that I was looking at the current ant build script as I was trying to set up my development machine and I couldn't really figure out how to easily start the wiki up after compiling so I rewrote the war build target to copy all the content that's supposed to go into the war file into the build/war directory, then I added a context file for the wiki in my tomcat setup so now I can just build it and start tomcat without having to copy/extract the war file. There might be an easier way which I'm not aware of, the documentation said something about a build target called opened-war which doesn't exist. One idea I had in mind was, why not try to integrate Jetty into the war file so you could run the war file using a main class that starts up the Jetty server and deploys the content for you. Maven has a plugin for this which is really nice. I would be willing to maintain something like this however if another build system is preferred by the developers then Maven would be a step in the wrong direction. On another note, I've not looked into Ivy that much (yet), but I shall have a look at it. I just think the development phase needs to be simpler for the developer unless you could point me in the right direction on where I can find information on how to run the wiki locally and debug the source, I might just have missed this somewhere. Thanks.
        Hide
        Janne Jalkanen added a comment -

        You have good points; it should be easier to get it deployed.

        One of the problems is that you need to modify jspwiki.properties after installation, and that can't be done if the whole thing is wrapped in a WAR. It would be nice if there was a simple way to do all that.

        (One of the chief problems with dependency management systems is that not all of our dependencies are available in Maven repos and the repos can get awfully messy [he said, having spent the entire morning trying to get Selenium to just resolve.])

        The best doc is at the root of the source directory in the file called "README".

        Show
        Janne Jalkanen added a comment - You have good points; it should be easier to get it deployed. One of the problems is that you need to modify jspwiki.properties after installation, and that can't be done if the whole thing is wrapped in a WAR. It would be nice if there was a simple way to do all that. (One of the chief problems with dependency management systems is that not all of our dependencies are available in Maven repos and the repos can get awfully messy [he said, having spent the entire morning trying to get Selenium to just resolve.] ) The best doc is at the root of the source directory in the file called "README".
        Hide
        Glen Mazza added a comment -

        quote: "One of the problems is that you need to modify jspwiki.properties after installation, and that can't be done if the whole thing is wrapped in a WAR. It would be nice if there was a simple way to do all that."

        Apache Roller (the WAR-based blogging software) has its admins place its roller-custom.properties configuration file in the common $CATALINA_HOME/lib folder while keeping the roller.war webapp the same for everybody. It's a nice design IMO--it allows users to deploy and undeploy new versions of the webapp without needing to tinker within the WAR to add in their config info.

        Show
        Glen Mazza added a comment - quote: "One of the problems is that you need to modify jspwiki.properties after installation, and that can't be done if the whole thing is wrapped in a WAR. It would be nice if there was a simple way to do all that." Apache Roller (the WAR-based blogging software) has its admins place its roller-custom.properties configuration file in the common $CATALINA_HOME/lib folder while keeping the roller.war webapp the same for everybody. It's a nice design IMO--it allows users to deploy and undeploy new versions of the webapp without needing to tinker within the WAR to add in their config info.
        Hide
        Juan Pablo Santos Rodríguez added a comment -

        jspwiki.properties can be placed outside the war, cfr. with JSPWIKI-660 and JSPWIKI-568, although you have to tinker a bit with either env or JAVA_OPTS variables.

        Show
        Juan Pablo Santos Rodríguez added a comment - jspwiki.properties can be placed outside the war, cfr. with JSPWIKI-660 and JSPWIKI-568 , although you have to tinker a bit with either env or JAVA_OPTS variables.
        Hide
        Glen Mazza added a comment -

        Starting Maven pom with the minimal dependencies necessary for JSPWiki's classes and test classes to compile.

        Show
        Glen Mazza added a comment - Starting Maven pom with the minimal dependencies necessary for JSPWiki's classes and test classes to compile.
        Hide
        Glen Mazza added a comment -

        The attached Maven pom can be placed in the JSPWiki home directory and the standard Maven commands "mvn clean", "mvn compile", and "mvn test-compile" (each one incorporating what the preceding command does) are now available. However, about 2/3rds of the test cases (called either via "mvn test" and "mvn package" which includes mvn test) are presently failing with this setup (632 out of 964 are failing). I had it down to just about 100 failures (mainly the web tests) yesterday but the latest API commits for some reason on my machine are causing JSPWiki to be unable to create org.apache.wiki.api.PluginManager (as done in WikiEngine, line 533)--despite heavy debugging I don't know what the problem is yet (the Ant tests still work though.) – probably a classpath issue.

        Also, by using mvn dependency:tree I was able to see which dependencies are transitive (brought in automatically by Maven without need for explicit declaration) and hence was able to remove about five dependencies in Maven pom.xml compared to what we need to have in the Ant file:

        [INFO] ------------------------------------------------------------------------
        [INFO] Building Apache JSPWiki (Incubating) 2.9.1-SNAPSHOT
        [INFO] ------------------------------------------------------------------------
        [INFO]
        [INFO] — maven-dependency-plugin:2.1:tree (default-cli) @ jspwiki —
        [INFO] org.apache.incubator:jspwiki:war:2.9.1-SNAPSHOT
        [INFO] +- xmlrpc:xmlrpc:jar:2.0.1:compile
        [INFO] +- org.apache.lucene:lucene-highlighter:jar:3.6.0:compile
        [INFO] | +- org.apache.lucene:lucene-core:jar:3.6.0:compile
        [INFO] | +- org.apache.lucene:lucene-memory:jar:3.6.0:compile
        [INFO] | - org.apache.lucene:lucene-queries:jar:3.6.0:compile
        [INFO] | - jakarta-regexp:jakarta-regexp:jar:1.4:compile
        [INFO] +- javax.servlet:servlet-api:jar:2.4:compile
        [INFO] +- net.sourceforge:sandler:jar:0.5:compile
        [INFO] | - xpp3:xpp3:jar:1.1.3.4-RC3:compile
        [INFO] +- opensymphony:oscache:jar:2.3:compile
        [INFO] +- oro:oro:jar:2.0.7:compile
        [INFO] +- javax.mail:mail:jar:1.4:compile
        [INFO] | - javax.activation:activation:jar:1.1:compile
        [INFO] +- log4j:log4j:jar:1.2.14:compile
        [INFO] +- javax.servlet.jsp:jsp-api:jar:2.0:compile
        [INFO] +- com.metaparadigm:json-rpc:jar:1.0:compile
        [INFO] +- org.jvnet.hudson:org.suigeneris.jrcs.diff:jar:0.4.2:compile
        [INFO] +- jdom:jdom:jar:1.0:compile
        [INFO] +- javax.servlet:jstl:jar:1.1.2:compile
        [INFO] +- org.freshcookies:freshcookies-security:jar:0.60:compile
        [INFO] +- ecs:ecs:jar:1.4.2:compile
        [INFO] +- commons-lang:commons-lang:jar:2.6:compile
        [INFO] +- commons-fileupload:commons-fileupload:jar:1.2.1:compile
        [INFO] +- net.sourceforge:akismet-java:jar:1.02:compile
        [INFO] | +- commons-codec:commons-codec:jar:1.3:compile
        [INFO] | - commons-logging:commons-logging:jar:1.0.4:compile
        [INFO] +- net.sourceforge.stripes:stripes:jar:1.5.7:compile
        [INFO] +- commons-httpclient:commons-httpclient:jar:3.1:compile
        [INFO] +- org.hsqldb:hsqldb:jar:1.8.0.10:test
        [INFO] +- tomcat:jasper-runtime:jar:5.5.23:test
        [INFO] | - commons-el:commons-el:jar:1.0:test
        [INFO] +- org.eclipse.jetty.aggregate:jetty-all:jar:7.6.7.v20120910:test
        [INFO] | - org.eclipse.jetty.orbit:javax.servlet:jar:2.5.0.v201103041518:test
        [INFO] +- junit:junit:jar:3.8.2:test
        [INFO] +- org.seleniumhq.selenium:selenium-java:jar:2.25.0:test
        [INFO] | +- org.seleniumhq.selenium:selenium-android-driver:jar:2.25.0:test
        [INFO] | | - org.seleniumhq.selenium:selenium-remote-driver:jar:2.25.0:test
        [INFO] | | +- cglib:cglib-nodep:jar:2.1_3:test
        [INFO] | | +- org.json:json:jar:20080701:test
        [INFO] | | - com.google.guava:guava:jar:12.0:test
        [INFO] | | - com.google.code.findbugs:jsr305:jar:1.3.9:test
        [INFO] | +- org.seleniumhq.selenium:selenium-chrome-driver:jar:2.25.0:test
        [INFO] | +- org.seleniumhq.selenium:selenium-htmlunit-driver:jar:2.25.0:test
        [INFO] | | +- org.seleniumhq.selenium:selenium-api:jar:2.25.0:test
        [INFO] | | +- net.sourceforge.htmlunit:htmlunit:jar:2.9:test
        [INFO] | | | +- commons-collections:commons-collections:jar:3.2.1:test
        [INFO] | | | +- org.apache.httpcomponents:httpmime:jar:4.1.2:test
        [INFO] | | | +- net.sourceforge.htmlunit:htmlunit-core-js:jar:2.9:test
        [INFO] | | | +- net.sourceforge.nekohtml:nekohtml:jar:1.9.15:test
        [INFO] | | | - net.sourceforge.cssparser:cssparser:jar:0.9.5:test
        [INFO] | | | - org.w3c.css:sac:jar:1.3:test
        [INFO] | | - org.apache.httpcomponents:httpclient:jar:4.1.2:test
        [INFO] | | - org.apache.httpcomponents:httpcore:jar:4.1.2:test
        [INFO] | +- org.seleniumhq.selenium:selenium-firefox-driver:jar:2.25.0:test
        [INFO] | | +- commons-io:commons-io:jar:2.0.1:test
        [INFO] | | - org.apache.commons:commons-exec:jar:1.1:test
        [INFO] | +- org.seleniumhq.selenium:selenium-ie-driver:jar:2.25.0:test
        [INFO] | | +- net.java.dev.jna:jna:jar:3.4.0:test
        [INFO] | | - net.java.dev.jna:platform:jar:3.4.0:test
        [INFO] | +- org.seleniumhq.selenium:selenium-iphone-driver:jar:2.25.0:test
        [INFO] | +- org.seleniumhq.selenium:selenium-safari-driver:jar:2.25.0:test
        [INFO] | +- org.seleniumhq.selenium:selenium-support:jar:2.25.0:test
        [INFO] | - org.webbitserver:webbit:jar:0.4.6:test
        [INFO] | - org.jboss.netty:netty:jar:3.2.7.Final:test
        [INFO] - jaxen:jaxen:jar:1.1-beta-6:test
        [INFO] +- dom4j:dom4j:jar:1.5.2:test
        [INFO] | - jaxme:jaxme-api:jar:0.3:test
        [INFO] +- xerces:xmlParserAPIs:jar:2.6.2:test
        [INFO] +- xerces:xercesImpl:jar:2.6.2:test
        [INFO] - xom:xom:jar:1.0b3:test
        [INFO] +- com.ibm.icu:icu4j:jar:2.6.1:test
        [INFO] +- xalan:xalan:jar:2.6.0:test
        [INFO] | - xml-apis:xml-apis:jar:1.0.b2:test
        [INFO] - org.ccil.cowan.tagsoup:tagsoup:jar:0.9.7:test
        [INFO] ------------------------------------------------------------------------
        [INFO] BUILD SUCCESS
        [INFO] ------------------------------------------------------------------------

        I also went through each of the dependencies, commenting them out and building to determine if any can be removed from our build.xml file (I didn't test such a compiled WAR, just did compilation) – the following Maven is reporting as unnecessary or miscategorized in our build.xml:

        Miscategorized:
        <dependency><groupId>net.sourceforge.stripes</groupId><artifactId>stripes</artifactId><version>1.5.7</version></dependency> is listed as a "test" dependency in our build.xml but is actually a main dependency (used by regular source code).

        Not needed: (at least for compilation and running of tests; would need to confirm with a WAR deployment):

        <!-dependency><groupId>commons-io</groupId><artifactId>commons-io</artifactId><version>1.4</version></dependency->
        <!-dependency><groupId>taglibs</groupId><artifactId>standard</artifactId><version>1.1.2</version></dependency->
        <!-dependency><groupId>jstl</groupId><artifactId>jstl</artifactId><version>1.1.2</version></dependency->
        <!-dependency><groupId>nekohtml</groupId><artifactId>nekohtml</artifactId><version>0.9.4</version></dependency->

        <!-dependency><groupId>org.dojotoolkit</groupId><artifactId>custom_rhino</artifactId><version>0.4.3</version><scope>test</scope></dependency->
        <!-dependency><groupId>tomcat</groupId><artifactId>jasper-compiler</artifactId><version>5.5.23</version><scope>test</scope></dependency->
        <!-dependency><groupId>xerces</groupId><artifactId>xercesImpl</artifactId><version>2.6.2</version><scope>test</scope></dependency->
        <!-dependency><groupId>xml-apis</groupId><artifactId>xml-apis</artifactId><version>1.0.b2</version><scope>test</scope></dependency->
        <!-dependency><groupId>com.yahoo.platform.yui</groupId><artifactId>yuicompressor</artifactId><version>2.4.7</version><scope>test</scope></dependency->

        If it is known already if any of these dependencies aren't being used it would be good to remove them from the Ant build.xml file.

        Possible next steps (if we wish to continue here):
        1.) Making the source more amenable to Mavenization: using the Standard Directory Layout (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html) (e.g., the source classes to src/main/java, webapp stuff in src/main/webapp, resources in src/main/resources; test classes to src/test/java, test resources in src/test/resources) – although it's simple in the pom to declare non-standard locations (already included).

        Also, do less configuration of our property files (jspwiki.properties) in the build.xml for our test cases, instead have an already created jspwiki.properties configured w/necessary test values that can be called by either Ant or Maven as-is.

        2.) Get the non-Web Test cases working (it's really mostly just that single PluginManager issue mentioned above that popped up above, that will fix about 80% of the failures).

        3.) Configure the commented-out Maven war plugin to create a WAR file that will work on Tomcat (not hard to do if the test cases are working, I can probably work on this). Having a WAR facilitates the web tests.

        4.) Separate the unit tests from the integration tests (add the -IT prefix to the latter, see the 2nd paragraph here: http://www.jroller.com/gmazza/entry/jersey_samples_on_cxf#jc2). The integration tests are the web tests that rely on an already created WAR. At this stage, all tests should be passing.

        5.) Incorporate the Rat reporting and Cobertura stuff (CXF's pom can be copied from here: http://svn.apache.org/viewvc/cxf/trunk/pom.xml?view=co&content-type=text%2Fplain).

        Anyway, we have a first step at least...

        Show
        Glen Mazza added a comment - The attached Maven pom can be placed in the JSPWiki home directory and the standard Maven commands "mvn clean", "mvn compile", and "mvn test-compile" (each one incorporating what the preceding command does) are now available. However, about 2/3rds of the test cases (called either via "mvn test" and "mvn package" which includes mvn test) are presently failing with this setup (632 out of 964 are failing). I had it down to just about 100 failures (mainly the web tests) yesterday but the latest API commits for some reason on my machine are causing JSPWiki to be unable to create org.apache.wiki.api.PluginManager (as done in WikiEngine, line 533)--despite heavy debugging I don't know what the problem is yet (the Ant tests still work though.) – probably a classpath issue. Also, by using mvn dependency:tree I was able to see which dependencies are transitive (brought in automatically by Maven without need for explicit declaration) and hence was able to remove about five dependencies in Maven pom.xml compared to what we need to have in the Ant file: [INFO] ------------------------------------------------------------------------ [INFO] Building Apache JSPWiki (Incubating) 2.9.1-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] — maven-dependency-plugin:2.1:tree (default-cli) @ jspwiki — [INFO] org.apache.incubator:jspwiki:war:2.9.1-SNAPSHOT [INFO] +- xmlrpc:xmlrpc:jar:2.0.1:compile [INFO] +- org.apache.lucene:lucene-highlighter:jar:3.6.0:compile [INFO] | +- org.apache.lucene:lucene-core:jar:3.6.0:compile [INFO] | +- org.apache.lucene:lucene-memory:jar:3.6.0:compile [INFO] | - org.apache.lucene:lucene-queries:jar:3.6.0:compile [INFO] | - jakarta-regexp:jakarta-regexp:jar:1.4:compile [INFO] +- javax.servlet:servlet-api:jar:2.4:compile [INFO] +- net.sourceforge:sandler:jar:0.5:compile [INFO] | - xpp3:xpp3:jar:1.1.3.4-RC3:compile [INFO] +- opensymphony:oscache:jar:2.3:compile [INFO] +- oro:oro:jar:2.0.7:compile [INFO] +- javax.mail:mail:jar:1.4:compile [INFO] | - javax.activation:activation:jar:1.1:compile [INFO] +- log4j:log4j:jar:1.2.14:compile [INFO] +- javax.servlet.jsp:jsp-api:jar:2.0:compile [INFO] +- com.metaparadigm:json-rpc:jar:1.0:compile [INFO] +- org.jvnet.hudson:org.suigeneris.jrcs.diff:jar:0.4.2:compile [INFO] +- jdom:jdom:jar:1.0:compile [INFO] +- javax.servlet:jstl:jar:1.1.2:compile [INFO] +- org.freshcookies:freshcookies-security:jar:0.60:compile [INFO] +- ecs:ecs:jar:1.4.2:compile [INFO] +- commons-lang:commons-lang:jar:2.6:compile [INFO] +- commons-fileupload:commons-fileupload:jar:1.2.1:compile [INFO] +- net.sourceforge:akismet-java:jar:1.02:compile [INFO] | +- commons-codec:commons-codec:jar:1.3:compile [INFO] | - commons-logging:commons-logging:jar:1.0.4:compile [INFO] +- net.sourceforge.stripes:stripes:jar:1.5.7:compile [INFO] +- commons-httpclient:commons-httpclient:jar:3.1:compile [INFO] +- org.hsqldb:hsqldb:jar:1.8.0.10:test [INFO] +- tomcat:jasper-runtime:jar:5.5.23:test [INFO] | - commons-el:commons-el:jar:1.0:test [INFO] +- org.eclipse.jetty.aggregate:jetty-all:jar:7.6.7.v20120910:test [INFO] | - org.eclipse.jetty.orbit:javax.servlet:jar:2.5.0.v201103041518:test [INFO] +- junit:junit:jar:3.8.2:test [INFO] +- org.seleniumhq.selenium:selenium-java:jar:2.25.0:test [INFO] | +- org.seleniumhq.selenium:selenium-android-driver:jar:2.25.0:test [INFO] | | - org.seleniumhq.selenium:selenium-remote-driver:jar:2.25.0:test [INFO] | | +- cglib:cglib-nodep:jar:2.1_3:test [INFO] | | +- org.json:json:jar:20080701:test [INFO] | | - com.google.guava:guava:jar:12.0:test [INFO] | | - com.google.code.findbugs:jsr305:jar:1.3.9:test [INFO] | +- org.seleniumhq.selenium:selenium-chrome-driver:jar:2.25.0:test [INFO] | +- org.seleniumhq.selenium:selenium-htmlunit-driver:jar:2.25.0:test [INFO] | | +- org.seleniumhq.selenium:selenium-api:jar:2.25.0:test [INFO] | | +- net.sourceforge.htmlunit:htmlunit:jar:2.9:test [INFO] | | | +- commons-collections:commons-collections:jar:3.2.1:test [INFO] | | | +- org.apache.httpcomponents:httpmime:jar:4.1.2:test [INFO] | | | +- net.sourceforge.htmlunit:htmlunit-core-js:jar:2.9:test [INFO] | | | +- net.sourceforge.nekohtml:nekohtml:jar:1.9.15:test [INFO] | | | - net.sourceforge.cssparser:cssparser:jar:0.9.5:test [INFO] | | | - org.w3c.css:sac:jar:1.3:test [INFO] | | - org.apache.httpcomponents:httpclient:jar:4.1.2:test [INFO] | | - org.apache.httpcomponents:httpcore:jar:4.1.2:test [INFO] | +- org.seleniumhq.selenium:selenium-firefox-driver:jar:2.25.0:test [INFO] | | +- commons-io:commons-io:jar:2.0.1:test [INFO] | | - org.apache.commons:commons-exec:jar:1.1:test [INFO] | +- org.seleniumhq.selenium:selenium-ie-driver:jar:2.25.0:test [INFO] | | +- net.java.dev.jna:jna:jar:3.4.0:test [INFO] | | - net.java.dev.jna:platform:jar:3.4.0:test [INFO] | +- org.seleniumhq.selenium:selenium-iphone-driver:jar:2.25.0:test [INFO] | +- org.seleniumhq.selenium:selenium-safari-driver:jar:2.25.0:test [INFO] | +- org.seleniumhq.selenium:selenium-support:jar:2.25.0:test [INFO] | - org.webbitserver:webbit:jar:0.4.6:test [INFO] | - org.jboss.netty:netty:jar:3.2.7.Final:test [INFO] - jaxen:jaxen:jar:1.1-beta-6:test [INFO] +- dom4j:dom4j:jar:1.5.2:test [INFO] | - jaxme:jaxme-api:jar:0.3:test [INFO] +- xerces:xmlParserAPIs:jar:2.6.2:test [INFO] +- xerces:xercesImpl:jar:2.6.2:test [INFO] - xom:xom:jar:1.0b3:test [INFO] +- com.ibm.icu:icu4j:jar:2.6.1:test [INFO] +- xalan:xalan:jar:2.6.0:test [INFO] | - xml-apis:xml-apis:jar:1.0.b2:test [INFO] - org.ccil.cowan.tagsoup:tagsoup:jar:0.9.7:test [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ I also went through each of the dependencies, commenting them out and building to determine if any can be removed from our build.xml file (I didn't test such a compiled WAR, just did compilation) – the following Maven is reporting as unnecessary or miscategorized in our build.xml: Miscategorized: <dependency><groupId>net.sourceforge.stripes</groupId><artifactId>stripes</artifactId><version>1.5.7</version></dependency> is listed as a "test" dependency in our build.xml but is actually a main dependency (used by regular source code). Not needed: (at least for compilation and running of tests; would need to confirm with a WAR deployment): <!- dependency><groupId>commons-io</groupId><artifactId>commons-io</artifactId><version>1.4</version></dependency -> <!- dependency><groupId>taglibs</groupId><artifactId>standard</artifactId><version>1.1.2</version></dependency -> <!- dependency><groupId>jstl</groupId><artifactId>jstl</artifactId><version>1.1.2</version></dependency -> <!- dependency><groupId>nekohtml</groupId><artifactId>nekohtml</artifactId><version>0.9.4</version></dependency -> <!- dependency><groupId>org.dojotoolkit</groupId><artifactId>custom_rhino</artifactId><version>0.4.3</version><scope>test</scope></dependency -> <!- dependency><groupId>tomcat</groupId><artifactId>jasper-compiler</artifactId><version>5.5.23</version><scope>test</scope></dependency -> <!- dependency><groupId>xerces</groupId><artifactId>xercesImpl</artifactId><version>2.6.2</version><scope>test</scope></dependency -> <!- dependency><groupId>xml-apis</groupId><artifactId>xml-apis</artifactId><version>1.0.b2</version><scope>test</scope></dependency -> <!- dependency><groupId>com.yahoo.platform.yui</groupId><artifactId>yuicompressor</artifactId><version>2.4.7</version><scope>test</scope></dependency -> If it is known already if any of these dependencies aren't being used it would be good to remove them from the Ant build.xml file. Possible next steps (if we wish to continue here): 1.) Making the source more amenable to Mavenization: using the Standard Directory Layout ( http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html ) (e.g., the source classes to src/main/java, webapp stuff in src/main/webapp, resources in src/main/resources; test classes to src/test/java, test resources in src/test/resources) – although it's simple in the pom to declare non-standard locations (already included). Also, do less configuration of our property files (jspwiki.properties) in the build.xml for our test cases, instead have an already created jspwiki.properties configured w/necessary test values that can be called by either Ant or Maven as-is. 2.) Get the non-Web Test cases working (it's really mostly just that single PluginManager issue mentioned above that popped up above, that will fix about 80% of the failures). 3.) Configure the commented-out Maven war plugin to create a WAR file that will work on Tomcat (not hard to do if the test cases are working, I can probably work on this). Having a WAR facilitates the web tests. 4.) Separate the unit tests from the integration tests (add the -IT prefix to the latter, see the 2nd paragraph here: http://www.jroller.com/gmazza/entry/jersey_samples_on_cxf#jc2 ). The integration tests are the web tests that rely on an already created WAR. At this stage, all tests should be passing. 5.) Incorporate the Rat reporting and Cobertura stuff (CXF's pom can be copied from here: http://svn.apache.org/viewvc/cxf/trunk/pom.xml?view=co&content-type=text%2Fplain ). Anyway, we have a first step at least...
        Hide
        Glen Mazza added a comment -

        Much better pom.xml that allows all the tests but one to pass (using mvn clean test); I'm just providing what I have in case others wish to add to it before I can resume improving it.

        Show
        Glen Mazza added a comment - Much better pom.xml that allows all the tests but one to pass (using mvn clean test); I'm just providing what I have in case others wish to add to it before I can resume improving it.
        Hide
        Juan Pablo Santos Rodríguez added a comment -

        Hi Glen,

        thanks a lot for the poms!

        At the very least, with all the dependencies listed in there, will allow us at least to upload jspwiki.jar and jspwiki.war to Apache's Nexus (and then Maven Central). I've run a mvn clean test and I've got a lot of test errors, but they fail with "Unable to locate test property resource: /jspwiki.properties" so most probably it's something you have placed in test/resources?

        Regarding the PluginManager issue, is it /ini/classmappings.xml on classpath? It took a me a while to realize this and add the appropiate entrance to .classpath, so the tests could run inside Eclipse. Take a look at ClassUtil, it is called at WikiEngine#initialize()

        I'm very interested on seeing the Maven integration. I haven't stopped at it because I'd preferred to modularize the source first, so when it comes to Maven it's a no-brainer to split the code in several modules, effectively having one jspwiki-api-VERSION.jar, jspwiki-plugins-VERSION.jar, etc.

        As for the layout of the project, in my experience with Maven the following structure has worked reasonible well:

        1.- builder.pom: builds all the project; includes all the <*management/> stuff except dependencies
        1.1.- dependencies 2 submodules (main dependencies and test dependencies) with the appropiate dependencies and dependenciesManagement sections, so we can refer to dependencies in the rest of the build with only groupId and artifactId:
        1.2.- main build: a pom with several sub-modules, for example
        1.2.1.- jspwiki-api
        1.2.2.- jspwiki-core
        1.2.3.- jspwiki-i18n
        1.2.4.- jspwiki-utils
        1.2.5.- jspwiki-plugins
        1.2.6.- jspwiki-test-infra (for TestWikiEngine and associateds)
        ...
        1.2.X.- jspwiki-war (includes all the former ones)
        1.2.X+1 - jspwiki-IT

        I think it would be easier to build up that structure and push the code in there rather than adapting the pom. WDYT?

        Show
        Juan Pablo Santos Rodríguez added a comment - Hi Glen, thanks a lot for the poms! At the very least, with all the dependencies listed in there, will allow us at least to upload jspwiki.jar and jspwiki.war to Apache's Nexus (and then Maven Central). I've run a mvn clean test and I've got a lot of test errors, but they fail with "Unable to locate test property resource: /jspwiki.properties" so most probably it's something you have placed in test/resources? Regarding the PluginManager issue, is it /ini/classmappings.xml on classpath? It took a me a while to realize this and add the appropiate entrance to .classpath, so the tests could run inside Eclipse. Take a look at ClassUtil, it is called at WikiEngine#initialize() I'm very interested on seeing the Maven integration. I haven't stopped at it because I'd preferred to modularize the source first, so when it comes to Maven it's a no-brainer to split the code in several modules, effectively having one jspwiki-api-VERSION.jar, jspwiki-plugins-VERSION.jar, etc. As for the layout of the project, in my experience with Maven the following structure has worked reasonible well: 1.- builder.pom: builds all the project; includes all the <*management/> stuff except dependencies 1.1.- dependencies 2 submodules (main dependencies and test dependencies) with the appropiate dependencies and dependenciesManagement sections, so we can refer to dependencies in the rest of the build with only groupId and artifactId: 1.2.- main build: a pom with several sub-modules, for example 1.2.1.- jspwiki-api 1.2.2.- jspwiki-core 1.2.3.- jspwiki-i18n 1.2.4.- jspwiki-utils 1.2.5.- jspwiki-plugins 1.2.6.- jspwiki-test-infra (for TestWikiEngine and associateds) ... 1.2.X.- jspwiki-war (includes all the former ones) 1.2.X+1 - jspwiki-IT I think it would be easier to build up that structure and push the code in there rather than adapting the pom. WDYT?
        Hide
        Glen Mazza added a comment -

        Hi Juan, please delete the older pom.xml so people don't accidentally use it. (I can't do so.) The newer one is much better in reducing the number of test errors (I just got one error, however some of the messages popping up indicates more configuration is needed--i.e., a lot more.)

        The plugin manager issue resolved itself – I think it was some strange classpath issue, but the new pom.xml takes care of it. In the original pom, I also failed to include the run-time resources during the tests (i.e., I just included the tests/etc and not the runtime etc.---see the <resources> and <testresources> tags) that fixed many of the problems.

        Show
        Glen Mazza added a comment - Hi Juan, please delete the older pom.xml so people don't accidentally use it. (I can't do so.) The newer one is much better in reducing the number of test errors (I just got one error, however some of the messages popping up indicates more configuration is needed--i.e., a lot more.) The plugin manager issue resolved itself – I think it was some strange classpath issue, but the new pom.xml takes care of it. In the original pom, I also failed to include the run-time resources during the tests (i.e., I just included the tests/etc and not the runtime etc.---see the <resources> and <testresources> tags) that fixed many of the problems.
        Hide
        Juan Pablo Santos Rodríguez added a comment -

        Hi Glen,

        I've deleted the pom from 15:10.

        I've also tried with the pom from 19:11 and still get the "Unable to locate test property resource: /jspwiki.properties" if I run it on a clean environment.

        However, if I make an "ant compile; mvn clean test" then I only get 21 failures (related to hsqldb), and 94 errors, most of them because "JSPWiki: Unable to load and setup properties from jspwiki.properties. Failed to start managers: java.io.IOException: Unable to find web.xml for processing."

        br,
        juan pablo

        Show
        Juan Pablo Santos Rodríguez added a comment - Hi Glen, I've deleted the pom from 15:10. I've also tried with the pom from 19:11 and still get the "Unable to locate test property resource: /jspwiki.properties" if I run it on a clean environment. However, if I make an "ant compile; mvn clean test" then I only get 21 failures (related to hsqldb), and 94 errors, most of them because "JSPWiki: Unable to load and setup properties from jspwiki.properties. Failed to start managers: java.io.IOException: Unable to find web.xml for processing." br, juan pablo
        Hide
        Glen Mazza added a comment -

        Yes, for code modularization, an excellent first step is to forget about Maven but still use the Maven standard directory format (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html) and then update the Ant build.xml to work with that new structure. At least with src/main/java, test/man/java, src/main/resources, test/main/resources (and for anything under the WEB-INF folder, src/main/webapp). This will make JSPWiki look like just about every other Mavenized project, making it easier for new people to jump in, knowing where everything is and realizing they can use the same Maven commands they use on other projects without needing to study a big build.xml file anymore.

        As for all those submodules, sure, sounds good! But you might wish to keep it simple right now with one pom.xml until we're off Ant (because others have to be brought up to speed with Maven), then put in submodules after that. Or do a hybrid... You understand the JWPWiki code a lot more than I do so you might be more comfortable jumping to submodules more quickly than I. The Apache CXF pom.xml has about as many bells and whistles as you can find, but you might want to take a look at the Apache Roller pom.xml & folder structure (http://svn.apache.org/viewvc/roller/trunk/), as it is also a Java web app like JSPWiki and was created by several skilled developers.

        Show
        Glen Mazza added a comment - Yes, for code modularization, an excellent first step is to forget about Maven but still use the Maven standard directory format ( http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html ) and then update the Ant build.xml to work with that new structure. At least with src/main/java, test/man/java, src/main/resources, test/main/resources (and for anything under the WEB-INF folder, src/main/webapp). This will make JSPWiki look like just about every other Mavenized project, making it easier for new people to jump in, knowing where everything is and realizing they can use the same Maven commands they use on other projects without needing to study a big build.xml file anymore. As for all those submodules, sure, sounds good! But you might wish to keep it simple right now with one pom.xml until we're off Ant (because others have to be brought up to speed with Maven), then put in submodules after that. Or do a hybrid... You understand the JWPWiki code a lot more than I do so you might be more comfortable jumping to submodules more quickly than I. The Apache CXF pom.xml has about as many bells and whistles as you can find, but you might want to take a look at the Apache Roller pom.xml & folder structure ( http://svn.apache.org/viewvc/roller/trunk/ ), as it is also a Java web app like JSPWiki and was created by several skilled developers.
        Hide
        Glen Mazza added a comment -

        Juan, two issues:
        1.) During testing, Maven adds the resources in the "runtime" (src/main/resources) to the resources in the "testtime" (src/test/resources) and I just declared them both (see my resources and testresources declarations under the <build> element, I don't know which jspwiki.properties is taking effect (presumably Maven would use the test one automatically). That's normally not a problem with Maven projects (run & test-time resources should be mergable just like run & test-time Java classes are) but that might cause an early hiccup with us, as we're not expecting the merging of run-time and test-time resources during testing.

        2.) The Ant build.xml does further configuration of the jspwiki.properties file prior to running the tests (propertiesfile task), Maven does not have this configuration, it's running that file raw. Your Ant compile may be helping because it causes those extra values to get into the jspwiki.properties file, that Maven is subsequently using. Two solutions: to create a fully populated test "jspwiki.properties" that is used as-is (either Maven or Ant) without additional elements added in by Ant, or: Maven always has an Ant Run plugin that can be used to call Ant build scripts (as well as include Ant targets if desired): http://maven.apache.org/plugins/maven-antrun-plugin/. The Ant Run plugin is usually a helpful crutch for projects in the process of Mavenizing but still have very complex functionality in Ant scripts that need to be used.

        Even if we never get to use Maven, it still helps in modularizing JSPWiki – Maven helps show which dependencies and resources we don't need and we can simplify the Ant build.xml as a result, also if we can stop doing the test file configuration in build.xml (as mentioned in #2 above) that also gives us more portability/independence across build tools.

        Show
        Glen Mazza added a comment - Juan, two issues: 1.) During testing, Maven adds the resources in the "runtime" (src/main/resources) to the resources in the "testtime" (src/test/resources) and I just declared them both (see my resources and testresources declarations under the <build> element, I don't know which jspwiki.properties is taking effect (presumably Maven would use the test one automatically). That's normally not a problem with Maven projects (run & test-time resources should be mergable just like run & test-time Java classes are) but that might cause an early hiccup with us, as we're not expecting the merging of run-time and test-time resources during testing. 2.) The Ant build.xml does further configuration of the jspwiki.properties file prior to running the tests (propertiesfile task), Maven does not have this configuration, it's running that file raw. Your Ant compile may be helping because it causes those extra values to get into the jspwiki.properties file, that Maven is subsequently using. Two solutions: to create a fully populated test "jspwiki.properties" that is used as-is (either Maven or Ant) without additional elements added in by Ant, or: Maven always has an Ant Run plugin that can be used to call Ant build scripts (as well as include Ant targets if desired): http://maven.apache.org/plugins/maven-antrun-plugin/ . The Ant Run plugin is usually a helpful crutch for projects in the process of Mavenizing but still have very complex functionality in Ant scripts that need to be used. Even if we never get to use Maven, it still helps in modularizing JSPWiki – Maven helps show which dependencies and resources we don't need and we can simplify the Ant build.xml as a result, also if we can stop doing the test file configuration in build.xml (as mentioned in #2 above) that also gives us more portability/independence across build tools.
        Hide
        Glen Mazza added a comment -

        Oh, for that issue "However, if I make an "ant compile; mvn clean test" then I only get 21 failures (related to hsqldb), and 94 errors, most of them because "JSPWiki: Unable to load and setup properties from jspwiki.properties. Failed to start managers: java.io.IOException: Unable to find web.xml for processing." that's because we don't have a WAR yet for testing – those are the web (integration) tests in item (4) in my posting at 15:42. If we can identify the tests which are web tests, and rename those with the "IT" extension, Maven will ignore them during unit testing (mvn test) but run them during later integration testing (mvn integration-test, see the links I provided at (4) above) once a WAR is created (using the commented-out maven-war-plugin in the pom). The Ant script would just need a minor tweaking to run tests that end with "IT" in addition to just "Test", so it will run as before. (We also should eventually upgrade the JUnit tests to JUnit 4, I don't know when that can be factored it.)

        Show
        Glen Mazza added a comment - Oh, for that issue "However, if I make an "ant compile; mvn clean test" then I only get 21 failures (related to hsqldb), and 94 errors, most of them because "JSPWiki: Unable to load and setup properties from jspwiki.properties. Failed to start managers: java.io.IOException: Unable to find web.xml for processing." that's because we don't have a WAR yet for testing – those are the web (integration) tests in item (4) in my posting at 15:42. If we can identify the tests which are web tests, and rename those with the "IT" extension, Maven will ignore them during unit testing (mvn test) but run them during later integration testing (mvn integration-test, see the links I provided at (4) above) once a WAR is created (using the commented-out maven-war-plugin in the pom). The Ant script would just need a minor tweaking to run tests that end with "IT" in addition to just "Test", so it will run as before. (We also should eventually upgrade the JUnit tests to JUnit 4, I don't know when that can be factored it.)
        Hide
        Juan Pablo Santos Rodríguez added a comment -

        Hi Glen,

        a lot of topics in last comments! My 0.02c:

        • IT's issue: I've misread, when you were talking about ITs I was thinking of the Selenium ones, duh
        • code modularization: my main concern on jumping to a Maven structure right now is that build.xml builds up a lot of generated files and sets up a lot of things, so it doesn't seem an easy task (the initial hiccups you mention). An equivalent pom.xml to the current build.xml is going to be real big (aside from the "usual", sonar, rat-report, precompiled-jsp-war, signing, hsql init & shutdown, generation of jspwiki.properties,..)
        • submodules: sonar's design page should give us some hints on what modules could emerge. I'm eager to jump into submodules as soon as possible becuase in my experience, having smaller submodules means having a ~30 lines pom + dependencies per module, which is way easier to manage than a big, customized, pom. Attaching to the Maven project layout should also help in minimizing the pom (i.e.: the clean ant target). If we end up with a ~1700 lines pom.xml then we're substituting one build system with another, but we're not making it more simple.

        Said that, I think you state a very good point, having a maven directory layout and a minimal pom (i.e.: default goals + container support) should ease the hop in. I'll definitely take a look at the CXF and Roller poms.

        @All: more opinions on this?

        Show
        Juan Pablo Santos Rodríguez added a comment - Hi Glen, a lot of topics in last comments! My 0.02c: IT's issue: I've misread, when you were talking about ITs I was thinking of the Selenium ones, duh code modularization: my main concern on jumping to a Maven structure right now is that build.xml builds up a lot of generated files and sets up a lot of things, so it doesn't seem an easy task (the initial hiccups you mention). An equivalent pom.xml to the current build.xml is going to be real big (aside from the "usual", sonar, rat-report, precompiled-jsp-war, signing, hsql init & shutdown, generation of jspwiki.properties,..) submodules: sonar's design page should give us some hints on what modules could emerge. I'm eager to jump into submodules as soon as possible becuase in my experience, having smaller submodules means having a ~30 lines pom + dependencies per module, which is way easier to manage than a big, customized, pom. Attaching to the Maven project layout should also help in minimizing the pom (i.e.: the clean ant target). If we end up with a ~1700 lines pom.xml then we're substituting one build system with another, but we're not making it more simple. Said that, I think you state a very good point, having a maven directory layout and a minimal pom (i.e.: default goals + container support) should ease the hop in. I'll definitely take a look at the CXF and Roller poms. @All: more opinions on this?
        Hide
        Janne Jalkanen added a comment -

        In the office we're using maven-ant-tasks to get the best of both worlds: we use Ant (and some custom Ant tasks) to provide packaging, distribution, etc; and Maven+WTP for a nice dev environment that just pretty much works out of the box.

        Using maven-ant-tasks in this case would also help, because you could just migrate things gradually (or as much as you like) from Ant to Maven...

        Show
        Janne Jalkanen added a comment - In the office we're using maven-ant-tasks to get the best of both worlds: we use Ant (and some custom Ant tasks) to provide packaging, distribution, etc; and Maven+WTP for a nice dev environment that just pretty much works out of the box. Using maven-ant-tasks in this case would also help, because you could just migrate things gradually (or as much as you like) from Ant to Maven...
        Hide
        Glen Mazza added a comment -

        Juan: "If we end up with a ~1700 lines pom.xml then we're substituting one build system with another, but we're not making it more simple."

        Not to worry, look at what presently has to be done to fire up Selenium w/Ant:
        http://svn.apache.org/viewvc/incubator/jspwiki/trunk/build.xml?revision=1420898&view=markup#l902

        And check the pom.xml at the bottom of here, using the Selenium Maven Plugin (providing we follow the Maven standard directory layout):
        http://mojo.codehaus.org/selenium-maven-plugin/examples/using-with-surefire.html

        Sleek...

        Show
        Glen Mazza added a comment - Juan: "If we end up with a ~1700 lines pom.xml then we're substituting one build system with another, but we're not making it more simple." Not to worry, look at what presently has to be done to fire up Selenium w/Ant: http://svn.apache.org/viewvc/incubator/jspwiki/trunk/build.xml?revision=1420898&view=markup#l902 And check the pom.xml at the bottom of here, using the Selenium Maven Plugin (providing we follow the Maven standard directory layout): http://mojo.codehaus.org/selenium-maven-plugin/examples/using-with-surefire.html Sleek...
        Hide
        Glen Mazza added a comment -

        Latest updated POM.

        Show
        Glen Mazza added a comment - Latest updated POM.
        Hide
        Glen Mazza added a comment -

        Hi latest changes to the pom (you may delete the older one--delete permissions aren't working for older JIRA items apparently):

        1.) Added in three dependencies with <scope>runtime</scope> – those used in deployment but not compilation (nekohtml, taglibs, commons-io).

        2.) Under <build>, refined the <resources> to exactly those that get placed in the JSPWiki.jar by the Ant build process.

        3.) Under <build>, refined the <testResources> to exactly those needed to run the unit tests.

        4.) Declared maven-surefire-plugin and placed the two failing tests (WikiEngineTest and AclImplTest) in exclusions for the time being. (Both look to be minor issues with the jspwiki.properties.)

        5.) Maven now creates a shell WAR with the necessary JARs and classes but none of the non-code resources yet. An upcoming step is to compare the Ant WAR vs. the Maven WAR and making sure they're identical.

        6.) In the shell WAR, Maven presently just copies the compiled JSPWiki classes and puts them under WEB-INF/classes instead of the Ant WAR which has lib/JSPWiki.jar. Either way should work, but the Ant way is cleaner. We'll probably need to move to multiple poms to first generate a JSPWiki.jar that can be placed into the JSPWiki.war.

        Right now, "mvn clean install" will run all the tests (except the two excluded above) and then create the WAR. However, one must run "ant tests" first so that the etc/WEB-INF/web.xml is created with the proper values. I think the next step for Mavenization is to create two additional concrete web.xmls (for unit and web tests) and have the Ant build script use them (instead of tweaking the production one), so we can have Maven use those concrete web.xmls as well. (Unless we want to use the maven-antrun-plugin and do all that modification in the pom.xmls--but I think just using separate web.xmls are cleaner.) Presently the Ant build script takes the web.xml for production and modifies it twice to create test and web-test versions.

        Show
        Glen Mazza added a comment - Hi latest changes to the pom (you may delete the older one--delete permissions aren't working for older JIRA items apparently): 1.) Added in three dependencies with <scope>runtime</scope> – those used in deployment but not compilation (nekohtml, taglibs, commons-io). 2.) Under <build>, refined the <resources> to exactly those that get placed in the JSPWiki.jar by the Ant build process. 3.) Under <build>, refined the <testResources> to exactly those needed to run the unit tests. 4.) Declared maven-surefire-plugin and placed the two failing tests (WikiEngineTest and AclImplTest) in exclusions for the time being. (Both look to be minor issues with the jspwiki.properties.) 5.) Maven now creates a shell WAR with the necessary JARs and classes but none of the non-code resources yet. An upcoming step is to compare the Ant WAR vs. the Maven WAR and making sure they're identical. 6.) In the shell WAR, Maven presently just copies the compiled JSPWiki classes and puts them under WEB-INF/classes instead of the Ant WAR which has lib/JSPWiki.jar. Either way should work, but the Ant way is cleaner. We'll probably need to move to multiple poms to first generate a JSPWiki.jar that can be placed into the JSPWiki.war. Right now, "mvn clean install" will run all the tests (except the two excluded above) and then create the WAR. However, one must run "ant tests" first so that the etc/WEB-INF/web.xml is created with the proper values. I think the next step for Mavenization is to create two additional concrete web.xmls (for unit and web tests) and have the Ant build script use them (instead of tweaking the production one), so we can have Maven use those concrete web.xmls as well. (Unless we want to use the maven-antrun-plugin and do all that modification in the pom.xmls--but I think just using separate web.xmls are cleaner.) Presently the Ant build script takes the web.xml for production and modifies it twice to create test and web-test versions.
        Hide
        Glen Mazza added a comment -

        Updated POM using Maven Ant Run plugin to bring in most of the necessary test resources (HSQL database still needs to be done, and possible property file filtering in the jspwiki.properties); mvn clean package now reports 18 failures and 51 errors without running "ant test" first; down to about 3 errors if "ant test" run first.

        Show
        Glen Mazza added a comment - Updated POM using Maven Ant Run plugin to bring in most of the necessary test resources (HSQL database still needs to be done, and possible property file filtering in the jspwiki.properties); mvn clean package now reports 18 failures and 51 errors without running "ant test" first; down to about 3 errors if "ant test" run first.
        Hide
        Glen Mazza added a comment -

        Updated pom.xml using the new hardcoded jdbc.properties file. More JDBC work still needed for "mvn clean package" to pass the tests.

        Show
        Glen Mazza added a comment - Updated pom.xml using the new hardcoded jdbc.properties file. More JDBC work still needed for "mvn clean package" to pass the tests.
        Hide
        Glen Mazza added a comment -

        <replace/> commands placed in Maven Antrun plugin to make configuration files more accurate.

        Show
        Glen Mazza added a comment - <replace/> commands placed in Maven Antrun plugin to make configuration files more accurate.
        Hide
        Glen Mazza added a comment -

        Updated pom.xml, mvn clean package now returns "Tests run: 942, Failures: 0, Errors: 16, Skipped: 0"

        Show
        Glen Mazza added a comment - Updated pom.xml, mvn clean package now returns "Tests run: 942, Failures: 0, Errors: 16, Skipped: 0"
        Hide
        Glen Mazza added a comment -

        Updated pom; JDBC tests now working. "mvn clean package" returns "Tests run: 942, Failures: 0, Errors: 1, Skipped: 0" (StressTests excluded however seem to work also when run.)

        Show
        Glen Mazza added a comment - Updated pom; JDBC tests now working. "mvn clean package" returns "Tests run: 942, Failures: 0, Errors: 1, Skipped: 0" (StressTests excluded however seem to work also when run.)
        Hide
        Glen Mazza added a comment -

        Updated pom. Tests still failing: StressTestSpeed (also with Ant build though), StressTestVersioningProvider (looks like a minor fix but I'm out of time right now for it.)

        Show
        Glen Mazza added a comment - Updated pom. Tests still failing: StressTestSpeed (also with Ant build though), StressTestVersioningProvider (looks like a minor fix but I'm out of time right now for it.)
        Hide
        Juan Pablo Santos Rodríguez added a comment -

        Hi Glen,

        the pom is looking real nice, what do you think about putting it in trunk?

        also, the tomcat plugin could be updated to the tomcat7 one, so we're then able to do something like http://tomcat.apache.org/maven-plugin-2.0/executable-war-jar.html

        br,
        juan pablo

        Show
        Juan Pablo Santos Rodríguez added a comment - Hi Glen, the pom is looking real nice, what do you think about putting it in trunk? also, the tomcat plugin could be updated to the tomcat7 one, so we're then able to do something like http://tomcat.apache.org/maven-plugin-2.0/executable-war-jar.html br, juan pablo
        Hide
        Glen Mazza added a comment -

        Sure, feel free to do so (as well as add to it...) or I will on Wednesday evening. Yes, we will certainly update to the Tomcat 7 plugin – my coworker has put in lots of changes in the upcoming 2.1 release of that plugin, we're just awaiting when he has time to release it. (We can use the current Tomcat 7 plugin, it's just much more limited than the upcoming 2.1 one.) We are at the "mvn clean package" or "mvn clean install" level – namely the tests are all running fine (may still be a hiccup in one or two of the Stress Test cases, I was unable to replicate today.)

        I think instead of tomcat:exec-war, tomcat:run-war is preferred because (1) it still uses an embedded Tomcat (no local tomcat needed) but (2) it uses the very same WAR that you would have if you deployed it on Tomcat standalone. But we can configure both.

        Upcoming Work (anybody, feel free to jump in where you'd like):
        1.) Populate the Maven war plugin defined in this pom.xml with the items needed for the WAR, to get something that can be placed on Tomcat. Goal: for the WAR that mvn clean installs to run OOTB on a standalone Tomcat (if not yet via tomcat:run-war).
        2.) Active the Selenium plugin to run the webtests (I think 1 before 2 here because I'm guessing Selenium on Maven will use the very same WAR that we output for deployment to Tomcat.)
        3.) Mavenize the project folder structure so we have less work to do in the maven-antrun-plugin, as well as needing to define nonstandard locations in the <build> (sourceDirectory, testSourceDirectory, and resources areas) – if we do any of this, the ant build.xml file will need to be reconfigured to the new locations so it continues to work.
        4.) (Eventually) Convert the tests to JUnit 4.x, and (I suspect) the web tests will have a new *IT.java naming to indicate they are integrated tests (i.e., run after a WAR is created) – I'm a little bit hazy here.
        5.) Maven Rat plugin added to pom.
        6.) Whatever Coburtura and other deployment stuff needs to be configured.
        7.) You had a more advanced folder structure you were thinking of moving to...

        Once the pom.xml is in the source repo, anytime we make a change to the build.xml – new dependencies, rearranging whatever, we will need to run "mvn clean install" after an "ant clean" just to check if the pom.xml also needs updating. The build.xml is still our official build until we retire it in favor of Maven.

        Show
        Glen Mazza added a comment - Sure, feel free to do so (as well as add to it...) or I will on Wednesday evening. Yes, we will certainly update to the Tomcat 7 plugin – my coworker has put in lots of changes in the upcoming 2.1 release of that plugin, we're just awaiting when he has time to release it. (We can use the current Tomcat 7 plugin, it's just much more limited than the upcoming 2.1 one.) We are at the "mvn clean package" or "mvn clean install" level – namely the tests are all running fine (may still be a hiccup in one or two of the Stress Test cases, I was unable to replicate today.) I think instead of tomcat:exec-war, tomcat:run-war is preferred because (1) it still uses an embedded Tomcat (no local tomcat needed) but (2) it uses the very same WAR that you would have if you deployed it on Tomcat standalone. But we can configure both. Upcoming Work (anybody, feel free to jump in where you'd like): 1.) Populate the Maven war plugin defined in this pom.xml with the items needed for the WAR, to get something that can be placed on Tomcat. Goal: for the WAR that mvn clean installs to run OOTB on a standalone Tomcat (if not yet via tomcat:run-war). 2.) Active the Selenium plugin to run the webtests (I think 1 before 2 here because I'm guessing Selenium on Maven will use the very same WAR that we output for deployment to Tomcat.) 3.) Mavenize the project folder structure so we have less work to do in the maven-antrun-plugin, as well as needing to define nonstandard locations in the <build> (sourceDirectory, testSourceDirectory, and resources areas) – if we do any of this, the ant build.xml file will need to be reconfigured to the new locations so it continues to work. 4.) (Eventually) Convert the tests to JUnit 4.x, and (I suspect) the web tests will have a new *IT.java naming to indicate they are integrated tests (i.e., run after a WAR is created) – I'm a little bit hazy here. 5.) Maven Rat plugin added to pom. 6.) Whatever Coburtura and other deployment stuff needs to be configured. 7.) You had a more advanced folder structure you were thinking of moving to... Once the pom.xml is in the source repo, anytime we make a change to the build.xml – new dependencies, rearranging whatever, we will need to run "mvn clean install" after an "ant clean" just to check if the pom.xml also needs updating. The build.xml is still our official build until we retire it in favor of Maven.
        Hide
        Juan Pablo Santos Rodríguez added a comment -

        latest attached pom.xml (26/Jan/13 15:28) has been added into trunk in 2.9.1-svn-24

        Show
        Juan Pablo Santos Rodríguez added a comment - latest attached pom.xml (26/Jan/13 15:28) has been added into trunk in 2.9.1-svn-24
        Hide
        Juan Pablo Santos Rodríguez added a comment -

        to properly open the project with m2e (at least with Indigo release), the following section should be added:

          <pluginManagement>
            <plugins>
              <!--This plugin's configuration is used to store Eclipse m2e settings only. It has no influence on the Maven build itself.-->
              <plugin>
                <groupId>org.eclipse.m2e</groupId>
                <artifactId>lifecycle-mapping</artifactId>
                <version>1.0.0</version>
                <configuration>
                  <lifecycleMappingMetadata>
                      <pluginExecutions>
                        <pluginExecution>
                          <pluginExecutionFilter>
                            <groupId>org.apache.maven.plugins</groupId>
                            <artifactId>maven-antrun-plugin</artifactId>
                            <versionRange>[1.7,)</versionRange>
                            <goals><goal>run</goal></goals>
                          </pluginExecutionFilter>
                          <action>
                            <ignore></ignore>
                          </action>
                        </pluginExecution>
                      </pluginExecutions>
                  </lifecycleMappingMetadata>
                </configuration>
              </plugin>
            </plugins>
          </pluginManagement>
        

        if that's ok I'll commit that tomorrow.

        On an aside, I think we can rename this issue to "initial Maven support" (closeable after the pluginManagement addition), and open a meta-JIRA to hold as many separate issues are needed to complete this task, they'll be easier to follow. What do you think?

        Show
        Juan Pablo Santos Rodríguez added a comment - to properly open the project with m2e (at least with Indigo release), the following section should be added: <pluginManagement> <plugins> <!--This plugin's configuration is used to store Eclipse m2e settings only. It has no influence on the Maven build itself.--> <plugin> <groupId> org.eclipse.m2e </groupId> <artifactId> lifecycle-mapping </artifactId> <version> 1.0.0 </version> <configuration> <lifecycleMappingMetadata> <pluginExecutions> <pluginExecution> <pluginExecutionFilter> <groupId> org.apache.maven.plugins </groupId> <artifactId> maven-antrun-plugin </artifactId> <versionRange> [1.7,) </versionRange> <goals> <goal> run </goal> </goals> </pluginExecutionFilter> <action> <ignore> </ignore> </action> </pluginExecution> </pluginExecutions> </lifecycleMappingMetadata> </configuration> </plugin> </plugins> </pluginManagement> if that's ok I'll commit that tomorrow. On an aside, I think we can rename this issue to "initial Maven support" (closeable after the pluginManagement addition), and open a meta-JIRA to hold as many separate issues are needed to complete this task, they'll be easier to follow. What do you think?
        Hide
        Glen Mazza added a comment -

        Hi Juan, your suggested plugin addition is fine. I don't use m2e, I always build from a command line window (mvn clean install) and use mvn eclipse:eclipse to import my project into Eclipse (http://www.jroller.com/gmazza/entry/web_service_tutorial#EclipseSetup) but there are many m2e users out there. So long as mvn clean install and mvn eclipse:eclipse still work from a command window, everything's OK. (Note the Eclipse project in general might not like Maven or Ant because the latter two tools provide easy IDE independence, so they might want to wiggle in requirements into the m2e plugin that, if taken, make it difficult to work with JSPWiki on IntelliJ or NetBeans or other IDEs--anything of that nature, if it comes up, we should try to avoid. Use of m2e should be an option, not a requirement.)

        I don't care how the tasks are chopped up into JIRA items, I just want to get build.xml deleted. I'll be leaving my company next Friday (Mar. 29th), so should have more time in the next few months to help out more here. Thanks!

        Show
        Glen Mazza added a comment - Hi Juan, your suggested plugin addition is fine. I don't use m2e, I always build from a command line window (mvn clean install) and use mvn eclipse:eclipse to import my project into Eclipse ( http://www.jroller.com/gmazza/entry/web_service_tutorial#EclipseSetup ) but there are many m2e users out there. So long as mvn clean install and mvn eclipse:eclipse still work from a command window, everything's OK. (Note the Eclipse project in general might not like Maven or Ant because the latter two tools provide easy IDE independence, so they might want to wiggle in requirements into the m2e plugin that, if taken, make it difficult to work with JSPWiki on IntelliJ or NetBeans or other IDEs--anything of that nature, if it comes up, we should try to avoid. Use of m2e should be an option, not a requirement.) I don't care how the tasks are chopped up into JIRA items, I just want to get build.xml deleted. I'll be leaving my company next Friday (Mar. 29th), so should have more time in the next few months to help out more here. Thanks!

          People

          • Assignee:
            Unassigned
            Reporter:
            Daniel Johansson
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development