Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1309645279.253591266074547966.JavaMail.jira@brutus.apache.org>
Date: Sat, 13 Feb 2010 15:22:27 +0000 (UTC)
From: "Bryan Pendleton (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-4341) Building with ant all with a
 different CLASSPATH defined causes the build to fail
In-Reply-To: <1553815269.1249582274849.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-4341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12833400#action_12833400 ] 

Bryan Pendleton commented on DERBY-4341:
----------------------------------------

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.


> Building with ant all with a different CLASSPATH defined causes the build to fail
> ---------------------------------------------------------------------------------
>
>                 Key: DERBY-4341
>                 URL: https://issues.apache.org/jira/browse/DERBY-4341
>             Project: Derby
>          Issue Type: Bug
>          Components: Build tools
>    Affects Versions: 10.6.0.0
>            Reporter: Tiago R. Espinha
>
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.