1 2 Previous Next 26 Replies Latest reply: Oct 2, 2008 10:18 AM by Kabir Khan RSS

Some maven updates

Paul Gier Master

I'm planning to continue some work on the AOP mavenization tomorrow. I will be moving the PluggableInstrumentor class to it's own module, and using maven to compile classes and create the jars in the aop module. The testsuite will still be run using ant the same way as before, and you will still be able to build all the modules using the shell script (build.sh) or ant from the main build directory.

If this causes problems for anyone, please let me know.

  • 1. Re: Some maven updates
    Kabir Khan Master

    As long as the test classes still are compiled to output/tests.classes it should be fine. As far as I understand the tests will still be under control of ant?

    Does this mean that we won't have to use the buildmagic thirdparty plugin anymore when doing a release? That would be nice.

  • 2. Re: Some maven updates
    Paul Gier Master

    Yes, the test classes will still be compiled to the same place and you will still run the tests with ant just like before. And I'll make sure the tests are not affected before making the change.

    And yes I think I'll be able to remove the use of the buildmagic-thirdparty plugin from the release process.

  • 3. Re: Some maven updates
    Paul Gier Master

    While working on this, I came up with a few questions about how the AOP build is supposed to work. First, should the artifactId be "jboss-aop" or "jboss-aop-jdk50"? Currently, we have two different artifactIds representing the same artifact, so I would like to combine them into one. Since we don't have other artifacts with the jdk version in the id, I would prefer just "jboss-aop".

    I am a little confused by the setup of building the jrockit-pluggable-instrumentor.jar. In the ant build, there are three files included in this jar:
    JDK14Transformer.class
    JDK14TransformerManager.class
    JRockitPluggableClassPreProcessor.class

    All three of these files are also included in the jboss-aop-jdk50.jar file. Do these files need to be in both places? Can I move these files out into the new pluggable-instrumentor module?

  • 4. Re: Some maven updates
    Paul Gier Master

    Here is a summary of the changes to the aop build so far.

    The aop module is now built with maven, so running "mvn install" from the aop module directory will run this part of the build. Running the tests can still be done with "ant -f build-tests-jdk50.xml tests" after the maven build is run. It looks like ant is compiling the tests twice, is this intentional?

    The combined aop build can be run from the build directory can still be run using build.sh or build.bat.

    To compile the JRockit stuff you have to pass JROCKIT_HOME to maven. This can be done in the aop directory using

    mvn install -DJROCKIT_HOME=/path/to/jrockit

    or from the main build directory
    ./build.sh -Dbuild.maven.opts=-DJROCKIT_HOME=/path/to/jrockit


    I'm planning to move the asintegration and aspects modules to maven on Monday. That will allow the entire build (except for the testsuite) to be run from the root directory using "mvn install".


  • 5. Re: Some maven updates
    Kabir Khan Master

     

    "pgier" wrote:

    All three of these files are also included in the jboss-aop-jdk50.jar file. Do these files need to be in both places? Can I move these files out into the new pluggable-instrumentor module?


    EDITED:
    I think JRockitPluggableClassPreProcessor.class should be in jrockit-pluggable-instrumentor.jar (used with AS), while JDK14Transformer.class and JDK14TransformerManager.class should be in jboss-aop-jdk50.jar. Having said that, they might be needed in jrockit-pluggable-instrumentor.jar, but I would need to check since I don't remember how the classloading works for JRockit bootup (since I might have added those classes there for that reason). However, I cannot find a version of JRockit for my mac.


  • 6. Re: Some maven updates
    Kabir Khan Master

     

    "pgier" wrote:
    While working on this, I came up with a few questions about how the AOP build is supposed to work. First, should the artifactId be "jboss-aop" or "jboss-aop-jdk50"? Currently, we have two different artifactIds representing the same artifact, so I would like to combine them into one. Since we don't have other artifacts with the jdk version in the id, I would prefer just "jboss-aop".


    I agree there should be just one, jboss-aop sounds good.

  • 7. Re: Some maven updates
    Kabir Khan Master

    Doing a
    ./build.sh release
    from the build directory gives me compilation errors in the asintegration/ module.

    Running
    mvn install from the top-level folder gives me OutOfMemoryErrors

    [INFO] ------------------------------------------------------------------------
    [INFO] Building JBoss AOP Framework
    [INFO] task-segment: [install]
    [INFO] ------------------------------------------------------------------------
    [INFO] [enforcer:enforce {execution: enforce-versions}]
    [INFO] [resources:resources]
    [INFO] Using default encoding to copy filtered resources.
    [INFO] [compiler:compile]
    [INFO] Nothing to compile - all classes are up to date
    [INFO] [resources:testResources]
    [INFO] Using default encoding to copy filtered resources.
    [INFO] [compiler:testCompile]
    [INFO] Compiling 839 source files to /Users/kabir/sourcecontrol/jboss-aop/aop/target/test-classes
    [INFO] ------------------------------------------------------------------------
    [ERROR] BUILD FAILURE
    [INFO] ------------------------------------------------------------------------
    [INFO] Compilation failure
    Failure executing javac, but could not parse the error:
    
    
    The system is out of resources.
    Consult the following stack trace for details.
    java.lang.OutOfMemoryError: Java heap space
     at java.lang.Object.clone(Native Method)
     at com.sun.tools.javac.code.Scope.dupUnshared(Scope.java:122)
     at com.sun.tools.javac.comp.MemberEnter.methodEnv(MemberEnter.java:587)
     at com.sun.tools.javac.comp.MemberEnter.visitMethodDef(MemberEnter.java:552)
     at com.sun.tools.javac.tree.Tree$MethodDef.accept(Tree.java:478)
     at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:383)
     at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:395)
     at com.sun.tools.javac.comp.MemberEnter.finishClass(MemberEnter.java:405)
     at com.sun.tools.javac.comp.MemberEnter.finish(MemberEnter.java:953)
     at com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:920)
     at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355)
     at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:612)
     at com.sun.tools.javac.comp.Enter.complete(Enter.java:467)
     at com.sun.tools.javac.comp.Enter.main(Enter.java:445)
     at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:404)
     at com.sun.tools.javac.main.Main.compile(Main.java:592)
     at com.sun.tools.javac.main.Main.compile(Main.java:544)
     at com.sun.tools.javac.Main.compile(Main.java:85)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:585)
     at org.codehaus.plexus.compiler.javac.JavacCompiler.compileInProcess(JavacCompiler.java:420)
     at org.codehaus.plexus.compiler.javac.JavacCompiler.compile(JavacCompiler.java:141)
     at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:493)
     at org.apache.maven.plugin.TestCompilerMojo.execute(TestCompilerMojo.java:102)
     at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
     at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
     at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
     at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
     at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
     at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
    

    It works if I go into the aop/ folder and run mvn install there.

  • 8. Re: Some maven updates
    Kabir Khan Master

     

    "pgier" wrote:

    To compile the JRockit stuff you have to pass JROCKIT_HOME to maven.


    Does maven have the concept of a local.properties file? It would be nice not to manually pass in this system property every time

  • 9. Re: Some maven updates
    Kabir Khan Master

     

    "pgier" wrote:
    It looks like ant is compiling the tests twice, is this intentional?


    No :-) Once the build is a bit more stable I can take a look at that

  • 10. Re: Some maven updates
    Paul Gier Master

     

    "kabir.khan@jboss.com" wrote:
    "pgier" wrote:

    To compile the JRockit stuff you have to pass JROCKIT_HOME to maven.

    Does maven have the concept of a local.properties file? It would be nice not to manually pass in this system property every time

    There is a properties plugin that can be used to load properties, but I don't think this can be used to activate a profile (for the conditional compilation and jar). The other option would be to put the conditional logic in ant (in the antrun plugin) but I think the plugin only allows one target so you can't conditionally call the target. I'll try to come up with a better way to handle this part of the build.

    "kabir.khan@jboss.com" wrote:

    mvn install from the top-level folder gives me OutOfMemoryErrors

    It looks like you and Hudson are both getting this error when maven compiles the test classes. Since ant is doing this anyway, I'll take this part out for now and see if that prevents running out of memory.

    "kabir.khan@jboss.com" wrote:

    I think JRockitPluggableClassPreProcessor.class should be in jrockit-pluggable-instrumentor.jar

    Should JRockitClassPreProcessor also be included only in the jrockit jar? Currently it is only being included in the main jboss-aop.jar.


  • 11. Re: Some maven updates
    Kabir Khan Master

     

    "pgier" wrote:

    Should JRockitClassPreProcessor also be included only in the jrockit jar? Currently it is only being included in the main jboss-aop.jar.


    JRockitClassPreProcessor should be in the main jar for standalone apps.
    JRockitPluggableClassPreprocessor should be in jrockit-pluggable-instrumentor.jar for use with AS

  • 12. Re: Some maven updates
    Kabir Khan Master

    The following fails for me with the new build

    ./build.sh release -DJROCKIT_HOME=/Users/kabir/Java/libs/jrockit
    ...
    
    BUILD FAILED
    /Users/kabir/sourcecontrol/jboss-aop/build/build.xml:220: The following error occurred while executing this line:
    /Users/kabir/sourcecontrol/jboss-aop/build/build-release.xml:161: Warning: Could not find file /Users/kabir/sourcecontrol/jboss-aop/aop/output/lib/jrockit-pluggable-instrumentor.jar to copy.
    
    Total time: 1 minute 29 seconds
    


    There is no jrockit-pluggable-instrumentor.jar in either the aop or the pluggable-instrumentor modules. I assume that is because my JROCKIT_HOME is being ignored? I tried adding it to a build/local.properties file, but that did not work?

  • 13. Re: Some maven updates
    Paul Gier Master

    If you run the build from the main build directory you have to pass the parameter like this:

    ./build.sh -Dbuild.maven.opts=-DJROCKIT_HOME=/path/to/jrockit


    Otherwise it doesn't get through to the maven build.

  • 14. Re: Some maven updates
    Kabir Khan Master

     

    "pgier" wrote:
    If you run the build from the main build directory you have to pass the parameter like this:
    ./build.sh -Dbuild.maven.opts=-DJROCKIT_HOME=/path/to/jrockit


    Otherwise it doesn't get through to the maven build.

    I added a build/build-release.sh to avoid having to remember that :-)


1 2 Previous Next