We've moved!
This site is now read-only. You can find our new documentation site and support forum for posting questions here.
Be sure to read our welcome blog!

Error in classpath for external builders

akiezunakiezun Cambridge, MAMember
edited August 2012 in Ask the GATK team

hi,
(this is on latest unstable). I'm getting a compile error for my external code. I traced it down to what seems to be an incorrect initialization external.gatk.classpath in build.xml that gets passed to external builders. The error seems to involve the wrong sequence of lib.dir creation and setting of external.dependencies.

    <path id="external.dependencies">
        <fileset dir="${lib.dir}" erroronmissingdir="false">
            <patternset refid="dependency.mask" />
        </fileset>
    </path> 

At this point lib.dir may not exist (after a clean). This issue seems to have been introduced when the initializing of external.dependencies was moved from the init task to the main project definition. What happens is that lib.dir is not set and so external.dependencies do not include the jars, so external.gatk.classpath does not include the jars, and so the external code does not get the jars on classpath and fails to compile. This used to work when the code was in init because there's an explicit mkdir in init.

Best Answer

  • droazendroazen Cambridge, MA ✭✭
    Accepted Answer

    As so often in the crazy world of ant, fixing one thing breaks another :) Thanks for the bug report and patch -- I've pushed this additional change into unstable, and hopefully external builds are now fully un-broken.

    Please let us know if you encounter additional problems, as external builds are not a feature we regularly use/test ourselves.

    David

Answers

  • droazendroazen Cambridge, MAMember, Broadie, Dev ✭✭

    Thanks for the report -- I'll look into this as soon as I get a chance and get back to you.

    David

  • droazendroazen Cambridge, MAMember, Broadie, Dev ✭✭

    I've pushed a patch into unstable that should resolve your issue -- please let me know if it doesn't. The solution was to use "path" instead of "pathconvert" to construct the external.gatk.classpath. That way the path can evolve as the build progresses, and it gets converted to a fixed property only at the last moment when the external build.xml is invoked.

    David

  • akiezunakiezun Cambridge, MAMember

    Thanks, this almost works (ie fixes gatk.classpath). It still fails though because now build.dir and dist.dir as visible from inside of the external build.xml are relative not absolute. When seems to be fixing the problem is the patch below.

    What the patch does is:
    1) use external.build.dist and external.dist.dir as paths as they used to be (they are properties in HEAD and it seems to not work)
    2) use refid to refer to them in both the gatk.compile.external.source and gatk.jar targets (the latter is missing currently from HEAD)

    Let me know if this makes sense (it may not).

    diff --git a/build.xml b/build.xml
    index 2ca48c5..11d3153 100644
    --- a/build.xml
    +++ b/build.xml
    @@ -70,10 +70,6 @@
         <property name="R.package.path" value="org/broadinstitute/sting/utils/R" />
         <property name="R.script.staging.dir" value="${build.dir}/R/stage" />
    
    -    <!-- Properties used for external builds -->
    -    <property name="external.build.dir" value="${java.classes}" />
    -    <property name="external.dist.dir" value="${dist.dir}" />
    -
         <!-- Packaging system properties -->
         <property name="package.xml.dir" value="${public.dir}/packages" />
         <property name="package.output.dir" value="${dist.dir}/packages" />
    @@ -211,6 +207,14 @@
             <include name="**/*.java" />
         </fileset>
    
    +     <path id="external.build.dir">
    +         <path path="${java.classes}"/>
    +     </path>
    +  
    +     <path id="external.dist.dir">
    +         <path path="${dist.dir}" />
    +     </path>
    +
         <!-- GATK dependencies consist of 3rd party plugins plus compiled GATK classes -->
         <path id="external.gatk.classpath">
             <path path="${java.classes}"/>
    @@ -425,8 +429,8 @@
    
         <target name="gatk.compile.external.source" depends="gatk.compile.internal.source" if="include.external">
             <subant target="compile" genericantfile="build.xml">
    -            <property name="build.dir" value="${external.build.dir}" />
    -            <property name="dist.dir" value="${external.dist.dir}" />
    +            <property name="build.dir" refid="external.build.dir" />
    +            <property name="dist.dir" refid="external.dist.dir" />
                 <property name="gatk.classpath" refid="external.gatk.classpath" />
                 <fileset dir="${external.dir}" includes="*/build.xml" erroronmissingdir="false" />
             </subant>
    @@ -675,9 +679,9 @@
             </jar>
    
             <subant target="dist" genericantfile="build.xml">
    -            <property name="build.dir" value="${external.build.dir}" />
    -            <property name="dist.dir" value="${external.dist.dir}" />
    -            <property name="gatk.classpath" value="${external.gatk.classpath}" />
    +            <property name="build.dir" refid="external.build.dir" />
    +            <property name="dist.dir" refid="external.dist.dir" />
    +            <property name="gatk.classpath" refid="external.gatk.classpath" />
                 <fileset dir="${external.dir}" includes="*/build.xml" erroronmissingdir="false" />
             </subant>
         </target>
    
  • droazendroazen Cambridge, MAMember, Broadie, Dev ✭✭
    Accepted Answer

    As so often in the crazy world of ant, fixing one thing breaks another :) Thanks for the bug report and patch -- I've pushed this additional change into unstable, and hopefully external builds are now fully un-broken.

    Please let us know if you encounter additional problems, as external builds are not a feature we regularly use/test ourselves.

    David

  • akiezunakiezun Cambridge, MAMember

    Works great now. Thanks!

Sign In or Register to comment.