Derby
  1. Derby
  2. DERBY-4341

Building with ant all with a different CLASSPATH defined causes the build to fail

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.6.1.0
    • Fix Version/s: 10.6.1.0
    • Component/s: Build tools
    • Labels:
      None
    • Urgency:
      Normal
    • Issue & fix info:
      Newcomer, Workaround attached

      Description

      The problem happens when we are trying to compile the source code in a folder and have the CLASSPATH variable set to a different code tree folder. This results in compile failures like the following:

      runmessagecheck:
      [runMessageBundleTest] WARNING: Message id 22011.S.1 in messages_en.properties is not referenced in either SQLState.java or MessageId.java
      [runMessageBundleTest] WARNING: Message id 42Y03.S.0 in messages_en.properties is not referenced in either SQLState.java or MessageId.java
      [runMessageBundleTest] WARNING: Message id 42Y03.S.1 in messages_en.properties is not referenced in either SQLState.java or MessageId.java
      [runMessageBundleTest] WARNING: Message id 42Y03.S.2 in messages_en.properties is not referenced in either SQLState.java or MessageId.java

      BUILD FAILED
      /home/tiago/Desktop/DerbyStuff/CodeTenFiveTwo/build.xml:514: Message check failed.
      See error in build output or call ant runmessagecheck.

      Total time: 1 minute 11 seconds

      This should be an easy fix and it is marked as a bug, since it doesn't seem very logical for the compiling process to be CLASSPATH-dependent. Note that unsetting the CLASSPATH altogether allows the compile to run without errors, so clearly this variable isn't needed and shouldn't be used when it is set.

      1. derby-4341.patch
        2 kB
        John Storta Jr.

        Activity

        Hide
        Bryan Pendleton added a comment -

        Thanks Tiago for having a look at this. This problem has bitten me before as well, and it would be nice to have it fixed.

        Show
        Bryan Pendleton added a comment - Thanks Tiago for having a look at this. This problem has bitten me before as well, and it would be nice to have it fixed.
        Hide
        Mark B added a comment -

        for now I'll just add the detail

        $ ant -v runmessagecheck
        Apache Ant version 1.7.1 compiled on October 3 2008
        Buildfile: build.xml
        Detected Java version: 1.6 in: /usr/lib/jvm/java-6-sun-1.6.0.10/jre
        Detected OS: Linux
        parsing buildfile /home/mark/src/derbypristine/verypristine/build.xml with URI = file:/home/mark/src/derbypristine/verypristine/build.xml
        Project base dir set to: /home/mark/src/derbypristine/verypristine
        [antlib:org.apache.tools.ant] Could not load definitions from resource org/apache/tools/ant/antlib.xml. It could not be found.
        [property] Loading /home/mark/ant.properties
        [property] Unable to find property file: /home/mark/ant.properties
        [property] Loading /home/mark/src/derbypristine/verypristine/tools/ant/properties/dirs.properties
        Property "jdk" has not been set
        Property "sanity" has not been set
        [property] Loading /home/mark/src/derbypristine/verypristine/tools/ant/properties/sane$

        {sanity}.properties
        [property] Unable to find property file: /home/mark/src/derbypristine/verypristine/tools/ant/properties/sane${sanity}

        .properties
        [property] Loading /home/mark/src/derbypristine/verypristine/java/engine/state.properties
        Build sequence for target(s) `runmessagecheck' is [runmessagecheck]
        Complete build sequence is [runmessagecheck, checklocaleinfo, localeinfo, setInitialProperties, init, setissane, sanitynamesane, sanitynameinsane, setsanityname, junit-all-codeline-jars-set-properties, junit-init, junit-system-mini, junit-system-mini-codeline-jars, infowriter, toolsdocs, showenv, getstate, state, shared, parsers, engine, junit-sysinfo, getsvnversion, prebuild, setCompilerProperties, initjars, derbywar, include-in-javadoc, buildlocaleinfo, publishedapi-workhorse, ckversioninfo, writeversioninfo, versioninfo, emma-init, derbyjarwithosgi, localeinfowriter, junit-core, jdbc3stubs, clean, cleanstate, cleanparsers, cleanmessages, cleancatalog, cleantoursdb, clobber, snapshotError, snapshot, checksanenotset, state.exists, checkstateremoved, checkforpackagingfile, cleanalljars, cleandocs, cleansnapshot, cleanreleasefiles, prepareforrelease, junit-pptesting, checkCompilerLevel, jsr169stubs, jdbc4stubs, felixStubs, storeless, tools, drda, client, build, buildsource, vti-demo, demo, demodocs, cscuptodate, class_size_catalog, junit-jdbc4-workhorse, checkVMLevel, junit-jdbc4, junit-jmx, junit-lowmem, junit-all, insane, ensuresanitystate.insane, l10ncheck, derbyjar, derbytoolsjar, derbynetjar, derbyclientjar, derbyrunjar, derbylocalejars, ckderbytesting, derbytestingjar, buildjars, plugin, junit-clean, declare-autoloadable-driver, make-core-derbyjar-manifest, public-jdbc4-api, chkparser, genParser, testing, pptesting, all, publishedapi, derbydocs, grammardocs, testingdocs, javadoc, gump_all, junit-single, junit-single-codeline-jars, emma-instrumentation, emma-report, emma-all, localejar, evaluate.sane, sane, public-jdbc3-api, emma-single, printCompilerProperties, ensuresanitystate, ensuresanitystate.sane, cleanlocale, junit-html, junitreport, exclude-from-javadoc, engine_169_opt, emma-clean, meta-inf-common, cleanjars, cleanversion, junit-all-codeline-jars, make-locale-classpath-manifest, buildworld, dojjdocs, cibuild, buildjarsclean, ]

        runmessagecheck:
        [runMessageBundleTest] WARNING: Message id XCL17.S in messages_en.properties is not referenced in either SQLState.java or MessageId.java
        [runMessageBundleTest] WARNING: Message id 08000.S.1 in messages_en.properties is not referenced in either SQLState.java or MessageId.java
        [runMessageBundleTest] WARNING: Message id XJ102.S in messages_en.properties is not referenced in either SQLState.java or MessageId.java
        [runMessageBundleTest] WARNING: Message id J106 in messages_en.properties is not referenced in either SQLState.java or MessageId.java
        [runMessageBundleTest] WARNING: Message id 25000 in messages_en.properties is not referenced in either SQLState.java or MessageId.java
        [runMessageBundleTest] WARNING: Message id 22004.S.4 in messages_en.properties is not referenced in either SQLState.java or MessageId.java
        [runMessageBundleTest] WARNING: Message id 42Y03 in messages_en.properties is not referenced in either SQLState.java or MessageId.java

        BUILD FAILED
        /home/mark/src/derbypristine/verypristine/build.xml:514: Message check failed.
        See error in build output or call ant runmessagecheck.
        at org.apache.derbyBuild.MessageBundleTest.execute(MessageBundleTest.java:69)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
        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:597)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.Target.execute(Target.java:357)
        at org.apache.tools.ant.Target.performTasks(Target.java:385)
        at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
        at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
        at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
        at org.apache.tools.ant.Project.executeTargets(Project.java:1189)
        at org.apache.tools.ant.Main.runBuild(Main.java:758)
        at org.apache.tools.ant.Main.startAnt(Main.java:217)
        at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
        at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)

        Total time: 0 seconds

        Show
        Mark B added a comment - for now I'll just add the detail $ ant -v runmessagecheck Apache Ant version 1.7.1 compiled on October 3 2008 Buildfile: build.xml Detected Java version: 1.6 in: /usr/lib/jvm/java-6-sun-1.6.0.10/jre Detected OS: Linux parsing buildfile /home/mark/src/derbypristine/verypristine/build.xml with URI = file:/home/mark/src/derbypristine/verypristine/build.xml Project base dir set to: /home/mark/src/derbypristine/verypristine [antlib:org.apache.tools.ant] Could not load definitions from resource org/apache/tools/ant/antlib.xml. It could not be found. [property] Loading /home/mark/ant.properties [property] Unable to find property file: /home/mark/ant.properties [property] Loading /home/mark/src/derbypristine/verypristine/tools/ant/properties/dirs.properties Property "jdk" has not been set Property "sanity" has not been set [property] Loading /home/mark/src/derbypristine/verypristine/tools/ant/properties/sane$ {sanity}.properties [property] Unable to find property file: /home/mark/src/derbypristine/verypristine/tools/ant/properties/sane${sanity} .properties [property] Loading /home/mark/src/derbypristine/verypristine/java/engine/state.properties Build sequence for target(s) `runmessagecheck' is [runmessagecheck] Complete build sequence is [runmessagecheck, checklocaleinfo, localeinfo, setInitialProperties, init, setissane, sanitynamesane, sanitynameinsane, setsanityname, junit-all-codeline-jars-set-properties, junit-init, junit-system-mini, junit-system-mini-codeline-jars, infowriter, toolsdocs, showenv, getstate, state, shared, parsers, engine, junit-sysinfo, getsvnversion, prebuild, setCompilerProperties, initjars, derbywar, include-in-javadoc, buildlocaleinfo, publishedapi-workhorse, ckversioninfo, writeversioninfo, versioninfo, emma-init, derbyjarwithosgi, localeinfowriter, junit-core, jdbc3stubs, clean, cleanstate, cleanparsers, cleanmessages, cleancatalog, cleantoursdb, clobber, snapshotError, snapshot, checksanenotset, state.exists, checkstateremoved, checkforpackagingfile, cleanalljars, cleandocs, cleansnapshot, cleanreleasefiles, prepareforrelease, junit-pptesting, checkCompilerLevel, jsr169stubs, jdbc4stubs, felixStubs, storeless, tools, drda, client, build, buildsource, vti-demo, demo, demodocs, cscuptodate, class_size_catalog, junit-jdbc4-workhorse, checkVMLevel, junit-jdbc4, junit-jmx, junit-lowmem, junit-all, insane, ensuresanitystate.insane, l10ncheck, derbyjar, derbytoolsjar, derbynetjar, derbyclientjar, derbyrunjar, derbylocalejars, ckderbytesting, derbytestingjar, buildjars, plugin, junit-clean, declare-autoloadable-driver, make-core-derbyjar-manifest, public-jdbc4-api, chkparser, genParser, testing, pptesting, all, publishedapi, derbydocs, grammardocs, testingdocs, javadoc, gump_all, junit-single, junit-single-codeline-jars, emma-instrumentation, emma-report, emma-all, localejar, evaluate.sane, sane, public-jdbc3-api, emma-single, printCompilerProperties, ensuresanitystate, ensuresanitystate.sane, cleanlocale, junit-html, junitreport, exclude-from-javadoc, engine_169_opt, emma-clean, meta-inf-common, cleanjars, cleanversion, junit-all-codeline-jars, make-locale-classpath-manifest, buildworld, dojjdocs, cibuild, buildjarsclean, ] runmessagecheck: [runMessageBundleTest] WARNING: Message id XCL17.S in messages_en.properties is not referenced in either SQLState.java or MessageId.java [runMessageBundleTest] WARNING: Message id 08000.S.1 in messages_en.properties is not referenced in either SQLState.java or MessageId.java [runMessageBundleTest] WARNING: Message id XJ102.S in messages_en.properties is not referenced in either SQLState.java or MessageId.java [runMessageBundleTest] WARNING: Message id J106 in messages_en.properties is not referenced in either SQLState.java or MessageId.java [runMessageBundleTest] WARNING: Message id 25000 in messages_en.properties is not referenced in either SQLState.java or MessageId.java [runMessageBundleTest] WARNING: Message id 22004.S.4 in messages_en.properties is not referenced in either SQLState.java or MessageId.java [runMessageBundleTest] WARNING: Message id 42Y03 in messages_en.properties is not referenced in either SQLState.java or MessageId.java BUILD FAILED /home/mark/src/derbypristine/verypristine/build.xml:514: Message check failed. See error in build output or call ant runmessagecheck. at org.apache.derbyBuild.MessageBundleTest.execute(MessageBundleTest.java:69) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) 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:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:357) at org.apache.tools.ant.Target.performTasks(Target.java:385) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1189) at org.apache.tools.ant.Main.runBuild(Main.java:758) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) Total time: 0 seconds
        Hide
        John Storta Jr. added a comment -

        I was trying to look into this issue, but I think I am missing a key piece. I have performed the runmessagecheck target with both CLASSPATH set and with CLASSPATH unset. In both cases the build is successful and the messages are the same.

        Can you provide some additional information about how to duplicate this issue?

        Thanks

        Show
        John Storta Jr. added a comment - I was trying to look into this issue, but I think I am missing a key piece. I have performed the runmessagecheck target with both CLASSPATH set and with CLASSPATH unset. In both cases the build is successful and the messages are the same. Can you provide some additional information about how to duplicate this issue? Thanks
        Hide
        Bryan Pendleton added a comment -

        Hi John, thanks for investigating this! You can mark the issue as "assigned" to you,
        during the time you are studying it, so that others will know.

        This problem doesn't always occur, only sometimes.

        I think that it tends to occur under a scenario like this:
        1) You have successfully built a certain vesion of the source
        2) Your classpath points to the built version of the source
        3) You update your subversion client to a new revision which holds new messages
        4) You try to build, with you classpath still pointing to the old built jars,
        which do NOT refer to that message.

        So see if it helps to reproduce the problem, by adding some new messages to messages.xml
        in your client, and then see if you are able to run the message checking tragets
        with your classpath pointing at jars that don't hold those messages.

        Show
        Bryan Pendleton added a comment - Hi John, thanks for investigating this! You can mark the issue as "assigned" to you, during the time you are studying it, so that others will know. This problem doesn't always occur, only sometimes. I think that it tends to occur under a scenario like this: 1) You have successfully built a certain vesion of the source 2) Your classpath points to the built version of the source 3) You update your subversion client to a new revision which holds new messages 4) You try to build, with you classpath still pointing to the old built jars, which do NOT refer to that message. So see if it helps to reproduce the problem, by adding some new messages to messages.xml in your client, and then see if you are able to run the message checking tragets with your classpath pointing at jars that don't hold those messages.
        Hide
        John Storta Jr. added a comment -

        What seems to be the simple solution to this is to run ant with the -noclasspath option.

        $ ant -v runmessagecheck -noclasspath

        I can duplicate the issue and adding the -noclasspath option allows the runmessagecheck task to complete successfully, when it would fail otherwise.

        I am looking into a way to modify the build.xml so that it ignores a user's CLASSPATH. There are several options I have found, but none seem to have any effect on the results. Still looking.

        At this point there is a workaround (add the -noclasspath option), and I am still looking for a permanent solution.

        Show
        John Storta Jr. added a comment - What seems to be the simple solution to this is to run ant with the -noclasspath option. $ ant -v runmessagecheck -noclasspath I can duplicate the issue and adding the -noclasspath option allows the runmessagecheck task to complete successfully, when it would fail otherwise. I am looking into a way to modify the build.xml so that it ignores a user's CLASSPATH. There are several options I have found, but none seem to have any effect on the results. Still looking. At this point there is a workaround (add the -noclasspath option), and I am still looking for a permanent solution.
        Hide
        John Storta Jr. added a comment -

        I have been digging into this for a while and the more I read about ant the more it becomes clear that ant runs best when CLASSPATH is not set at all. The ant documentation has a whole section about the classpath.

        http://ant.apache.org/manual/install.html
        Section: "The CLASSPATH environment variable"

        The gist of it is that you should not run ant with CLASSPATH set. And if you do, you should run ant with the -noclasspath option as I had indicated in the workaround section.

        They also include the following code as something that you can add to your build.xml file to error out if the CLASSPATH is set.
        <property environment="env."/>
        <property name="env.CLASSPATH" value=""/>
        <fail message="Unset $CLASSPATH / %CLASSPATH% before running Ant!">
        <condition>
        <not><equals arg1="$

        {env.CLASSPATH}" arg2=""/></not>
        </condition>
        </fail>

        This essentially checks if your CLASSPATH is set and reports a relevant error message.

        I've tested it at the top of the build.xml and also within the runmessagecheck target. With this in place, the build will fail with a message indicating the problem and how to fix it, which is at least clearer than just getting errors about missing messages.

        Below is my modified version of the runmessagecheck target.
        <!-- Run the MessageBundleTest -->
        <target name="runmessagecheck">
        <property environment="env."/>
        <property name="env.CLASSPATH" value=""/>
        <fail message="Unset $CLASSPATH / %CLASSPATH% before running Ant!">
        <condition>
        <not><equals arg1="${env.CLASSPATH}

        " arg2=""/></not>
        </condition>
        </fail>

        <taskdef
        name="runMessageBundleTest"
        classname="org.apache.derbyBuild.MessageBundleTest"
        classpath="$

        {out.dir}

        "
        />
        <runMessageBundleTest/>
        </target>

        The test could also be put at the top of the build.xml if we want to fail out any time CLASSPATH is set rather than just from within this one target. I could see this same situation occurring with other targets and with it apparently never being a good idea to have the CLASSPATH set, we might want to avoid the case of getting additional bugs down the road as new targets exhibit the issue.

        In my opinion, the solution that matches what ant recommends is to update the documentation to reflect that ant should be run without the CLASSPATH set (or with the -noclasspath option)

        As a separate item, we can add the code I indicated to the appropriate place in build.xml to catch cases where it would fail so that a meaningful message is displayed. One thing to keep in mind if the build.xml is changed. If you have CLASSPATH set AND use the -noclasspath option, the code will still result in the fail since it does not check the -noclasspath option. I am seeing if there is a way to also test for the -noclasspath option.

        Show
        John Storta Jr. added a comment - I have been digging into this for a while and the more I read about ant the more it becomes clear that ant runs best when CLASSPATH is not set at all. The ant documentation has a whole section about the classpath. http://ant.apache.org/manual/install.html Section: "The CLASSPATH environment variable" The gist of it is that you should not run ant with CLASSPATH set. And if you do, you should run ant with the -noclasspath option as I had indicated in the workaround section. They also include the following code as something that you can add to your build.xml file to error out if the CLASSPATH is set. <property environment="env."/> <property name="env.CLASSPATH" value=""/> <fail message="Unset $CLASSPATH / %CLASSPATH% before running Ant!"> <condition> <not><equals arg1="$ {env.CLASSPATH}" arg2=""/></not> </condition> </fail> This essentially checks if your CLASSPATH is set and reports a relevant error message. I've tested it at the top of the build.xml and also within the runmessagecheck target. With this in place, the build will fail with a message indicating the problem and how to fix it, which is at least clearer than just getting errors about missing messages. Below is my modified version of the runmessagecheck target. <!-- Run the MessageBundleTest --> <target name="runmessagecheck"> <property environment="env."/> <property name="env.CLASSPATH" value=""/> <fail message="Unset $CLASSPATH / %CLASSPATH% before running Ant!"> <condition> <not><equals arg1="${env.CLASSPATH} " arg2=""/></not> </condition> </fail> <taskdef name="runMessageBundleTest" classname="org.apache.derbyBuild.MessageBundleTest" classpath="$ {out.dir} " /> <runMessageBundleTest/> </target> The test could also be put at the top of the build.xml if we want to fail out any time CLASSPATH is set rather than just from within this one target. I could see this same situation occurring with other targets and with it apparently never being a good idea to have the CLASSPATH set, we might want to avoid the case of getting additional bugs down the road as new targets exhibit the issue. In my opinion, the solution that matches what ant recommends is to update the documentation to reflect that ant should be run without the CLASSPATH set (or with the -noclasspath option) As a separate item, we can add the code I indicated to the appropriate place in build.xml to catch cases where it would fail so that a meaningful message is displayed. One thing to keep in mind if the build.xml is changed. If you have CLASSPATH set AND use the -noclasspath option, the code will still result in the fail since it does not check the -noclasspath option. I am seeing if there is a way to also test for the -noclasspath option.
        Hide
        Bryan Pendleton added a comment -

        Thanks for working on this problem, John!

        Can we run MessageBundleTest as a sub-process, using <java fork="true">,
        and would that allow us to ignore the parent process's CLASSPATH, if it was set?

        Show
        Bryan Pendleton added a comment - Thanks for working on this problem, John! Can we run MessageBundleTest as a sub-process, using <java fork="true">, and would that allow us to ignore the parent process's CLASSPATH, if it was set?
        Hide
        John Storta Jr. added a comment -

        Thanks Bryan.

        I modified the runmessagecheck target to fork a java process. Since this was no longer a taskdef running within the ant process, I had to modify the MessageBundleTest.java source so that it no longer extends org.apache.tools.ant.Task. This meant changing the execute method to a standard main method.

        I also changed it to throw a basic Exception rather than a org.apache.tools.ant.BuildException. Since it no longer runs in the ant environment, it does not have visibility to the ant classpath.

        Now when you run ant -v runmessagecheck, you get consistent results whether or not you have CLASSPATH set. I also tested it with and without an extra message.

        The only downside I see is that there are some extra lines of output, especially when it finds an extra message and throws the exception. The results seem to get lost in the output.

        I've attached a diff showing the changes I made from Revision 910374.

        I am new to all of this so if I am off in the weeds on my solution or not following the correct process for posting it, let me know.

        Show
        John Storta Jr. added a comment - Thanks Bryan. I modified the runmessagecheck target to fork a java process. Since this was no longer a taskdef running within the ant process, I had to modify the MessageBundleTest.java source so that it no longer extends org.apache.tools.ant.Task. This meant changing the execute method to a standard main method. I also changed it to throw a basic Exception rather than a org.apache.tools.ant.BuildException. Since it no longer runs in the ant environment, it does not have visibility to the ant classpath. Now when you run ant -v runmessagecheck, you get consistent results whether or not you have CLASSPATH set. I also tested it with and without an extra message. The only downside I see is that there are some extra lines of output, especially when it finds an extra message and throws the exception. The results seem to get lost in the output. I've attached a diff showing the changes I made from Revision 910374. I am new to all of this so if I am off in the weeds on my solution or not following the correct process for posting it, let me know.
        Hide
        Bryan Pendleton added a comment -

        Hi John,

        This seems like a promising approach to me.

        Can you attach an example of the output when MessageBundleTest finds problem,
        so we can see what it would look like when it occurs?

        Also, is the '-v' necessary in your solution? Or will MessageBundleTest catch the
        message problems with just 'ant runmessagecheck'?

        Show
        Bryan Pendleton added a comment - Hi John, This seems like a promising approach to me. Can you attach an example of the output when MessageBundleTest finds problem, so we can see what it would look like when it occurs? Also, is the '-v' necessary in your solution? Or will MessageBundleTest catch the message problems with just 'ant runmessagecheck'?
        Hide
        John Storta Jr. added a comment -

        Sorry about the -v. That was how it was specified in the original posting so that is what I was using in all of my testing. It does work without the -v, and the output is naturally much cleaner.

        Here is what the output shows if it finds a failure.
        $ ant runmessagecheck
        Buildfile: build.xml

        runmessagecheck:
        [java] WARNING: Message id 99999 in messages_en.properties is not referenced in either SQLState.java or MessageId.java
        [java] Exception in thread "main" java.lang.Exception: Message check failed.
        [java] See error in build output or call ant runmessagecheck.
        [java] at org.apache.derbyBuild.MessageBundleTest.main(MessageBundleTest.java:68)

        BUILD FAILED
        /public/dev/svnwork/derby/build.xml:513: Java returned: 1

        Total time: 0 seconds
        $

        If no issues, you get the following.
        $ ant runmessagecheck
        Buildfile: build.xml

        runmessagecheck:

        BUILD SUCCESSFUL
        Total time: 0 seconds
        $

        Outputs are the same regardless of whether or not the CLASSPATH is set.

        Show
        John Storta Jr. added a comment - Sorry about the -v. That was how it was specified in the original posting so that is what I was using in all of my testing. It does work without the -v, and the output is naturally much cleaner. Here is what the output shows if it finds a failure. $ ant runmessagecheck Buildfile: build.xml runmessagecheck: [java] WARNING: Message id 99999 in messages_en.properties is not referenced in either SQLState.java or MessageId.java [java] Exception in thread "main" java.lang.Exception: Message check failed. [java] See error in build output or call ant runmessagecheck. [java] at org.apache.derbyBuild.MessageBundleTest.main(MessageBundleTest.java:68) BUILD FAILED /public/dev/svnwork/derby/build.xml:513: Java returned: 1 Total time: 0 seconds $ If no issues, you get the following. $ ant runmessagecheck Buildfile: build.xml runmessagecheck: BUILD SUCCESSFUL Total time: 0 seconds $ Outputs are the same regardless of whether or not the CLASSPATH is set.
        Hide
        Bryan Pendleton added a comment -

        This seems like very reasonable behavior to me, and appears to address the principal concern
        of this issue as I understand it.

        Are you comfortable with the patch at this point? Do you feel it is complete?

        Show
        Bryan Pendleton added a comment - This seems like very reasonable behavior to me, and appears to address the principal concern of this issue as I understand it. Are you comfortable with the patch at this point? Do you feel it is complete?
        Hide
        John Storta Jr. added a comment -

        Yes. I cannot think of anything else that should be done with it. I think it addresses the reported problem with no side-effects that I have been able to find.

        I feel good about it and I think it is complete.

        Show
        John Storta Jr. added a comment - Yes. I cannot think of anything else that should be done with it. I think it addresses the reported problem with no side-effects that I have been able to find. I feel good about it and I think it is complete.
        Hide
        Bryan Pendleton added a comment -

        Great. I'll try to have a closer look at the patch in my environment, and
        unless I encounter any problems I'll try to commit it soon.

        Show
        Bryan Pendleton added a comment - Great. I'll try to have a closer look at the patch in my environment, and unless I encounter any problems I'll try to commit it soon.
        Hide
        Bryan Pendleton added a comment -

        Thanks John for the patch! Your change seems to work great
        in my environment, so I've committed it to the trunk as revision 911999.

        Show
        Bryan Pendleton added a comment - Thanks John for the patch! Your change seems to work great in my environment, so I've committed it to the trunk as revision 911999.
        Hide
        Knut Anders Hatlen added a comment -

        [bulk update] Close all resolved issues that haven't been updated for more than one year.

        Show
        Knut Anders Hatlen added a comment - [bulk update] Close all resolved issues that haven't been updated for more than one year.

          People

          • Assignee:
            John Storta Jr.
            Reporter:
            Tiago R. Espinha
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development