7 Replies Latest reply on Nov 15, 2007 2:47 PM by pgier

    Problems with maven

    bdaw

      I have few problem with maven in test and identity modules.

      The first one is that Identity module requires JBoss AS to run the tests (integration-test phase). So the situation is that I run AS with cargo in pre-integration-test phase and deploy OpenDS LDAP server. To do this I need to refer to its installation directory. At the moment I use ${env.JBOSS_HOME} but this requires JBOSS_HOME env to be set before doing 'mvn install'. Possible solutions and limitations:
      1) Current {enb.JBOSS_HOME} solution - problems are:
      - if the JBOSS_HOME env is not set the build will fail with some mess like '${JBOSS_HOME}' directory created somewhere... How could I check if the property is present and break the maven build with some nice help message? It should be possible to handle in it hudson with -DJBOSS_HOME=/... argument but I'm not sure how to prepare AS instance somewhere as hudson doesn't support shell script executions before maven goal invokation AFAIK.
      2) Use cargo ZIP installer - this will download JBoss AS zip distribution and unzip it locally. No presets are required to run the build but quite big zip file will be downloaded on the first run and installed somewhere in the home dir...

        • 1. Re: Problems with maven
          bdaw

          Second problem is much more weird and refers to maven plugin development.
          As was described in previous post I use cargo to deploy OpenDS LDAP server before identity tests are run. The tests are not run using surefire plugin but with our own jboss unit maven plugin. The plugin uses ant Java class (that handles 'java' task in ant) to invoke the tests. It gets proper classpath from MavenProject object using methods like:

          mavenProject.getCompileArtifacts()
          mavenProject.getTestArtifacts()
          mavenProject.getRuntimeArtifacts()
          mavenProject.getSystemArtifacts()
          mavenProject.getDependencyArtifacts()
          mavenProject.getTestResources()
          mavenProject.getTestClasspathElements()
          


          Normally it works perfectly. I started having problems when I decided to cleanup module dependencies and marked some of them with

          <scope>test</scope>


          This is important as when the identity module will be used in other project all such "not needed for compilation" libraries will also be downloaded and used in classpath. So with test scope the code above still returns proper classpath. This happens UNTIL I use cargo maven plugin.... So with cargo most off those dependencies are not present in my plugin classpath. If I don't use test scope for dependencies everything is fine.
          Any idea? Before I start to debug maven.... ;)



          • 2. Re: Problems with maven
            bdaw

            The story with cargo is really strange as I looked at its source code and I know that it also uses ant Java class to run the AS - and its forked mode.

            Also during plugin development I learned that when I run something with ant Java (forked) maven somehow eats whole output (System.out. stuff). Currently I use very lame workaround - create temporary file, set it as Java output and then print it...

            • 3. Re: Problems with maven
              pgier

               

              "bdaw" wrote:

              How could I check if the property is present and break the maven build with some nice help message?



              The maven enforcer plugin can check for a property and then fail if it's not there. http://maven.apache.org/plugins/maven-enforcer-plugin/rules/requireProperty.html

              • 4. Re: Problems with maven
                pgier

                 

                "bdaw" wrote:
                So with cargo most off those dependencies are not present in my plugin classpath. If I don't use test scope for dependencies everything is fine.
                Any idea? Before I start to debug maven.... ;)



                So the results of
                mavenProject.getTestClasspathElements()

                is different depending on whether you're using the cargo plugin or not? That seems strange. I guess you could look at the cargo source to see if/where it is modifying the test classpath. If there's nothing you can do to change cargo's behavior maybe you could add the dependencies you need for your plugin as plugin dependencies instead of project test dependencies.


                • 5. Re: Problems with maven
                  prabhat.jha

                  Can cargo's zip installer be used so that instead of downloading it, it copies it from NFS? This will be much faster and will serve our purpose as well.

                  Paul: This requirement will apply to other JBoss projects as well once they get mavenized for example AOP.

                  • 6. Re: Problems with maven
                    prabhat.jha

                    Paul, what I meant is that there will be other projects that would need to pull down JBoss AS, do some config changes before it run tests. It does not necessarily will be using cargo though.

                    • 7. Re: Problems with maven
                      pgier

                       

                      "prabhat.jha@jboss.com" wrote:
                      Can cargo's zip installer be used so that instead of downloading it, it copies it from NFS? This will be much faster and will serve our purpose as well.

                      Paul: This requirement will apply to other JBoss projects as well once they get mavenized for example AOP.


                      If the nfs share is mounted I'm assuming that it would work the same way as an http url. You would just use a file url instead.

                       <configuration>
                       <container>
                       <containerId>jboss4x</containerId>
                       <zipUrlInstaller>
                       <url>http://downloads.sourceforge.net/jboss/jboss-4.0.5.GA.zip</url>
                       <installDir>${user.home}/jboss</installDir>
                       </zipUrlInstaller>
                       </container>
                       <configuration>
                       <home>${project.build.directory}/jboss/server</home>
                       </configuration>
                       </configuration>